Gdzie Scrum nie może tam Kanban pośle

Agile, Lean, Scrum oraz Kanban to obecnie jedne z bardziej popularnych terminów z zakresu zwinnego wytwarzania oprogramowania. Nie raz, nie dwa miałem okazje usłyszeć sformułowanie podobne do tego: “Scrum się tutaj nie nadaje, zróbmy to w Kanbanie”. Czy to znaczy, że Kanban to po prostu mniej skomplikowany brat bliźniak Scrum’a? Czy pozbycie się “zbędnych” ról i artefaktów oraz skupienie się na realizacji zadań bądź historyjek zamieszczonych na fizycznej bądź wirtualnej tablicy to już Kanban? Różnica między tymi dwoma podejściami do wytwarzania oprogramowania jest trochę bardziej skomplikowana.

Scrum w pigułce

Scrum, przez jednych, nie do końca prawidłowo, nazywany metodyką, zgodnie z oficjalną definicją umieszczoną w polskiej wersji Scrum Guide to ramy postępowania (ang. framework), dzięki którym ludzie mogą z powodzeniem rozwiązywać złożone problemy adaptacyjne, by w sposób produktywny i kreatywny wytwarzać produkty o najwyższej możliwej wartości¹. Co warte podkreślenia Scrum może być wykorzystywany nie tylko w tworzeniu produktów technologicznych.

Sprint Backlog a Kanban

Jednym z bardziej istotnych artefaktów dla Zespołu Deweloperskiego (ang. Development Team) jest Backlog Sprintu (ang. Sprint Backlog), który, w dużym skrócie, obrazuje zakres pracy, nad którym zespół pracuje w bieżącym Sprincie. Trzeba tutaj podkreślić, że Scrum Guide nie definiuje jak powinien on wyglądać. Możemy znaleźć jedynie wskazówkę, że Backlog Sprintu to zbiór elementów Backlogu Produktu wybranych do Sprintu rozszerzony o plan dostarczenia Przyrostu produktu i realizacji Celu Sprintu¹. Pomimo to, że przewodnik nie narzuca konkretnego sposobu bądź narzędzia, jednym z najczęściej stosowanych rozwiązań jest tablica podzielona na co najmniej trzy kolumny z nagłówkami: TO DO, IN PROGRESS, DONE, pomiędzy którymi przesuwa się elementy wybrane do Sprintu.

A teraz zapomnij na chwile o wszystkich elementach Scruma, oprócz tablicy przedstawiającej zadania pogrupowane w trzy kategorie i spróbuj odpowiedzieć na pytanie: Czy to jest Kanban?

Krótka historia metody Kanban

Aby lepiej zrozumieć metodę Kanban musimy przenieść się do Japonii i odwiedzić jedną z fabryk firmy Toyota, gdzie jest on częścią większej filozofii “Just-in-Time” (JIT). Jej kluczowym założeniem jest dostarczanie w procesie produkcyjnym tylko tego, co jest potrzebne, tylko w takiej ilości, która jest aktualnie potrzebna. JIT wraz z Jidoką to dwa kluczowe filary Systemu Produkcyjnego Toyoty (ang. Toyota Production System).

Słowo Kanban po przetłumaczeniu z języka japońskiego oznacza szyld lub tabliczkę z napisem informującym. Jest to metoda sterowania produkcją, której najważniejszym elementem jest sterowaniem zapasami – każda komórka organizacyjna powinna produkować tylko tyle towaru ile jest obecnie potrzebne. Celem metody jest redukcja zapasów, kosztów ich magazynowania, wyeliminowanie przestojów w produkcji, a ostatecznie zwiększenie produktywności całego przedsiębiorstwa. Jednym z powodów do wprowadzenia pierwszej jej wersji w roku 1947 przez Taiichi Ohno, pracownika Toyoty, była wyższa produktywność konkurencyjnych firm ze Stanów Zjednoczonych. Doszukiwał się on inspiracji wśród rozwiązań stosowanych w supermarketach: Powinno być możliwe, zorganizowanie przepływu materiałów w produkcji, wg zasady supermarketu, konsument bierze z półki określoną ilość produktu, a powstała luka jest natychmiast uzupełniana².

Wdrożenie Kanbana w przedsiębiorstwie produkcyjnym to proces nietrywialny, jednak na przykładzie Toyoyty, może ono przynieść zaskakujące efekty. Po trzech latach od wprowadzenia metody zanotowano tam:

• • 30% wzrost produkcji,
  • 60% redukcja wszelkich zapasów,
  • 90% redukcja braków,
  • 15% redukcja przestrzeni produkcyjnej,
  • 15% redukcja operatorów i personelu administracyjno-technicznego.³

Kanban a wytwarzanie oprogramowania

Kanban wykorzystywany do bardziej efektywnego wytwarzania oprogramowania w dużej mierze bazuje na jego oryginalnej wersji. Pomimo tego, że sam proces różni się od procesu produkowania samochodu, podstawowe mechanizmy zarządzania taśmą produkcyjną znajdują zastosowanie również w przypadku wytwarzania oprogramowania. Dostosowana pod wymogi inżynierii oprogramowania wersja została po raz pierwszy przedstawiona w 2010 roku przez Davida J. Andersona w książce Kanban: Successful Evolutionary Change for Your Technology Business. Wyróżnić można sześć podstawowych zasad, których przestrzeganie jest kluczowe, aby dobrze wykorzystać metodę Kanban.

Zwizualizuj proces

Najważniejszą zasadą metody Kanban jest wizualizacja procesu. Stąd też przekonanie, że “transformacja” Scruma do postaci tablicy podzielonej na kolumny przedstawiającej kolejne etapy procesu to już Kanban. Tablica ta powinna jak najdokładniej odźwierciedlać cały proces dlatego też może składać się z trzech kolumn, jednakże nie ma tutaj górnego limitu. Co więcej, oprócz samych kolumn, nad każdą z nich powinna znajdować się liczba, która odzwierciedla maksymalną liczbę zadań, które mogą znajdować się jednocześnie w danej kolumnie. Liczby te mają na celu ograniczenie pracy w toku (ang. work in progress) co jest kolejną zasadą metody.

Ogranicz pracę w toku

Ograniczenie pracy w toku poprzez ograniczenie liczby zadań, które jednocześnie mogą znajdować się na danym etapie procesu, pozwala na uwidocznienie problemów i identyfikację wąskich gardeł. Jednocześnie, poprzez skupienie się członków zespółu na poszczególnych etapach, pomaga wyeliminować wielozadaniowość. Wprowadzenie limitów work in progress dodatkowo tworzy system pull, w którym zadania są przenoszone do kolejnego etapu procesu tylko wtedy, kiedy w ramach limitu pracy w toku zwolni się miejsce. Analizując powyższą tablicę, można zauważyć, że wąskim gardłem może okazać się faza testowania. Kolejne zadanie może przejść do etapu Analysis dopiero w momencie przeniesienia przynajmniej jednej karty z kolumny Test do kolumny Deploy. Może to sygnalizować, że zespół nie posiada wystarczającej liczby testerów.

Zarządzaj przepływem

W celu ciągłego usprawniania procesu wytwórczego trzeba systematycznie mierzyć wartości, takie jak czas i płynność wykonywania zadań. Przepływ pracy przez każdy etap jej przepływu powinien być monitorowany, zmierzony i zgłoszony. Poprzez aktywne zarządzanie przepływem, oceniony może być negatywny lub pozytywny wpływ ciągłych, narastających, ewolucyjnych zmian na system⁴. Jeżeli zadanie o zbliżonym zakresie w przeszłości zostało wykonane w dwukrotnie krótszym czasie, może to sygnalizować problem, który powinien zostać zbadany i rozwiązany. Idealny proces powinien charakteryzować się płynnością, dużą szybkością realizacji zadań oraz przewidywalnością.

Zarządzaj przepływem

Polityka i zasady ustalone w ramach danego procesu powinna być wyraźne i jawne. Zrozumienie przez każdego członka zespołu jak przebiega i wygląda proces wytwórczy pozwala przeprowadzać bardziej racjonalne i obiektywne dyskusje o napotkanych problemach. Dzięki temu możliwe jest znalezienie wspólnego rozwiązania, zamiast marnowania czasu na wyjaśnianie ewentualnych nieporozumień.

Zastosuj sprzężenie zwrotne

Filozofia Lean zakłada, że aktywne przekazywanie wiedzy jest konieczne dla osiągania pozytywnych zmian. Dzięki regularnym okazją do dzielenia się informacją zwrotną (na przykład w postaci spotkań takich jak retrospektywa czy poranne planowania dnia) środowisko pracy staję się bardziej otwarte na proponowanie oraz wdrażanie regularnych usprawnień. Zespoły stają się bardziej zgrane i proaktywne, ulepszają proces w sposób ciągły co bezpośrednio przekłada się na komfort i wyniki pracy.

Wspólnie ulepszaj

Metoda Kanban zachęca do małych, stałych, narastających i ewolucyjnych zmian, które pasują do siebie. Kiedy zespoły podzielają zrozumienie teorii na temat pracy, przepływu pracy, procesów, ryzyka, wtedy jest bardziej prawdopodobne, że będą w stanie zbudować podobne zrozumienie problemu lub zasugerować działania poprawiające, na które można się zgodzić dzięki konsensusowi⁴.

Podsumowanie

Tak samo jak Scrum nie nadaje się do każdego projektu, tak samo “uproszczenie” go do postaci prostej tablicy wizualizującej elementy danego procesu to jeszcze nie Kanban. Różnica między tymi dwoma metodami jest bardziej złożona, jednakże prawidłowe wdrożenie każdej z nich pozwala na usprawnienie działania całego zespołu – należy tylko pamiętać o wyborze odpowiedniego narzędzia dla konkretnego przypadku, a wybór ten nie zawsze jest oczywisty.

1. http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-PL.pdf
2. http://www.system-kanban.pl/kanban-prezentacja-metody/
3. https://pl.wikipedia.org/wiki/Kanban
4. http://www.governica.com/Kanban_w_tworzeniu_oprogramowania