Blog

Kanban to strategia optymalizacji przepływu wartości poprzez proces, w którym ta wartość jest wytwarzana. Dzięki temu możliwe staje się zoptymalizowanie samej wartości, czyli uzyskanie maksimum tego, co możliwe do osiągnięcia w określonym czasie.

Żeby zaistniał przepływ, potrzeba wielu rzeczy, ale przede wszystkim praca nad uzyskiwaniem wartości musi posuwać się do przodu. A tego nie da się osiągnąć w żaden sposób, jeśli pracy tej nie będzie miał kto wykonać albo gdy niezbędne narzędzia i środki będą niedostępne (bo np. używane są zrobienia czegoś pilniejszego).

Wniosek z tego oczywisty: w każdym środowisku (organizacji, Zespole) istnieje naturalna granica możliwości, której przekroczenie spowoduje, że rozpoczęta praca przestanie posuwać się do przodu, albo to przesunięcie stanie się zbyt powolne. Zainwestowane już środki zwrócą się później, niż mogłyby… o ile się zwrócą, bo im dłużej trwa wykonanie pracy, tym więcej jest czasu na wystąpienie takich zdarzeń, które jej dokończenie uniemożliwią.

Aby nie przekroczyć tej granicy, a najlepiej odsunąć się od niej na bezpieczną odległość, trzeba kontrolować ilość pracy wykonywanej równocześnie. W Kanbanie mówi się o niej, że to praca w toku (ang. work in progress, w skrócie WIP). Obowiązek monitorowania poziomu owego WIP-u i dbania, by się nadmiernie nie rozrósł, jest jednym z wymogów Kanbana, bez którego spełnienia strategia ta ma mierne szanse przynieść korzyści.

WIP i jego limity

Każdy, kto cokolwiek słyszał lub czytał o Kanbanie, zetknął się zapewne z limitami WIP. Być może natrafił też na opinie, że pozbawiony tych limitów proces ciężko uznać za implementację Kanbana. Limitowanie WIP-u jest wskazywane jako kluczowy element tej strategii, na równi z koniecznością stworzenia tablicy kanbanowej. Czy słusznie? O tym za moment.

Najpierw warto wyjaśnić, czym są wspomniane limity, a na wszelki wypadek zdefiniować trzeba, czym jest WIP – bo i to nie jest dla wszystkich oczywiste.

WIP, czyli praca w toku, to każda rzecz, której realizacja ma przynieść wartość i nad którą praca już się rozpoczęła, ale jeszcze nie zakończyła. Inaczej mówiąc, jeśli np. budowane jest oprogramowanie, którego użytkownicy desperacko potrzebują możliwości sporządzenia jakiegoś raportu, to w momencie, gdy development mechanizmu raportowego się zacznie, wymaganie opisujące potrzebę użytkowników stanie się częścią WIP-u. I pozostanie jego częścią do momentu, gdy prace zostaną ukończone – nawet wtedy, gdy aktualnie żaden Developer się nim nie zajmuje.

To ostatnie stwierdzenie jest bardzo ważne, bo praca w toku nie obejmuje tylko tych rzeczy, nad którymi faktycznie teraz ktoś pracuje, ale wszystko, co już jest robione, a jeszcze nie zostało skończone.

Miarą WIP-u jest więc aktualna liczba realizowanych rzeczy – tak po prostu. A że ta liczba bywa zmienna (bo coś się zaczyna, a coś innego kończy potencjalnie każdego dnia), poziom WIP-u też nie jest stały. Czasem rośnie, czasem spada.

Limity WIP są więc określeniem poziomu WIP-u, który nie powinien być przekraczany, jeśli ma zaistnieć przepływ (czyli jeśli ma istnieć realna możliwość, by praca nad tym WIP-em faktycznie posuwała się do przodu).

Limit czy limity?

Dlaczego mowa nie o limicie WIP, ale o limitach? Oczywiście można posłużyć się jednym globalnym limitem dla całego procesu, ale niekoniecznie ma to sens, bo można wyobrazić sobie, że cała rozpoczęta już praca skumuluje się na jednym etapie. A to ma szansę przerosnąć możliwości ludzi, którzy się WIP-em zajmują, choćby dlatego, że etap ten wymagać będzie np. specyficznego narzędzia, którego dostępność jest ograniczona. Dlatego najczęściej stosuje się więcej niż jeden limit, np. poprzez określenie liczby rzeczy, które jednocześnie mogą znaleźć się w każdym ze stanów procesu.

Przy czym Kanban nie determinuje, jak należy te limity definiować. Może być jednocześnie stosowany limit globalny obejmujący całość WIP-u, limity związane z poszczególnymi stanami w procesie albo w całych grupach takich stanów. Limit może być zdefiniowany dla konkretnego typu pracy (np. dopuszczać pracę na raz tylko nad jednym wymaganiem i nad maksymalnie dwoma błędami zgłoszonymi przez użytkowników jakiegoś produktu).

Co oczywiste, nie można tu przesadzić, bo wtedy stosowanie limitów stanie się kłopotliwe lub niemożliwe. Tym bardziej że nie da się ich ustanowić raz-a-dobrze i liczyć, że już zawsze będą dobrze działać. W miarę, jak zmienia się charakter pracy, którą trzeba wykonywać, oraz w wyniku zmian kompetencji ludzi, sposobu ich pracy, możliwości i dostępności narzędzi itd., limity mogą wymagać dostosowania. Podwyższenia, jeśli zadławiają proces, doprowadzając do zmarnowania potencjału, albo obniżenia, jeśli zdarza się, że ilość pracy zrealizowanej równocześnie jest czasami za duża.

Kontrola czy ograniczanie?

Sposób użycia limitów WIP i sama ich nazwa sugeruje, że chodzi o ograniczanie WIP-u, a niektórzy posuwają się w tym dalej, twierdząc, że należy dążyć do stałego jego zmniejszenia. Cóż, zwykle jest to korzystne, ale nawet wtedy tylko do osiągnięcia pewnej granicy, poniżej której przestaje być opłacalne. To jednak temat wart osobnego omówienia.

Wracając do limitów WIP: one nie służą ograniczaniu, ale kontrolowaniu WIP-u. Czy to nie to samo? Zależy od tego, jak ktoś rozumie ograniczanie. Jeśli uważa, że ograniczanie to dążenie do tego, by wartość WIP-u nie przerosła poziomu, przy którym zanika przepływ, to faktycznie na jedno wychodzi. Jeśli natomiast ograniczanie traktowane jest jako ustanowienie formalnego limitu „na wszelki wypadek”, to zdecydowanie jest to coś odległego od kontrolowania. Kontrolowanie nie ogranicza się przecież do bezmyślnego sprawdzania, czy WIP jest mniejszy bądź równy ustanowionemu limitowi, ale obejmuje jeszcze co najmniej dwie rzeczy:

• organizowanie pracy w sposób sprzyjający szybkiemu kończeniu rzeczy (wtedy przestają one być częścią WIP-u);
• monitorowanie skuteczności mechanizmów, które służą utrzymaniu WIP-u na odpowiednio niskim poziomie, a jeśli trzeba, ich dostosowywanie lub zmiana.

Inaczej mówiąc, samo przestrzeganie ustalonych limitów nie wystarczy, by kontrolować WIP, bo jeśli limity są zbyt wysokie, to mimo tego, że nie są przekroczone, przepływ stanie się utrudniony albo w ogóle zaniknie.

Czy limity WIP są obowiązkowe?

Wymóg stosowania limitów WIP jest uznawany za oczywistą rzecz w Kanbanie, ale… nie ma takiego wymogu. Kanban wymaga kontrolowania WIP-u, a limity są jedynie jednym z możliwych mechanizmów (lub strategii), po które można sięgnąć.

Jest to najprostszy sposób, więc ogromna większość użytkowników Kanbana po niego sięga, po czym zmagają się oni z ustalaniem, jakie limity będą w ich sytuacji najlepsze. A potrafi to sprawić spory kłopot i wymaga często dość długiego eksperymentowania.

Czym można posłużyć się zamiast limitów WIP? Można ustanowić reguły (ang. policies), które sterują procesem wciągania pracy zarówno do procesu, jak i do kolejnych stanów w nim. Można też skorzystać ze sposobu ograniczania WIP-u, który funkcjonuje w Scrumie. Albo kreatywnie połączyć te wszystkie podejścia, zachowując przy tym umiar, żeby nie skomplikować nadmiernie kontrolowania WIP-u.

Zaraz, zaraz… ograniczanie WIP-u w Scrumie…?! Niby w jaki sposób?

Na te oraz inne pytania związane z Kanbanem i sposobem kontrolowania WIP-u można uzyskać odpowiedź w trakcie warsztatu Mastering Professional Kanban. A pytań uczestnicy zadają całkiem sporo. Przykłady? Proszę bardzo, oto kilka z nich:

• Czy limity WIP, jeśli już są użyte, można łamać?
• Czy jeśli trzeba wykonać jakąś pilną robotę, wymaga to tymczasowego podniesienia limitów, jeśli już są w pełni wykorzystanie?
• Czy aby obniżyć limit WIP, należy najpierw zmniejszyć WIP do docelowego, niższego poziomu?
• Czy limity WIP muszą zawsze być w pełni wykorzystane?

Temu ostatniemu problemowi poświęcony zostanie kolejny artykuł, który pojawi się już wkrótce.