Kanban – wprowadzenie

Data ostatniej modyfikacji: 18 lutego 2013

Zapewne zwróciliście uwagę na “zegarki” wręczane wam przy wejściu na basen. Czy czekaliście kiedyś w kolejce przed wejściem, ponieważ akurat w kasie ich zabrakło? A może obserwowaliście jak obsługiwane jest wasze zamówienie w McDonald's? W tych (i zapewne w wielu innych) sytuacjach zetknęliście się z implementacjami technik sygnalizacji i monitorowania przepływu produktu przez system produkcyjny.

Kanban jest niczym innym jak techniką sygnalizacyjną stosowaną w systemach “ciągnionych” (pull). W uproszczeniu system “ciągniony” w odróżnieniu od systemów “pchanych” (push), sterowany jest bezpośrednio przez składane przez odbiorcę zamówienie, a nie ogólny, arbitralny plan produkcji. Za pomocą techniki kanban zapewnia się ciągły przepływ produktu przez system produkcyjny (flow), a także ciągłą optymalizację tego systemu pod kątem jego przepustowości, wydajności i efektywności kosztowej.

Geneza

Kanban stanowi jedną z podstaw systemów produkcyjnych Toyoty (Toyota Production System, TPS) i pochodnych, opartych o zasadę pull. W przemyśle kanban przyjmuje postać fizycznej, plastikowej lub papierowej karty, która opisuje liczbę podzespołów potrzebnych na danym stanowisku pracy, aby to stanowisko mogło kontynuować pracę.

Z drugiej strony kanban służy również do oznaczania podzespołów przekazywanych ze stanowiska na stanowisko. Monitorowanie w ten sposób przebiegu produkcji pozwala na obniżanie stanów magazynowych i kosztów ich obsługi, przyczyniając się do zwiększenia efektywności całego systemu. Istotne jest tu spojrzenie holistyczne, skupiające się na optymalizowaniu całości systemu a nie jego poszczególnych elementów.

Pierwsze udokumentowane zastosowanie techniki kanban w inżynierii oprogramowania pojawia się około 2004 roku, przede wszystkim w pracach Davida J. Andersona bazujących na doświadczeniach zespołów wytwarzających oprogramowanie w firmach Microsoft i Corbis.

Kanban i agile

Rozwój oprogramowania jest wyrazem twórczej aktywności, a jego wytworem nie jest fizyczny produkt. Chociaż proces wytwarzania oprogramowania znacząco różni się od procesów przemysłowych, niektóre idee z nich zaczerpnięte mogą być z powodzeniem stosowane. W szczególności idea przepływu produktu przez system, podczas którego systematycznie zwiększana jest jego wartość, stoi u podstaw wszystkich metodyk zwinnych (agile).

Większość z nich opiera swoje działanie na bardzo krótkich cyklach produkcyjnych, regulowaniu wykonywanej pracy za pomocą zarządzania kolejkami (backlog), ograniczaniu ilości pracy “niezakończonej” (work-in-progress, WIP) i eliminowaniu strat (waste). Najbardziej jawnie do tych idei odwołującą się metodą jest Lean Software Development autorstwa Mary i Toma Poppendieck.

Kanban w procesie produkcji oprogramowania

Fizyka cieczy pokazuje, że zwiększenie ciśnienia ponad miarę może doprowadzić do zjawiska niezgodnego z intuicją – spadku przepustowości (tzw. przepływ laminarny a turbulentny). Warto zapamiętać tę analogię - jest bardzo prawdziwa w przypadku produkcji oprogramowania w dużych organizacjach.

Często, pod wpływem dobrej koniunktury lub aby maksymalnie wykorzystać dostępne zasoby na przykład wobec przestojów spowodowanych nieefektywnością (blokadami, opoźnieniami), podejmowane są kolejne zobowiązania, co skutkuje równoległą realizacją wielu projektów. Zdecydowanie korzystniej zaś jest zapewnić realizację tych projektów w sposób sekwencyjny.

Analogii ciąg dalszy

Na każdy system, czy proces produkcji, można spojrzeć jak na rurociąg do którego z jednej strony wprowadzamy żądania dostarczenia nowego, rozbudowy czy naprawy istniejącego produktu, a z drugiego końca którego, po upływie określonego czasu, spodziewamy się gotowego produktu. Proces produkcji przedstawiony w ten sposób, w szczegółach realizacyjnych może być nieformalnym procesem ad hoc, lub przeciwnie, może to być bardzo sformalizowany proces produkcji.

Rozpatrywana skala czasowa, którą przyrównać można do długości rurociągu, może być znacząco różna — od kilku– czy kilkunastodniowej iteracji stosowanej w zwinnych podejściach, po wielomiesięczne projekty, reliazowane przy użyciu kaskadowych procesów produkcji.

Bez względu na szczegóły realizacji, każdy system ma określoną przepustowość, w każdym występują przewężenia i zatory. Przez niektóre jego odcinki produkt przepływa swobodnie i szybko nabiera wartości, przez niektóre z trudem się przeciska, a w niektórych zatrzymuje się na długie okresy czasu.

Jawne odniesienie się do etapowości procesu wytwarzania oprogramowania może powodować nieprzyjemne skojarzenia z procesami kaskadowymi. Bez wątpienia jednak, nawet w zespołach najpełniej stosujących podejście zwinne, zawsze występują przynajmniej trzy stany pracy — do zrobienia, w trakcie, gotowe.

Etapowość jest szczególnie widoczna w tych zespołach, których zadaniem jest utrzymanie produktu (maintenance). Dla każdego rozwiązywanego problemu często stosowane są stany: zalogowanie defektu, klasyfikacja i przypisanie do odpowiedniej grupy/osoby, odtworzenie w kontrolowanych warunkach, analiza, naprawa, testowanie i wdrożenie. Ponadto w zespołach interdyscyplinarnych występuje zjawisko przekazywania pracy pomiędzy specjalistami z różnych dziedzin — projektant, webdeveloper, programista, tester.

To właśnie te etapy realizacji, mogą zostać zobrazowane a następnie cały proces może być optymalizowany za pomocą techniki kanban.

Wąskie gardła

Dla uproszczenia przyjmijmy, że rozważany proces produkcji oparty jest o trzy etapy, na przykład: (1) analiza, (2) implementacja, (3) testowanie. W rozważanym przypadku załóżmy, że zespół testowy jest zdolny do przetestowania jedynie 4 funkcjonalności miesięcznie, podczas gdy zespoły analityczny i deweloperski przetwarzają po 10 funkcjonalności miesięcznie.

Ponieważ dział testowy stanowi oczywiste wąskie gardło, całkowita przepustowość naszego systemu równa jest czterem funkcjonalnościom miesięcznie. Jeżeli pozostałe działy będą kontynuować pracę w dotychczasowym tempie (realizując kolejne projekty) praca będzie się kumulować w dziale testów.

Kanban

Efekt ten powoduje, że mimo szybkiego tempa przetwarzania w początkowych etapach procesu, zwiększa się całkowity czas przebywania produktu w systemie (czyli od chwili podjęcia zobowiązania do momentu wypuszczenia oprogramowania na rynek), a co za tym idzie zwiększa się dystans do końcowego odbiorcy.

Z ekonomicznego punktu widzenia każde opóźnienie w procesie produkcji powoduje, że wartość końcowa produktu spada, a “innowacje stają się imitacjami”. Co więcej, produkt przebywający na linii produkcyjnej wymaga ciągłych nakładów. Wiąże zasoby (ktoś musi się nim przecież zajmować) oraz niesie ze sobą potencjalne ryzyko (wciąż można wprowadzić defekt, lub klient może zmienić wymagania), co tylko pogarsza ogólny rozrachunek ekonomiczny przedsięwzięcia.

Identyfikacja wąskich gardeł

Wszystkim praktykom doskonale znany jest efekt “prawie gotowe!” (czasem występujący w wariancie “u mnie działa!”), kiedy ostatnie 10% dewelopmentu zajmuje tyle samo (lub więcej) czasu co poprzednie 90%. Syndrom ten jest powszechny i niestety ciągnie się za nami od lat — patrz reguła 90–90).

Im dłuższy rurociąg, tym trudniej jest odkrywać wąskie gardła, a tym samym trudniej doskonalić proces wytwórczy, przede wszystkim ze względu na długi czas upływający od momentu wprowadzenia usprawnienia do chwili zweryfikowania płynących z niego korzyści. Ponieważ związek przyczynowo–skutkowy nie jest oczywisty, wiele potencjalnych usprawnień nie przynosi pożądanego efektu, lub skutek ich wprowadzenie jest zgoła przeciwny do założonego.

Bezrefleksyjna próba zwiększenia przepustowości systemu (na przykład poprzez wytworzenie odpowiednio wysokiej presji na zespół testów z naszego przykładu) może doprowadzić do obniżenia całkowitej jakości wytwarzanego produktu. Co więcej, takie zjawisko może pojawić się nawet samoistnie, bez ingerencji kierownictwa. Chęć nadążenia, dorównania działom analizy i rozwoju oprogramowania, może prowadzić do “ścinania zakrętów” przez zespół testerski. Wypuszczenie wadliwego produktu na rynek zwykle prowadzi do zwiększenia kolejki żądań na początku systemu (klienci będą domagać się dotrzymania podjętych już zobowiązań i usunięcia wad w produkcie już dostarczonym), co tylko pogarsza sytuację.

Mając świadomość istnienia problemu w powyższym przykładowym procesie, można próbować dynamicznie zmieniać rozkład odpowiedzialności. Przykładowo, w razie wystąpienia zatoru w obszarze testów, kilkoro analityków może wesprzeć zespół testerski.

Jest to idea towarzysząca tworzeniu niewielkich, interdyscyplinarnych zespołów promowanych m.in. przez metodę Scrum. Oczywiście nasz przykładowy system jest trywialny, prawdziwe problemy zaczynają się mamy do czynienia ze złożonymi przedsięwzięciami dużej skali, angażującymi dziesiątki, setki czy nawet tysiące osób. Wąskie gardła takiego systemu nie są łatwe do wychwycenia, bądź, co obserwuje się szczególnie często w produkcji oprogramowania, ich lokalizacja dynamicznie się zmienia (każde nowe wymaganie niesie ze sobą nowe wyzwania i nowe problemy, i wymaga wypracowania nowego podejścia do jego rozwiązania).

Kanban pozwala ujawniać wąskie gardła na bieżąco

Zastosowanie techniki kanban w produkcji oprogramowania jest bardzo proste i jednocześnie efektywne. W swojej najprostszej formie metoda ta może przyjąć postać tablicy podzielonej na pionowe obszary (kolumny) reprezentujące kolejne etapy procesu. Elementy wytwarzanego produktu — wymagania, historie użytkownika, defekty do naprawienia — przedstawione są za pomocą kart, które “przepływają” przez kolejne etapy procesu, z lewej strony na prawą. Liczba przy każdej kolumnie reprezentuje górny limit elementów, które mogą znajdować się na danym etapie produkcji.

Limity te stanowią najbardziej istotną różnicę pomiędzy techniką kanban, a jakąkolwiek inną techniką wizualizacji procesów produkcyjnych. Wprowadzenie, obserwacja i regulowanie jawnych ograniczeń “pracy będącej w toku” (work-in-progress, WIP), na każdym z etapów produkcji, zapobiega nadprodukcji i pozwala kontrolować wąskie gardła.

System kanban w procesie wytwarzania oprogramowania

Przykładowa tablica obok reprezentuje sytuację, w której zespół deweloperski, funkcjonujący w systemie jako dostawca (upstream), nie może podjąć się żadnej dodatkowej, nowej pracy, dopóki odbiorca (downstream), czyli zespół testerski, nie zwolni jednej z pozycji w przetwarzanej kolejce. Kolejka wejściowa (backlog) osiągnęła swój limit, wobec czego nie jest możliwe podjęcie przez cały zespół nowych zobowiązań. Oprócz odzwierciedlenia kolejnych etapów produkcji, w przykładzie poniżej wprowadzono dodatkowe kolumny, jawnie opisujące kolejki wyjściowe każdego etapu, kumulujące elementy gotowe do przejęcia przez kolejną grupę.

Istnieje wiele możliwości wizualizacji procesów produkcyjnych za pomocą tej techniki. Przedstawiona tutaj jest stosunkowo prosta. Ograniczenia na górze kolumn obejmują oba wewnętrzne stany każdego etapu — “w trakcie” i “gotowe”. Zwykle dodaje się także logikę wizualizacji i postępowania z zadaniami zablokowanymi przez zewnętrzne zależności, typami zadań i przypisaniem zadań do poszczególnych członków zespołu. Czasami definiuje się zadania priorytetowe, przyspieszone (silver bullet), którym zespół poświęca swoją uwagę całkowicie.

W procesach przemysłowych, operujących na fizycznych produktach, ten drugi, wewnętrzny etap, ma zwykle postać magazynu (store), w którym składowane są półprodukty. Można go również postrzegać jako bufor lub kolejkę, z której kolejny etap produkcji (downstream) “wyciąga” dokładnie tyle elementów, ile w danym momencie może wykorzystać lub obsłużyć. Taka strategia nazywana jest działaniem "dokładnie na czas" (just-in-time, JIT).

System kanban w procesie wytwarzania oprogramowania

Ta analogia do fizycznego produktu pozwala pełniej zrozumieć dlaczego nadprodukcja jest marnotrawstwem — przemieszczanie półproduktów pomiędzy stanowiskami, ich przechowywanie, wszystko to wymaga przestrzeni magazynowej oraz nakładów związanych z jej obsługą, w ogólnym rozrachunku zwiększając czas przebywania produktu w systemie.

W kolejnym kroku naszego przykładu testerzy kończą testowanie jednego z elementów i przenoszą odpowiadającą mu kartę do kolumny “gotowe”, dając sygnał zespołowi wdrożeniowemu, że można rozpocząć wdrożenie tego elementu. Jednocześnie zwolnione zostało jedno miejsce w kolumnie “w trakcie”.

Zwolniona pozycja może teraz zostać wypełniona przez jedną z kart z kolumny “gotowe” z etapu “development”. To z kolei umożliwia przesunięcie jednej karty z etapów wcześniejszych (upstream) — w naszym przypadku wprost z kolejki wejściowej. W ten sposób zakończenie pracy w etapie późniejszym inicjuje, pociąga (pull) elementy produktu z etapów wcześniejszych. W tym procesie odbiorca końcowy jest ostatnim ogniwem łańcucha i niejako "wyciąga" produkt z naszego rurociągu.

System kanban w procesie wytwarzania oprogramowania

Ponieważ kanban nie jest tylko i wyłącznie techniką wizualizacji stanu procesu produkcji, a przede wszystkim narzędziem do jego doskonalenia, w naszym przykładzie należałoby w pierwszej kolejności znaleźć sposób na odblokowanie zespołu testów (np. poprzez udzielenie mu wsparcia przez zespół deweloperski). W dalszej perspektywie należałoby poszukać sposobów na zbalansowanie zależności pomiędzy tymi dwoma zespołami, a także zespołem wdrożeń, którego zdolność produkcyjna jest wyższa niż obecnie wykorzystywana. Kontynuowanie pracy przez zespół deweloperski tylko pogarsza sytuację i jest krótkowzroczną strategią maksymalnego wykorzystania wszystkich dostępnych zasobów.

Sześć reguł kanbana

Kanban wymaga dyscypliny i kultury stosowania. W procesach przemysłowych obowiązuje kodeks sześciu reguł:

  1. odbiorca przetwarza dokładnie tyle elementów, ile opisane jest na karcie kanban (sygnalizacja na kierunku upstreamdownstream),
  2. dostawca wytwarza dokładnie tyle elementów, ile opisane jest na karcie kanban (sygnalizacja na kierunku downstreamupstream),
  3. żaden element nie jest wytwarzany lub przekazywany pomiędzy stanowiskami bez karty kanban,
  4. karta kanban musi towarzyszyć każdemu elementowi czy półproduktowi przetwarzanemu w ramach systemu,
  5. elementy wadliwe lub występujące w niewłaściwych ilościach, nigdy nie są przekazywane w dół procesu (odbiorcom), a przyczyna ich pojawienia się w systemie jest analizowana i eliminowana (idea stop the line),
  6. limity obowiązujące na każdym z etapów (fizyczna ilość kart kanban) są stopniowo obniżane aby redukować zapasy i odkrywać nieefektywności procesów produkcji, dążąc do ich doskonalenia

Zastosowanie tych reguł do produkcji oprogramowania jest tym bardziej zasadne i tym trudniejsze jednocześnie, że operujemy zwykle na niematerialnym produkcie, w związku z czym trudniej jest zauważyć przewężenia systemu, nawarstwiające się zadania i wynikające z nich konsekwencje dla całego procesu produkcji. Z tego powodu wizualizacja stanu bieżącego i dbałość o jego aktualność jest kluczowa dla tego typu podejścia.

Podsumowanie

Kanban jest techniką pozwalającą identyfikować niewydolności systemu i przy odpowiedniej kulturze użycia sprawia, że organizacja bardziej świadomie (np. poprzez analizę statystyczną) podchodzi do problemu wąskich gardeł w procesie produkcyjnym i poświęca więcej uwagi usuwaniu rzeczywistych powodów ich istnienia. Tak rozumiany kanban jest narzędziem służącym ciągłemu doskonaleniu procesu produkcji i zwiększaniu efektywności całej organizacji.

W procesach przemysłowych kanban nierozerwalnie powiązany jest z pojęciem kaizen (doskonalenie procesów) zachodzącym w gemba (miejscu pracy), pojęciem ciągłego przepływu (flow), pojęciem taktu (cadence), oraz pojęciem niedoskonałości procesu. Niedoskonałości są zwykle kategoryzowane przy użyciu japońskich terminów:

  • mura — brak regularności (czas przebywania produktu w systemie jest różny, zachodzące procesy cechuje podejście ad hoc, organizacja pogrążona jest w chaosie); najpierw należy ustanowić system “ciągniony”, uzyskać ciągły przepływ, dopiero w kolejnych krokach skupić się na zwiększaniu jego efektywności
  • muri — przeładowanie systemu (procesu, osób); próba wtłoczenia do systemu większej ilości pracy niż jest on w stanie przyjąć
  • muda — tradycyjne rozumiane marnotrawstwo (klasyczne 7 źródeł marnotrawstwa skategoryzowane i opisane przez Taichi Ohno).

Nie bez znaczenia jest “fizyczność” tej techniki (fizyczne karty umieszczone na tablicy). Wykorzystanie prostych technik wizualizacji jest nie tylko wygodne (łatwo dostosowuje się je do zmian procesu), ale także stymuluje pracę zespołową i zespołową analizę i rozwiązywanie sytuacji problemowych.

Warto zwrócić uwagę, że kanban nie implikuje iteracyjnego podejścia. W systemach ciągnionych operuje się raczej pojęciami ciągłego przepływu (flow), strumienia wartości (value stream) i głębokości kolejek, niż określonego czasu trwania cyklu produkcyjnego. Niemniej jednak, wykorzystanie jawnie wyodrębionych iteracji nie stoi w sprzeczności z systemem kanban, a często stanowi wręcz wstępny krok w jego kierunku.

Po pewnym czasie taki podział może się okazać sztuczny. Produkt będzie przekazywany klientowi w stałym rytmie, w miarę jak kolejne elementy będą przypływać przez system w sposób asynchroniczny, nie powiązane ze sobą. Zespoły efektywnie stosujące kanban podejmują zobowiązania co do czasu, w którym funkcjonalność zgłoszona przez klienta zostanie mu przekazana (service level agreement, SLA). Zwykle jest to kilka–kilkanaście dni upływających od chwili złożenia przez klienta żądania na kolejkę wejściową, do momentu wdrożenia gotowej funkcjonalności.

Elementem podlegającym systemowi kanban mogą być pojedyncze zadania będące przedmiotem pracy jednej osoby, wymagania, opowieści użytkownika, defekty, czy ogólniej rzecz biorąc, kolejne pozycje rejestru produktowego (backlog items). Mogą to być również całe wydania (release) grupujące zestawy funkcjonalności reprezentujące realną, biznesową wartość dla odbiorcy końcowego (minimal marketable feature, MMF).

Najlepsze rezultaty technika ta przynosi tam, gdzie jej zasięg obejmuje cały system produkcji — od marketingu po dział wdrożeń czy dystrybucję — a nie ogranicza się tylko do działu rozwoju oprogramowania, czy pojedynczych zespołów. Kanban łączony bywa ze Scrumem (scrum-ban), przede wszystkim w celu wypracowania kultury pracy zespołowej oraz sekwencyjnego podejmowania i realizacji zobowiązań, a także w celu odkrywania niedoskonałości procesu produkcji. Kanban często jest podstawową techniką organizacji pracy w zespołach utrzymaniowych oraz tych, które mają problemy z utrzymaniem dyscypliny sprintów.

Komentarze (3)

  • Radek

    Radek

    13 kwietnia 2011 o 15:37 |
    Świetny artykuł o kanbanie.
  • Mike

    Mike

    02 grudnia 2011 o 17:50 |
    Bardzo dobry artykuł wprowadzający do tematyki
  • Marcin

    Marcin

    31 lipca 2013 o 13:48 |
    Gdyby w podobny sposób autor przedstawił SCRUM i do tego zestawił te metody ze sobą było by ekstra. Taka mała propozycja na backlog :)

Zapraszam do komentowania.

Komentujesz jako Gość. Opcjonalny login poniżej.