Zarządzanie wymaganiami jest jednym z najważniejszych etapów procesu wytwórczego oprogramowania. Zaczyna cieszyć, że wielu organizacjach rola analityka jest coraz bardziej ważna. Jego udział w wielu projektach i inicjatywach jest już nieodzowny. Niestety wzrost obowiązków analityka nie idzie w parze ze wzrostem zatrudnienia. Zazwyczaj analityk jest zaangażowany w kilka projektów. Powstaje problem z dostarczaniem na czas produktów analizy. Powstaje problem z procesem wytwórczym oprogramowania.

Analityk ma do zrealizowania wiele zadań. Teoretycznie może je zrobić. Zazwyczaj mamy takie doświadczenia, że jeśli chcemy wykonać 10 zadań na raz, napotkamy wiele trudności. Głównym tego powodem jest strata czasu przy przechodzeniu z jednego zadania na drugie (koszt zmiany). Aby ograniczyć straty należy ograniczyć skakanie z jednego zadania na drugie – to automatycznie pomoże zaoszczędzić czas. Podniesie też jakość. Zbyt dużo otwartych zadań nie sprzyja szeroko rozumianej produktywności.

Gdy zadania są rozproszone warto jest skorzystać z jakiegoś sprawdzonego systemu. Takim systemem jest Kanbanie.

Czym jest Kanban?

To zbiór dobrych praktyk odnośnie zarządzania zadaniami. Wpiera proces wytwarzania. W IT stosuje się go do organizowania pracy zespołu. Zadaniami mogą być wymagania do zrealizowania, błędy do naprawienia, funkcjonalności do przetestowania, incydentami do przeanalizowania (np. w ITIL) lub innymi rzeczami do wykonania.

Kanban to nie metodyka. Nie mówi nam tak jak SCRUM, OPENUP czy RUP o tym kto i co powinien robić. Skupia się jedynie na tym, by zarządzanie zadaniami było przejrzyste i proste.

Tablica i karty zadań

Czego potrzebujesz, żeby zarządzać zadaniami wg Kanban? Tablicy i karteczek. Tablica może być fizyczna – wisząca na ścianie lub wirtualna. Każde zadanie ma swoją kartę zawierającą:

  • Nazwę zadania,
  • Opis zadania,
  • Termin realizacji,
  • Osobę odpowiedzialną za zadanie.

Możemy też przypisywać dodatkowe informacje.

Przykładowa wirtualna karta Kanban wygląda jak poniżej:

Analiza IT: Kanban

Kolumny

Kiedy już opiszesz zadanie w tej formie, umieszczasz je na tablicy. W jakim miejscu? Tablica podzielona jest na kolumny. Każda z nich symbolizuje kolejny etap realizacji zadania.

Proces wytwarzania oprogramowania można porównać do procesu w fabryce. Krok po kroku wykonujemy podobne czynności. Oczywiście nie musi oznaczać to kaskadowego wytwarzania oprogramowania. Bardziej patrzę na ten proces jak na działania w fabryce, gdzie na każdym stanowisku montażowym dokładana jest kolejna część.

kanban2

Typowe etapy na tablicy Kanban dla IT to:

  • Do zrobienia – zadania oczekują na podjęcie pracy,
  • Analiza
  • Programowanie
  • Testowanie
  • Zrobione

Przepływ na tablicy Kanban obserwujemy od lewej do prawej. W pierwszej lewej kolumnie czekają zawsze zadania do zrobienia.

Jak Kanban może pomóc analitykowi, a w przypadku rozszerzenia Kanban na cały zespół także w całym procesie wytwórczym.

Work in progress i buforowanie

Otóż Kanban poza wizualizacją zadań oferuje dwie doskonałe praktyki. Po pierwsze, aby praca analityka była produktywna mamy parametr WIP. Parametr WIP (ang. Work in Progress) określa pracę, która jest aktualnie wykonywana (a przynajmniej została rozpoczęta). W naszym przypadku WIP ogranicza nam ilość zadań, jakie możemy równocześnie realizować.

Ograniczenie liczby otwartych zadań zapewnia skupienie. A to przyśpieszy czas realizacji. Unikamy szamotania, czasochłonnego przełączania się i przypominania sobie o co chodziło.

Drugim mechanizmem jest buforowanie zadań. Buforowanie pozwala natychmiast zorientować się ile zadań czeka na analizę. Wizualizacja całego procesu obrazuje także ile zadań jest w trakcie realizacji i na jakim są etapie.

Kanban na potrzeby analizy

Zadaniem, patrząc pod kątem inżynierii oprogramowania, będzie przykładowo:

  • opis przypadku użycia
  • implementacja historyjki użytkownika
  • wykonanie testu akceptacyjnego

Patrząc na prace analityczne, przykładowe zadania to:

  • analiza wymagań biznesowych dla zmiany CR.YYY
  • przygotowanie procesu biznesowego dla procesu X (AS-IS)
  • przygotowanie dokumentu: specyfikacja wymagań dla zmiany CR.YYX

Przykładowa tablica Kanban ze szczególnym uwzględnieniem analiz może wyglądać w następujący sposób. Poza buforem i limitem WIP na tablicy analityka znalazły się, wyrażone wierszami, projekty, w których uczestniczy.

Analiza IT: Kanban

Przesuwanie zadań

Zwróć uwagę, że w fazie analizy w trakcie prac mogą być otwarte tylko dwa zadania. Co więcej, w momencie, gdy zadanie będące „W trakcie przeglądu u interesariuszy” wróci z uwagami to nie jest przenoszone do kolumny „W trakcie prac” (nie rzucamy się do jego wykonywania), ale trafia do kolumny „Oczekuje”, gdzie czeka na swoją kolejność.

Każde zdanie, które zostanie zrealizowane tj. w przypadku omawianego przykładu – zdobyły akceptację interesariuszy, trafia do fazy programowania do kolumny „Oczekuje”.

Główne zalety Kanban

Kanban jest systemem skalowalnym. Swoim zasięgiem może objąć zarówno wiele projektów jak i uwzględnić specyfikę pracy nie tylko analityka, ale także programisty, testera czy też innego członka zespołu wytwarzającego oprogramowanie. To uniwersalne narzędzie.

To co wyróżnia Kanban to limity (WIP) które, stanowią istotną różnicę pomiędzy tablicą Kanban a innymi tablicami typu storyboard. Ograniczenie ilości otwartych zadań (WIP) na każdym etapie procesu zapobiega nadprodukcji oraz szybko wykrywa wąskie gardła. Można im zapobiec zanim wymkną się spod kontroli. Zastosowanie Kanban sprzyja przejrzystości całego procesu wytwórczego oprogramowania. Jedno spojrzenie na tablicę i widzisz, na jakim etapie jest praca.

Więcej na temat Kanban można znaleźć na stronie: https://www.michalwolski.pl/kanban

Michał Wolski
Od ponad dekady zajmuję się szeroko rozumianą inżynierią oprogramowania. Specjalizuję się w modelowaniu procesów biznesowych, architekturze korporacyjnej, zarządzaniu wymaganiami oraz projektowaniu systemów informatycznych. Prowadziłem także projekty w metodykach zwinnych takich jak SCRUM czy Agile Modeling. Na co dzień używam Enterprise Architect'a firmy Sparx Systems. Modeluję stosując notację UML, BPMN, ArchiMate. Narzędzia CASE i notację uzupełniam dobrymi praktykami oferowanymi przez Rational Unified Process, Essential Unified Process, SCRUM, Agile Modeling oraz TOGAF. W swojej pracy zawodowej pełniłem role analityka, projektanta, Scrum Mastera, kierownika projektu, zamawiającego, trenera, coacha oraz konsultanta. Moimi klientami były małei duże oraz ogromne firmy, które reprezentowały sektory: finansów, ubezpieczeń, bankowości, energetyki, logistyki oraz publiczny.

ZOSTAW ODPOWIEDŹ