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źniaka 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ści1. Co warte podkreślenia Scrum może być wykorzystywany nie tylko w tworzeniu produktów technologicznych.

Kluczowe elementy wchodzące w skład Scrum’a m.in. role, zdarzenia i artefakty zostały opisane przez Tomka w kursie Scruma, który polecam wszystkim chcącym poznać bądź odświeżyć wiedzę.

Scrum
Źródło: http://www.agileforall.com/intro-to-agile/

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 Sprintu1. Pomimo to, że przewodnik nie narzuca konkretnego sposobu bądź narzędzia, jednym z najczęsciej 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.

http://blog.xebia.com/2008/09/19/the-task-burn-down-trap-everything-finished-nothing-done/
Źródło: http://blog.xebia.com/2008/09/19/the-task-burn-down-trap-everything-finished-nothing-done/

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łniana2.

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.3

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 5 podstawowych zasad, których przestrzeganie jest kluczowe, aby sukcesywnie 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 odźwierciedla maksymalną liczbę zadań, które mogą znajdować się jednocześnie w danej kolumne. Liczby te mają na celu ograniczenie pracy w toku (ang. work in progress) co jest kolejną zasadą metody.

Źródło: http://kanbanblog.com/explained/
Źródło: http://kanbanblog.com/explained/

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 system4. 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ścia, dużą szybkością realizacji zadań oraz przewidywalnością.

Ustal wyraźne zasady

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ń.

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 konsensusowi4.

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
PODZIEL SIĘ
Od najmłodszych lat związany z Internetem. Aktualnie programista aplikacji internetowych zarówno po stronie serwera jak i klienta. Od ponad trzech lat tworzę i rozwijam produkty dla międzynarodowych startupów.Na co dzień pracuję w Scrumie (certyfikowany Scrum Master) zwinnie wykorzystując praktyki Agile - ciągłą integrację, regularny refaktoring oraz przegląd kodu.Po pracy czytam o i eksperymentuje z nowymi technologiami.

ZOSTAW ODPOWIEDŹ