Blog

Na szkoleniach, które prowadzę, ale też w rozmowach ze znajomymi pracującymi w różnych firmach, zdarza się czasami dyskusja na temat ograniczenia ilości pracy, która jest wykonywana równocześnie (ang. work in progress, czyli WIP). Dla osób świadomie korzystających z Kanbana taki limit nie jest niczym nowym lub niezwykłym. Inni często reagują zaskoczeniem, a czasami oburzeniem, gdy twierdzę, że WIP należy ograniczać także w Scrumie, a optymalną wartością w większości przypadków jest limit równy jeden (1). I bynajmniej nie uważam tego za podejście fundamentalistyczne, irracjonalne lub pozbawione pragmatyzmu. Wręcz przeciwnie, WIP limit = 1 jest naturalną konsekwencją świadomego stosowania Scruma.

Scrum i empiryzm

Scrum jako framework jest prostym narzędziem pozwalającym rozwiązywać złożone problemy. Takim problemem jest na przykład wytwarzanie oprogramowania, bo to domena równie nieprzewidywalna co prognozowanie pogody i nie sposób stworzyć pełnej listy czynników mających wpływ na produkt. Równie wiele czynników wpływa na sposób, w jaki produkt ten wytwarzamy. Nie ma też co marzyć o kontrolowaniu tych czynników, a pamiętać trzeba, że oprogramowanie tworzą ludzie i jest ono tworzone dla ludzi. To kolejny poziom złożoności.

Aby poradzić sobie ze złożonością i nieprzewidywalnością, Scrum wykorzystuje empiryczną kontrolę procesów. Empiryzm ten obejmuje zarówno proces, jak i produkt. W regularnych interwałach czasowych, wyznaczonych rytmem Sprintów, następuje sprawdzenie, co udało się  zrealizować w kończącym się Sprincie i dostosowanie planów dalszego rozwoju produktu. Kluczowym artefaktem, który to umożliwia, jest działający, zintegrowany produkt.

Co ma do tego WIP limit = 1?

Bez limitów

Rzadko kiedy podczas Planowania Sprintu Zespół szacuje, że zrealizuje tylko jedno wymaganie. W istocie, jeśli się to zdarza, jest objawem mało efektywnej pracy z Backlogiem Produktu (ale to temat na osobny artykuł). Przyjmijmy, że zazwyczaj tych wymagań w Sprincie Zespół realizuje kilka, cztery, może pięć, czasem więcej.

Jeśli Developerzy nie zdecydują się na limitowanie ilości wymagań, nad którymi pracują jednocześnie, najpewniej zaczną realizować dwa, czasami trzy od pierwszego dnia Sprintu. Daje to poczucie, że prace postępują, dużo się dzieje i wszyscy są zajęci. Wielu Zespołom (ale też wielu Scrum Masterom) umyka, że niekoniecznie chodzi o to, by być zajętym; celem powinno być skuteczne realizowanie wymagań tak, by rozwiązania spełniały kryteria opisane przez Definicję Ukończenia (ang. Definition of Done).

Co się stanie, jeśli Developerzy zaczną realizować wiele wymagań jednocześnie i w drugiej połowie Sprintu odkryją, że nie uda się wszystkiego skończyć? Odpowiedź jest pozornie prosta: to, co uda się skończyć, zostanie dostarczone (uznane zostanie za done), a reszta wymagań powróci do Backlogu Produktu. Cóż, nie do końca jest to takie proste.

Skoro done oznacza, że wymaganie jest w pełni zrealizowane i rozwiązanie może być użyte (przekazane użytkownikom), Product Owner ma prawo poprosić o to na koniec Sprintu. Przy czym skoro mamy jeden produkt, w którym część wymagań jest done a pozostałe nie, nie da się go tak po prostu wydać, bo udostępnione zostałyby również te funkcjonalności produktu, które ukończone nie są.

Jedynym rozwiązaniem w tej sytuacji jest podjęcie twardej decyzji przez Developerów: to, czego nie udało się skończyć, zostanie z produktu usunięte lub w jakiś sposób w nim wyłączone. Wtedy i tylko wtedy da się użyć tego, co jest done. Wymaga to dodatkowej pracy i czasu. Pytanie, czy Developerzy zdążą to zrobić w Sprincie i czy aby efektem nie będzie sytuacja, w której w praktyce nic nie jest gotowe do użycia.

Sekwencyjna praca nad wymaganiami

Gdy Developerzy realizują wymagania sekwencyjnie, czyli WIP limit = 1 jest obowiązującą zasadą, taka sytuacja nie może mieć miejsca. Widząc, że nie ma szans na zrealizowanie kolejnego elementu Backlogu Produktu przed końcem Sprintu, Developerzy zrezygnują po prostu z rozpoczynania pracy nad nim. A gdyby właśnie pracowali nad jakimś wymaganiem, na którego ukończenie byłoby już za mało czasu, w kontrolowany sposób mogą zaparkować prace nad nim, lub w ostateczności usunąć związane z nim zmiany z produktu. Wtedy zintegrowany produkt na koniec Sprintu zawierał będzie wyłącznie te rozwiązania, które są done – i bez trudu można ich użyć.

Kto decyduje o kolejności?

Jest drugi powód, dla którego WIP limit = 1 ma w Scrumie głęboki sens. Skoro odpowiedzialnością Product Ownera jest decydowanie o kolejności realizacji wymagań (albo szerzej: elementów Backlogu Produktu, bo przecież nie zawsze są w nim tylko wymagania), Developerzy powinni honorować te decyzje. Podejmując się realizacji wielu wymagań jednocześnie, mogą łatwo doprowadzić do sytuacji, że zakończą prace nad wymaganiami, które w Backlogu Produktu były niżej niże te, na które czasu zabrakło (i które na koniec Sprintu nie są done).

Cel Sprintu a limit WIP

Warto też pamiętać, że Cel Sprintu często jest wypadkową wymagań, które w Backlogu Produktu były na samej górze. Można śmiało przyjąć, że realizując wymagania według kolejności określonej w Backlogu Produktu, maksymalizuje się szansę na osiągnięcie Celu Sprintu (w trakcie Sprintu czasami ujawnia się niezbędna do wykonania dodatkowa praca i konieczne jest zrezygnowanie z realizacji jednego lub kilku wymagań).

Jeśli kolejność wymagań w Backlogu jest z jakiegokolwiek powodu nieakceptowalna (bo zwiększa ryzyko lub prowadzi do nierozwiązywalnych zależności) – odpowiedzialnością Developerów jest poinformować o tym Product Ownera. Mając tę wiedzę, dostosuje on Backlog tak, by umożliwić efektywne realizowanie wymagań.

Wartości Scrum

Gdyby komuś było mało argumentów, jest jeszcze jeden. Jedną z wartości Scrum jest skupienie (ang. focus). Pracując nad jednym wymaganiem na raz, Developerzy unikają rozproszenia się na wiele tematów, pomaga to też uzyskać wspólnotę pracy. Zespół pracujący nad czymś razem jest dużo bardziej przygotowany do radzenia sobie z wyzwaniami i złożonością, bo jest bardziej wszechstronny (ang. cross-functional). Jeśli każdy w Zespole pracuje nad czymś innym, zaczyna być trudniej: ktoś na kogoś musi poczekać, czasami pojawiają się zależności między poszczególnymi kawałkami równolegle wykonywanej pracy…

Czy zatem połączenie Scrum i WIP limit = 1 naprawdę jest objawem fundamentalizmu i braku zdrowego rozsądku? Czy też naturalną konsekwencją zastosowania empiryzmu i reguł obowiązujących w tej metodzie?