Kanban

Przepływ Kanban, kamień węgielny metodologii Agile i DevOps, zwiększa wydajność przez planowanie płynnego postępu w realizacji zadań dzięki wizualizacji przepływów pracy. Przepływ Kanban tworzy kopię lustrzaną usprawnionego zarządzania zapasami supermarketów, dzięki czemu zadania przemieszczają się między procesami tworzenia oprogramowania dokładnie wtedy, gdy jest to potrzebne.

Zadania, przedstawiane na tablicach Kanban jako karty, umożliwiają przejrzyste śledzenie postępów i szybką identyfikację wąskich gardeł. Dzięki ograniczeniu prac w toku (WIP) zespoły optymalizują alokację zasobów i utrzymują stały przepływ pracy. Nacisk Kanban na ustawiczne doskonalenie ułatwiają wskaźniki, takie jak wykresy kontrolne i kumulacyjne diagramy przepływu, umożliwiając zespołom iteracyjne doskonalenie przepływów pracy.

Przy tworzeniu oprogramowania przepływ Kanban sprzyja dynamicznemu zarządzaniu zadaniami, przyspiesza cykle dostaw i zwiększa satysfakcję klientów dzięki nieprzerwanej pracy w skupieniu. W istocie przepływ Kanban jest przejawem wydajności — harmonijnym połączeniem przejrzystości, zdolności adaptacyjnych i ustawicznego doskonalenia — uwalniając pełny potencjał metodologii Agile.

Ustanowienie zorganizowanego przepływu Kanban w zespole programistycznym jest niezbędne do skutecznego wdrożenia metodologii Kanban. Zapewnia to płynny postęp w realizacji zadań i zoptymalizowane zarządzanie przepływem pracy. Oto jak można zorganizować przepływ Kanban:

Wizualizacja przepływu pracy: zacznij od wizualizacji przepływu pracy zespołu na tablicy Kanban. Zarówno tablica fizyczna, jak i wirtualna powinna przedstawiać każdy etap procesu tworzenia oprogramowania, od rozpoczęcia do zakończenia zadania.

Standaryzacja przepływu pracy: zdefiniuj i znormalizuj etapy przepływu pracy zgodnie z procesami i wymaganiami zespołu. Typowe etapy to „Do zrobienia”, „W toku” i „Gotowe”, ale dostosowuj je do potrzeb, aby odzwierciedlały konkretny przepływ pracy.

Identyfikacja blokerów i zależności: upewnij się, że tablica Kanban umożliwia natychmiastową identyfikację blokerów i zależności. Ta przejrzystość pozwala na szybkie rozwiązywanie problemów i zapobiega zakłóceniom przepływu pracy.

Ustawienie limitów pracy w toku (WIP): wdrażaj limity WIP dla każdego etapu przepływu pracy, aby uniknąć przeciążenia i utrzymać stały przepływ pracy. Limity WIP pomagają zoptymalizować alokację zasobów i ograniczyć wielozadaniowość, sprzyjając wyższej produktywności.

Zachęcanie do współpracy: rozwijaj kulturę współpracy w zespole, w ramach której członkowie wspólnie usuwają wąskie gardła i wspólnie zapewniają płynny przepływ pracy. To podejście oparte na współpracy sprzyja wydajności i przyspiesza realizację zadań.

Wykorzystanie kart Kanban: przedstaw każde zadanie na tablicy jako kartę Kanban zawierającą istotne szczegóły, takie jak opis zadania, osoba przypisana i szacunkowy czas wykonania. Karty Kanban ułatwiają wzrokowe śledzenie postępów w realizacji zadań i sprzyjają przejrzystości w zespole.

Organizując przepływ Kanban w ten sposób, możesz usprawnić procesy tworzenia oprogramowania i współpracę zespołu oraz zmaksymalizować wydajność zarządzania zadaniami.

Kanban jest metodyką szeroko stosowaną przez dzisiejsze zespoły programistyczne Agile i DevOps, jednak jej początków należy szukać ponad 50 lat wcześniej. Pod koniec lat 40. XX wieku firma Toyota rozpoczęła optymalizację procesów inżynierskich w oparciu o model, który wykorzystywano do uzupełniania towaru na półkach w supermarketach. 

Przechowywano w nich tylko tyle towaru, ile było potrzeba do zaspokojenia popytu. Taka praktyka umożliwiała optymalizację przepływu między supermarketem a klientem. Dzięki dostosowaniu poziomu zapasów do wzorców konsumpcyjnych supermarket znacznie zwiększył efektywność zarządzania zapasami, ograniczając nadwyżkę zapasów magazynowych, jakie musiał mieć do dyspozycji w dowolnym momencie. Jednocześnie supermarket nadal zapewniał dostępność niezbędnych produktów w magazynie.

Gdy firma Toyota zastosowała podobny system w swoich halach produkcyjnych, jej celem było lepsze zsynchronizowanie ogromnych poziomów zapasów z rzeczywistym zużyciem materiałów. Aby informować o poziomach mocy przerobowych w czasie rzeczywistym na terenie hali (i przekazać te informacje dostawcom), pracownicy przekazywali kartę (nazywaną „Kanban”) między zespołami. 

Gdy ktoś opróżnił pojemnik z materiałami używanymi na linii produkcyjnej, kartę Kanban przekazywano do magazynu wraz z m.in. opisem potrzebnego materiału i jego dokładną ilością. W magazynie miał czekać nowy pojemnik z takim materiałem, który w takiej sytuacji wysyłano do hali produkcyjnej, po czym magazyn przekazywał dostawcy własną kartę Kanban. Chociaż proces ten ewoluował od lat 40. XX wieku, ten sam proces produkcji „just in time” (JIT) pozostaje sercem metodologii 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 ciągłym 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 dostępu 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 unikatowym 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 pojedyncze ź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.

Elastyczność planowania

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ść.

Krótsze cykle czasowe

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.

Mniej wąskich gardeł

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.

Wskaźniki wizualne

Jedną z podstawowych wartości jest silna koncentracja na ciągłej poprawie wydajności i skuteczności zespołu z każdą kolejną iteracją pracy. Wykresy są dla zespołów wizualnym mechanizmem, który pozwala im upewnić się, że stale się doskonalą.

Gdy członkowie zespołu widzą dane, łatwiej jest im wykryć (i usunąć) wąskie gardła w procesie. Dwoma popularnymi raportami, z których korzystają zespoły Kanban, są wykresy kontrolne i kumulacyjne diagramy przepływu. Wykres kontrolny ilustruje czas cyklu każdego zgłoszenia, a także średnią kroczącą dla zespołu.

Kumulacyjny diagram przepływu ilustruje liczbę zgłoszeń w poszczególnych stanach. 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

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 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ół 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 ich ze sobą mylić.

Niektóre zespoły łączą ze sobą ideały przyświecające koncepcjom Kanban i Scrum w metodyce „scrumban”. Zapożycza się w niej 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.

Jednak 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. Jeśli Twój zespół jest gotowy, aby skorzystać z metodyki Kanban, użyj naszego bezpłatnego szablonu tablicy Kanban już dziś!