Blog

Kiedy gotowa będzie funkcjonalność produktu, której pilnie potrzebują użytkownicy? Kiedy odbędzie się kolejne wydanie tego produktu? Co się w nim znajdzie? Ile wymagań można podjąć bezpiecznie do realizacji w najbliższej iteracji?

To typowe pytania, z jakimi zmagają się kierownicy projektów, managerowie produktów (np. Product Ownerzy w Scrumie), Developerzy i całe Zespoły. Wydaje się, że jedynym sposobem na uzyskanie odpowiedzi jest wyszacowanie czasochłonności prac i sporządzenie prognozy na ich podstawie. No, chyba że stosowane są metody zwinne, to wtedy jakiś fundamentalista Agile na pewno zaordynuje szacowanie relatywne z użyciem story pointów, wyliczy velocity i będzie wykorzystywał go do klecenia prognoz.

Oczywiście oba te podejścia pozwalają z mniejszą lub większą skutecznością zgadywać, co i kiedy uda się zrobić. Wbrew naiwnej wierze wielu popularyzatorów story pointów, ich użycie do sporządzania prognoz nie będzie ani trochę lepsze, niż posłużenie się wycenami w formie godzin roboczych lub man-daysów.

O ile bowiem punkty są bezwymiarowymi jednostkami porównania relatywnej wielkości szacowanych elementów, to przecież prognozy nieuchronnie sprowadzają się do przewidywania terminów, a więc konieczne będzie przełożenie punktów na czas – za pomocą velocity. Inaczej mówiąc, jeśli szacuje się, ile pracy zostanie wykonane do określonej daty w tempie odpowiadającym wartości velocity, to niejawnie przelicza się te wspaniałe bezwymiarowe punkty na jednostki czasu, czy się to komuś podoba, czy nie.

#NoEstimates

Istnieje podejście #NoEstimates, które jest równie skutecznym generatorem nieporozumień, co wspomniane powyżej story pointy. Czegóż to ludzie nie wymyślają o #NoEstimates! Ponoć technika ta wymaga dzielenia roboty na kawałki tej samej wielkości (a tak naprawdę nie wymaga). Albo trzeba tę robotę tak dzielić, żeby żaden kawałek nie był większy, niż jakiś tam przyjęty limit (kolejna bzdura, bo to tylko jedna z możliwych strategii, a nie wymóg).

A już największą bzdurą jest przekonanie, że #NoEstimates jest tożsame z odejściem od szacowania, co jakoś wielu osobom nie kłóci się w ogóle z dwoma mitami wspomnianymi wcześniej. Jak niby ktokolwiek miałby się upewnić, że robota została poszatkowana na równej wielkości kawałki albo że są one dostatecznie małe, nie dokonując oszacowania ich wielkości?

W rzeczywistości ci, co buńczucznie krzyczą, że radzą sobie świetnie bez szacowania, bo używają #NoEstimates, kompromitują się niewiedzą i brakiem logiki, ale to już ich problem. W praktyce to jest metoda szacowania relatywnego, którą od wielu innych różni to, że nie przypisywane są wycenianym elementom żadne symboliczne, literowe lub cyfrowe wyceny. I stąd zresztą wywodzi się nazwa #NoEstimates – brak oszacowań (a nie #NoEstimation, czyli brak szacowania).

W jaki sposób prognozować daty realizacji czegokolwiek, jeśli brak oszacowań w ogóle albo nie mają one formy numerycznej, więc nie da się wyliczyć velocity? Można posłużyć się przepustowością (ang. throughput), która jest jedną z miar przepływu i doskonale nadaje się jako zamiennik dla velocity w tym przypadku. Jak się ją wylicza? Bardzo prosto: to liczba rzeczy, którą udało się zrealizować w jednostce czasu.

I w ten sposób, jeśli np. zastanawiamy się, ile roboty uda się wykonać w ciągu najbliższego kwartału, to można powiedzieć, że będzie tego mniej więcej tyle samo, co w kwartale minionym. Oczywiście już słyszę ten wrzask, jak nieprecyzyjne i bezużyteczne takie prognozowanie jest. Jasne, zgadzam się. Podobnie bezużyteczne, jak to oparte o velocity i story pointy, bo przecież polega w istocie na tym samym i różni się jedynie mechaniką. To właśnie dlatego przepustowość, użyta w ten sposób (marny, bo da się lepiej, o czym za moment) jest doskonałym zamiennikiem dla velocity.

Kiepskie prognozy

Przewidywanie dat realizacji na podstawie tempa pracy (wyrażonego czy to za pomocą velocity, czy poprzez przepustowość) ma kilka wad.

Po pierwsze, bardzo często używane są wtedy wartości średnie tego tempa pracy, co jest wynikiem działania tzw. chłopskiego rozumu, który podpowiada, że średnie wartości są najbardziej prawdopodobne. Bzdura, bo nie są, a przynajmniej nie w każdym przypadku.

Po drugie, prognozy tego typu opisują zazwyczaj tylko jeden wariant przebiegu przyszłych prac. Bez rozważenia różnych scenariuszy ciężko powiedzieć, czy jest on pesymistyczny (zachowawczy), czy optymistyczny (ambitny, ale być może mało realny). Oczywiście można sporządzić wiele prognoz zamiast jednej, lecz to będzie zwykle dość kosztowne i nie ma co ukrywać – wielu odbiorców dostarczonej w ten sposób informacji zwyczajnie nie zdoła wyciągnąć z niej sensownych wniosków.

Po trzecie wreszcie, każda prawdziwa prognoza powinna zawierać nie tylko przewidywania, ale też ocenę prawdopodobieństwa ich trafności. I w tym obszarze kryje się największa słabość prognoz opracowywanych z użyciem wartości średnich czy to velocity, czy przepustowości, czy nawet oszacowań czasochłonności. Można oszacować błąd takich prognoz, ale niewiele to będzie miało wspólnego z faktycznym rachunkiem prawdopodobieństwa albo wymagało będzie jednej z dwóch rzeczy: stworzenia modelu matematycznego (nierealne, bo jest za dużo niewiadomych) lub wykonania mnóstwa różnych prognoz (nieopłacalne, bo czasochłonne).

Prognozowanie bez użycia oszacowań

Istnieje sposób prognozowania, którego da się użyć niezależnie od tego, czy cokolwiek jest szacowane, czy też nie. I wcale nie chodzi tu o jakieś mniej lub bardziej pokrętne użycie podejścia #NoEstimates, tylko o wykorzystanie wspomnianej już przepustowości, ale w zupełnie inny sposób, czyli nie jako prostej alternatywy dla velocity.

Zamiast zastanawiać się, ile pracy zwykle udaje się ukończyć w czasie tygodnia, miesiąca, Sprintu w Scrumie czy jakimkolwiek innym okresie i na tej podstawie przewidywać, co zostanie zrobione w porównywalnych okresach w przyszłości, można posłużyć się przepustowością dzienną do sporządzenia symulacji Monte Carlo. Ta przepustowość dzienna to po prostu liczba rzeczy ukończonych każdego dnia i to z uwzględnieniem dni wolnych od pracy (świąt, weekendów itd.).

Wspomniana symulacja Monte Carlo opiera się o trzy założenia:

1. Proces w przyszłości będzie przebiegał mniej więcej tak samo, jak przebiegał do tej pory (a przynajmniej jak funkcjonował w tym okresie, z którego zaczerpniemy dane do sporządzenia symulacji).
2. Charakter pracy, jaka jest wykonywana, nie ulegnie istotnej zmianie.
3. Osoby zaangażowane w wykonanie pracy będą dbać o to, by posuwała się ona do przodu, a nie będą zaczynać realizacji kolejnych rzeczy, nie kończąc tego, co rozbabrali wcześniej.

Jeśli te warunki są spełnione, można zasymulować jaką przepustowość dzienną uda się uzyskać w kolejnych dniach w przyszłości, wykorzystując historyczne dane. A że są to dane bardzo proste do zebrania (bo wystarczy wiedzieć, ile każdego dnia rzeczy udało się skończyć) i przetwarzania , sama symulacja jest trywialna. Można więc wykonać takich symulacji w parę minut nie kilka czy kilkanaście, ale np. kilkadziesiąt albo kilkaset tysięcy. Lub choćby milion.

Powstanie wtedy ogromna liczba różnych scenariuszy opisujących możliwy przebieg prac w przyszłości. Ponieważ generowane są one tak, by odtworzyć rozkład przepustowości dziennej, jaki zaistniał w przeszłości, niektóre scenariusze będą zdarzać się częściej, inne rzadziej. To pozwoli ocenić prawdopodobieństwo wystąpienia każdego z nich w banalny sposób: jeśli symulacji było milion, a jakiś scenariusz wystąpił 25 tysięcy razy, to jego prawdopodobieństwo jest równe 2.5% (czyli jest to udział liczby jego wystąpień wśród wszystkich wykonanych symulacji).

Zwracam uwagę, że zupełnie niepotrzebne do tego typu prognozowania są oszacowania zrealizowanych rzeczy lub tego, co na realizację oczekuje. Jedyną informacją, jaką trzeba dysponować, są daty ukończenia tego, co zostało już ukończone, czyli wiedza o dziennej przepustowości w przeszłości.