Blog

W niedawnym artykule pisałem o tym czym spike jest, do czego można wykorzystać go w Scrumie, oraz jak można użyć tej praktyki w sposób niekoniecznie sensowny. Nie odpowiedziałem natomiast na częste pytania związane z liczeniem velocity i procesem szacowania.

Proces szacowania

Zacznę od innego zagadnienia, a dokładniej od pytania: po co w Scrumie szacuje się koszt, czas, wielkość etc. wymagań w backlogu produktu? Odpowiedzi można udzielić kilka:

• przede wszystkim po to, by zdecydować, czy warto coś zrobić – do tego musimy wszak dysponować zarówno prognozą wartości jak i oszacowaniem kosztów jej uzyskania,
• by lepiej zrozumieć, co kryje się w wymaganiu,
• by ocenić, czy możliwe jest jego zrealizowanie w sprincie i zdecydować o ewentualnym podziale na mniejsze elementy,
• by uzyskać prognozę, kiedy (mniej więcej) wymaganie zostanie zrealizowane,
• w końcu – by móc łatwiej zaplanować sprint.

Rodzaj oszacowania (i cel, któremu ma służyć) decyduje o tym, kto estymacji dokonuje. Product Owner dokona oszacowań wartości, jaką uzyskać można z realizacji określonych elementów backlogu produktu, a zespół developerski szacował zatem będzie wszystko, co związane z jego pracą, na przykład:

• w czasie planowania sprintu to developerzy prognozują, ile wymagań zdołają ukończyć w czasie iteracji,
• szacują również ilość pracy związanej z realizacją poszczególnych elementów backlogu sprintu,
• codziennie, podczas Daily Scruma, sprawdzają postęp prac i adekwatność planów na pozostałą część sprintu (co również implikuje jakąś formę szacowania).

Natomiast prognoza terminów ukończenia prac nad konkretnymi wymaganiami lub zakresów poszczególnych wydań produktu wymagać będzie wspólnego wysiłku developerów i Product Ownera. Ale wróćmy do spike’ów.

Oszacowanie spike’a

Definiując spike zespół prognozuje przede wszystkim jego rezultat, a nie ilość pracy, wielkość lub czas (o tym za moment). Celem jest uzyskanie wiedzy, potwierdzenie lub wykluczenie istnienia problemu, rzadziej eksploracja „w ciemno”.

W przypadku spike’a developerskiego mamy do czynienia z timeboxem, który jest ustalany z góry, na początku. Raz zdefiniowany nie jest prognozą, ale czymś pewnym, w pełni pod kontrolą zespołu. Co oczywiste, określenie długości timeboxu w innych jednostkach niż jednostki czasu nie ma żadnego sensu.

Dobierając długość timeboxu dla spike’a zespół ocenia, ile czasu może poświęcić w sprincie na eksplorację bez pewności, jakie da ona rezultaty – jest wiec to oszacowanie przede wszystkim ryzyka, a nie czasu. Developerzy powinni wziąć pod uwagę:

• jakie jest minimum długości timeboxu pozwalające uzyskać użyteczną wiedzę,
• na jak długie eksplorowanie „w ciemno” można pozwolić sobie w sprincie bez zagrożenia możliwościom osiągnięcia celu sprintu.

Spike a relatywne oszacowania

Próba „przylepiania” do spike’a relatywnych estymat (takich jak story pointy) świadczy o niezrozumieniu jednej z tych technik (a może i obu). Story point jest przecież bezwymiarowy i opisuje wielkość rozumianą jako wypadkowa czasochłonności, pracochłonności, złożoności, ryzyka, ilości zależności, poziomu wiedzy i umiejętności developerów itd. Albo story point zostaje „uwymiarowiony” w tym przypadku i opisuje czas trwania spike’a, albo zespół nie traktuje spike’a jako timeboxu.

Zdarza się też, że spike ma określony zarówno timebox (na przykład w dniach lub godzinach), jak i „estymatę” w story pointach (lub dowolnej innej formie relatywnych oszacowań używanej w odniesieniu do elementów backlogu produktu). Zespoły zapytane o to wyjaśniają, że wynika to z „konieczności” uwzględnienia pracy poświęconej na realizację spike’ów podczas planowania oraz liczenia velocity. A ja ciężko wtedy wzdycham…

Czego miarą jest velocity?

Fachowo mówiąc to lagging indicator pokazujący tempo przetwarzania backlogu produktu przez zespół developerski. Lagging – ponieważ obrazuje to, co już zaszło, jest informacją historyczną. Nie da się użyć wiedzy o velocity w zakończonym już sprincie by zmienić przebieg tego sprintu, czyż nie? Można jedynie użyć informacji o przebiegu sprintu jakiej dostarcza velocity do wyciągnięcia wniosków na przyszłość.

Dla zespołu scrumowego i będącego jego częścią zespołu developerskiego velocity może służyć jako narzędzie do wykrycia, że tempo prac spada lub wzrasta z każdym sprintem. To pierwsze może (ale nie musi) być symptomem jakiegoś problemu, to drugie może (ale nie musi) być pozytywnym efektem poczynionych usprawnień.

Dla Product Ownera velocity jest narzędziem prognozowania potencjalnych dat ukończenia poszczególnych elementów backlogu produktu, przy czym nigdy nie ma pewności, że przewidywania te się potwierdzą.

Velocity nie jest miarą ani skuteczności, ani efektywności, ani nawet produktywności zespołu scrumowego lub zespołu developerskiego. Nie jest też miarą uzyskanej wartości, bo dostarczany jest produkt, a nie abstrakcyjny twór jakim jest velocity. Nie jest „za niskie” ani „za wysokie” – jest po prostu informacją o tym, jak przebiegły zakończone już sprinty.

Velocity a spike developerski

Wróćmy do pomysłu, by szacować spike i uwzględniać go przy kalkulacji velocity. Na początek przypomnę, że istnieją trzy zasadnicze przyczyny, dla których spike w ogóle jest używany:

• uzyskanie wiedzy niezbędnej do podjęcia kluczowych decyzji technologicznych,
• wsparcie dla procesu pielęgnacji backlogu,
• wsparcie dla procesu usprawniania pracy zespołu.

Realizacja spike wymaga wykonania pracy, więc „zjada” on czas dostępny w sprincie. Podobnie rzecz ma się z realizowanymi usprawnieniami i wszystkimi czynnościami podejmowanymi w ramach procesu pielęgnacji backlogu produktu. Im więcej ich robimy, tym mniej czasu pozostaje na realizację wciągniętych do sprintu elementów backlogu produktu. Z drugiej strony, jeśli zaprzestaniemy na przykład pielęgnacji backlogu, dość szybko niemożliwe stanie się zaplanowanie kolejnego sprintu.

Przyjmuję za oczywistą rzecz, że czas poświęcony na pielęgnację backlogu nie jest „szacowany” w story pointach ani uwzględniany jako osobny element backlogu produktu. Może za to znaleźć odzwierciedlenie w backlogu sprintu. Rozsądek podpowiada, że tak samo należy podejść do spike’a developerskiego, który jest częścią tej pielęgnacji.

Również usprawnienia zdefiniowane podczas retrospekcji nie są umieszczane w backlogu produktu, tylko stają się częścią backlogu sprintu. Praca nad nimi również nie jest uwzględniana podczas kalkulacji velocity. Jeśli w ramach realizacji usprawnienia zespół zdecyduje się na przeprowadzenie krótkiego spike’a, jego szacowanie w story pointach byłoby zatem nielogiczne.

A co jeśli spike realizowany jest, by rozwiązać problem technologiczny, na który zespół natrafił pracując nad produktem? Wtedy faktycznie praca ta powinna być uwzględniona w velocity, o ile dotyczy wymagań już realizowanych, a nie tych znajdujących się wciąż w backlogu produktu. Tyle, że w takim przypadku ów spike jest po prostu jednym z wielu zadań, jakie zespół developerski musi wykonać, by wytworzyć produkt. Jeśli wymaganie uda się zrealizować, to wtedy praca poświęcona na spike zostanie uwzględniona w velocity, podobnie jak uwzględniane w nim są inne czynności: programowanie, testowanie czy pisanie dokumentacji.

Robienie zbyt dużej ilości spike’ów spowoduje, że mało wymagań zostanie zrealizowanych. Zdrowy rozsądek podpowiada, że velocity (będące miarą nie tego, że „zespół pracuje”, ale tempa realizacji elementów backlogu) powinno być wtedy niskie. Im więcej spike’ów, tym velocity jest niższe. I dobrze, bo przecież spike developerski nie dostarcza wartości w rozumieniu funkcjonalności lub cech produktu, a jedynie wiedzy potrzebnej do jego budowania.

Takie traktowanie spike’ów trzyma w ryzach skalę stosowania tej techniki. Jeśli pojawi się pokusa, by przed każdym wymaganiem „na brudno” zrobić jakieś rozwiązanie, żeby potem było łatwiej, velocity (zakładając, że zespół je liczy i się nim przejmuje) poszybuje w dół.

„Ale przecież spike to wartościowa praca!”

Nie neguję, że tak jest i pisałem o tym w pierwszej części. Wiedza pozwalająca podejmować lepsze decyzje to wartość. Natomiast sama wiedza nie skutkuje rozwojem produktu. Innymi słowy nie każda sensowna czynność wykonana przez zespół scrumowy podnosi wartość produktu – co nie znaczy, że jest zbędna.

Dążenie do wykazania pracy poświęconej na spike w velocity podpowiada, że to ostatnie użyte jest do udowodnienia czegoś otoczeniu, a niekoniecznie dla dobra zespołu i rozwiązań, jakie wytwarza. Robi się dość upiornie, jeśli celem jest „bycie zajętym”, czy też „dostarczanie dużej ilości wymagań”. Tym celem powinno być osiągnięcie wartości, a velocity nie jest jej miarą.

Jeśli więc team chce szacować spike developerski po to, by dodać go do velocity, bo „wykonał pracę”, Scrum Masterowi powinny się zapalić lampki alarmowe. Udowadnianie, że nie marnuje się czasu, prowokuje do zadania pytania skąd w ogóle wątpliwość co do tego? Przed kim trzeba wykazać się produktywnością? Czy ten ktoś patrzy na właściwe wskaźniki podejmując decyzje?

Spike developerski będący częścią pielęgnacji backlogu powinien być zrozumiały dla Product Ownera – a jeśli nie jest, warto usprawnić współpracę między poszczególnymi rolami w zespole scrumowym. Możliwe też, że uczestnicy procesu nie rozumieją, że w Scrumie robi się wiele rzeczy, które „nie dodają nic do velocity” ale są niezbędne, żeby cokolwiek „do velocity można było dodać”. Odkrycie tego ujawnia potrzebę edukacji w zespole (kolejna praca dla Scrum Mastera).

Z dokładnie takich samych (marnych) powodów zespoły czasami szacują pracę związaną z usuwaniem błędów: chcą wykazać, że „praca wre”. Tymczasem rozwiązywanie „bugów” (nie wszystkich, ale większości) to robienie raz jeszcze czegoś, co już było robione, ale zostało źle wykonane. Mówiąc obrazowo zespół już sobie to dodał do velocity, gdy – świadomie lub nie – zamiast działającego rozwiązania dostarczył bubla. Dodanie tego raz jeszcze (albo i wiele razy, gdy błąd zostanie źle rozwiązany), nie wydaje się do końca uczciwe…

Estymaty dla spike’a na planowaniu sprintu

Czasami szacowanie spike’a developerskiego w story pointach jest uzasadnione koniecznością zapewnienia, że możliwe będzie zaplanowanie sprintu. Celem jest „lepsze planowanie”, lecz niezupełnie rozumiem, jak przypisanie story pointów może w tym pomóc. Dlatego musiałem sięgnąć do propagatorów tego podejścia i raz jeszcze potknąłem się o kwestię velocity.

Planując sprint zespół może i powinien korzystać ze wszystkich dostępnych miar i wskaźników, które pozwolą mu zrobić to lepiej. Jednym z nich jest wspomniane velocity, które umożliwia zgrubne oszacowanie, ile elementów backlogu produktu może dać się zrealizować w zaczynającym się sprincie. Natomiast planowanie „pod velocity” (czyli tak, aby uzyskać taką prędkość jak w poprzednich sprintach) nie jest rozsądne, a bywa bardzo szkodliwe.

Jeśli gdzieś punktem wyjścia do planowania i jego podstawą faktycznie jest velocity, to nieuchronnie pojawi się dążenie, by do każdej pracy – również tej nie wynikającej z elementów backlogu produktu – przypisywać story pointy. Scrum Master takiego zespołu powinien zadbać o podniesienie zrozumienia, czym jest prognoza sprintu i jak używać narzędzi takich jak velocity.

Niezależnie od tego, czy velocity używa się jako punktu wyjścia do planowania, czy do dodatkowej weryfikacji poczynionych planów – brak oszacowania spike’ów nie jest w tym przeszkodą. Skoro to timeboxy, da się precyzyjnie określić, ile z czasu dostępnego w sprincie skonsumują. I dysponując tą wiedzą, można zaplanować pozostałe działania w czasie iteracji.

Ciąg dalszy nastąpi

W kolejnej, ostatniej już części, podpowiem jak korzystać ze spike’a developerskiego w Scrumie jako narzędzia ułatwiającego organizację pracy w sprincie.

Część 1 Część 3