System Kanban rozpoczął swoją podróż w latach 50. XX wieku na liniach produkcyjnych Toyoty, po czym przeszedł do biur i stał się ważnym narzędziem dla menedżerów projektów.
Nielimitowana elastyczność tej praktyki i jej zdolność do samodzielnej organizacji personelu pozwoliła na osiągnięcie efektywności tam, gdzie inne podejścia nie działały. W tym przypadku wizytówką systemu stała się sama karta — stała się ona wewnętrzną walutą w organizacjach, które wdrożyły Kanban.
Pochodzenie
Podobnie jak koncepcja Lean manufacturing, system Kanban został opracowany przez menedżerów Toyoty. Autorem systemu, japońskim inżynierem Taiichi Ohno, zainspirowały zasady działania amerykańskich supermarketów, gdzie klienci sami wybierali potrzebne im produkty. Rolę “supermarketu” pełnił w Toyocie magazyn.Tam wymieniano karty sygnalizacyjne — co dosłownie oznacza “kanban” z japońskiego — między pracownikami, którzy ręcznie regulowali proces produkcyjny.Karty były przyczepiane do skrzynek z częściami. Takie etykiety wskazywały informacje o numerze części i ilości, z którego działu zostały wysłane oraz dokąd miały trafić.
Pracownik bezpośrednio zaangażowany w montaż maszyn (“w dół”) brał części ze skrzynki, do której była przymocowana karta “kanban” żądająca uzupełnienia. Karta została usunięta i przekazana wraz z pustą skrzynką do transportera do magazynu. Tam inny pracownik przygotowywał nową skrzynkę z częściami zamiennymi, do której dołączano produkcyjną “kanban” — etykietę z informacją o produkowanych częściach.
Produkcja “kanban” była zastępowana “kanbanem” żądającym uzupełnienia i wysyłana na linię produkcyjną części zamiennych — “w górę”. W ten sposób produkowano dokładnie taką ilość części, jaka była określona na karcie. Skrzynka z nowymi częściami zamiennymi była umieszczana przez transporterów na linii montażowej.
Zasady Kanban
Menedżerowie Toyoty sformułowali 6 zasad tworzących system:
- Pracownicy z “w dół” usuwają dokładnie tyle części z magazynu, ile określono na kanbanie.
- Pracownicy z “w górę” również dostarczają części dokładnie zgodnie z kartami.
- Nic nie jest produkowane ani przemieszczane bez kanbanu.
- Kanban zawsze musi być przymocowany do części.
- Uszkodzone części nie są używane w systemie.
- Zmniejszenie liczby kart kanban sprawia, że zarządzanie staje się bardziej wrażliwe na zmiany. Jednak bez ekstremalnej potrzeby nie zaleca się zmiany ustalonej liczby kart.
Kanban jest systemem “ciągnącym”. Tworzy równowagę między stałym przepływem, co eliminuje koszty oczekiwania, a minimalną ilością pracy w toku (WIP), co zmniejsza ryzyko nadprodukcji. WIP jest regulowane za pomocą kart: ich liczba jest stała, a instrukcje w nich kierują pracownikami “w dół”.
Limit WIP jest uzależniony od liczby kart kanban, które oblicza się na podstawie poziomów sprzedaży i statystycznej zmienności w aktualnych procesach. Maksymalna liczba etykiet — “energia” w systemie — zabezpiecza górny poziom WIP w danym momencie. WIP jest również ograniczone zasadą ciągnienia: szybkość produkcji z góry zależy od szybkości pracy “w dół”.
Grafika pokazuje, że jednym z podstawowych elementów systemu jest kultura Kaizen. Autonomiczne procesy i standardowa zmienność uwalniają zarządzanie od ciągłego nadzoru, pozwalając mu skoncentrować się na poprawie wydajności pracowników.
Zastosowanie Kanban w IT
System Kanban, nadal przynosząc korzyści na liniach produkcyjnych, przeniknął do domeny oprogramowania.
Jedynie karty, które zawierają informacje o terminach, opisach lub numerach procesów oraz imionach wykonawców, są teraz przymocowywane nie do skrzynek z częściami zamiennymi, ale do tablic podzielonych na kolumny:
- Backlog — zadania do zrealizowania
- Zadania aktualnie w opracowaniu
- Zadania zakończone, ale jeszcze nie przekazane testerom
- Zadania gotowe do przekazania działowi testowania
- Zadania w trakcie przeglądu przez menedżera projektu (PM)
- Zadania zakończone
Liczba zwykle jest zapisywana nad kolumnami — limit, który wskazuje maksymalną liczbę procesów w niej. Limit backlogu oblicza się w zależności od czasu realizacji. Jeśli w systemie są 5 procesów roboczych, a średni czas zakończenia każdego wynosi 1 dzień, backlog może być ograniczony do 5.
Struktura powyżej nie jest ścisła — w zależności od specyfiki projektu, można dodać improwizowane kolumny. System Kanban może często mieć potrzebę zdefiniowania kryteriów gotowości zadania przed realizacją. W takim przypadku pojawiają się dwie kolumny, zwane po angielsku specify (określając parametry) i execute (przyjmując pracę).
- Może być dodana kolejna kolumna z priorytetem. Gdy wykonawca staje się wolny, najpierw musi usunąć zadania z tej kolumny przed przystąpieniem do innych.
- Zadania, które nie zostały ukończone, są albo zwracane do backlogu, albo przekreślane z schematu.
- Kanban nie zachęca do wielozadaniowości, ograniczając tym samym liczbę procesów dla każdego wykonawcy.
- Zakończona praca jest lepsza niż kilka rozpoczętych zadań.
- Drugą pracę można podjąć, jeśli pierwsza jest zablokowana.
- Czas na realizację zadania musi być zbalansowany. Zbyt krótki termin może wpływać na jakość. Zbyt wydłużony limit spala zasoby zespołu i podnosi koszty procesów.
Dlaczego tablica Kanban jest stosowana wszędzie zamiast na przykład tabletów lub dużych monitorów? Zwolennicy systemu odpowiadają na to pytanie, stwierdzając, że zwykła tablica ma dwie zalety: jest prosta i zapewnia kontrolę wizualną. Łatwo na niej wprowadzać zmiany i zachęca do interakcji dotykowej i społecznej wśród członków zespołu.
Zalety i wady Kanban
Kanban ma następujące zalety:
- Elastyczność w planowaniu. Zespół koncentruje się wyłącznie na bieżącej pracy, priorytet zadań ustala menedżer.
- Wysoka zaangażowanie zespołu w procesie rozwoju. Dzięki regularnym spotkaniom, przejrzystości procesów i możliwościom samorganizacji pracownicy łączą się i okazują prawdziwe zainteresowanie.
- Krótszy czas cyklu. Jeśli niezbędne umiejętności posiada kilka osób, czas trwania się skraca; jeśli tylko jedna osoba je posiada, powstaje wąskie gardło. Dlatego pracownicy powinni dzielić się wiedzą, optymalizując czas cyklu. Dzięki temu cały zespół może pracować nad utknionymi zadaniami i przywracać płynność.
- Mniej wąskich gardeł. Limity WIP pozwalają szybko zidentyfikować wąskie gardła i obszary problemowe wynikające z braku skupienia, siły roboczej lub umiejętności.
- Widoczność. Gdy wszyscy wykonawcy mają dostęp do danych, łatwiej jest zauważyć wąskie gardła. Zespoły Kanban, oprócz samych kart, zazwyczaj wykorzystują dwa wspólne raporty: wykresy kontrolne i skumulowany przepływ.
W praktyce system osiąga doskonałe wyniki w obszarach produkcji nienależących do rdzenia:
- grupy wsparcia oprogramowania lub help deski.
- Kanban sprawdza się w zarządzaniu startupami bez jasnego planu, ale gdzie aktywność rozwojowa ma miejsce.
Kanban ma również wady:
- system słabo działa w zespołach liczących więcej niż 5 osób
- nie jest przeznaczony do długoterminowego planowania.
Różnice między Scrum a Kanban
Scrum, podobnie jak elastyczny Kanban, jest elastyczną metodologią, która również często znajduje zastosowanie w sferze IT. Różnice między nimi nie są oczywiste na pierwszy rzut oka. Istnieje wiele podobieństw, na przykład obecność backlogu w obu podejściach.
Scrum | Kanban | |
Tempo | Powtarzane sprinty o stałym czasie trwania | Proces ciągły |
Wydanie | Na końcu każdego sprintu po zatwierdzeniu przez menedżera projektu (właściciela produktu) | Przepływ trwa nieprzerwanie lub według uznania zespołu |
Role | Właściciel produktu, Scrum master, zespół deweloperów | Zespół kierowany przez PM; w niektórych przypadkach zaangażowani są coachowie agile Kanban |
Kluczowe metryki | Prędkość zespołu | Czas realizacji |
W kwestii akceptacji zmian | W trakcie sprintu zmiany są niepożądane, ponieważ mogą prowadzić do błędnych obliczeń zadań | Zmiany mogą występować w dowolnym momencie |
Przykłady zastosowania w IT
Prosto z Microsoftu: Debiut Kanban w rozwoju oprogramowania
Użycie zasad Kanban w technologii informacyjnej rozpoczęło się nieco ponad 10 lat temu. David Anderson, jeden z głównych propagatorów Kanban dla programistów, konsultował się z Microsoftem w 2005 roku. Byli niezadowoleni z wydajności swojego działu — XIT Sustained Engineering, który naprawiał błędy w aplikacjach wewnętrznych. Na początku roku sprawozdawczego ten dział był najgorszy w swojej dziedzinie. Backlog przekraczał akceptowalny rozmiar pięciokrotnie, a czas realizacji jednego zgłoszenia wynosił zazwyczaj pięć miesięcy.
Nowy PM, przy konsultacjach Andersona, zwiększył wydajność problematycznego działu o 155% w ciągu dziewięciu miesięcy. Czas realizacji wynosił teraz pięć tygodni, backlog wrócił do normalnych rozmiarów, a terminowe wykonanie zadań ustabilizowało się na poziomie 90%. Wszystkie te wyniki osiągnięto przy minimalnym wprowadzeniu nowych pracowników; personel nadal naprawiał błędy w ten sam sposób — zmieniły się jedynie podejścia do organizacji pracy.
Interesujący fakt: menedżer programu Dragos Dumitriu, który postanowił poprawić sytuację w XIT, był zafascynowany książką Andersona. Ku jego zaskoczeniu, spotkał ideologa programu Kanban w samej Microsoft, gdzie rozpoczął pracę zaledwie dzień wcześniej. Dumitriu poprosił Andersona o pomoc w swoim zadaniu, a ten zgodził się zastosować zasady swojej książki w praktyce.Dumitriu natrafił na dział składający się z trzech programistów i trzech testerów, w którym w backlogu zalegały 80 zgłoszeń. PM został tymczasowo wyznaczony, ponieważ wymagania dotyczące pracy obejmowały wiedzę z technologii ASP, administracji SQL Serverem i znajomości MS Project Server. Kierownictwo przewidywało “technika”, który potrafiłby kodować, przygotowywać raporty i prognozować obciążenie backlogu. Jak wtedy sądzono, problem działu ujawniłby się, gdyby zgromadzono dużą ilość danych. Dumitriu nie był takim “technikiem”.
Jednak rozpoczynając analizę operacji XIT z Andersonem, szybko zidentyfikował kluczowe czynniki negatywnie wpływające na szybkość działania działu:
- Prognozowanie konsekwencji (ROM) realizacji zgłoszenia zajmowało dużo czasu. Zarówno programista, jak i tester musieli poświęcić pełny dzień roboczy na wykonanie niezbędnych obliczeń, sprawdzenie kodu i wypełnienie dokumentacji. Średnio codziennie napływało jedno zgłoszenie. Zgodnie z obliczeniami PM, 40% wydajności działu szło na ROM;
- Priorytet nadawano zgłoszeniom o wyższej wartości. XIT był finansowany w zależności od wartości zamówienia. Priorytetyzacja zgłoszeń była omawiana co miesiąc na spotkaniach kierowników działów z klientami — menedżerami z innych działów. Przy rosnącym backlogu przy obecnej szybkości, gdzie miesięcznie przetwarzano tylko 6 – 7 zgłoszeń, priorytety innych zgłoszeń zmieniały się nieustannie z upływem czasu. Wiele z nich było odkładanych na znaczące “później”, które nie równało się nawet z następnym miesiącem.
- Na etapie ROM połowa zgłoszeń była odrzucana. Niektóre były zbyt duże i przekwalifikowywano je jako projekty do przeniesienia do innych działów, inne były zbyt kosztowne i po prostu anulowane. Niektóre zgłoszenia nie były brane do rozwoju, ponieważ ich realizacja zajmowałaby zbyt dużo czasu. W ten sposób 40% wydajności działu było wydawane na analizę zgłoszeń, z których 50% było odrzucanych. Około 15 – 20% zasobów roboczych było marnowanych.
- Prace przygotowawcze nad zgłoszeniami mogły trwać miesiącami, zanim rozpoczęto realizację. Obliczenia na etapie ROM mogły być zagubione lub zapomniane w tym czasie. Szczególnie jeśli realizację prowadziłby inny programista niż ten, który rozpoczął analizę.
Rozwiązania Kanban dla problematycznego działu Microsoftu
Na koniec 2005 roku wydajność działu zwiększyła się o 155%. Aby dalej poprawić pracę XIT, zatrudniono dwóch pracowników: jednego programistę i jednego testera. Liczba zgłoszeń w backlogu spadła do 10, a jeden programista systematycznie przetwarzał 11 zgłoszeń na kwartał. Średnio co kwartał realizowano 56 zgłoszeń w porównaniu do 11 wcześniej. Koszt zgłoszeń spadł z 7500 USD do 2900 USD.
Zastosowanie w Corbis
Po osiągnięciu sukcesu w Microsoft, Anderson w 2006 roku podjął się nowego, złożonego zadania. Teraz pracował w Corbis — kolejnej firmie Billa Gatesa, który jeszcze nie opuścił Microsoftu. Jedną z działań Corbis była licencjonowanie zdjęć. W tamtym czasie była to druga co do wielkości biblioteka zdjęć stockowych na świecie z bazą danych około 3,5 tysiąca obrazów.
Zadaniem Andersona było przyspieszenie głównych wydania firmy. Interwał między ich wydaniami wynosił trzy miesiące i mógł jeszcze się wydłużyć. Samo omawianie planu wydania zajmowało kierownictwu dwa tygodnie. Należało ustalić wydanie wtórnych wydania lub aktualizacji co dwa tygodnie. Jednocześnie kluczowe zasoby musiały być skierowane na główny projekt.
W biurze Corbis pojawiła się tablica Kanban, przy której Anderson rozmawiał z zespołem codziennie. Celem PM było poprawienie wizualnej kontroli nad procesami, zachęcenie do samorganizacji i większej odpowiedzialności osobistej wśród wykonawców. System Kanban miał również na celu ograniczenie nadzoru menedżerów i zwiększenie wydajności.
Oprócz kolorowych kart i wykresów, na tablicy pojawił się “kosz na śmieci” — do którego trafiały zbyt duże zadania.
Zdjęcie z oficjalnej prezentacji
System Kanban dla Inżynierii Utrzymania oprogramowania autorstwa Davida J. Andersona
System Kanban wyjaśnił, kiedy przepływ przestaje być płynny i gdzie występują opóźnienia, tzw. wąskie gardło. Szybkie dyskusje z zespołem pomogły zidentyfikować bieżące problemy. Na przykład testowanie zajmowało 3 dni, co negatywnie wpływało na harmonogram wydania. Trzech pracowników zebrało się i znalazło sposób na skrócenie czasu do jednego dnia.
Wąskie gardło to odcinek schematu lub algorytmu operacji firmy, gdzie ograniczenia produktywności zasobów lub ludzi znacznie redukują przepustowość przepływu zadań. Niedobór siły roboczej, słaby internet lub dyrektor na urlopie blokują lub spowalniają realizację zadań.
Limity dla kart Kanban ustalono w sposób empiryczny dwukrotnie. W kolumnie “gotowe do opracowania” limity zostały zwiększone. Pojawiła się również nowa kolumna — “gotowe do testowania”. Wiele zgłoszeń dla “w dół” było sformułowanych niewłaściwie, co powodowało niepotrzebne wydatki czasowe. Dlatego PM zbadał operacje w górnym przepływie i znalazł błędy.
Procedura przeglądu zgłoszeń mogła trwać 100 dni, ale wydania zaczęły się pojawiać co dwa tygodnie zgodnie z planem. Decyzje w sprawie treści wydania podejmowano 5 dni przed publikacją. Praktyka liczenia, jak w przypadku działu XIT w Microsoft, została porzucona na rzecz wydajności. Priorytety zadań ustalano zgodnie z “kosztem opóźnień” lub gotowością zasobów.
System Kanban nie tylko pomógł Andersonowi osiągnąć wyznaczony cel, ale także poprawił morale w zespole. Dzięki zbiorowym dyskusjom i widoczności procesów pracownicy nawiązali zaufanie do siebie nawzajem. Personel również przyjął praktykę Kaizen, czyli praktykę ciągłego doskonalenia.
Programy i aplikacje do KANBAN
Trello
Popularny system Kanban do zarządzania zadaniami. Zauważany jest za swój wizualny urok i przyjazny interfejs użytkownika. Użytkownicy podkreślają jego ogromną elastyczność.
Kanbantool
Darmowa tablica dla dwóch użytkowników. Wsparcie API i interfejsy dotykowe.
Lean Kit Kanban
Darmowa tablica dla pięciu użytkowników z dobrymi funkcjami współpracy. Wsparcie API i możliwości importu/eksportu, obszerne statystyki.
Kanbanize
Całkowicie darmowa usługa z przyzwoitą funkcjonalnością. Jej właściciele gwarantują 300% wzrost wydajności przy użyciu ich produktu.
Worksection
Ukraiński SaaS — aplikacja do szybkiego śledzenia i zarządzania projektami. Obecnie, poza rachunkowością finansów i terminów, istnieje wykres Gantta. W nadchodzących miesiącach deweloperzy dodadzą tablicę Kanban z opcjami dostosowania, co uczyni usługę jeszcze bardziej odpowiednią dla Kanban.
Werdykt
Kanban to praktyka, która pomaga osiągnąć sukces, podczas gdy użycie jedynie metod zwinnych nie jest obowiązkowe. Znaczące zmiany osiąga się dzięki eliminacji marnotrawstwa czasu, zarządzaniu wąskimi gardłami i redukcji zmienności.
Jednak udane zmiany wymagają czasu. Zachodzą stopniowo, podczas gdy opór zespołu na innowacje jest minimalny. System Kanban motywuje personel do doskonalenia bez zmian metod inżynieryjnych.
Książki do artykułu dostarczyło kniga.biz.ua