Na tablicy zespołu w kolumnie "W trakcie" wisi piętnaście zadań. Każda osoba pracuje nad dwoma, trzema rzeczami naraz, przeskakując między nimi w zależności od tego, co akurat się pali. Mimo dużej aktywności mało zadań trafia do kolumny "Gotowe". To klasyczny objaw braku WIP limits, czyli limitów liczby zadań w toku - jednego z najprostszych, a najczęściej ignorowanych usprawnień w pracy zespołowej.
WIP limits brzmią jak ograniczenie, ale w praktyce działają odwrotnie - zamiast zwalniać zespół, przyspieszają faktyczne kończenie pracy. Mniej zadań rozpoczętych naraz oznacza więcej zadań skończonych w danym okresie.
W tym artykule pokażę, dlaczego limit pracy w toku działa, jak ustalić go dla własnego zespołu i jak wdrożyć go na tablicy Kanban bez wywoływania oporu zespołu.
Co to są limity pracy w toku
WIP limit (work in progress limit) to maksymalna liczba zadań, które mogą znajdować się w danej kolumnie tablicy w danym momencie - najczęściej w kolumnie "W trakcie", choć limit można ustalić dla każdego etapu pracy. Gdy kolumna osiąga limit, zespół nie zaczyna nowego zadania, dopóki jedno z obecnych nie zostanie przesunięte dalej.
To jeden z fundamentów metodyki Kanban - więcej o samej metodyce przeczytasz w artykule Czym jest metodyka Kanban i komu się sprawdzi.
Limit nie musi obowiązywać dla całej tablicy jednakowo. Kolumna obejmująca trudniejszy etap pracy, na przykład code review wymagające drugiej osoby, może mieć niższy limit niż kolumna z prostszymi zadaniami, które jedna osoba przerabia szybko.
Dlaczego ograniczanie liczby zadań w toku zwiększa wydajność
Prawo Little'a w praktyce
Prawo Little'a, znane z teorii kolejek, mówi w uproszczeniu, że czas, jaki zadanie spędza w systemie, jest proporcjonalny do liczby zadań znajdujących się w tym systemie jednocześnie. Innymi słowy: im więcej zadań zespół trzyma "w trakcie" naraz, tym dłużej każde z nich faktycznie czeka na zakończenie, nawet jeśli sumaryczna liczba godzin pracy się nie zmienia.
W praktyce nie trzeba znać wzoru, żeby zauważyć efekt. Wystarczy porównać dwa tygodnie: jeden, w którym każda osoba miała otwarte trzy zadania naraz, i drugi, w którym miała jedno. W drugim tygodniu zadania kończą się szybciej, mimo że nikt nie pracował więcej godzin.
Koszt przełączania kontekstu
Każde przejście między zadaniami wymaga chwili na przypomnienie sobie, na czym dana praca stała. Przy dwóch zadaniach naraz ten koszt jest niewielki. Przy pięciu zadaniach w toku znacząca część dnia idzie na samo przypominanie sobie kontekstu, nie na realną pracę.
Jak ustalić limit pracy w toku dla zespołu
Zacznij od liczby osób w zespole
Dobrym punktem wyjścia jest limit równy liczbie osób w zespole, czasem nawet trochę niższy. Pięcioosobowy zespół zaczynający od limitu czterech lub pięciu zadań w kolumnie "W trakcie" zmusza się do kończenia pracy, zamiast rozpraszać się na więcej tematów niż ma rąk do ich obsłużenia.
Obserwuj, gdzie się piętrzy
Po wprowadzeniu limitu warto obserwować, w którym miejscu tablicy zadania najczęściej się zatrzymują. Jeśli kolumna "Do testów" stale jest przepełniona, problem leży w tempie testowania, nie w liczbie zadań rozpoczynanych przez programistów - limit w tym miejscu pomoże to szybko zauważyć.
Dostosuj limit po kilku sprintach
Limit ustalony na starcie rzadko jest idealny od razu. Jeśli zespół regularnie blokuje się, czekając na zwolnienie miejsca w kolumnie, limit może być zbyt niski. Jeśli zadania wciąż się piętrzą mimo limitu, prawdopodobnie jest wciąż zbyt wysoki względem realnej przepustowości zespołu.
Dobry rytm to przegląd limitu raz na kilka sprintów, najlepiej podczas retrospektywy, kiedy zespół i tak rozmawia o tym, co działało, a co nie.
Jak wdrożyć WIP limits na tablicy Kanban
Najprostszy sposób to ustalenie limitu liczbowego przy każdej kolumnie tablicy i jasna zasada: nikt nie przenosi nowego zadania do kolumny, która już ma osiągnięty limit. Zamiast zaczynać nowe zadanie, zespół skupia się na pomocy w odblokowaniu zadania, które już tam czeka - na przykład przez wspólne code review albo testowanie.
Ten mechanizm naturalnie zachęca do pracy zespołowej nad odblokowywaniem zadań, podobnie jak praktyki opisane w artykule Code review - jak robić to dobrze i nie tracić czasu - zamiast czekać, aż ktoś sam znajdzie czas na przegląd kodu, osiągnięty limit jest sygnałem, żeby zająć się tym właśnie teraz.
Ważne, żeby limit był widoczny dla całego zespołu na tablicy, nie tylko zapisany w dokumencie, do którego nikt nie wraca. Widoczność limitu jest tym, co realnie wpływa na codzienne decyzje, nie sama reguła.
Co robić, gdy limit jest osiągnięty
Osiągnięty limit jest sygnałem, nie problemem do zignorowania. Zamiast obchodzić limit "tym razem zrobimy wyjątek", zespół powinien zapytać, dlaczego zadania nie przechodzą dalej - czy ktoś czeka na decyzję, czy brakuje osoby do code review, czy zadanie jest po prostu większe niż wydawało się na starcie.
Częste osiąganie limitu w tym samym miejscu tablicy wskazuje na realne ograniczenie przepustowości zespołu w tym etapie pracy - to konkretna informacja, którą trudno zauważyć bez limitu, a łatwo zignorować bez niego.
Czasem rozwiązaniem nie jest dodanie kolejnej osoby do zespołu, a przesunięcie kogoś tymczasowo do etapu, który stał się wąskim gardłem. Limit pracy w toku pomaga zauważyć ten moment szybciej, niż gdyby zadania po prostu czekały w niewidocznej kolejce.
Przykład z praktyki
Zespół wsparcia technicznego pracował z otwartą liczbą zgłoszeń "w trakcie" - każda osoba brała nowe zgłoszenie, gdy tylko się pojawiło, niezależnie od tego, ile innych miała już otwartych. Średni czas rozwiązania zgłoszenia rósł z tygodnia na tydzień, mimo że zespół nie zmniejszył się ani nie zwiększył napływ zgłoszeń.
Po wprowadzeniu limitu trzech zgłoszeń w toku na osobę, część zgłoszeń zaczęła czekać w kolejce dłużej, zanim ktoś je przejął - ale te, które trafiały do pracy, były kończone wyraźnie szybciej. W ciągu miesiąca średni czas rozwiązania zgłoszenia spadł, mimo że na pierwszy rzut oka zespół "robił mniej rzeczy naraz".
Co ważne, klienci czekający w kolejce nie czekali dłużej niż wcześniej - po prostu czas czekania przesunął się z "czekam, bo nikt jeszcze tego nie otworzył" na "czekam chwilę, zanim ktoś skończy poprzednie zgłoszenie", co w praktyce dawało podobny, a czasem krótszy całkowity czas obsługi.
Najczęstsze błędy przy WIP limits
- Ustalanie limitu bez konsultacji z zespołem - limit narzucony z góry, bez zrozumienia realnej pracy, zwykle jest albo zbyt restrykcyjny, albo bezsensowny.
- Robienie wyjątków przy pierwszej presji - jeden wyjątek "bo to pilne" szybko staje się regułą, a limit przestaje cokolwiek znaczyć.
- Ustalanie limitu tylko dla jednej kolumny - jeśli ograniczona jest tylko jedna część procesu, zadania po prostu piętrzą się gdzie indziej.
- Traktowanie limitu jako celu samego w sobie - sens limitu to szybsze kończenie pracy, nie sama liczba zadań na tablicy.
Jak Taskello pomaga z limitami pracy w toku
W Taskello kolumny tablicy Kanban pokazują liczbę zadań przypisanych do danego etapu, dzięki czemu zespół od razu widzi, kiedy kolumna robi się przeciążona, bez potrzeby liczenia kart ręcznie. Priorytety i przypisania widoczne na zadaniu pomagają szybko zdecydować, które zadanie odblokować najpierw, gdy limit zostaje osiągnięty.
To naturalnie wspiera podejście opisane w artykule Zarządzanie czasem w zespole - praktyczne metody - mniej zadań rozpoczętych naraz oznacza mniej przełączania kontekstu i mniej czasu traconego na wracanie do przerwanej pracy.
Podsumowanie
Limit pracy w toku jest jedną z tych zmian, które brzmią jak ograniczenie, a w praktyce zwiększają liczbę realnie kończonych zadań. Klucz to zacząć od rozsądnego limitu, obserwować, gdzie zadania się piętrzą, i traktować osiągnięty limit jako sygnał do reakcji, nie przeszkodę do obejścia.
Jeśli Twój zespół planuje sprinty zgodnie z artykułem Sprint Planning - jak prowadzić planowanie sprintu, limit pracy w toku jest naturalnym uzupełnieniem - pomaga utrzymać tempo realizacji zaplanowanych zadań w trakcie samego sprintu, nie tylko na etapie planowania.