Postanowiłem końcówkę 2016 ogłosić na moim blogu rokiem Agile. Listopad i grudzień poza wpisami dotyczącymi Scrum będzie dostarczał wiedzy na temat Kanban.
Niniejszy artykuł otwiera cykl tekstów na temat Kanban. O Kanban pisałem już w 2014. Te wpisy traktuję jako odświeżenie i uzupełnienie tematu. Planuję 7-8 tekstów na ten temat, które będę co tydzień publikował.
Zacznijmy od początku. Czym jest Kanban?
Moim zdaniem najlepiej definicja kanban została wyjaśniona w książce M. Hammarberg, J Sunden pt.:”Kanban”, Wydawnictwo Helion 2015:
Kanban, kanban czy systemy kanban?
Jeżeli dokładnie przyjrzysz się tekstowi, zobaczysz, że kanban piszemy z małej litery. Społeczność kanban wciąż się zmienia i ewoluuje, tak więc wszystko ulega zmianie.
Aktualną wiedzę zinterpretowaliśmy tak:
Metoda Kanban (duże K) — metoda kreowania zmian ewolucyjnych w organizacji, którą sformułował i opisał w książce Kanban: Successful Evolutionary Change for Your Technology Business (Blue Hole Press, 2010,) David J. Anderson.
Kanban (czasami małe k, czasami duże K) — niekiedy odnosi się do „wizualnego systemu zarządzania procesem, określającego, co, kiedy i w jakiej ilości produkować” (tak przynajmniej było ostatnim razem, kiedy sprawdzaliśmy w Wikipedii), a czasami do samego sygnału wizualnego.
System kanban — system stworzony do śledzenia aktualnie wykonywanej pracy.
Przykładem może być tablica kanban, karty i ustalenia związane z pracą. To wszystko składa się na system kanban. W teorii te rzeczy mają bardzo różne znaczenie, jednak w praktyce ludzie ze społeczności często ich nie rozróżniają. Kiedy ludzie odnoszą się do terminu „używanie kanban”, przeważnie mają na myśli korzystanie z jakiegoś systemu kanban do zarządzania i optymalizowania sygnałów wizualnych w celu ewolucyjnej poprawy procesu. Właśnie to mamy na myśli, kiedy używamy słowa kanban.
Kanban w IT to metoda obsługi zadań przez zespół. Zadania mogą być zarówno wymaganiami w klasycznym rozumieniu przy rozwoju oprogramowania jak i również błędami, zgłoszeniami incydentów (np. w ramach ITIL) czy innymi zdaniami dla IT.
Sam kanban nie jest metodyką wytwarzania oprogramowania. Nie jest podobny do SCRUM, OPENUP czy RUP. Kanban nie skupia się na rolach i produktach.
Kanban skupia się na na usprawnieniu procesu.
Kanban nakłada się na istniejący proces wytwórczy i wymaga wyłącznie przestrzegania trzech podstawowych zasad:
- Wizualizuj swój przepływ
- Ogranicz swoją pracę cząstkową
- Zarządzaj przepływem
Wizualizuj swoją pracę
Pierwsza zasada to przedstawienie zadania w formie wizualnej. Może to być karteczka samoprzylepna albo obiekt w narzędziu elektronicznym. Uwidocznienie zadania, które wcześniej były gdzieś ukryte, pomaga rozwiązać wiele problemów.
Uwidocznienie zadania pozwala zobaczyć na jakim etapie jest praca w procesie. Przyjmij przepływ pracy przez następujące etapy: wymagania, projekt, budowa, test jednostkowy, testy, akceptacja testów, wdrażanie. Wizualizacja pracy pokaże na jakim etapie jest każda z funkcji. Jedno spojrzenie na tablicę Kanban i dowiesz się, na jakim etapie jest twoja praca. Wizualizacja pracy pomoże również zidentyfikować straty w procesie, które możesz zredukować lub wyeliminować. Pomoże Ci również zidentyfikować wąskie gardła zanim staną się prawdziwym zagrożeniem. Szukanie wąskich gardeł opiszę w kolejnym poście za kilka tygodni.
Ogranicz swoją pracę cząstkową
Druga zasada to kwintesencja wszystkich zasad zarządzania czasem/zadaniami. W każdej ze znanych mi podejść czy to GTD, POMODORO itp jest jedna zasada. W danym czasie wykonuj tylko jedno zadanie.
W ramach Kanban dopuszcza się większą liczbę zadań. Określa to parametr WIP czyli wskaźnik, który mówi o tym nad iloma zadaniami możesz pracować w danym momencie. Limit WIP to pewne ograniczenie, ale ograniczenie to pozwoli określić ile zadań „tak naprawdę” jesteś w stanie zrobić. Twoim ograniczonym zasobem jest czas. W danym momencie na tzw.” tapecie” możesz mieć otwartych kilka zadań. W danym momencie pracuj nad jednym zadaniem.
Zarządzaj przepływem
Trzecia zasada związana z zarządzaniem przepływem to reagowanie na prędkość zespołu. Innymi słowy przepływ pracy przez tablicę będzie zwalniał (zadania będą przesuwane wolniej), zacznie się blokować (wiele zadań będzie w tym samym miejscu) lub całkowicie się zatrzyma (zadania będą czekały). Pracując z Kanban trzeba nieustannie obserwować prędkość zespołu by w porę wyłapać możliwość zatrzymania procesu. Czasem trzeba zmienić parametr WIP, czasem dołożyć rąk do pracy.
Poza wspomnianymi zasadami warto jeszcze pamiętać o ustalaniu jasnych zasad dotyczących pracy. Sama tablica wizualizuje przepływ pracy. Już określenie zasad kolumn to pierwsza zasada. Kluczowe określenie jest też, jakie statusy mogą przyjmować zadania. Jak muszą być przygotowane lub wykonane zadania by można je przekazać dalej. Zasady te to wskazówki do działania. Czasem, po wewnętrznych konsultacjach, trzeba je „nagiąć” na chwilę lub zmienić na stałe.
Podsumowując, Kanban nie musi zmieniać istniejącego procesu. Może on być realizowany w istniejącym procesie wytwórczym oprogramowania. Gdy zespół pozna jego podstawy, powstaną jego ulepszenia. Limity WIP działają jak blokada w rurociągu. Jeśli rurociąg zostanie zatkany, nie będzie przepływu pracy w systemie, a zespół będzie zmuszony odetkać rurociąg przed rozpoczęciem nowej pracy.
Kanban pomaga wygładzić przepływ pracy w celu zmaksymalizowania „przepustowości” i osiągnięcia produktów o wysokiej jakości.
W odróżnieniu do wielu metodologii wprowadzających przełomowe zmiany w procesach organizacji, Kanban jest ewolucyjnym systemem preferującym stopniowe ulepszanie istniejących procesów organizacji. To sprawia, że wdrożenie Kanban jest znacznie łatwiejsze od innych rozwiązań, co czyni go coraz bardziej popularnym narzędziem do zarządzania wszelkiego rodzaju pracami, w tym programowania zwinnego (ang. Agile Software Development).
W kolejnych postach opiszę tablicę, zadania i pracę cząstkową. Wszystkie wpisy są pod adresem: https://wolski.pro/kanban
Przykro mi, ale zabodło w – jakby nie było bardzo profesjonalnym tekście.
Ne piszemy 'z małej litery’. 'Z dużej/wielkiej’ – również nie. To rusycyzmy, czyli błędy. Po polsku będzie 'małą/dużą/wielką literą’.
Ups, błąd jest w cytacie z książki, czyli nie do skorygowania. Szkoda.
Dziękuję za komentarz. Obawiam się, że cytatu nie będę poprawiał.:-)
Systemu kanban używam w mojej firmie produkcyjnej do zamawiania komponentów.
Ten artykuł poszerzył moje horyzonty:)