Wiele razy spotykałem się z opiniami jakoby Kanban (w IT) to była tylko kolejka zadań, które realizujemy jedno po drugim. Dodatkowo „nie ma w nim zasad”. I „nie ma też tylu niepotrzebnych spotkań jak np. w Scrumie” 🙃
Kanban też ma zasady
Kanban to bardzo dobre ramy pracy – proste, zwinne, efektywne i lekkie. Jednak wielu z nas je spłaszcza. Nie jest tak, że Kanban to tylko chaos, kolejka i robienie jednego zadania za drugim. Mimo tego, że zasad zbyt wielu nie ma to jednak opiera się na 3 filarach: wizualizacja pracy, limitowaniu „Work In Progress”, skupienie na procesie (zarządzanie przepływem).
Przez stały przepływ zadań zespół deweloperski może być naprawdę zwinny. W praktyce oznacza to dostarczenie wartości dla klienta (użytkownika) z każdym kolejnym wykonanym zadaniem. Po jego skończeniu pobieramy kolejne, które w momencie pobierania najbardziej odpowiada potrzebom, ma najwyższy priorytet (czyli jest „na górze listy”) itd.
Kanban kojarzymy często z tablicą z kartami (zadania, historyjki), która wizualizować ma naszą pracę. Zadania są ułożone na tablicy w lewej kolumnie (np. „Do zrobienia”), a potem „płyną” w prawo przez kolejne etapy (np. „W trakcie”, „Testowanie”, „Zrobione”). Taka tablica zatem będzie jednym z przejawów pierwszej zasady (wizualizacja).
Istotną kwestią jest to, aby lista rzeczy do wykonania była świadomie zarządzana i miała przejrzyste priorytety. Bez tego powstanie problem – wpada sobie “karta”, trzeba ją zrobić, ale nikt nie wie o co w niej chodzi ani jaki jest jej rzeczywisty priorytet. Przez to np. możemy skupić się na dostarczeniu niewłaściwych funkcjonalności. Trzeba pamiętać o porządku 👮
Limitowanie Work In Progress jest proste z założenia i… trudne w realizacji. Limit WIP ma sprzyjać temu, aby programiści mogli skupić się np. na jednym zadaniu, skończyć je i dopiero potem dobierać następne. Tak jest szybciej, m.in. dlatego że nie trzeba się przełączać myślowo między różnymi, odmiennymi wątkami. W praktyce często programista jest proszony o dodatkową pracę („to jest małe zadanko, na 5 minut, dla Ciebie jedna linijka”) i zamiast jednego zadania zaczyna się tworzyć tasiemiec 😂 Tu zespoły muszą być wyposażone w bardzo ważne narzędzie – asertywność ☺️
Skupienie na procesie (czy inaczej zarządzanie przepływem, trzecia zasada) jest już czymś o czym niewiele osób myśli decydując się na Kanban. W praktyce oznacza to, aby dobierać odpowiednie miary, standardy i środki opisujące nasz proces oraz wspierające usprawnienia. Dzięki mierzeniu można obiektywnie oceniać naszą pracę i szukać docelowego poziomu. Dobrze sprawdzą się miary dotyczące czasów między etapami wytwarzania (np. ile czasu karta jest trzymana między „W trakcie” i „testowanie”), długość jej życia (od pomysłu do zakończenia) itp. Bez mierzenia i analizy nie dowiemy się jaki jest obiektywnie nasz proces.
Ponadto Kanban wykorzystuje pojęcie Kaizen, ciągle doskonalenie (continous improvement), które w wybranych źródłach jest czwartą zasadą. Szukanie wąskich gardeł (bottlenecks), poprawianie komunikacji z interesariuszami, szukanie narzędzi, które jeszcze bardziej automatyzują proces wdrażania kodu “na produkcję” to przykładowe elementy takiego doskonalenia. Tu z pomocą przychodzą m.in. miary i obiektywnie opisany proces z punktu poprzedniego. Zespoły, które wybrały Kanban, nie mają przepisanego momentu, takiego jak Retro w Scrumie, aby zatrzymać się i pomyśleć o swoich problemach, ale często z tego typu formy korzystają.
Kanban to coś więcej niż myślisz
Mam nadzieję, że wiesz już, że Kanban nie sprowadza się do kolejki zadań. To wbrew pozorom, wymagające podejście, które też ma swoje zasady, mimo tego, że nie jest tak „zdefiniowane” jak np. Scrum (przez Scrum Guidea). Kanban nie przepisuje ról i spotkań, ale one same się wyklarują w trakcie używania, bo będzie taka potrzeba i często takie zespoły wykorzystują pełną paletę zwinnych praktyk (np. ze Scruma). Decydując się na Kanban warto zatem pamiętać o tych kilku szczegółach i stosować się do każdej z zasad.
Sprawdź też post pewnym zespole, który walczył z wrzutkami w sprintach (Scrum) i ostatecznie przesiadł się na Kanban.
A jeśli interesuje Cię temat planowania w Scrumie to może spodoba Ci się ten post.
Zdjęcie główne: Pixabay