Agile’owy światek uwielbia akronimy. Jednym z nich jest WIP, który oznacza Work In Progress, a mówiąc po polsku – pracę w toku. Jest to coś, czemu powinniśmy poświęcić naprawdę dużo uwagi, zarówno w pracy, jak i w życiu prywatnym.
Work In Progress (WIP)
WIP bywa rozwijany także jako „work in process” i jako termin ma swoje źródło w zarządzaniu łańcuchem dostaw. W procesach wytwórczych bardzo ważna jest optymalizacja czasu, jaki niedokończony produkt spędza w naszej organizacji.
Nie chcemy poświęcać środków na przechowywanie niegotowych, nienadających się do sprzedaży towarów – to jest nasz WIP. Idealnie byłoby jak najszybciej kończyć to, co zaczęliśmy, ale nie chcemy też posiadać ogromnych magazynów z zapasami wszystkich niezbędnych materiałów. Najlepiej byłoby mieć ich tylko tyle, żeby produkcja przebiegała bez przestojów.
W tym miejscu pojęcie pracy w toku łączy się z innymi ciekawymi skrótami, takimi jak TPS (Toyota Production System) i JIT (Just-In-Time Manufacturing), które jak łatwo się domyślić, powstały w fabrykach Toyoty. Te strategie stworzone zostały w celu ograniczenia czasu przepływu produktów (samochodów) przez proces wytwórczy i szybszego reagowania na potrzeby klientów, przy jednoczesnej minimalizacji zapasów własnych.
W wielkim skrócie chodzi o to, żeby niedokończone towary (WIP) nie blokowały nam niepotrzebnie zasobów. Możemy je przecież poświęcić na coś bardziej konstruktywnego. Ale jak to ma się do naszego agile’owego światka?
Multitasking nie działa
Im więcej rzeczy robimy, tym gorzej nam to wychodzi. Szacuje się, że już przy 4 zadaniach, którymi żonglujemy jednocześnie, więcej czasu poświęcimy na przełączanie kontekstu (czytaj: zabieranie się do pracy) niż efektywne wykonywanie zadań (czytaj: pracę).
O ile czynność nie jest mechaniczna, to zasadniczo potrafimy skupić się tylko na jednym wyzwaniu. Szczególnie, jeśli jest to wyzwanie intelektualne. A przecież wyłącznie z takimi mamy do czynienia w każdym kreatywnym przedsięwzięciu, w tym na projekcie informatycznym.
„Multitasking to okazja do zepsucia kilku rzeczy na raz.”
Co gorzej – próbując żonglować zadaniami nie tylko poświęcamy na to więcej czasu, ale i osiągnięte efekty są o wiele gorsze, niż gdybyśmy się skupili na jednej rzeczy. Z jednej strony cierpi jakość, a z drugiej sprawiamy, że korzyści pojawią się później.
Jeśli mamy trzy projekty, z których każdy zajmie nam miesiąc, to realizując je jednocześnie pewnie skończymy po czterech miesiącach (bo pracujemy mniej wydajnie). Gdybyśmy skupili się na każdym z nich po kolei, to pierwszy zacząłby przynosić korzyści już po miesiącu, a nie po czterech. A nawet ten „ostatni” zrealizowany byłby po zaledwie trzech miesiącach.
O tym i o innych zagrożeniach multitaskingu wspominaliśmy w naszym filmiku na YouTube:
Limit WIP
Żeby uniknąć multitaskingu wprowadzane są limity WIP. Tak, jak w fabryce samochodów nie ma sensu, żeby na taśmę produkcyjną wjeżdżało 10 samochodów na godzinę, skoro zjechać z niej mogą tylko 3, tak i u nas nie ma sensu zabierać się za 10 zadań, jeżeli zrealizujemy tylko 3. Dotyczy to zarówno zespołu, jak i konkretnego etapu (np. „nie więcej niż 2 funkcjonalności w testach”) czy stanowiska (np. „developer nie zajmuje się więcej niż 1 wymaganiem na raz”).
Każda metodyka agile promuje samoorganizujące się zespoły. W nich zaś praca nie jest przypisywana do nikogo na sztywno. Każdy może, w ramach swoich kompetencji, wziąć się za dowolne zadanie. Nie ma żadnego sensu zagarniać dla siebie dziesięciu zadań. Po pierwsze – na raz będziemy pracować tylko nad jednym. Po drugie – pozostałe dziewięć mogą w tym czasie realizować inni członkowie zespołu.
W idealnym świecie limit WIP dla każdej osoby i każdego etapu realizacji zadania powinien wynosić 1 (słownie: jeden). Zabieramy się za jakieś zadanie, realizujemy je, kończymy i dopiero potem szukamy następnego wyzwania. W życiu jednak nie jest tak prosto.
Wąskie gardła
Bardzo często zdarza się, że napotkamy na problemy w trakcie realizacji naszych zadań. Czasami są one proste i wymagają jedynie zwiększonego wysiłku, a czasami nas przerastają. Zdarzają się też sytuacje, w których musimy na kogoś poczekać, zanim ruszymy dalej. Wszystko to są naturalne sytuacje, w których aktualnie rozpoczęty fragment pracy odkładamy na bok i zabieramy się za coś innego.
Pamiętajmy, że w chwilach, w których pauzujemy naszą pracę, bo czekamy na kogoś innego, to ktoś czeka na nas. Jeśli nie inny zespół, to na pewno czeka użytkownik końcowy (czytaj: klient).
Po co więc ograniczać Work In Progress? Przede wszystkim po to, żeby walczyć z naszą ludzką naturą. W przypadku napotkania problemów z zadaniem mamy tendencje do odkładania go na bok i zabierania się za kolejne. Nasze sumienie śpi, bo przecież wykonujemy „jakąś” pracę.
Niestety, te odłożone zadanie blokuje nas, zespół i wszystkie prace związane z tym elementem. A czasami wystarczy tylko odrobina wysiłku, żeby uporać się z „problemem” i ruszyć dalej.
Indywidualny Work In Progress
Najtrudniej jest przyznać się przed samym sobą i stwierdzić, że coś jest trudniejsze niż myśleliśmy. Ale to pierwszy krok do tego, żeby rozwiązać ten problem, a nie odkładać go na już i tak uginającą się półkę. Co więcej, w chwili gdy jasno powiemy jaka jest sytuacja z tym zadaniem, zapewniamy tak ważną we współpracy transparentność.
Jeszcze ważniejsza niż ograniczenie pracy realizowanej w każdym Sprincie jest umiejętność ignorowania zadań, którym i tak nie damy rady podołać. Przed tym pierwszym chronią nas takie spotkania jak Sprint Planning i Sprint Retrospective. O te drugie musimy zadbać sami.
Nie ma nic bardziej destrukcyjnego niż interesariusz, albo – o zgrozo – Product Owner, który w trakcie sprintu dorzuca rzeczy do zrobienia „na wczoraj”. Pamiętajmy, że Scrum Master powinien chronić zespół przed takimi sytuacjami.
Pamiętajmy, że pracujemy w zespole. Z jednej strony nie chomikujmy pracy po to, żeby np. w ostatnim dniu sprintu oddać dziesięć funkcjonalności do testów, ale z drugiej strony pamiętajmy, że my również powinniśmy wspierać innych. Spójrzmy na nasz Cel Sprintu i zastanówmy się, czy to, co teraz robimy przybliży nas do jego zrealizowania.
Ale zanim weźmiesz się za kolejne zadanie z backlogu Sprintu, upewnij się, że zrobiłeś absolutnie wszystko co mogłeś z aktualnie wykonywanymi wyzwaniami. Bo jeśli masz więcej niż dwa-trzy „work in progress”, to być może potrzebujesz systemowo wprowadzonego limitu WIP.
