W niedawnym artykule pisałem o tym, czym jest spike, do czego można wykorzystać go w Scrumie, oraz jak można użyć tej praktyki w sposób sensowny. Nie odpowiedziałem natomiast na częste pytania związane z liczeniem velocity i procesem szacowania.
Oszacowania
Zacznę od innego zagadnienia, a dokładniej od pytania: po co w Scrumie wycenia się koszt, czas, wielkość etc. elementó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 poszczególnych elementach Backlogu,
- by ocenić, czy możliwe jest ich zrealizowanie w Sprincie i zdecydować o ewentualnym podziale na mniejsze elementy,
- by sporządzić prognozę tego, kiedy (mniej więcej) element zostanie zrealizowany,
- w końcu – by móc łatwiej zaplanować Sprint.
Rodzaj oszacowania (i cel, któremu ma służyć) determinuje, kto wycen powinien dokonać. Product Owner oszacować może wartość, jaką uzyskać można z realizacji określonych elementów Backlogu Produktu, a Developerzy wycenić mogą ilość pracy, jaka się z tym wiąże. W szczególności:
- w czasie Planowania Sprintu Developerzy prognozują, jak wiele zmian w produkcie są w stanie dokonać przed końcem iteracji,
- szacują również ilość pracy związanej z realizacją poszczególnych elementów Backlogu Produktu,
- codziennie, w trakcie Daily Scrumów, 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 elementami Backlogu Produktu wymagać będzie wspólnego wysiłku Developerów i Product Ownera. Wróćmy jednak do spike’ów.
Oszacowanie spike’a
Definiując spike, Developerzy prognozują (przewidują) rezultaty, które być może uda się uzyskać. Celem jest uzyskanie wiedzy, potwierdzenie lub wykluczenie istnienia jakiegoś potencjalnego problemu, rzadziej eksploracja w ciemno. Nie jest nim natomiast wytworzenie rozwiązania, a jeśli nawet, to w formie prototypu lub demonstratora możliwości (ang. proof of concept, w skrócie POC lub PoC).
W przypadku spike’a niezbędne jest określenie maksymalnego czasu, po którym prace zostaną przerwane (choć może nastąpić to również szybciej). Taki timebox jest ustalany z góry i nie jest prognozą, tylko konkretnym ustaleniem, którego należy się trzymać. To chroni Deweloperów od poświęcenia zbyt dużej ilości czasu na eksplorację, która prowadzi donikąd. Co oczywiste, timebox definiowany jest w jednostkach czasu (a nie np. w story pointach). Czasami dodatkowo ograniczana jest liczba osób, które będą w spike’u uczestniczyć.
Dobierając długość timeboxu, Developerzy oceniają, ile czasu mogą poświęcić w Sprincie na eksplorację bez pewności, jakie da ona rezultaty – jego podstawą jest więc przede wszystkim oszacowanie 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 ograniczenia możliwości osiągnięcia Celu Sprintu.
Spike a relatywne oszacowania
Próba wyceniania spike’a w relatywnych estymatach (takich jak story pointy) świadczy o niezrozumieniu albo jednej z tych technik, albo może i obu.
Story point jest bezwymiarową jednostką do porównywania relatywnej wielkości szacowanych elementów, gdzie przez wielkość rozumieć należy wypadkową czasochłonności, pracochłonności, złożoności, ryzyka, ilości zależności, poziomu wiedzy, umiejętności Developerów itd. Czyli wszystkich tych rzeczy, których Developerzy mogą chcieć się dowiedzieć dzięki przeprowadzeniu spike’a. Jakiż więc sens miałoby szacowanie go w ten sposób?
Oczywiście niektórzy znajdą „sens” bardzo łatwo, bo nieustannie przeliczają story pointy na czas, więc tym razem dokonają operacji odwrotnej i timebox spike’a wyrażą w punktach… Z szacowaniem relatywnym i ideą story pointów nie ma to absolutnie nic wspólnego.
Zdarza się też, że spike ma określony zarówno timebox (na przykład w dniach lub godzinach), jak i wycenę w story pointach (lub dowolnej innej formie relatywnych oszacowań wielkości stosowanej przez Zespół do wycen elementów Backlogu Produktu). Ponoć wynika to z „konieczności poprawnego wyliczenia velocity”, które rzekomo miałoby ulec przekłamaniu, gdyby pracy związanej z realizacją spike’a w niej nie uwzględnić. A ja ciężko wzdycham, gdy to słyszę…
Czego miarą jest velocity?
Fachowo mówiąc, to wskaźnik opóźniony (ang. lagging indicator) tempa przetwarzania Backlogu Produktu – informacja o tym, jak szybko udaje się posuwać w dół listy elementów (stąd zresztą nazwa velocity). Jest to wskaźnik opóźniony, ponieważ dostarcza informacji o tym, co już zaszło. Nie da się użyć wiedzy o velocity w zakończonym Sprincie, by zmienić przebieg tego Sprintu, czyż nie? Można jedynie użyć tej informacji do wyciągnięcia wniosków na przyszłość.
Dla Zespołu Scrum velocity może służyć jako narzędzie monitorowania stabilności i kondycji procesu, czyli np. 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 Scrum. Nie jest też miarą uzyskanej wartości, bo dostarczany jest produkt, a nie abstrakcyjny twór, jakim jest velocity, które może być wysokie nawet wtedy, gdy produkowane są wyłącznie zbędne funkcjonalności i niepotrzebne cechy produktu. Nie jest za niskie ani za wysokie – bo nie ma czegoś takiego jak wymagana prędkość albo dobra prędkość.
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 Produktu,
- 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 i tym samym dążenie do osiągnięcia Celu Sprintu. Z drugiej strony, jeśli np. zaprzestaniemy 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 Produktu nie jest szacowany w story pointach (lub w inny sposób) ani uwzględniany jako osobny element Backlogu Produktu (jeśli ktoś tak robi, to warto bardzo solidnie zastanowić się, jaki to ma sens…). Może za to znaleźć odzwierciedlenie w Backlogu Sprintu, może też polegać na przeprowadzeniu spike’a developerskiego. Wysiłek związany z pielęgnacją dotyczy elementów wciąż znajdujących się w Backlogu Produktu, więc nie może być uwzględniony w velocity. Może natomiast spowodować spadek prędkości, jeśli Zespół poświęca na pielęgnację nieracjonalnie dużo czasu.
Usprawnienia zdefiniowane podczas Retrospekcji Sprintu również nie są umieszczane w Backlogu Produktu, tylko stają się częścią Backlogu Sprintu i raczej nikt (rozsądny) nie szacuje ich w story pointach ani nie uwzględnia przy wyliczaniu velocity. Jeśli w ramach realizacji usprawnienia Zespół zdecyduje się na przeprowadzenie krótkiego spike’a, jego szacowanie w story pointach, a potem uwzględnienie w velocity, byłoby zatem nielogiczne.
A co jeśli spike realizowany jest po to, by rozwiązać problem technologiczny, na który Developerzy natrafili, pracując nad realizacją elementów Backlogu Produktu? Taki spike jest wprost związany z dążeniem do osiągnięcia Celu Sprintu i stanowi jedną z wielu czynności, jakie Developerzy podejmują, by wytworzyć Przyrost. Ten wysiłek faktycznie należy uwzględnić przy wyliczeniu velocity, ale zwykle nie robi się tego w ten sposób, że sam spike jest jakkolwiek szacowany. Dlaczego?
Spike taki jest realizowany w ramach realizacji jakiejś zmiany w produkcie, która przecież ma przypisaną jakąś wycenę, na której podstawie na koniec wyliczone zostanie velocity. Nawet jeśli jest to początkowo nieplanowana praca, która ujawniła się już w trakcie developmentu, niekoniecznie sensowne jest modyfikowanie pierwotnej estymaty. Jeśli jednak Developerzy uprą się przy tym, mogą albo zmodyfikować oszacowanie elementu, z jakim związany jest spike (podnosząc je), albo na upartego przypisać wycenę do spike’a (będzie to chyba jedyny przypadek, gdy da się sensowność takiej decyzji jakkolwiek obronić).
Ja jednak sugerowałbym pozostawić po prostu oryginalną estymatę elementu Backlogu Produktu i wstrzymać się z szacowaniem spike’ów, bo przecież to normalne, że pracy czasami jest więcej, niż Zespół się spodziewał na początku Sprintu. Próba dostosowywania wszystkich oszacowań za każdym razem, gdy coś w pierwotnych planach trzeba zmienić, zabierać będzie czas, nie dając niczego w zamiast. A „lepiej wyliczone velocity” to tylko fałszywa obietnica tego, że w przyszłości sytuacja się nie powtórzy, bo „lepiej zaplanujemy Sprint”.
Robienie zbyt dużej ilości spike’ów spowoduje, że mało zmian w produkcie zostanie zrealizowanych przed końcem Sprintu. Zdrowy rozsądek podpowiada, że velocity musi w takiej sytuacji być dramatycznie niskie. Jeśli jest wciąż wysokie… cóż, coś robimy nie tak.
Niewliczanie spike’ów do velocity pozwala 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) musi poszybować w dół i zadziałać jako ostrzeżenie lub kubeł zimnej wody wylanej na rozpalone głowy.
„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ół Scrum 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 być może 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 jak pisałem wcześniej, velocity nie jest jej miarą.
Jeśli więc Zespół chce szacować spike developerski tylko po to, by móc dodać go do velocity, Scrum Masterowi powinny się zapalić lampki alarmowe. Udowadnianie, że nie marnuje się czasu, prowokuje do zadania pytania o to, skąd w ogóle bierze się potrzeba, by to robić? Przed kim trzeba wykazać się „produktywnością” (cudzysłów celowy, bo velocity nie jest miarą produktywności, ale bywa tak niestety traktowana)? Czy ten ktoś patrzy na właściwe wskaźniki, podejmując decyzje?
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 problemów (nie wszystkich, ale większości) to robienie raz jeszcze czegoś, co już było realizowane, ale zostało źle wykonane. Mówiąc obrazowo, Zespół już sobie to wliczył w przeszłości do velocity jakiegoś Sprintu, gdy – świadomie lub nie – zamiast działającego rozwiązania dostarczył bubla. Dodanie tego do velocity raz jeszcze (albo i wiele razy, jeśli błąd zostanie źle rozwiązany), nie wydaje się uczciwe.
Estymaty dla spike’a na Planowaniu Sprintu
Czasami szacowanie spike’a developerskiego w story pointach jest uzasadniane koniecznością zapewnienia, że możliwe będzie zaplanowanie Sprintu. Celem jest oczywiście „lepsze planowanie”, lecz niezupełnie rozumiem, jak przypisanie story pointów do czegokolwiek (elementu Backlogu Produktu, spike’a itd.) 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ół powinien korzystać ze wszystkich dostępnych miar i wskaźników, które pozwolą mu zrobić to lepiej. Jednym z nich bywa wspomniane velocity, które umożliwia zgrubne oszacowanie, ile elementów Backlogu Produktu może potencjalnie zostać zrealizowanych w zaczynającym się Sprincie. Natomiast planowanie „pod velocity” (czyli tak, aby uzyskać prędkość taką, jak w poprzednich Sprintach) nie jest rozsądne, a bywa bardzo szkodliwe. Dlaczego?
Bo z prognozy opartej o kryteria jakościowe Zespół przechodzi do posługiwania się do prognoz czysto ilościowych. Zamiast dyskutować o planie osiągnięcia Celu Sprintu i oceniać, czy realistyczne jest jego wykonanie przed końcem iteracji, Developerzy wraz z Product Ownerem analizują, które elementy Backlogu Produktu wybrać do realizacji, żeby ich oszacowania w sumie dały tyle, ile średnio wynosi velocity. Jest to podwójnie absurdalne, bo przecież wszystkie te wyceny są obarczone mniejszych lub większym błędem…
Jeśli punktem wyjścia do Planowania Sprintu i jego podstawą faktycznie jest velocity, to nieuchronnie pojawi się dążenie, by do każdej pracy – również tej niewynikającej z realizacji 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 definiowane są dla nich timeboxy, da się precyzyjnie określić, ile z czasu dostępnego w Sprincie skonsumują. Dysponując tą wiedzą, można zaplanować pozostałe działania w czasie iteracji.
Ciąg dalszy
W kolejnej, ostatniej już części, podpowiadam jak korzystać ze spike’a developerskiego w Scrumie jako narzędzia ułatwiającego organizację pracy Developerów w Sprincie.