Sobota późny wieczór wieczór albo i niedziela rano - pijesz piwo ze znajomi w barze. Niektórzy mają "standardowe" kufle, niektórzy wolą kufelki podobne do dużych kieliszków. Zawodowcy zaś walą z kufli sięgających od stołu aż po brwi. W pewnym momencie nadchodzi kolejka na twój koszt. Zgarniasz więc naręcze szkła ze stołu, podchodzisz do baru. I o co poprosisz barmana o kufle piwa, czy o litry piwa?
Prawie na pewno poprosisz o kufle. Czyli tym samym zobowiążesz się wobec barmana do zapłacenia bliżej nieokreślonej kwoty za piwo. Cena wszak jest liczona (przyjmijmy) "za litr", a ty prosisz o napełnienie różnego rodzaju kufli. Mimo to, wstępne zakontraktowanie kufli, daje ci lepsze wyobrażenie o tym, ile kto potrzebuje jeszcze wypić na dobicie niż litry. Dlatego właśnie poprosisz o kufle nawet, jeśli końcowa kwota do zapłaty będzie pewną niespodzianką.
No i te kufle to właśnie story pointy.
Można by na tym zakończyć, gdyby nie parę szczegółów, które domagają się gruntowniejszego wyjaśnienia.
Zrób skalę
Szacowanie za pomocą story pointów wymaga przygotowania skali, czyli przykładów naszych zadań na 1, 2, 3,...etc. story pointów.
W jaki sposób przygotować tę skalę dla zespołu, opisałem szczegółowo w książce Getting Things Programmed w rozdziale "Szacowanie względne".
Zacznijmy od tego dlaczego skala jest absolutnie konieczna.
Ile to story pointów?
Gdy nie ma skali, to przy próbie estymacji - pokerem, czy nie - każdy z zespołu zadaje sobie pytanie Ile to zadanie może mieć story pointów?. Tak postawione pytanie sprawia, że każdy, ale to każdy developer, myśląc o zadaniu pomyśli tak:
Sory, ale nie ma ucieczki przed tym schematem myślowym. Zawsze gdy zapytasz ile? - story pointów, mendejów, ogórków, czy kurczaków - deweloper skorzysta z tego właśnie magicznego wzoru
Pojawienie się skali sprawia, że zdajemy sobie inne pytanie Do którego z tych zadań podobne jest nowe zadanie?. To jest kosmiczna różnica, bo koncentrujesz się na porównywaniu zadań do siebie - czym się różnią? w czym są podobne? - a nie na wyliczaniu takiej, czy innej liczby punktów.
Estymacja bez presji
Gdy zespół startuje, często jedną pierwszych rzeczy jest włączenie testerów w tryb pracy zespołu, w tym w refinement, estymacje i planownie. Czasem do zespołu dołącza nowa osoba, która jeszcze nie zna wszystkich zawiłości tworzonego oprogramowania.
Moja obserwacja jest taka, że owi testerzy mocno się spinają, gdy mają podać swoją estymatę. Ogrywa się to Planning Pokerem, gdzie pokazujemy punkty na trzy-cze-ry!.
Tak czy siak niemal zawsze w takich przypadkach wychodzą na wierzch następujące kwestie:
- nie znam systemu jak mam szacować?
- a może zrobimy story pointy deweloperskie i testerskie?
- a może każdy będzie miał własne story pointy?
Używanie skali oraz pytania Do którego z zadań najbardziej podobne jest nowe zadanie? od razu eliminuje te trudności. Po prostu tłumaczymy nowym osobom, w czym zadania są podobne, a w czym się różnią. Nowi mają niepowtarzaną szansę zadać jakieś pytanie-killer, które postawi taska w nowym świetle. Znika też duch kretyńskiej rywalizacji w "kto da mniej punktów".
Nie nie musi być Fibbonacci
ani potęgi dwójki. Po szersze wyjaśnienie odsyłam do Getting Things Programmed.
Boshe! Przeliczyli na MD!
Uczą, by nie przeliczać story pointów na mendeje, bo...stanie się COŚ STRASZNEGO.
Prowadzi to przekomicznych sytuacji. Poniżej kilka cytatów, z którymi się spotkałem:
- teraz to nie wiemy ile zespołom zajmie zrobienie ficzera, bo wszystko jest w story pointach
- mówiliśmy biznesowi, że to zajmie 200 SP, ale oni chyba nie rozumieją
- nie wolno pytać zespołów kiedy zrobią ficzera, bo story point to złożoność, a nie czas
Naprawdę? Naprawdę?!
Wyobraź sobie, że do twojego nowozakupionego mieszkania wchodzi ekipa remontowa. Po wstępnych oględzinach fachowcy stwierdzają: zrobimy, nie ma problemu; dwa tygodnie naszej pracy to 20k; skończymy jak będzie gotowe. I co wyłożysz kasę ekipie? Szczerze wierzę, że instynkt samozachowawczy ci nie pozwoli.
Proszę Państwa, powiedzmy sobie szczerze i otwarcie: pieprzyć takiego adżajla, w którym nie wiadomo na kiedy ani za ile!
Wypada wyjaśnić, o co właściwie chodzi z tym nie przeliczaniem.
Co to jest Mendej?
W organizacji komercyjnej mendej (man-day, MD) to jednostka kosztu, nie czasu. Mówiąc, że ten projekt zajmie 100 MD w rzeczywistości mamy na myśli, że liczba osób x liczba dni = 100 (dla uproszczenia przyjąłem, że wszyscy zarabiają po równo <rotfl>).
Gdy inżynierowie szacują pracę, to będą próbować odgadnąć ile kalendarzowych dni zajmie im jej wykonanie. Coś wymyślą i podadzą liczbę zleceniodawcy. Zleceniodawca weźmie tę liczbę dni kalendarzowych, potraktuje ją jako koszt pracy i postara się o taki właśnie budżet.
W powyższym akapicie zadziało się coś, przed czym przestrzegano mnie w pierwszej klasie technikum: nie dodaje się do siebie wielkości w różnych jednostkach, bo to nie ma sensu.
Aby uniknąć tych nieporozumień, wygodnie jest inaczej mierzyć koszt prac a inaczej zakres tychże. Koszty mamy w mendejach, które często są synonimem pieniędzy, a zakres mamy w story pointach.
W zakazie nie przeliczania SP na MD chodzi właśnie o to, żeby za automatu nie traktować np 1SP = 1MD albo 1SP = 0.5MD, bo taka równość po prostu nie zachodzi. To niepoprawne wnioskowanie.
Skąd się bierze przewidywalność?
Przewidywalność bierze się ze stałej długości cyklu pracy np. sprintu. Wiadomo, że zespół monitoruje ile story pointów może zrobić w sprincie. Jeśli ta wartość jest w miarę stała, nazywamy ją prędkością.
Jeśli zatem jakiś nowy ficzer oszacujemy na 200SP, a nasza prędkość to 20SP. W takim razie powinniśmy dostarczyć całość za 200/20 = 10 sprintów, czyli np. 20 tygodni.
W/w przeliczenie Jira ogarnia za pomocą Epic Burdown Report.
Jeśli w zespole mamy 8 osób to 20 tygodni (5 dni roboczych na tydzień) daje nam 8*20*5 = 800MD. I to jest szacowany koszt prac.
Pomijamy tu przypadki szczególne takie jak np. nie wszyscy będą brali udział w pracach, co zmienia koszt oraz święta, urlopy i choroby.
Nie mów tego Biznesowi!
Nie mów Biznesowi o story pointach. To jest narzędzie dla zespołu. Nawet jeśli twój biznes zna tę idę, komunikuj się z nimi za pomocą kosztów, które wydedukujesz ze story pointów jak wyżej.
Zakres wzrósł
Ktoś mógłby powiedzieć: a co w przypadkach, gdy zakres wzrósł, czegoś nie przewidzieliśmy, coś się popsuło? Cóż, wtedy dochodzą punkty do backloga, co automatycznie zwiększa liczbę potrzebnych mendejów, czyli koszt pracy.
Nie oszukujmy się - zawsze tak było. Niezależnie od tego, czy posługiwaliśmy się story pointami czy mendejami, w nagłych przypadkach umiejętnie cięło się zakres albo dosypywało pieniędzy na dalsze prace. Story pointy niczego tu nie zmieniają.
Więcej szczegółów na temat cięcia zakresu i innych trików w Getting Things Programmed w rozdziale "Ile szacowania jest w szacowaniu".
SP nie są ciałem liczbowym
Mówią, że SP określają złożoność zadania albo ilość roboty albo trudność. Moim zdaniem SP jedynie wyraża relację zadania w odniesieniu do innych zdań.
Czymże jest ten story point. Powiedzmy, że w kolejnych sprintach szacujesz jakieś zadanie na 3 SP i okazuje się, że zajęło ono 2 dni. Innym razem też szacujesz jakieś zadanie na 3SP i zajęło on 2.5 dnia. Gdyby zrobić sobie taką rozpiskę dla każdej wartości story pointa, w efekcie wyjdzie poniższa tabela.
Można powiedzieć, że story point to jedynie symbol wektora, zawierającego rzeczywiste czasy pracy. Zabierając się do zadania np. 3SP, raz będziemy pracować dzień, raz dwa, innym razem półtora dnia. Z takiej interpretacji story pointów wynika kilka ciekawych wniosków.
SP nie można dodawać
Operator dodawania nie jest zdefiniowany dla story pointów. Mówienie, że skoro mamy do zrobienia zadanie na 2SP oraz 3SP, to razem mamy 5SP jest niepoprawne. No bo jakże dodać do siebie dwa wektory, które mogą mieć różną liczbę składowych?
Jednakże dla uproszczenia i żeby nie sprawiać przykrości twórcom Jiry, przyjmujemy uproszczenie i dodajemy do siebie wartości story pointów tak, jakby były liczbami naturalnymi.
Przyjmując uproszczenie na temat dodawania story pointów zakładamy, że:
zatem można story pointy "dodawać" jeśli:
czyli wymagamy, aby dana wielkość w story pointach zawsze zajmowała określoną ilość dni rzeczywistej pracy. Jest to oczywiście nie prawdą. Po to wymyślono story pointy, żeby sobie oszacować prace do wykonania, z pełną świadomością, że z rzeczywistym przepracowanym czasem różnie może być.
Właściwszym podejściem byłoby mówienie, że: "w sprincie możemy zrobić 3 zadania za 3SP jedno za 5SP i trzy za 1SP" niż: "nasza prędkość wynosi 17SP". Mówienie o gotowości do wykonania poszczególnych typów zadań daje lepsze wyobrażenie o zakresie sprintu niż w nieco naciągany sposób liczona "prędkość".
8SP != 8 * 1SP
Ze wspomnianej wyżej niemożności dodawania do siebie story pointów wynika również, że jedno zadanie za 8SP nie jest wymienne na osiem zadań po 1SP.
Intuicyjne tłumaczenie jest takie, że jedno duże i trudne zadanie nie jest równoważne kilkudziesięciu zadaniom na poziomie CRUDa. Głównie chodzi o dwie rzeczy:
- niepewność - im większe oszacowanie w SP, tym większa szansa, że objawi się coś, o czym nie mieliśmy pojęcia
- złożoność - tą bym rozumiał jako stopnie swobody, czyli liczba rzeczy, którą należy wziąć pod uwagę, aby jednoznaczenie zdefiniować dane zadanie
Wsteczne przeliczanie ma MD
Wiemy już, że adżajlowcy straszą swoje dzieci przeliczaniem story pointów na mendeje. Trzeba jednak pamiętać, że chodzi tylko o przeliczanie w jedną stronę.
Nie wolno zatem twierdzić, że skoro coś zostało oszacowane na 2SP, to z pewnością zajmie 2.5MD, bo to nie jest reguła.
Jednocześnie wolno przeliczyć sobie wstecznie szacowania oraz rzeczywiste osiągi i powiedzieć, że do tej pory 2SP zajmował 2.5MD, ale czy tak będzie w przyszłości, to nie wiadomo.
"Zwijanie" SP jest bez sensu
Parę lat temu, miałem okazję zostać Certified SAFe Program Consultant, ukończywszy uprzednio czterodniowe szkolenie.
Bazując na koncepcji znormalizowanego story pointa, każą tam zsumować story pointy z wielu zespołów, aby policzyć wartość dla feature. Te natomiast również sumujemy, aby policzyć wartość dla business epic.
Ostatecznie zdziwiony prezes otrzymuje feedback z dołu organizacji: Panie prezesie to oprogramowanie szacujemy na 75 000 000 SP?. Prezes grzecznie dziękuje, po czym przydziela akcjonariuszom po 5SP na akcję. Ci z kolei idą do spożywczaka i za swoje story pointy kupują chleb i pęto swojskiej...
Koncept normalizowania i zwijania w górę story pointów osobiście uważam, za wyjątkowo nietrafiony.
Dla danego zespołu możemy przyjąć uproszczenie, że dodajemy do siebie story pointy, bo poruszamy się w kontekście konkretnych ludzi, architektury i innych uwarunkowań. Takiego założenia nie sposób już poczynić dla dodawania do siebie story pointów pochodzących od różnych zespołów.
"Stabilny" nie "znormalizowany"
Celem normalizacji wg SAFe jest "zwinięcie" story pointów tak, aby posiadać miarę i przewidywalność w business epic, czyli inicjatyw na poziomie organizacji. Jeśli już, to lepszym pomysłem niż normalizowanie SP jest ich stabilizowanie.
Z poprzednich akapitów wiemy już, że sensowne i uprawnione jest wsteczne przyglądanie się relacji między story pointami, a rzeczywistym czasem pracy.
Stabilna wartość story pointa ta taka, w której wektorze większość rzeczywistych czasów pracy oscyluje w otoczeniu jakieś wartości. Precyzyjniej brzmiałoby to tak:
Czyli jeśli na przykład kilkaset razy razy oszacowaliśmy coś na 3SP, to analizując wstecznie rzeczywiste czasy pracy dla tych trzystorypointowych zadań, okaże się, że prawie wszystkie lądują w okolicy np. 2dni z założoną z góry dokładnością np. +/- 0.5 dnia. Wg powyższej definicji termin "prawie wszystkie" oznacza "wszystkie za wyjątkiem co najwyżej skończonej ilości". Ponieważ analizowanych szacowań jest zawsze skończona ilość, to "prawie wszystkie" należy tu rozumieć jako po prostu "większość". Dywagację na temat "jaka większość?" spokojnie można odłożyć na później.
Co daje stabilność?
Dopóki story pointy są stabilne wg powyższej definicji, można powiedzieć, że skala używana przez zespół dobrze prognozuje obłożenie w sprincie.
Nie informujemy więc zarządu o milionie story pointów potrzebnych na daną inicjatywę, lecz stale analizujemy stabilność skali, a zarządowi przekazujemy mendeje wynikające np. z przytoczonego wcześniej raportu Jiry Epic Burndown.
Kiedy się destabilizuje?
Dalej - trzymając się definicji stabilności - wartość story pointów destabilizuje się, gdy większość składowych wektora wykracza poza wartość wokół której wcześniej oscylowały. Nowy framework, nowi członkowie zespołu, zmiana założeń itd. to zdarzenia, które sprawiają, że story point stracą stabilność, czyli analizując wstecz nie ma wyraźnej odpowiedzi na pytanie "ile zazwyczaj nam zajmują zadania tego typu"?
Destabilizacja jest zatem metryką, która wskazuje ScrumMasterowi, że ma coś do zrobienia w procesie.
Inflacja story pointów
Jeśli destabilizacja story pointów ma charakter tendencyjny tak, że wyznacza nową wartość w okół której oscylują rzeczywiste czasy pracy, to mówimy o inflacji (ew. deflacji) story pointów. Ktoś ciśnie na większą liczbę story pointów w sprincie, więc nominalnie robimy więcej, ale tak naprawdę to tyle samo, albo i mniej.
A może rzeczywiste dni pracy?
Na sam koniec można jeszcze zapytać, po co zawracać sobie głowę story pointami, skoro i tak w ostateczności gdzieś na końcu mamy rzeczywiste dni pracy albo mendeje. Nie można od razu szacować w rzeczywistych dniach pracy?
No, nie bardzo.
Gdy się przypatrzyć uważniej, to gdy prosisz o oszacowanie w dniach, to otrzymujesz wartości:
- 8, 16, 24,...
- 5, 10, 15,...
- 2, 4, 6, 8,...
Inżynierowie najczęściej szacują wielokrotnością interwału, który muszą wypełnić w timesheet. W niektórych firmach w dniu roboczym trzeba zaraportować 6h (reszta to międzyczas), w niektórych 5h - co wynika z efektywnego dnia pracy, a w niektórych trzeba ściemniać i raportować, że nad projektem pracowało się bite 8h.
Ostatecznie szacując w tzw. rzeczywistych dniach i tak posługujesz się jakąś wartością jednostkową - 2h, 5h, 6h, 8h - i ją zwielokrotniasz. Jest to bardziej twoje wyobrażenie o ilości pracy, jaka cię czeka niż odpowiedź na pytanie "ile to rzeczywiście zajmie". Mimo, że nazywasz to dniami pracy.
Bezpieczniej zatem nie mieszać pojęć i story pointy nazywać story pointami, a dni pracy daniami pracy.
Podsumowując
Przedstawione tezy:
- odnośnie do estymacji posługujemy się trzema metrykami
- mendeje (MD) - koszt pracy
- story pointy (SP) - zakres pracy
- rzeczywiste dni pracy - o tych się dowiadujemy, gdy już praca zostanie wykonana
- jeśli chcesz używać story pointów, to tylko ze skalą
- story pointy są tylko dla zespołu, Biznesowi podawaj mendeje
- daną wartość story pointa można interpretować jako wektor, którego składowe to rzeczywiste czasy wykonania zadania oszacowanego na tę wartość story pointów
Przedstawione wnioski:
- dodawanie story pointów jest z definicji niepoprawne, ale w kontekście jednego zespołu można przymknąć na to oko
- użyteczniej jest twierdzić: "na sprint bierzemy 2 zadania po 5SP i siedem po 2SP" niż mówić o prędkości wyrażonej jedną liczbą
- story pointy można przeliczać na rzeczywiste dni pracy oraz mendeje tylko wstecz
- stabilność story pointa jest użyteczniejszą metryką niż normalizowanie story pointów
- na poziomie organizacji dbaj o stabilność story pointów w zespołach, a z Biznesem rozmawiaj o mendejach
Wersja angielska
Oh, those story points... - dzięki uprzejmości Pawła Łukasika mamy tłumaczenie posta.
