|
16 listopada 2009
Czy 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). System “ciągniony” w odróżnieniu od systemów “pchanych” (push), sterowany jest bezpośrednio przez składane przez klienta 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 nie jest nowym wynalazkiem, stanowi on 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.
Rozwój oprogramowania jest wyrazem twórczej aktywności, a jego wytworem nie jest fizyczny produkt. I 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 ciągłego przepływu produktu przez system, podczas którego systematycznie zwiększana jest jego wartość, stoi u podstaw wszystkich metodyk lekkich (agile). Większość z nich opiera swoje działanie na ekstremalnie 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.
Technika sygnalizacji Kanban w procesie produkcji oprogramowania
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. Również rozpatrywana skala czasowa (długość rurociągu) może być znacząco różna - od kilku- czy kilkunastodniowej iteracji stosowanej w lekkich metodykach, po wielomiesięczne, kaskadowe procesy 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 metodyki lekkie, zawsze występują przynajmniej dwa etapy pracy - rozwój oprogramowania i jego wdrożenie. Etapowość jest szczególnie widoczna w tych zespołach, których zadaniem jest utrzymanie produktu (maintenance) - zalogowanie defektu, jego klasyfikacja, odtworzenie w kontrolowanych warunkach, analiza, naprawa, testowanie i wdrożenie. Ponadto, nawet 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 przekazania, czy 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 naszym 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 4-em 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.
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 klienta. 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.
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 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 - upraszczając niego sprawę - 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 - na przykład w razie wystąpienia zatoru w obszarze testów, kilkoro analityków może wesprzeć zespół testerski. Oczywiście nasz przykładowy system jest trywialny, prawdziwe problemy zaczynają się gdy wąskie gardła systemu nie są znane, bądź, co obserwuje się bardzo często w produkcji oprogramowania, ich lokalizacja dynamicznie się zmienia (każde nowe wymaganie niesie ze sobą nowe wyzwania i nowe problemy).
Kanban pozwala ujawniać wąskie gardła na bieżąco
Technika kanban jest ekstremalnie prosta i jednocześnie bardzo efektywna. W swojej najprostszej formie 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. To właśnie te limity 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.
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) - zespół testerski - nie zwolni jednej z pozycji w przetwarzanej kolejce. Co więcej, kolejka wejściowa (backlog) również 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 kolejny zespół.
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).
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 klient jest ostatnim ogniwem łańcucha i pociąga produkt z naszego rurociągu.
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
Oczywiście jak każdy proces, tak i kanban wymaga dyscypliny i kultury stosowania, aby efektywnie spełniać swoją rolę. W procesach przemysłowych obowiązuje kodeks sześciu reguł:
- odbiorca przetwarza dokładnie tyle elementów, ile opisane jest na karcie kanban (sygnalizacja na kierunku upstream—downstream),
- dostawca wytwarza dokładnie tyle elementów, ile opisane jest karcie kanban (sygnalizacja na kierunku downstream—upstream),
- żaden element nie jest wytwarzany lub przekazywany pomiędzy stanowiskami bez karty kanban,
- karta kanban musi towarzyszyć każdemu elementowi czy półproduktowi przetwarzanemu w ramach systemu,
- 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,
- 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.
Zastosowanie tych reguł do produkcji oprogramowania jest tym bardziej zasadne, i tym trudniejsze jednocześnie, że operujemy zwykle na niematerialnym produkcie - porcjach informacji, 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.
Podsumowanie
Kanban jest techniką pozwalającą identyfikować niewydolności systemu i przy odpowiedniej kulturze użycia sprawia, że organizacja bardziej świadomie 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:
Fizyka cieczy pokazuje, że zwiększenie ciśnienia ponad miarę może doprowadzić do dalszego zmniejszenia się przepustowości (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, podejmowane są kolejne zobowiązania, co skutkuje równoległą realizacją wielu projektów. Tymczasem zdecydowanie korzystniej jest, inaczej rozkładając dostępne zasoby, zapewnić realizację tych projektów w sposób sekwencyjny. To z kolei wymaga wielofunkcyjnych zespołów, a to już zupełnie inny temat...- 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 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ą.
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, podział procesu produkcyjnego na iteracje nie stoi w sprzeczności z systemem kanban, a często stanowi wręcz wstępny krok w jego kierunku. Po pewnym czasie jednak 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.
Kanban stosowany jest na różną skalę, w zależności od potrzeb i dojrzałości organizacji. 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 z metodyką Scrum (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.
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.
Bibliografia
- Ohno, Taiichi, Toyota Production System, 1984
- Liker, Jeffrey, The Toyota Way, 2003
- Poppendieck, Mary, Poppendieck, Tom, Implementing Lean Software Development, 2006
- Limited WIP Society
