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 (WiP limit, czyli Work in Progress limit). Dla osób świadomie korzystających z metody Kanban taki limit nie jest niczym nowym lub niezwykłym. Inni, pracujący w Scrum, 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. Wytwarzanie oprogramowania to domena równie nieprzewidywalna jak prognozowanie pogody, 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 również 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 zespół szacuje, że w sprincie 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 wpis). Przyjmijmy, że zazwyczaj tych wymagań w sprincie zespół realizuje kilka, cztery, może pięć, czasem więcej.

Jeśli Zespół Developerski nie zdecyduje się na limitowanie ilości wymagań, nad którymi pracuje jednocześnie, najpewniej zacznie 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 Definition of Done (DoD).

Co się stanie, jeśli zespół zacznie realizować wiele wymagań jednocześnie i w drugiej połowie sprintu odkryje, że nie uda się wszystkiego skończyć? Odpowiedź jest pozornie prosta: to, co uda się skończyć, będzie Done, a reszta wró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ć wydane, 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 Done 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 ostateczności wyłączone). Wtedy, i tylko wtedy, da się wydać to, co jest Done. Wymaga to dodatkowej pracy i czasu. Pytanie, czy zespół zdąży to zrobić w sprincie i czy efektem nie będzie sytuacja, w której w praktyce nic nie jest gotowe do wydania.

Sekwencyjna praca nad wymaganiami

Gdy zespół realizuje wymagania sekwencyjnie, czyli WiP limit = 1 jest obowiązującą zasadą, taka sytuacja nie może mieć miejsca. Widząc, że nie ma szans zakończyć kolejnego wymagania w sprincie, zespół zrezygnuje po prostu z rozpoczynania pracy nad nim. Gdyby już pracował nad kolejnym wymaganiem, a czasu na dokończenie byłoby za mało, w kontrolowany sposób może „zaparkować” prace nad nim, lub w ostateczności usunąć związany z nim kod 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 je wydać, jeśli Produkt Owner podejmie taką decyzję.

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: zagadnień z backlogu produktu), zespół powinien honorować te decyzje. Podejmując się realizacji wielu wymagań jednocześnie może łatwo doprowadzić do sytuacji, że zakończy 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 z reguły 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 te 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 (focus). Pracując nad jednym wymaganiem na raz, zespół unika rozproszenia się na wiele tematów, pomaga to też budować 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 w pełni cross–funkcyjny (interdyscyplinarny). 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?