Kanban

Współczesne zespoły programistyczne Agile mogą wykorzystać 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, silniejsze skupienie na ustawicznym doskonaleniu oraz większą przejrzystość w całym cyklu programistycznym.

Choć zasady leżące u podstaw ram postępowania Kanban są ponadczasowe i dotyczą niemal każdej branży, praktyka Agile okazała się szczególnie skuteczna w zespołach programistycznych. W przeciwieństwie do wdrażania metodyki Kanban w 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 zadań, a i one mogą być wirtualne.

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

Zarówno cyfrowa, jak i fizyczna tablica Kanban zapewniają, że zespół wizualizuje swoją pracę, standaryzuje przepływ pracy oraz natychmiast identyfikuje i usuwa wszystkie blokery i 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 swojej wielkości, struktury i celów zespół może dostosować przepływ pracy, aby odpowiadał jego unikalnym procesom.

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

W języku japońskim kanban oznacza dosłownie „szyld”. Zespoły Kanban prezentują każdy element pracy jako osobną kartę na tablicy. Prezentowanie prac w formie kart na tablicy Kanban ma na celu przede wszystkim umożliwienie członkom zespołu śledzenia postępów w obrębie przepływu pracy w sposób wysoce wizualny.

Karty Kanban zawierają krytyczne informacje o zadaniach projektowych, dając zespołom wgląd w to, kto jest odpowiedzialny za które zadania, a także krótki opis zadania oraz szacunkowy czas jego realizacji. 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 dowolnym momencie w status każdego zadania wraz z odpowiednimi szczegółami sprzyja zwiększeniu poziomu koncentracji, pełnej identyfikowalności oraz szybkiej identyfikacji blokerów i zależności.

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

Zespół Kanban koncentruje się tylko na pracach, które są akurat w toku. Gdy zespół wykona zadanie, wybiera następne z 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 może być pewny, że dostarcza firmie maksymalną wartość.

W zespołach Kanban kluczowym wskaźnikiem jest czas cyklu. Jest 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ą do skrócenia czasów cyklu. 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ą najlepsze praktyki, 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.

Ponadto takie podejście umożliwia całemu zespołowi wspólne usuwanie wszelkich wąskich gardeł w pracy, ułatwiając szybkie rozwiązywanie problemów i zapewniając płynny przepływ pracy. Przykładowo obowiązki związane z testowaniem dotyczą nie tylko inżynierów QA, ale także programistów, sprzyjając wspólnym wysiłkom na rzecz utrzymania wydajności. W systemie Kanban cały zespół zapewnia płynny przebieg pracy przez cały proces.

Wielozadaniowość znacząco obniża wydajność. Zwiększone obciążenie pracą prowadzi jednocześnie do częstszego przełączania kontekstu, utrudniając postęp w realizacji. Dlatego istotną zasadą procesu Kanban jest ograniczenie prac w toku (WIP). Limity prac w toku uwidaczniają wąskie gardła 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. W przypadku przeglądu kodu może zostać ustawiony limit WIP wynoszący 2. Może się to wydawać niską granicą, ale jest ku temu dobry powód.

Programiści często wolą napisać nowy kod niż poświęcać czas na przeglądanie czyjejś pracy. Niski limit zachęca zespół do zwrócenia szczególnej uwagi na zgłoszenia w stanie przeglądu i przejrzenia pracy innych osób przed zgłoszeniem własnego kodu do przeglądu, co ostatecznie skraca ogólny czas cyklu.

Kumulacyjny diagram przepływu ilustruje liczbę zgłoszeń z poszczególnym stanem. Widząc rosnącą liczbę zgłoszeń w danym stanie, członkowie zespołu mogą z łatwością wykrywać blokery. Zgłoszenia w stanach pośrednich, takich jak „W toku” lub „W trakcie przeglądu”, oznaczają, że wyniki prac nie zostały jeszcze wysłane do klientów, a blokery 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) opisuje 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 DevOps zasadnicze znaczenie dla szybszej wysyłki 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ół potrafi 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ą zasady koncepcji Kanban i Scrum w metodyce „Scrumban”. Zapożycza ona sprinty o stałej długości i role z metodyki Scrum oraz koncentrację na limitach prac w toku i czasie cyklu z metodyki Kanban.

Zespołom, które dopiero rozpoczynają wdrażanie podejścia Agile, zdecydowanie zalecamy wybór jednej metodyki i przetestowanie jej przez pewien czas. Jeśli Twój zespół jest gotowy, aby skorzystać z metodyki Kanban, użyj naszego bezpłatnego szablonu tablicy Kanban już dziś!