Kanban
Zastosowanie metodyki Kanban w procesie tworzenia oprogramowania
Przeglądaj tematy
Zacznij korzystać bezpłatnie z szablonu Kanban w Jira
Zmaksymalizuj wydajność, dostrzegając i wykonując prace o największym znaczeniu.
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.
Artykuły dotyczące metodyki Kanban
Dowiedz się, jak korzystać z metodyki Kanban w Jira Software
Instrukcje krok po kroku dotyczące realizacji projektów Kanban, ustalania priorytetów prac, wizualizacji przepływu pracy i minimalizowania liczby prac w Jira Software.
Przeczytaj ten samouczekOd przygotowania do realizacji z tablicami Kanban w systemie Jira
Tablicę Kanban w Jira Software opracowano z myślą o ułatwieniu zespołom ciągłego skracania czasu cyklu i zwiększania wydajności.
Zacznij korzystać za darmoKanban 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.

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

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.
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.
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.
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.
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.
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
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.
Zacznij korzystać bezpłatnie z szablonu Jira Kanban
Zmaksymalizuj wydajność, dostrzegając i wykonując prace o największym znaczeniu.
Chcesz rozpocząć już teraz?
Instrukcje krok po kroku dotyczące realizacji projektów Kanban, ustalania priorytetów prac, wizualizacji przepływu pracy i minimalizowania liczby prac w Jira Software.
Przeczytaj ten samouczekProjektowanie Agile: proces i wytyczne dotyczące projektowania opartego na współpracy
Projektowanie oparte na współpracy polega na uwzględnianiu w projekcie produktu punktu widzenia klientów i programistów już od samego początku. Dowiedz się więcej.
Przeczytaj ten artykuł