Kanban

Zastosowanie metodyki Kanban w procesie tworzenia oprogramowania

Przeglądaj tematy

Czym jest Kanban?

Kanban to popularne ramy postępowania stosowane do wdrażania procesów programistycznych Agile i DevOps. Wymagają one informowania o potencjale wykonawczym w czasie rzeczywistym i zapewnienia pełnej przejrzystości pracy. Jednostki pracy są prezentowane w formie wizualnej na tablicy Kanban, umożliwiając członkom zespołu śledzenie stanu każdego elementu prac przez cały czas.

Tablica Jira

Zacznij korzystać bezpłatnie z szablonu Jira Kanban

Użyj szablonu

Artykuły dotyczące metodyki Kanban

[KONTYNUACJA]

Kanban jest metodyką szeroko stosowaną wśród współczesnych zespołów programistycznych Agile i DevOps, jednak jej początki sięgają ponad 50 lat wstecz. 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. Dokładano w nich tylko tyle towaru, aby zaspokoić popyt. 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ększał efektywność zarządzania zapasami, ograniczając ilość zapasów magazynowych, jakie musiał mieć do dyspozycji w dowolnym momencie. Jednocześnie supermarket zapewniał, że produkt, którego klient potrzebuje, jest nadal na stanie.

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 dostawców), pracownicy przekazywali kartę (nazywaną „Kanban”) między zespołami. Po opróżnieniu pojemnika z materiałami używanymi na linii produkcyjnej kartę Kanban przekazywano do magazynu wraz z opisem potrzebnego materiału, jego dokładnej ilości itp. W magazynie miał czekać nowy pojemnik z takim materiałem, który w takiej sytuacji wysyłano do hali produkcyjnej, po czym magazyn przekazywał do dostawcy własną kartę Kanban. U dostawcy również czekał pojemnik tego konkretnego materiału, który był wówczas wysyłany do magazynu. Choć stosowana w tym procesie technologia sygnalizacji rozwinęła się od lat 40. XX wieku, serce tego procesu do dziś stanowi ten sam proces produkcyjny „just-in-time” (lub JIT), co oznacza „dokładnie na czas”.

Kanban dla zespołów programistycznych

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.

Tablica Kanban | Atlassian Agile Coach

While the core principles of the framework are timeless and applicable to almost any industry, software development teams have found particular success with the agile practice. In part, this is because software teams can begin practicing with little to no overhead once they understand the basic principles. Unlike implementing kanban on a factory floor, which would involve changes to physical processes and the addition of substantial materials, the only physical things software teams need are a board and cards, and even those can be virtual.

Tablice kanban

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.

Tablica Kanban Agile | Atlassian Agile Coach

Karty Kanban

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.

Zalety metodyki Kanban

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.

Elastyczność planowania

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.

Wskazówka eksperta:

Doświadczeni product ownerzy zawsze angażują zespół programistyczny w rozważania nad zmianami w backlogu. Jeśli na przykład w backlogu znajdują się historyjki użytkowników 1–6, może się okazać, że szacunki dotyczące historyjki nr 6 są zależne od ukończenia historyjek 1–5. Zawsze dobrze jest konsultować zmiany z zespołem inżynierskim, aby uniknąć niespodzianek.

Krótsze cykle czasowe

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.

Overlapping skill sets lead to smaller cycle times. When only one person holds a skill set, that person becomes a bottleneck in the workflow. So teams employ basic best practices like code review and mentoring help to spread knowledge. Shared skills mean that team members can take on heterogeneous work, which further optimizes cycle time. It also means that if there is a bottleneck of work, the entire team can swarm on it to get the process flowing smoothly again. For instance, testing isn't only done by QA engineers. Developers pitch in, too.

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

Mniej wąskich gardeł

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.

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ą w przypadku zespołu.

Wskazówka eksperta:

Celem zespołu jest ograniczenie czasu potrzebnego na przejście zgłoszenia przez cały proces. Spadek średniego czasu cyklu na wykresie kontrolnym jest wskaźnikiem sukcesu.

Wykres kontrolny Agile | Atlassian Agile Coach

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.

Wykres przepływu skumulowanego

Ciągłe dostarczanie

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.

Porównanie Scrum i Kanban

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

Scrum

Kanban
Kadencja

Regularne sprinty o stałej długości (np. dwutygodniowe)

Ciągły przepływ
Metodologia wydawania Pod koniec każdego sprintu po zatwierdzeniu przez product ownera Ciągłe dostarczanie lub według uznania zespołu
Rola Product owner, Scrum Master, zespół programistyczny Brak konkretnych ról. Niektóre zespoły korzystają z pomocy Agile coacha.
Kluczowe wskaźniki Prędkość Czas cyklu
Filozofia dotycząca zmian Zespoły powinny starać się nie wprowadzać zmian w prognozach sprintu w trakcie jego trwania. Takie działania utrudniają wyciąganie wniosków związanych z szacunkami. Zmiana może nastąpić w dowolnej chwili

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.

Tablica Jira

Zacznij korzystać bezpłatnie z szablonu Jira Kanban

Użyj szablonu
Dan Radigan
Dan Radigan

Koncepcja Agile wywarła na mnie ogromny wpływ, zarówno pod względem zawodowym, jak i prywatnym. Przekonałem się, że zasady Agile sprawdzają się najlepiej tak w pisaniu kodu, jak i w życiu. Często znajdziecie mnie tam, gdzie technologia spotyka się z fotografią i motocyklami. 

Następny
Tablice