Wszystko, co powinieneś wiedzieć o zarządzaniu metodą Kanban

Kanban to prostota, zwinność i efektywność. To zestaw zasad i praktyk do zarządzania i poprawy procesu produkcji. Do zastosowania w każdej branży i każdym zespole (również Twoim). Dowiedz się, jak poprawnie korzystać z tego sposobu zarządzania.

Artykuł to fragment książki pt. „1,2,3 KANBAN” autorstwa Tomasza Kaczanowskiego

Kanban opiera się na wizualizacji istniejącego procesu. Domaga się ograniczenia ilości zadań jednocześnie wykonywanych przez zespół. Zachęca do nieustannej optymalizacji procesu. Promuje kulturę ciągłego usprawniania. Zmusza do myślenia w kategoriach wartości dostarczanej klientowi. Wspiera komunikację i współpracę wszystkich uczestników projektu. Brzmi ciekawie?

Rozdział 5. Pryncypia

„Prawdziwego kanbanowca poznaje się po tym, że kończy, a nie, że zaczyna” – Milek z Leszna

Zespół działający zgodnie z duchem kanbana powinien zawsze pamiętać o celu prac, którym jest dostarczanie wartości klientowi. Stąd też priorytetem jest kończenie zadań. Nikt nie przyznaje punktów za rozpoczęcie kolejnego zadania. Żaden klient nie zachwyci się zadaniem, które już niby jest zrobione, ale nie zostało jeszcze przetestowane. Końcowego odbiorcę interesuje bezbłędnie działająca, kompletna funkcjonalność. I warto pamiętać o tym, że zazwyczaj chce ją otrzymać jak najszybciej.

Jak mówi jedno z kanbanowych powiedzeń: przestań zaczynać, zacznij kończyć¹. Zastanówmy się wspólnie, co to oznacza w praktyce.

Na potrzeby naszych rozważań załóżmy, że tablica zespołu wygląda tak jak to przedstawiono na następnej ilustracji:

Wyobraźmy sobie teraz, że deweloper pracujący nad zadaniem reprezentowanym przez kartę oznaczoną numerem 11 zakończył pracę. Przenosi ją więc do kolumny oznaczonej jako Done. Następnie, po chwilowej przerwie na celebrację i wypiciu kawy, osoba ta staje przed dylematem, który wyrazić można krótko tak: za co powinienem się teraz zabrać?. Odpowiedź kanbana brzmi: zrób to, co przyniesie wartość klientowi.

Done

Spójrzmy zatem na tablicę. Wartość dla klienta niosą wyłącznie zadania znajdujące się w kolumnie Production. Jeżeli tak, to deweloper powinien zająć się wdrożeniem na produkcję historyjek leżących w kolumnie Done. Oczywiście, ile zespołów, tyle sytuacji i reguł. Być może wdrożenie robi się raz w miesiącu (oby nie…), być może czekamy na zielone światło od Kogoś Ważnego, być może umówiliśmy się z klientem, że kolejne wdrożenie obejmie (nieukończoną jeszcze) funkcjonalność Y. I tak dalej. Nie twierdzę, że obowiązkiem naszego dewelopera jest dokonać wdrożenia. Wskazuję tylko palcem miejsce, w którym jego działanie przyniesie największą korzyść klientowi.

Czy w danej sytuacji możliwe jest, żeby akurat tam skierował swoje wysiłki? Tego nie potrafię ocenić. Z pewnością jednak dobrze by było, gdyby mógł dokonać wdrożenia na produkcję.

Test

Załóżmy jednak, że wdrożenie na produkcję nie wchodzi w danej chwili w grę. Przesuwamy wzrok w lewo i koncentrujemy się na kolumnie oznaczonej jako Test. Widzimy tam dwa zadania. Skoro tam są, to najpewniej ktoś już nad nimi pracuje. Pytanie brzmi: czy można włączyć się w pracę nad tymi zadaniami i przyspieszyć ich ukończenie?

Wiele zależy tu od kontekstu. Często będzie to niemożliwe ze względu na organizację testów lub charakter zadań testowych. Przykładowo, testowanie może być domeną wyspecjalizowanych osób, albo też zadania mogą być zbyt małe, by móc rozsądnie zrównoleglić pracę nad ich testowaniem. Jednak czasem może okazać się, że nasz deweloper jak najbardziej będzie mógł wesprzeć swoich kolegów. Być może dokona przeglądu kodu, podczas gdy dział QA skupi się na pisaniu testów end-to-end. Słowem, powinien się nieco wysilić, starając się znaleźć sposób na przyspieszenie prac nad zadaniami w kolumnie Test.

Doing

Jeżeli jednak i to nie było możliwe, wówczas deweloper powinien szukać dla siebie pracy w kolumnie Doing. Istnieje spora szansa, że tutaj uda mu sie coś znaleźć. Wiele niebanalnych zadań można podzielić na mniejsze, co może przyspieszyć ich realizację. Innym pozytywnym efektem podzielenia zadań jest rozpropagowanie wiedzy o danej funkcjonalności pomiędzy większą liczbę członków zespołu.

Innym sposobem włączenia się w prace jest „sparowanie” się z kimś. Jak mówi staropolskie przysłowie: „co dwie głowy to nie jedna” i każdy, kto kiedykolwiek kodował w parze, wie, że mądrość ta wciąż jest aktualna.

ToDo

Dopiero jeżeli okaże się, że i w kolumnie Doing nie ma nic do zrobienia, wówczas deweloper powinien sięgnąć po nowe zadanie z kolumny ToDo. Tutaj z kolei można zastanawiać się, które z zadań powinien zabrać (zazwyczaj w tej kolumnie jest ich przynajmniej kilka). Cóż, albo są one spriorytetyzowane, co ułatwia podjęcie decyzji, albo należy sytuację omówić z innymi członkami zespołu. Oczywiście w grę wchodzą też umiejętności danego członka zespołu i znajomość poszczególnych zagadnień.

Kończmy!

Pozwolę sobie tu powtórzyć, co następuje: dla klienta wartość ma tylko to, co zostało wdrożone na produkcję. Jest to oczywiste, a przecież wielu deweloperów niechętnie zajmie się zadaniami w kolumnie Test, gdy tyle cudownych nowych tematów czeka w ToDo!

Nie znam uniwersalnej recepty, skłaniającej członków zespołu do zachowań zgodnych z opisanym tu ideałem. Osobiście staram się nagradzać (dobrym słowem) wszelkie przejawy takiego właśnie zachowania i zachęcam do współpracy wśród członków zespołu, przypominając o tym, jak ważne jest kończenie zadań.

5.1. Kanban to sposób myślenia

Jak wynika z naszego przykładu, deweloper postępujący zgodnie z duchem kanbana przegląda tablicę od prawej ku lewej w poszukiwaniu wartości, którą może dostarczyć klientowi. Wymaga to od niego:

komunikacji z innymi członkami zespołu (w tym z właścicielem projektu),
wspólnej pracy nad zadaniami w kilka osób,
wykraczania poza własną „strefę komfortu”,
myślenia w kategoriach wartości dostarczanych klientowi.

(Nie)przypadkowo powyższe zachowania są dokładnie takimi, jakie chętnie widzielibyśmy u wszystkich członków zespołu!

Jako dodatkowy komentarz do powyższych rozważań, powiedzmy jeszcze kilka słów o kanbanie. Jego zastosowanie ma przyczynić się do płynnego, niezakłóconego przepływu zadań. Kluczowe jest doprowadzanie spraw do końca przy jednoczesnym pilnowaniu, by nigdy zbyt wiele zadań nie było otwartych jednocześnie.

Kolumny na tablicy kanbanowej nie są wyznacznikiem granic odpowiedzialności poszczególnych osób! Nie ma tu mowy o tzw. over the wall attitude, w której poszczególne grupy przerzucają się zadaniami, na zasadzie: „myśmy swoje zrobili, a teraz wy się martwcie”. Zachowania znane z procesów produkcji opartych na niesławnym waterfallu nie mają tu wstępu. Kolumny na tablicy to tylko fazy jednego płynnego przejścia od początku aż do końca. Sensem ich istnienia jest wizualizacja przebiegu prac i wykrywanie wąskich gardeł.

5.2. Niezakłócony przepływ

Ideałem jest ciągle płynący strumień zadań. Osobom romantycznym przyjdzie na myśl woda w spokojnej rzece, której przepływu nie blokują żadne przeszkody. Bardziej inżynierskie umysły mogą przywołać obraz zautomatyzowanej taśmy produkcyjnej, miarowo dostarczającej gotowe produkty. Oba obrazy są poprawne i dobrze przedstawiają sedno tego, do czego dążymy. Interesuje nas ciągły, niezakłócony przepływ.

Oczywiście nic nie jest tak proste, jak się wydaje. Kluczem do uniknięcia zacinania się naszej taśmy produkcyjnej jest trzymanie jakości na wysokim poziomie. Jeżeli nam się to nie uda, płynny przepływ zostanie zakłócony. Zamiast przesuwać się miarowo w rytmie Doing → Test → Done → Production, karty będą wracały z kolumny Test do Doing. To z kolei spowoduje, że deweloperzy będą przełączali kontekst, porzucając bieżące zadania i biorąc się za naprawę błędów.

Jeszcze gorzej, gdy i testowanie nie jest na odpowiednim poziomie. Wtedy zespół osiągnie chwilowy sukces (tj. wdrożenie na produkcję), po którym nastąpi jednak katastrofa, gdy zadanie przetestuje klient. A ponieważ od czasu ukończenia praca nad zadaniem mogło minąć już sporo czasu, więc i naprawa może okazać się o wiele bardziej kosztowna. Zakłócenie w przepływie będzie tym wyraźniejsze.

Innym ważnym aspektem wpływającym na płynność pracy jest niezależność od osób spoza zespołu. Uzależnienie od innych zespołów – np. od wyspecjalizowanych bazodanowców – powoduje, że zespół traci kontrolę nad tempem przepływu zadań. Ciężko wówczas popchnąć do przodu zablokowane zadanie, czekające na działanie osób trzecich. Niezakłócony przepływ przenosi się w sferę marzeń. Pozostaje błaganie, wykłócanie się, lub przekupywanie członków innego zespołu, by to nasze zadanie uznali za priorytetowe.

Krótko rzecz ujmując: warto być niezależnym. Stąd też niegłupim pomysłem jest budowa zespołu samowystarczalnego.

5.3. Wąskie gardła

Intuicyjnie rozumiem czym jest „wąskie gardło”: to ten etap w procesie, w którym prace posuwają się najwolniej. To tu następuje spiętrzenie zadań, tak że osoby zaangażowane w kolejne etapy procesu muszą (bezczynnie) czekać, aż wąskie gardło wypuści kolejny element gotowy do dalszej obróbki.

Przykładem wąskiego gardła jest pojedyncza kasa w sklepie, przy której ustawia się długa kolejka klientów. Na gruncie zespołu deweloperskiego wąskim gardłem może być, przykładowo, etap analizy, w którą zaangażowane są nieliczne osoby. Może się wówczas zdarzać, że programiści będą czekali, aż otrzymają kolejne gotowe do pracy zadania.

Zauważmy, że w obu przypadkach wąskie gardło decyduje o przepustowości całego systemu. Tylko udrożnienie tego właśnie elementu polepszy wydajność całości. W przypadku sklepu, nic nie da poszerzenie alejek pomiędzy półkami z towarami. Aby zwiększyć przepustowość sklepu trzeba przyspieszyć obsługę w kasie albo wprowadzić kolejne kasy. W przypadku zespołu produkującego oprogramowanie, na nic się nie zda zatrudnienie lepszych programistów. Tylko zmiany w zespole analityków mogą poprawić sytuację.

Wąskie gardło może występować na każdym etapie. Potraktuj proszę poniższe rozważania dotyczące analizy zadań jako przykładowe. Równie dobrze można by rozpatrywać sytuację spiętrzenia zadań w kolumnie Doing, Test, czy Done.

Najkorzystniej byłoby podnieść wydajność elementu stanowiącego wąskie gardło całego procesu. Przede wszystkim warto upewnić się, że osoby, które powinny wykonywać analizę, nie są zajęte innymi zadaniami. I bardzo możliwe, że tu właśnie leży źródło problemu. Niewykluczone, że analitycy są zaangażowani w więcej niż jeden projekt, w związku z czym tempo ich pracy w naszym projekcie jest jakie jest.

Jeżeli nie jest w naszej mocy przejąć w naszym projekcie analityków „na własność”, powinniśmy spróbować zwiększyć częstotliwość, z jaką są dla nas dostępni. Załóżmy, że mamy do dyspozycji tylko jednego analityka, który pracuje dla nas w środy i w czwartki. Jeżeli uda nam się zmienić jego grafik tak, by pojawiał się np. w poniedziałki i czwartki, to nasza sytuacja ulegnie pewnej poprawie. Może się okazać, że w każdym z tych dni będzie mógł przeprowadzić analizę jakiegoś zadania. Wówczas kolejne „porcje pracy” będą docierały do nas regularnie, a nie raz na tydzień. Przyczyni się to do bardziej stałego tempa pracy całego zespołu.

Następnie można próbować przesuwać ludzi między pozycjami, tak by szybko rozładować sytuację. W przypadku omawianego problemu z analizą oznaczałoby to przeniesienie wybranych programistów do analizowania zadań. Gdy tak wzmocniony zespół analityków poradziłby już sobie z natłokiem zadań, wówczas wdrożeni do niego programiści mogliby wrócić do swoich normalnych obowiązków. Takie działanie może wiązać się z pewnymi niebezpieczeństwami.

Po pierwsze, można przypuszczać, że niewprawni w analizie pracownicy wykonaliby je gorzej niż doświadczeni analitycy. Ryzykujemy więc, że w krótkiej perspektywie czasowej jakość analiz obniży się, a to może okazać się bardzo niekorzystne.

Po drugie, przełączanie kontekstu jest niekorzystne, a opóźnienia w realizacji zadań programistycznych mogą być trudne do zaakceptowania. Programiści będą zmuszeni najpierw przestawić się do zupełnie nowych zadań, a po pewnym czasie wrócić do tych, którymi zajmowali się przedtem.

Co więcej, przerzucając osoby tam i z powrotem nie usuniemy przyczyny problemu – tj. niewydolności etapu analizy – i co pewien czas będziemy musieli powtarzać ten sam manewr. Za każdym razem płacąc wysoką cenę.

Patrząc na problem w dłuższej perspektywie, jedno wydaje się pewne: nie ma sensu zarzucać analityków zadaniami przekraczającymi ich moce przerobowe. Dopóki nie wzmocnimy działu analizy, nie powinniśmy łudzić się, że uzyskamy większą przepustowość systemu, niż moce tego działu. Stąd też rozsądnym wydaje się ograniczenie ilości wykonywanych zadań, tak by zapewnić płynny, niezakłócony przepływ zadań.

Kanbanowa tablica jest wyśmienitym narzędziem do wykrywania wąskich gardeł. Spiętrzenie kart u wejścia wąskiego gardła i nieliczne karty po drugiej jego stronie dają nam jasny sygnał, że w tym właśnie miejscu warto dokonywać usprawnień.

Tomek Kaczanowski

Autor książki „1,2,3 KANBAN„

Programista i lider zespołu w firmie Codewise. Od ponad dziesięciu lat stara się stworzyć idealne oprogramowanie. Aby zrealizować ten cel nie cofa się przed niczym: pisze testy, usuwa kod, a nawet chyłkiem i podstępnie przemyca do pracy zespołu techniki zwinne. I właśnie o tych ostatnich – a dokładniej o kanbanie – traktuje jego ostatnia książka.

Zdjęcie główne artykułu royalty free z Fotolia