Kanban

Współczesne zespoły programistyczne Agile mogą wykorzystać te same zasady JIT, dostosowując ilość prac w toku (WIP) do potencjału wykonawczego zespołu. Dzięki temu zespoły zyskują bardziej elastyczne opcje planowania, szybsze rezultaty, wyraźniejszy cel oraz większą przejrzystość w całym cyklu programistycznym.

Choć zasady leżące u podstaw ram postępowania są ponadczasowe i dotyczą niemal każdej branży, praktyka Agile okazała się szczególnie skuteczna wśród zespołów programistycznych. Po części wynika to z faktu, że po opanowaniu podstawowych zasad zespoły tworzące oprogramowanie mogą przystąpić do działania niemal bez żadnego dodatkowego nakładu pracy. W przeciwieństwie do wdrażania metodyki Kanban na hali produkcyjnej, które wymaga wprowadzenia zmian w procesach fizycznych oraz uzupełnienia istotnych materiałów, jedynymi przedmiotami fizycznymi, których potrzebują zespoły programistyczne, są tablice i karty, a i one mogą być wirtualne.

Praca wszystkich zespołów Kanban koncentruje się wokół tablicy Kanban — narzędzia służącego do wizualizacji prac i optymalizacji przepływu pracy wśród członków zespołu. W niektórych zespołach nadal popularne są tablice fizyczne, jednak w narzędziach do tworzenia oprogramowania według metodyki Agile to wirtualne tablice stanowią kluczową funkcję, ponieważ zapewniają możliwość monitorowania, ułatwiają współpracę i są dostępne z wielu lokalizacji.

Jednak niezależnie od tego, czy tablica zespołu ma postać fizyczną, czy cyfrową, służy do wizualizacji pracy zespołu, ustandaryzowania stosowanego przepływu pracy oraz szybkiego rozpoznawania i rozwiązywania blokerów oraz zależności. Podstawowa tablica Kanban ma formę przepływu pracy obejmującego trzy kroki: Do wykonania, W toku i Gotowe. Jednak, w zależności od wielkości, struktury i celów zespołu, przepływ pracy można zmodyfikować tak, aby odwzorowywał unikatowy proces konkretnego zespołu.

Metodyka Kanban opiera się na pełnej przejrzystości prac i informowaniu o potencjale wykonawczym w czasie rzeczywistym. W związku z tym tablicę Kanban należy traktować jako pojedyncze źródło rzetelnych informacji na temat pracy zespołu.

W języku japońskim kanban oznacza dosłownie „sygnał wizualny”. W przypadku zespołów Kanban każda jednostka pracy jest przedstawiana na tablicy w formie odrębnej karty.

Prezentowanie prac w formie kart na tablicy Kanban ma na celu przede wszystkim umożliwienie członkom zespołu śledzenia postępów prac w obrębie przepływu pracy w sposób wysoce wizualny. Karty Kanban zawierają najważniejsze dane na temat konkretnych jednostek pracy, dzięki czemu cały zespół ma pełny dostęp do informacji o tym, kto odpowiada za dany element prac i ile wynosi szacowany czas realizacji danego elementu, a także do krótkiego opisu samego zadania itp. Karty na wirtualnych tablicach Kanban często zawierają również zrzuty ekranu i inne szczegóły techniczne przydatne dla przypisanej osoby. Zapewnienie członkom zespołu wglądu w stan każdej jednostki pracy w dowolnym momencie, a także we wszystkie powiązane z nim dane, pozwala zwiększyć poziom koncentracji oraz umożliwia pełne śledzenie prac i szybką identyfikację blokerów oraz zależności.

Kanban jest obecnie jedną z najpopularniejszych metodyk tworzenia oprogramowania stosowanych przez zespoły Agile. Ma również kilka dodatkowych zalet związanych z planowaniem zadań i produktywnością w zespołach dowolnej wielkości.

Zespół Kanban koncentruje się tylko na pracach, które są aktywnie w toku. Gdy zespół zakończy jedną jednostkę pracy, sięga po kolejną ze szczytu backlogu. Product owner może swobodnie zmieniać priorytety prac w backlogu bez zakłócania działań zespołu, ponieważ żadne zmiany wprowadzane poza bieżącymi jednostkami pracy nie wpływają na zespół. Dopóki product owner dba o to, aby najważniejsze jednostki pracy znajdowały się na szczycie backlogu, zespół programistyczny ma pewność, że dostarcza firmie maksymalną korzyść. Nie ma więc potrzeby stosowania iteracji o stałej długości jak w metodyce Scrum.

W zespołach Kanban kluczowym wskaźnikiem jest czas cyklu. Czas cyklu to ilość czasu potrzebna na przeprowadzenie jednostki pracy przez cały przepływ pracy zespołu — od momentu rozpoczęcia pracy aż do jej dostarczenia. Dzięki optymalizacji czasu cyklu zespół może z dużą pewnością prognozować dostarczanie wyników prac w przyszłości.

Nakładające się zestawy umiejętności prowadzą skrócenia czasów cykli. Jeśli tylko jedna osoba w zespole dysponuje określonymi kompetencjami, staje się ona wąskim gardłem w przepływie pracy. W związku z tym zespoły stosują podstawowe najlepsze rozwiązania, takie jak przegląd kodu czy mentoring, które sprzyjają rozpowszechnianiu wiedzy. Dzięki posiadaniu tych samych umiejętności członkowie zespołu mogą podejmować się różnorodnych prac, co dodatkowo optymalizuje czas cyklu. Oznacza to również, że gdy wystąpi wąskie gardło, cały zespół może się nad nim pochylić, aby przywrócić płynność procesu. Przykładowo testy są przeprowadzane nie tylko przez inżynierów QA. Programiści również w tym uczestniczą.

Ramy postępowania Kanban zakładają, że zapewnienie płynnego przepływu prac w procesie jest obowiązkiem całego zespołu.

Wielozadaniowość znacząco obniża wydajność. Im więcej jednostek pracy znajduje się równocześnie w toku, tym więcej występuje zmian kontekstu, które utrudniają ich ukończenie. Dlatego właśnie kluczowym założeniem metodyki Kanban jest ograniczenie liczby prac w toku (WIP). Limity liczby prac w toku pozwalają uwidocznić wąskie gardła i zaległości w procesie zespołu wynikające z braku koncentracji, ludzi lub posiadanych umiejętności.

Przykładowo typowy zespół programistyczny może korzystać z przepływu pracy obejmującego cztery stany: Do wykonania, W toku, Przegląd kodu i Gotowe. Dla etapu przeglądu kodu może zostać ustawiony limit WIP wynoszący 2. Wydaje się on niski, jednak istnieje dobry powód przyjęcia takiej wartości: programiści często wolą pisać nowy kod niż spędzać czas na recenzowaniu pracy innych. Niski limit zachęca zespół do zwrócenia szczególnej uwagi na zgłoszenia w stanie przeglądu i recenzję pracy innych przed zgłoszeniem własnego kodu do przeglądu. W efekcie pozwala to skrócić całkowity czas cyklu.

Kumulacyjny diagram przepływu ilustruje liczbę zgłoszeń z poszczególnym stanem. Widząc rosnącą liczbę zgłoszeń z danym stanem, członkowie zespołu mogą z łatwością wykrywać zatory. Zgłoszenia o stanach pośrednich, takich jak „W toku” lub „W trakcie przeglądu”, oznaczają, że wyniki prac nie trafiły jeszcze do klientów, a blokady w tych stanach mogą zwiększać prawdopodobieństwo poważnych konfliktów integracyjnych, gdy prace zostaną scalone na późniejszym etapie.

Ciągłe dostarczanie (CD) jest praktyką polegającą na częstym udostępnianiu efektów pracy klientom. Ciągła integracja (CI) jest praktyką automatycznego kompilowania i testowania kodu w sposób przyrostowy przez cały dzień. Wspólnie tworzą one pipeline CI/CD, który ma w zespołach programistycznych (a zwłaszcza w zespołach DevOps) zasadnicze znaczenie dla szybszego wydawania oprogramowania przy zapewnieniu jego wysokiej jakości.

Kanban i CD doskonale się uzupełniają, ponieważ obydwie techniki koncentrują się na dostarczaniu korzyści dokładnie na czas (just-in-time) i pojedynczo. Im szybciej zespół jest w stanie dostarczyć innowację na rynek, tym bardziej konkurencyjny będzie jego produkt. Zespoły Kanban na tym się właśnie skupiają — na optymalizacji przepływu pracy do klientów.

Mimo że niektóre pojęcia stosowane w Kanban i Scrum są wspólne, to jednak te metodyki reprezentują zupełnie odmienne podejścia. Nie należy ze sobą ich mylić.

Niektóre zespoły łączą ze sobą ideały przyświecające koncepcjom Kanban i Scrum w metodyce Scrumban. Zapożycza ona sprinty o stałej długości oraz role z metodyki Scrum oraz koncentrację na limitach prac w toku oraz czasie cyklu z metodyki Kanban. Jedak zespołom, które dopiero rozpoczynają wdrażanie podejścia Agile, zdecydowanie zalecamy wybór jednej lub drugiej metodyki i przetestowanie jej przez pewien czas. Później zawsze można spróbować czegoś bardziej ambitnego.