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ę błędogennymi wycenami roboczogodzin lub man-daysów.

Choć faktycznie 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 przeliczenie punktów na czas – za pomocą velocity. Inaczej mówiąc, jeśli analizuje się, ile pracy zostanie wykonane do określonej daty, jeśli tempo jej wykonywania będzie takie, jak velocity właśnie, to niejawnie przelicza się te wspaniałe bezwymiarowe punkty na dni robocze, czy się to komuś podoba, czy nie.

#noestimates

Istnieje podejście #noestimates (zapożyczone od twitterowego hashtaga), które jest równie skutecznym generatorem nieporozumień, co wspomniane powyżej story pointy. Czegóż to ludzie nie wymyślają o #noestimates! Ponoć wymaga ono 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 praktyk, 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ę tylko swoją 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 estymaty. 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ń ani nie da się, jak w przypadku story pointów, wyliczyć velocity? Można posłużyć się przepustowością (ang. throuphput), 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, 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, ale to będzie zwykle dość kosztowne i nie ma co ukrywać – wielu odbiorców dostarczonej w ten sposób informacji zwyczajnie nie będzie w stanie wyciągnąć z niej wniosków.

Po trzecie wreszcie, każda prawdziwa prognoza powinna zawierać nie tylko przewidywania, ale też ocenę prawdopodobieństwa, z jaką została sporządzona. I w tym obszarze kryje się największa słabość prognoz opracowywanych z użyciem 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 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.).

Taka 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 w ostatnim okresie).
2. Charakter pracy, jaka jest wykonywana, będzie mniej więcej taki sam, jak do tej pory.
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 (bo wystarczy wiedzieć, ile każdego dnia rzeczy udało się skończyć), sama symulacja jest naprawdę 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 powoli 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 liczba jego wystąpień wśród wszystkich symulacji).

Zwracam uwagę, że kompletnie niepotrzebne do tego typu prognozowania są jakiekolwiek 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, żeby dało się kalkulować dzienną przepustowość w rozważanym w ramach symulacji okresie.

Zaproszenie do SPA

Podejście do prognozowania opartego o probabilistykę budzi u wielu osób wątpliwości. Przykładowe pytania, jakie się nasuwają:

• Jak to działa, gdy czas realizacji poszczególnych rzeczy znacząco się różni?
• Jak uwzględnić w prognozie dni wolne i urlopy?
• Czy da się tak prognozować, jeśli realizowane rzeczy wymagają zupełnie różnych działań, narzędzi i kompetencji?

Najlepszym sposobem na rozwianie wątpliwości i dostarczenie odpowiedzi jest pokazanie w praktyce, jak tego typu symulacje są realizowane. Warto przy okazji wspomnieć, że wymaga to nieco odmiennego postępowania w zależności od tego, co jest celem symulacji. A może nim być:

1. Prognozowanie liczby rzeczy, jaką uda się zrealizować w określonym czasie (to się przydaje przy planowaniu zakresów wydań produktu lub choćby Planowaniach Sprintu w Scrumie).
2. Prognozowanie daty ukończenia określonej liczby rzeczy (to dla odmiany przydatne jest przy planowaniu dat wydań produktu lub np. do zarządzania dostępnością ludzi, którzy mają wykonywać pracę).

Wszystkich zainteresowanych tym tematem i ogólniej sposobami estymowania i sporządzania prognoz w metodach zwinnych, zapraszam jesienią do SPA, czyli na warsztat Szacowanie i prognozowania w Agile.