System Kanban został zapoczątkowany w latach 50-tych na liniach produkcyjnych korporacji Toyota.
Następnie przeniósł się do biur, stając się niezbędnym narzędziem menedżerów projektów.
Nieograniczona elastyczność Kanban w praktyce oraz jego zdolności do samodzielnego zarządzania zespołami
zapewniły efektywność tam, gdzie inne podejścia zawiodły. W tym przypadku karta tożsamości systemu
ustanowiła się jako zasadniczo karta, która rozwijała się dalej w wewnętrzną walutę w
zakładach, w których przyjęto Kanban.
Pochodzenie
Podobnie jak koncepcja produkcji Lean, system Kanban został opracowany przez menedżerów Toyoty.
Taiichi Ohno, japoński inżynier przemysłowy i autor systemu, zainspirował się zasadą działania amerykańskich supermarketów, gdzie kupujący sam wybierał potrzebne produkty. Magazyn odgrywał rolę takiego „supermarketu” w korporacji Toyota.
Pracownicy tam wymieniali karty sygnałowe (dosłowne tłumaczenie Kanban z japońskiego) i w ten sposób samodzielnie kontrolowali proces produkcji.
Karty były przymocowane do kontenerów z częściami. Takie etykiety wskazywały następujące szczegóły:
liczby i ilości części, dział je wysyłający oraz ich przeznaczenie. Pracownik bezpośrednio zaangażowany w montaż pojazdów (downstream) pobierał części z kontenerów z przyczepioną „Kanban” wskazującą prośbę do magazynu. Karta była zdejmowana, aby być przekazywaną, razem z pustym pudełkiem, przez pracownika transportu do magazynu, gdzie inny pracownik już przygotował inny kontener z częściami z etykietą „produkcja Kanban” wskazującą dane wyprodukowanych części.
Taka produkcja Kanban była zastępowana przez Kanban z prośbą kierowaną do magazynu, aby następnie wysłać go na linię produkcyjną części (upstream). Tak więc produkowano tylko ilość części
wskazaną w karcie. Kontenery z nowymi częściami były dostarczane do linii montażowej dla pracowników transportu.
Proces
Podstawy Kanban
Menedżerowie Toyoty sformułowali 6 zasad ramowych:
- Pracownicy downstream wycofują z magazynu dokładnie tę liczbę części, która jest wskazana w karcie Kanban
- Specjaliści upstream również dostarczają części zgodnie z kartami
- Nie produkuje się ani nie przemieszcza bez Kanban
- Kanban powinien zawsze być powiązany z częściami
- Uszkodzone części nie są używane w systemie
- Jakiekolwiek zmniejszenie liczby kart Kanban sprawia, że zarządzanie staje się bardziej wrażliwe na zmiany. Jednakże nie powinno się wprowadzać zmian w ustalonej liczbie kart, chyba że jest to absolutnie konieczne.
Kanban jest „systemem rozszerzającym”. Tworzy równowagę pomiędzy ciągłym przepływem, aby wyeliminować koszty oczekiwania z jednej strony, a minimalną ilością pracy w toku (WIP) z drugiej, co ostatecznie zmniejsza ryzyko nadprodukcji. WIP jest regulowany za pomocą kart: ich liczba jest stała, a ich instrukcje kierują pracownikami downstream.
Ścisła zasada przymocowywania etykiet działa jak prawo konserwacji energii. Limit WIP ustanawiany jest proporcjonalnie do liczby kart Kanban obliczonej na podstawie poziomu sprzedaży i statystycznych
odchyleń w bieżących procesach. Maksymalna liczba etykiet, która reprezentuje tę „energię systemu” ustala najwyższy poziom WIP w danym czasie. WIP jest również ograniczany przez
zasadę rozszerzenia: szybkość produkcji upstream zależy od wskaźnika produkcji downstream.
Wykres wyraźnie pokazuje, że kultura Kaizen jest jednym z elementów leżących u podstaw systemu.
Samowystarczalność procesów i standardowe odchylenia uwalniają zarządzanie od ciągłej
kontroli, co z kolei umożliwia skupienie się na poprawie wydajności pracowników.
Używanie Kanban w IT
System Kanban przeniknął do branży oprogramowania, jednocześnie wciąż generując wartość na
przenośnikach produkcyjnych.
Jednak karty wskazujące takie szczegóły jak terminy, opis procesu czy numer oraz nazwisko wykonawcy są teraz przymocowywane nie do kontenerów z częściami, lecz do tablicy zawierającej następujące kolumny:
Backlog — zadania do wdrożenia
- Zadania, które są aktualnie w trakcie rozwoju;
- Zadania już wdrożone, ale jeszcze nie przekazane testerom;
- Zadania gotowe do przekazania do działu testowego;
- Zadania, które są aktualnie sprawdzane przez menedżera projektu (PM);
- Zadania ukończone.
Limit liczby zazwyczaj jest wskazany nad kolumną, aby oznaczyć maksymalną liczbę
procesów w niej. Limit backlogu oblicza się na podstawie czasu realizacji. Jeśli 5 prac jest w toku,
a każda z nich może być ukończona w średnio 1 dzień, to backlog może również być
ograniczony do 5.
Powyższa struktura nie jest sztywna – możesz improwizować i dodawać kolumny w zależności od specyficznychcech twojego projektu. Systemy Kanban wymagające określenia kryteriów gotowości zadań przed ich wykonaniem są często spotykane. W takim przypadku pojawia się dwu kolumny nazwane w języku angielskim jako sprecyzuj (tj. wyjaśnij parametry) i wykonaj (tj. rozpocznij pracę).
- Można również dodać kolumnę do kolejkowania priorytetowego. Kiedy wykonawca jest wolny, powinien opróżnić tę właśnie kolumnę z zadaniami, a dopiero potem zająć się innymi.
- Niewykonane zadania wracają do backlogu lub są usuwane z wykresu.
- Kanban nie zachęca do multitaskingu, dlatego ustawia się limit procesów dla jednego wykonawcy.
- Jedna ukończona praca jest bardziej preferowana niż kilka prac, które dopiero się zaczęły.
- Drugą pracę można zacząć pod warunkiem, że pierwsza została zablokowana.
- Okres realizacji zadania powinien być zrównoważony. Zbyt krótkie okresy wpływają na jakość. Zbyt długie limity nadwyrężają zasoby zespołu i czynią proces droższym.
Zalety i wady Kanban
Kanban ma następujące zalety:
- Elastyczne planowanie. Zespół koncentruje się tylko na bieżącej pracy, a menedżer priorytetuje
- Zespół jest mocno zaangażowany w proces rozwoju. Regularne spotkania, przejrzystość procesów i możliwości samodzielnego zarządzania jednoczą zespoły i naprawdę
- Zmniejszenie czasu trwania cyklu. Jeśli kilka osób ma podobne umiejętności, czas ten się skraca, lecz jeśli tylko jedna osoba jest odpowiednio wykwalifikowana, pojawia się wąska przestrzeń. Dlatego specjaliści powinni dzielić się swoją wiedzą, tym samym optymalizując czas trwania cyklu. Umożliwi to całemu zespołowi zajęcie się pracą, która została spowolniona i przywrócenie płynności pracy.
- Zmniejszenie liczby wąskich gardeł. Limity WIP umożliwiają znalezienie wąskich i problematycznych miejsc skutkujących brakiem uwagi, zasobów ludzkich lub umiejętności.
- Widoczność. Gdy wszyscy wykonawcy mają dostęp do danych, łatwiej jest dostrzegać wąskie gardła. Poza kartami, zespoły Kanban zwykle korzystają z dwóch ogólnych rodzajów raportów: wykresów zarządzania oraz wykresów kumulacyjnych.
W praktyce system wykazuje doskonałe wyniki w takich operacjach niekluczowych jak:
- Grupy wsparcia oprogramowania lub usługi wsparcia;
- Kanban działa dobrze w zarządzaniu startupami bez jasnych harmonogramów, ale z aktywną promocją rozwoju.
Kanban ma również swoje wady:
- System działa słabo z zespołami liczącymi więcej niż 5 osób.
- Nie jest zaprojektowany do długoterminowego planowania.
Różnica względem Scrum
Tak jak Agile Kanban, Scrum jest elastyczną metodologią, która jest również często stosowana w branży IT. Na
pierwszy rzut oka różnica między nimi nie jest oczywista. Istnieje wiele podobieństw, np. obu
podejściom towarzyszy backlog.
Przykłady zastosowania w IT
Z Microsoftem od razu: debiut Kanban w dziedzinie rozwoju oprogramowania
Podstawy Kanban znalazły zastosowanie w dziedzinie technologii informacyjnych niecałe 10 lat
temu. David Anderson, jeden z głównych zwolenników Kanban dla programistów, konsultował firmę Microsoft w 2005 roku. Jeden z działów firmy, XIT Sustained Engineering, który zajmował się rozwiązywaniem problemów z aplikacjami wewnętrznymi, powodował niezadowolenie. Na początku roku sprawozdawczego ten dział okazał się najgorszy w swoim dziale. Backlog przekraczał 5 razy dopuszczalną objętość, a czas przetwarzania jednej prośby – lead time – zazwyczaj trwał 5 miesięcy.
Konsultacje Andersona umożliwiły nowemu PM zwiększenie wydajności problematycznego działu o 155% w ciągu 9 miesięcy. Lead time zmniejszył się do 5 tygodni, backlog odzyskał swoją normalną objętość, a terminowe wykonywanie zadań zostało ustalone na poziomie 90%. Wszystkie te wyniki osiągnięto przy minimalnym zaangażowaniu nowych specjalistów, a personel nadal poprawiał błędy programowe, korzystając z tych samych metod – tylko podejścia do organizacji pracy zmieniły się.
Interesujący przypadek: Dragos Dumitriou, menedżer oprogramowania, który podjął się odwrócenia sytuacji w XIT, był pochłonięty książką Andersona w tym czasie. Ku jego zaskoczeniu, spotkał ideologa oprogramowania Kanban w firmie Microsoft, w której ten ostatni pracował krótko przedtem. Dumitriou poprosił Andersona o pomoc w swoim zadaniu, a Anderson zgodził się zastosować zasady opisane w jego książce w praktyce.
Dumitriou znalazł dział składający się z trzech programistów i trzech testerów, którego backlog skumulował 80 próśb. Czas na stanowisku PM był tymczasowy, ponieważ wymagania dotyczące pracy obejmowały umiejętność obsługi technologii ASP, administracji SQL Server i znajomości MS Project Server. Kierownictwo wyżej zamierzało zatrudnić „pracownika technicznego” na to stanowisko, odpowiedzialnego za programowanie i generowanie raportów oraz przewidywanie obciążeń backlogu. Problem działu uważano za wykryty, o ile zebrano znaczne ilości danych. Dumitriou nie był tym „pracownikiem technicznym” rzeczywiście.
Jednak po rozpoczęciu analizy działania XIT z Andersonem, szybko odkrył kluczowe czynniki, które negatywnie wpływały na tempo pracy działu:
- Przewidywanie konsekwencji (ROM) wynikających z wykonania próśb zajmowało zbyt dużo czasu. Zarówno programiści jak i testerzy musieli poświęcać cały dzień roboczy na niezbędne obliczenia, weryfikację kodu i wypełnianie dokumentów. Średnio przypływać jedną prośbę dziennie. Zgodnie z obliczeniami PM, ROM wymagał 40% wydajności podziału;
- Priorytetem były prośby o wyższej wartości. XIT uzyskiwał finansowanie na podstawie budżetów zamówień.
- Priorytet zamówień był omawiany na comiesięcznych spotkaniach menedżerów podziałów z klientami – menedżerami innych podziałów. Biorąc pod uwagę rosnący backlog przy obecnym tempie, kiedy tylko 6 – 7 próśb przetwarzano w ciągu miesiąca, priorytety innych próśb stale przesuwały się w miarę upływu czasu. Wiele z nich zostało odłożonych na dalszą „potem”, co nawet nie oznaczało następnego miesiąca.
- Pół próśb wypadło na etapie ROM. Część z nich była zbyt duża, więc zostały przeklasyfikowane jako projekty i musiały zostać przekazane do innych działów, inne były zbyt kosztowne i po prostu anulowane. Niektóre prośby nie zostały przyjęte do rozwoju, ponieważ ich wprowadzenie okazało się zbyt czasochłonne. Dlatego 40% wydajności podziału marnowano na analizowanie próśb, z których 50% zostało odrzuconych. Około 15 – 20% zasobów roboczych zostało zmarnowanych.
- Wcześniejsze przygotowanie próśb mogło trwać miesiące przed rozpoczęciem wprowadzenia. Obliczenia dokonane na etapie ROM mogły zostać utracone lub zapomniane w tak długim czasie. Dotyczyło to szczególnie sytuacji, w których procedura wprowadzania była przeprowadzana przez innego programistę – nie przez tego, który rozpoczął analizę.
Rozwiązania Kanban dla problematycznego podziału Microsoftu
- W dialogu z wyższym kierownictwem i menedżerami klientów, Dumitriou i Anderson nalegali na porzucenie etapu ROM. Obliczenia bezpośrednio poprzedzały fazę wprowadzania, która była przeprowadzana przez tego samego wykonawcę, tj. zawsze pozostawały „świeże”.
- Prośby były priorytetyzowane nie na comiesięcznych spotkaniach, lecz wg potrzeb, poprzez telefony lub e‑maile. 80 zadań backlogu zostało posortowanych w zależności od klientów. Klientów poproszono o podkreślenie głównych próśb, które miały być wdrożone w pierwszej kolejności.
- Finansowanie XIT stało się ustalone.
- Koszt próśb nie był już brany pod uwagę.
- PM wprowadził bufory na tablicy Kanban. Programiści pobierali pracę z dwóch obszarów: zatwierdzonych zadań i zadań wykonanych. Bufor zawierał 6 próśb, z których 5 zostało wciągniętych do przepływu. Testery wybierały elementy z buforu „do testu”. Niektóre zadania, które nie wymagały zmian w kodzie, trafiały tam po obejściu programistów. Dzięki rozbiciu próśb na procesy jednozadaniowe, PM mógł lepiej monitorować sytuację i zapewnić przejrzystość dla klientów. Wprowadzenie buforów zmniejszyło lead time. W takim przewidywalnym systemie klienci mogli lepiej określić, która prośba była następną do wciągnięcia do buforu.
- Decyzje dotyczące zadań stawały się natychmiastowe w przypadku zbyt dużych i kosztownych próśb. Jeśli programista potwierdził swoją gotowość do realizacji zadania w ciągu 15 dni, lub jeśli zmiany były warte wprowadzenia, takie prośby były przyjmowane do realizacji niezależnie od ich objętości i kosztów.
- Monitorując przepływ pracy w dziale, PM doszedł do wniosku, że struktura personelu musi zostać przekształcona na korzyść programistów, którzy poradzą sobie z większym obciążeniem. Przekształcenie zostało przeprowadzone w proporcji 2:1: wtedy XIT składał się z 4 programistów i 2 testerów.
Według podsumowania 2005 roku, wydajność działu wzrosła o 155%. Aby dalej poprawić wyniki XIT, zaangażowano dwóch dodatkowych specjalistów: jednego programistę i jednego testera. Liczba próśb w backlogu zmniejszyła się do 10, a jeden programista systematycznie przetwarzał 11 próśb kwartalnie. 56 próśb kwartalnie zostało zrealizowanych w porównaniu do poprzednich 11. Koszt prośby spadł z $7500 do $2900.
Kiedy wykorzystano przez Corbis
Po osiągnięciu sukcesu w Microsoft, Anderson przystąpił do rozwiązania nowego skomplikowanego problemu w 2006 roku.
W tym czasie pracował w Corbis – innej firmie Billa Gatesa, która jeszcze nie opuściła MS. Jednym z działań Corbis było licencjonowanie zdjęć. Wtedy to była drugą największą bazą zdjęć w świecie, posiadającą około 3,5 tysiąca zdjęć.
Cel Andersona był przyspieszenie głównych wydania firmy. Interwał pomiędzy wydaniami wynosił trzy miesiące, a mógł wzrosnąć jeszcze bardziej. Samo omawianie planu wydania zajmowało dwa tygodnie pracy zarządzającej. Konieczne było dostosowanie wyjścia wtórnych wydań lub aktualizacji co dwa tygodnie. Jednocześnie kluczowe zasoby musiały być ukierunkowane na realizację głównego projektu.
Biuro Corbis otrzymało tablicę Kanban, która stała się miejscem codziennych rozmów Andersona z pracownikami. Celem PM było poprawienie wizualnego monitorowania procesów, wspieranie samodzielnego zarządzania oraz wzmocnienie odpowiedzialności osobistej wykonawców.
System Kanban miał również na celu luzowanie nadzoru kierowniczego i zwiększenie wydajności.
Oprócz wielobarwnych kart i wykresów, na tablicy pojawił się „kosz na śmieci”, aby zbierać
zbyt duże zadania.
Zdjęcie z oficjalnej prezentacji
System Kanban do utrzymania inżynieryjnego w systemach oprogramowania autorstwa Davida J Andersona
System Kanban wyjaśnił punkty, w których przepływy pracy przestały być płynne i gdzie występowały opóźnienia powodujące tzw. wąskie gardła. Natychmiastowe dyskusje zespołu ułatwiły odkrycie bieżących problemów. Na przykład, procedura testowania trwała 3 dni, co negatywnie wpływało na terminy wydania. Trzech specjalistów zjednoczyło się, aby znaleźć sposób na skrócenie tego czasu do 24 godzin.
Limity dla kart Kanban ustalono empirycznie dwukrotnie. W kolumnie „gotowe do rozwoju” limity nie były zwiększane. Pojawiła się również nowa kolumna – „gotowe do testowania”. Wiele dalszych próśb zostało niewłaściwie sformułowanych, co powodowało nieuzasadniony czas. Dlatego PM zbadał przepływ pracy upstream i znalazł błędy. Przetwarzanie próśb mogło zająć 100 dni, ale jednak wydania stały się regularne – raz na dwa tygodnie, jak planowano. Decyzje dotyczące treści wydania podejmowano 5 dni przed publikacją. Tak jak w przypadku podziału XIT w Microsoft, praktyka obliczeń została przesunięta na rzecz wydajności.
Zadania były priorytetyzowane na podstawie „kosztu opóźnień” lub gotowości zasobów. Nie tylko system Kanban umożliwił Andersonowi osiągnięcie celu, ale także poprawił klimat wśród personelu. Dzięki wspólnym dyskusjom i przejrzystości procesów, członkowie zespołu stali się głęboko pewni siebie nawzajem. Personel przestrzegał również Kaizen, co jest praktyką ciągłego doskonalenia.
Zastosowania i programy dla Kanban
Trello
Jest to popularny system Kanban do zarządzania zadaniami. Różni się wizualną atrakcyjnością i wygodnym interfejsem. Użytkownicy zwracają uwagę na jego superelastyczność.
Kanbantool
Reprezentuje tablicę bezpłatną dla dwóch użytkowników. Oferuje również wsparcie dla API i interfejsów dotykowych.
Lean Kit Kanban
To tablica bezpłatna dla pięciu użytkowników, która dobrze realizuje wspólną pracę. Oferuje również wsparcie dla API, umożliwia import/eksport oraz dostarcza dobre statystyki.
Kanbanize
To całkowicie bezpłatna usługa o adekwatnej funkcjonalności. Jej właściciele gwarantują wzrost wydajności o 300% przy korzystaniu z ich aplikacji.
Worksection
To ukraińska aplikacja saas do szybkiego śledzenia i zarządzania projektami. Oprócz rachunkowości finansowej, terminów i wykresu Gantta, jej funkcje obejmują obecnie konfigurowalną tablicę Kanban.
Werdykt
Kanban to praktyka, która pomaga osiągnąć sukces bez potrzeby używania tylko metod zwinnych.
Znaczące zmiany osiągane są poprzez eliminację strat czasowych, dzięki zarządzaniu wąskimi gardłami z redukcją zmienności.
Jednak efektywne zmiany wymagają czasu. Są stopniowe, a opór zespołu wobec nowości jest minimalny. System Kanban motywuje zespoły do uzyskania aktualizacji bez zmiany ich
metod inżynieryjnych.