Kanban jest popularnym frameworkiem używanym do implementacji oprogramowania agile. Wymaga on komunikacji w czasie rzeczywistym w zakresie możliwości i pełnej przejrzystości pracy. Przedmioty pracy są reprezentowane wizualnie na tablicy kanban, dzięki czemu członkowie zespołu mogą w każdej chwili zobaczyć stan każdej pracy.
Kanban jest niezwykle istotny w dzisiejszych zespołach oprogramowania agile, ale metodologia pracy z kanbanem sięga ponad 50 lat wstecz. Pod koniec lat 40. ubiegłego wieku Toyota zaczęła optymalizować swoje procesy inżynieryjne w oparciu o ten sam model, którego używały supermarkety do zaopatrzenia swoich półek. Supermarkety zaopatrują się w produkty w ilości wystarczającej do zaspokojenia popytu konsumentów, co jest praktyką, która optymalizuje przepływ między supermarketem a konsumentem. Ponieważ poziom zapasów odpowiada wzorcom konsumpcji, supermarket zyskuje znaczącą efektywność w zarządzaniu zapasami poprzez zmniejszenie ilości nadwyżek, które musi utrzymywać w danym momencie. W międzyczasie supermarket nadal może zagwarantować dostępność w magazynie danego produktu, którego potrzebuje konsument.
Kiedy Toyota zastosowała ten sam system w swoich halach fabrycznych, celem było lepsze dostosowanie ich ogromnych zapasów do rzeczywistego zużycia materiałów. Aby w czasie rzeczywistym informować o poziomach zapasów na hali fabrycznej (i u dostawców), pracownicy przekazywali między zespołami kartę, czyli “kanban”. Gdy pojemnik z materiałami używanymi na linii produkcyjnej był całkowicie pusty, do magazynu przekazywano kanban opisujący, jaki materiał był potrzebny, dokładną ilość tego materiału itd. W magazynie czekał nowy pojemnik z tym materiałem, który następnie wysyłano na halę fabryczną, a następnie wysyłano własny kanban do dostawcy. Dostawca miałby też czekający pojemnik z tym materiałem, który wysyłałby do magazynu. Podczas gdy technologia sygnalizacyjna tego procesu ewoluowała od lat czterdziestych XX wieku, ten sam proces produkcyjny “just in time” (lub JIT) nadal znajduje się w jego centrum.
Spis treści
Kanban dla zespołów programistycznych
Zespoły ds. rozwoju oprogramowania Agile są dziś w stanie wykorzystać te same zasady JIT, dopasowując ilość pracy w toku (WIP) do możliwości zespołu. Daje to zespołom bardziej elastyczne opcje planowania, szybsze rezultaty, wyraźniejsze ukierunkowanie i przejrzystość w całym cyklu rozwoju.
Podczas gdy podstawowe zasady ram są ponadczasowe i mają zastosowanie w prawie każdej branży, zespoły zajmujące się tworzeniem oprogramowania odniosły szczególny sukces w ramach praktyki agile. Po części dlatego, że zespoły programistyczne mogą rozpocząć praktykę z niewielkim lub żadnym nakładem pracy, gdy tylko zrozumieją podstawowe zasady. W przeciwieństwie do wdrażania kanbanu w fabryce, co wiązałoby się ze zmianami w procesach fizycznych i dodawaniem istotnych materiałów, jedyne fizyczne rzeczy, których zespoły programistyczne potrzebują to tablica i karteczki, a nawet te mogą być wirtualne.
Tablice Kanban
Praca wszystkich zespołów kanban obraca się wokół tablicy kanban, narzędzia służącego do wizualizacji pracy i optymalizacji przepływu pracy pomiędzy zespołami. Podczas gdy tablice fizyczne są popularne wśród niektórych zespołów, tablice wirtualne są kluczową cechą każdego zwinnego narzędzia do tworzenia oprogramowania dla ich śledzenia, łatwiejszej współpracy i dostępności z wielu miejsc.
Niezależnie od tego, czy tablica zespołu jest fizyczna czy cyfrowa, ich zadaniem jest zapewnienie wizualizacji pracy zespołu, standaryzacja przepływu pracy oraz natychmiastowa identyfikacja i rozwiązanie wszystkich przeszkód i zależności. Podstawowa tablica kanban ma trzyetapowy cykl pracy: Do zrobienia, w toku, i gotowe. Jednakże, w zależności od wielkości, struktury i celów zespołu, przepływ pracy może zostać zmapowany tak, aby odpowiadał unikalnym procesom danego zespołu.
Metodologia kanbana opiera się na pełnej przejrzystości pracy i komunikacji zdolności w czasie rzeczywistym, dlatego też zarząd kanban powinien być postrzegany jako jedyne źródło prawdy dla pracy zespołu.
Karty Kanban
W języku japońskim, kanban dosłownie przekłada się na “sygnał wizualny”. Dla zespołów kanban, każdy element pracy jest prezentowany jako osobna karta na tablicy.
Głównym celem reprezentowania pracy jako karty na tablicy kanban jest umożliwienie członkom zespołu śledzenia postępu pracy poprzez jej przepływ w sposób wysoce wizualny. Karty kanban zawierają krytyczne informacje o danym elemencie pracy, dając całemu zespołowi pełny wgląd w to, kto jest odpowiedzialny za ten element pracy, krótki opis wykonywanej pracy, jak długo ta praca ma trwać itd. Karty na wirtualnych planszach kanbana często zawierają zrzuty ekranu i inne szczegóły techniczne, które są cenne dla pracownika. Umożliwienie członkom zespołu zobaczenia stanu każdego elementu pracy w danym momencie, jak również wszystkich związanych z tym szczegółów, zapewnia większą ostrość, pełną identyfikowalność oraz szybką identyfikację blokad i zależności.
Korzyści z Kanbanu
Kanban jest jedną z najbardziej popularnych metodologii tworzenia oprogramowania przyjętych przez dzisiejsze zespoły agile. Kanban oferuje kilka dodatkowych korzyści w zakresie planowania zadań i wydajności dla zespołów różnej wielkości.
Elastyczność planowania
Zespół kanban jest skoncentrowany tylko na pracy, która jest aktywnie realizowana. Kiedy zespół kończy pracę, wyciąga następną pozycję z listy zaległych prac. Właściciel produktu może dowolnie zmieniać priorytety pracy bez zakłócania pracy zespołu, ponieważ wszelkie zmiany poza aktualnymi elementami pracy nie mają na niego wpływu. Tak długo, jak właściciel produktu utrzymuje najważniejsze pozycje na szczycie listy zaległych prac, zespół ds. rozwoju jest zapewniony, że dostarcza maksymalną wartość z powrotem do firmy. Nie ma więc potrzeby stosowania powtórzeń o stałej długości, które można znaleźć w scrumie.
Skrócone cykle czasowe
Czas cyklu jest kluczową metryką dla zespołów kanban. Czas cyklu jest to ilość czasu, jaką zajmuje jednostce pracy przejście przez przepływ pracy zespołu – od momentu rozpoczęcia pracy do momentu jej zakończenia. Optymalizując czas cyklu, zespół może śmiało prognozować wykonanie przyszłej pracy.
Nakładające się na siebie zestawy umiejętności prowadzą do skrócenia czasu trwania cyklu. Kiedy tylko jedna osoba posiada zestaw umiejętności, staje się ona wąskim gardłem w przepływie pracy. Dlatego też zespoły stosują podstawowe najlepsze praktyki, takie jak przegląd treści oraz mentoring, które pomagają w rozpowszechnianiu wiedzy. Wspólne umiejętności oznaczają, że członkowie zespołu mogą podejmować się niejednorodnej pracy, co dodatkowo optymalizuje czas trwania cyklu. Oznacza to również, że jeśli istnieje rezerwa pracy, cały zespół może się na niej pracować, aby proces mógł znów płynnie przebiegać. Na przykład, testy są wykonywane nie tylko przez inżynierów. Deweloperzy też się w to angażują.
W ramach kanban, cały zespół jest odpowiedzialny za zapewnienie, że praca przebiega płynnie w całym procesie.
Mniej wąskich gardeł
Wielozadaniowość zabija wydajność. Im więcej elementów pracy w locie w danym momencie, tym więcej przełączania kontekstu, co utrudnia ich wykonanie. Dlatego kluczowym założeniem kanbanu jest ograniczenie ilości pracy w toku (WIP). Limity pracy w toku zwracają uwagę na wąskie gardła i rezerwy w procesie pracy zespołu z powodu braku koncentracji, ludzi lub zestawów umiejętności.
Na przykład, typowy zespół oprogramowania może mieć cztery stany przepływu pracy: do wykonania, w toku, przegląd projektu i gotowe. Mogą oni ustawić limit WIP na poziomie 2 dla stanu przeglądu oprogramowania. Może się to wydawać niskim limitem, ale jest ku temu dobry powód: programiści często wolą pisać nowy kod, niż spędzać czas na analizowaniu czyjejś pracy. Niski limit zachęca zespół do zwracania szczególnej uwagi na kwestie związane ze stanem weryfikacji, a także do recenzowania innych prac przed wystawieniem własnej wersji kodu. To ostatecznie redukuje całkowity czas cyklu.
Wizualna metryka
Jedną z podstawowych wartości jest silna koncentracja na ciągłym zwiększaniu efektywności i skuteczności zespołu przy każdej iteracji pracy. Wykresy dostarczają zespołom wizualnego mechanizmu zapewniającego ich ciągłe doskonalenie. Kiedy zespół widzi dane, łatwiej jest dostrzec wąskie gardła w procesie (i usunąć je). Dwa popularne raporty, z których korzystają zespoły kanban, to wykresy kontrolne i skumulowane diagramy przepływu.
Wykres kontrolny pokazuje czas trwania cyklu dla każdego problemu, jak również średnią kroczącą dla zespołu.
Skumulowany diagram przepływu pokazuje liczbę spraw w każdym stanie. Zespół może łatwo zauważyć blokady, widząc wzrost liczby spraw w danym statusie. Problemy w stanach pośrednich, takich jak “W trakcie realizacji” lub “W przeglądzie” nie są jeszcze wysyłane do klientów, a blokada w tych stanach może zwiększyć prawdopodobieństwo wystąpienia masowych konfliktów integracyjnych, gdy praca zostanie przesunięta w górę strumienia.
Ciągła dostawa
Wiemy, że ciągła integracja, praktyka automatycznego budowania i testowania oprogramowania w sposób stopniowy w ciągu całego dnia pracy, jest niezbędna dla utrzymania jakości. Teraz nadszedł czas na ciągłą dostawę. Ciągła dostawa to praktyka polegająca na częstym udostępnianiu pracy klientom, nawet codziennie lub co godzinę. Kanban i ciągła dostawa pięknie się uzupełniają, ponieważ obie techniki skupiają się na dostarczaniu wartości w systemie dokładnie na czas.
Im szybciej zespół może dostarczyć innowację na rynek, tym bardziej konkurencyjny będzie ich produkt na rynku. A zespoły kanban koncentrują się właśnie na tym, na optymalizacji przepływu pracy do klientów.
Scrum vs. kanban
Kanban i scrum podzielają niektóre z tych samych koncepcji, ale mają bardzo różne podejścia. Nie należy ich ze sobą mylić.
Niektóre zespoły mieszają ideały kanban i scrumów w “scrumban”. Od scrumu biorą cykle i role o stałej długości, a od kanbanu koncentrują się na limitach pracy w toku i czasie cyklu. Dla zespołów dopiero rozpoczynających pracę ze zwinnością zdecydowanie zalecamy jednak wybór jednej lub drugiej metodologii i pracę z nią przez jakiś czas. Zawsze można później nabrać fantazji.
