Kanban w dosłownym tłumaczeniu może oznaczać szyld, tabliczkę z informacją, spis. Metoda powstała w Japonii, podobnie jak Lean wzięta z taśmy produkcyjnej Toyoty. A idea dotyczyła takiej organizacji zespołów produkcyjnych, aby powstawało dokładnie to, co jest potrzebne w danej chwili i aby eliminować niepotrzebne zapasy. To się dobrze przedkłada na IT, czyli takie zrównoważenie zapotrzebowania z dostępną wydajnością, by pozbyć się wąskich gardeł.
W tym celu metoda stawia olbrzymią wagę na wizualizację pracy, stąd powstawała tablica kanbanowa dająca zespołom podgląd procesu i postępów od początku do końca. Kanban sugeruje podejście do zmian procesów w organizacji tak, by lepiej zrozumieć pracę, przepływy i zależności oraz ograniczyć prace w toku. Eliminuje to straty wynikające z wielozadaniowości i ciągłej zmiany kontekstu, a także wzmacnia współpracę w celu udoskonalenia systemu. Metoda opiera się na dwóch zasadach, na zarządzaniu zmianami i dostarczaniu usług, które podkreślają zmiany ewolucyjne i skupianie uwagi na klientach. Nie określa przy tym konkretnego zestawu kroków, ale stawia na wyjście od bieżącego kontekstu stymulując ciągłe, przyrostowe i ewolucyjne zmiany w systemie. Ma ona na celu zminimalizowanie oporu wobec zmian.
Kanban ma sześć ogólnych praktyk: wizualizacja, ograniczenie prac w toku, zarządzanie przepływem, jednoznaczne określenie zasad, wykorzystanie pętli zwrotnych oraz ewolucja współpracy. Obejmują one postrzeganie pracy i jej procesu oraz usprawnianie, utrzymywanie i wzmacnianie użytecznych zmian oraz uczenie się i tłumienie nieskuteczności.
Można powiedzieć, że Kanban nie toleruje żadnych:
- braków,
- opóźnień,
- zapasów,
- kolejek,
- bezczynności,
- zbędnych czynności technologicznych i kontrolnych,
- przemieszczeń.
W przypadku systemów produkcyjnych dużym ryzykiem jest odpowiednie dostosowanie dostaw towaru, tak by nie generować przestojów i nie tworzyć zapasów. Podobnie jest w IT a towarem jest konkretny kawałek kodu czy zadanie biznesowe.
Wróćmy teraz do tablicy kanban. Jest to najprostsze odwzorowanie metody, a czytelne i łatwe do wykonania.
Ograniczenia pracy w toku ujawniają wąskie gardła, dzięki czemu można je łatwo kontrolować i rozwiązywać. Karty reprezentują elementy robocze, gdy przepływają przez proces tworzenia reprezentowany przez kolumny. Liczby u góry każdej kolumny są ograniczeniami liczby kart dozwolonych w każdej kolumnie. Ograniczenie nakładów pracy (WIP) na każdym kroku procesu zapobiega nadmiernej produkcji i ujawnia wąskie gardła w sposób dynamiczny.
Spójrzmy na prosty przykład:
Poniższa tabela przedstawia sytuację, w której programiści i analitycy nie mogą podejmować żadnej pracy, dopóki testerzy nie skończą zadania i podejmą następne. W tym momencie programiści i analitycy powinni zastanowić się nad sposobem, w jaki mogą pomóc złagodzić obciążenie testerów.
Kolumny zostały dodatkowo podzielone na dwa, żeby zobrazować pracę w toku i już wykonaną w danym zespole. Ograniczenia na górze odnoszą się do obu podkolumn. Gdy testerzy skończą testowanie funkcjonalności przenoszą kartę i zwalniają slot w kolumnie "Test"
Teraz pusta szczelina w kolumnie "Test" może być wypełniona jedną z kart w podkolumnie "Done". To zwalnia slot w "Development", a następną kartę można przesunąć z kolumny "Analysis" i tak dalej.
Metoda jest naprawdę prosta a pozwala fajnie zobrazować gdzie jesteśmy z projektem. Do tego też przydają się codzienne spotkania i aktualizacja tablicy. Można użyć różnych kolorów karteczek w zależności od skomplikowania projektu i złożoności zadań. Kartki mogą być podpisane imionami członków zespołu, wiemy wtedy kto czym się zajmuje i czy ewentualnie potrzebuje pomocy.
