Blog

Bardzo często posługujemy się przy sporządzaniu prognoz lub analiz wartościami średnimi różnych parametrów, za pomocą których próbujemy opisać otaczającą nas rzeczywistość lub to, co się wydarzyło. Wiele osób jest przy tym przekonanych, że wartości średnie jakiegoś zmiennego parametru występują najczęściej, albo inaczej mówiąc, są najbardziej prawdopodobne. Cóż, niekoniecznie, a właściwie zupełnie nie.

Potrzeba prognozowania

Rozważmy przykład Zespołu Scrum, który pracuje w dwutygodniowych iteracjach (Sprintach) nad rozwojem jakiegoś produktu. W trakcie całego roku iteracji takich odbędzie się ponad dwadzieścia. Niektóre będą nieco krótsze, bo wypadną święta lub dni wolne od pracy z jakiegoś innego powodu. W innych skład Zespołu będzie mniejszy niż zwykle, bo ktoś zachoruje, ktoś inny będzie na urlopie itd.

Różnić się też będą poszczególne Sprinty tym, czym Zespół zajmuje się w każdym z nich. Czasami będzie to wiele niewielkich zmian w produkcie, innym razem zaledwie kilka modyfikacji, ale za to rozbudowanych, skomplikowanych i czasochłonnych.

Każde Planowanie Sprintu wymaga stworzenia przez Zespół prognozy tego, co zostanie zrealizowane przed końcem iteracji (oczywiście nie ma nigdy gwarancji, że ta prognoza się potwierdzi).

Product Owner również musi prognozować daty realizacji elementów Backlogu Produktu, bo interesariusze dopytują się, kiedy dostępne dla nich będą konkretne nowe funkcjonalności i cechy produktu.

Czego można użyć do sporządzania wspomnianych prognoz? Najczęściej Zespoły sięgają po informację na temat prędkości (ang. velocity), jaką Zespół osiągał w zakończonych Sprintach, ewentualnie po dane o przepustowości (ang. throughput).

Prędkość i przepustowość

Velocity w jakimś Sprincie obliczana jest jako suma oszacowań, wyrażonych np. w story pointach tych elementów Backlogu Produktu, które zostały zrealizowane w tej iteracji. Oczywiście uwzględnia się wyłącznie te elementy, których implementacja stała się częścią Przyrostu – nowej wersji produktu, która spełnia warunki zawarte w obowiązującej Zespół Definicji Ukończenia. Inaczej mówiąc, velocity obejmuje tylko to, nad czym prace faktycznie zostały ukończone i co może być realnie użyte.

Throughput w Sprincie to po prostu liczba zrealizowanych w tej iteracji elementów Backlogu Produktu. Jego zaletą w porównaniu do velocity jest prostota wyliczenia oraz brak konieczności posługiwania się oszacowaniami elementów Backlogu Produktu w formie numerycznej (właściwie w ogóle nie musi być żadnych oszacowań i przepustowość dalej da się wyliczyć). Niektórzy wskazują natomiast jako wadę przepustowość brak uwzględnienia w niej wielkości poszczególnych elementów. Faktycznie, throughput nie bierze tej wielkości pod uwagę, ale niekoniecznie ma to znaczenie – jeszcze do tego wrócę.

Ekstrapolacja, czyli zgadywanie

Prognozowanie z wykorzystaniem tak przepustowości, jak i prędkości polega na ekstrapolacji tempa, z jakim Zespół przesunie się w dół listy elementów Backlogu Produktu w określonym czasie.

Przyjmijmy, że przykładowy Zespół Scrum ma informację o velocity albo o przepustowości za ostatnich kilka, czasami kilkanaście Sprintów.

W trakcie Planowania Sprintu Zespół używa tej wiedzy jako podpowiedzi, ile elementów Backlogu Produktu mniej więcej powinno dać się zaimplementować tym razem.

Oczywiście nierozsądnym byłoby kierowanie się wyłącznie tym kryterium przy podejmowaniu decyzji i Developerzy biorą też pod uwagę (albo przynajmniej powinni brać) czasochłonność i realne możliwości realizacji konkretnego planu działania, który pozwoli im osiągnąć ustalony Cel Sprintu.

Product Owner posługuje się wiedzą o prędkości lub przepustowości bardzo podobnie, ale nie stara się ocenić jedynie tego, jak wiele elementów Backlogu Produktu może zostać zrealizowanych w bieżącym Sprincie, ale też dokonuje ekstrapolacji potencjalnych granic kilku kolejnych iteracji.

Dzięki temu może z pewnym wyprzedzeniem zauważyć, że niektóre elementy znajdują się zbyt nisko na liście i muszą zostać przesunięte wyżej, by zdążyć z ich realizacją na określoną datę. Może też poinformować interesariuszy o potencjalnych datach realizacji tego czy innego elementu.

Przy czym te prognozy wymagają odświeżenia za każdym razem, gdy zmieni się kolejność lub zawartość Backlogu Produktu albo oszacowania jego elementów (w przypadku korzystania z informacji o velocity).

Wartości średnie

Zarówno Product Owner, jak i Zespół posługują się wartościami miar (prędkości lub przepustowości) z więcej niż jednego zakończonego Sprintu. Niektóre z tych iteracji były naprawdę nieudane, inne przebiegały rewelacyjne, ale nikt nie posługuje się skrajnymi wartościami miar zebranych w przeszłości. Średnia wartość wydaje się bezpieczna, rozsądna i – tak większość osób powie – najbardziej prawdopodobna.

Jednocześnie mało kto zadaje sobie trud, by sprawdzić, czy wśród historycznych danych o przepustowości lub velocity choćby jeden raz wyliczona średnia wartość faktycznie wystąpiła. A przecież jeśli jest najbardziej prawdopodobna, powinna się często pojawić, nieprawdaż? Jeśli zaś się nie pojawia ani razu, to chyba jednak nie jest aż tak prawdopodobna, jak podpowiada tzw. chłopski rozum.

W rzeczywistości wyliczona wartość jakiegokolwiek średniego parametru nie musi być w ogóle możliwa do osiągnięcia. Wyobraźmy sobie prostą sytuację, w której średnia przepustowość z ostatnich dziesięciu Sprintów to 11.5 elementu Backlogu Produktu. Przypominam, że throughput liczony jest jako liczba ukończonych elementów w każdej iteracji, czyli musi zawsze być liczbą całkowitą, bo nie da się ukończyć połowy elementu (będzie on wtedy zrealizowany w połowie, czyli w praktyce niezrealizowany i do przepustowości doliczać go nie można). Nie jest więc w ogóle możliwe uzyskanie przepustowości 11.5.

To samo dotyczy velocity, jeśli np. wyrażamy ją w liczbie story pointów. Te punkty są również niepodzielne i prędkość w Sprincie musi zawsze być liczbą całkowitą. Dlatego, choć średnia velocity wynosząca np. 33.7 punktu jest możliwa, to prawdopodobieństwo, że kiedykolwiek prędkość w jakiejś iteracji osiągnie 33.7, jest dokładnie zerowe.

Przedział zmienności

Jeśli ktoś już ma świadomość, że wartość średnia wcale nie musi być najbardziej prawdopodobna, sięga zwykle po informację o tym, w jakim zakresie przepustowość lub prędkość Zespołu się zmieniała. I tu też pojawia się często przekonanie, że wartości skrajne zanotowane dotychczas są najmniej prawdopodobne, a najpewniejsze są te ze środka przedziału. Cóż, niezupełnie tak jest.

Po pierwsze, w przyszłości wystąpić mogą przecież wartości jeszcze niższe lub wyższe, niż te uzyskane w zrealizowanych już Sprintach. A to automatycznie przesuwa mityczny „najbardziej prawdopodobny środek przedziału” w jedną lub drugą stronę. Jasne, im więcej danych historycznych Zespół Scrum zebrał, tym mniejsze jest ryzyko takiego przesunięcia się wartości velocity lub throughputu w kolejnym Sprincie – ale nigdy nie będzie ono zerowe. No, może z wyjątkiem minimalnej wartości zero, bo faktycznie, nie da się w iteracji zrobić mniej niż nic.

Po drugie, średnią wartość można wyliczać na wiele sposobów. Większość osób uzna, że należy po prostu wyliczyć średnią arytmetyczną, ale właściwie czemu nie medianę? Różnica może być znacząca. Wyobraźmy sobie, że Zespół dysponuje danymi o dziesięciu Sprintach, z których w sześciu udało mu się zrealizować po dziesięć elementów Backlogu Produktu, a w czterech tylko po jednym elemencie. Średnia arytmetyczna tej przepustowości wynosi 6.4, podczas gdy mediana to 10. Która wartość jest więc bardziej prawdopodobna?

Po trzecie, duże znaczenie ma szerokość przedziału, w jakim zmienia się mierzona wartość miar. Jeśli np. przepustowość wyliczona w szeregu Sprintów nie spadła nigdy poniżej 10 i nie była większa niż 15 elementów, to zdecydowanie łatwiej jest cokolwiek prognozować na tej podstawie, niż gdyby zaobserwowane minimum wynosiło zero, a maksimum sięgało 100.

Po czwarte, ten przedział zmienności może się zmieniać w czasie, np. rozrastając (wartości minimalne są coraz niższe, maksymalne rosną). Średnia nie będzie się przesuwać, mediana być może również nie. Spadać natomiast będzie nieustannie prawdopodobieństwo uzyskania prędkości (lub przepustowości) mieszczącej się pomiędzy dotychczasowymi skrajnymi wartościami.

Wielkość ma znaczenie?

Pora powrócić do obaw o to, że posługiwanie się przepustowością, zamiast velocity może prowadzić do przekłamania sporządzanych na jej podstawie prognoz, bo ignorowana jest wówczas wielkość elementów Backlogu Produktu.

Prędkość wylicza się na podstawie oszacowań, które są próbą oceny wielkości elementu i obarcza je zawsze błąd, którego wartości nie da się realnie ustalić. Mało tego: bierze się następne uśrednione wartości tak liczonego velocity i nakłada uzyskaną w ten sposób miarę na oszacowania elementów znajdujących się w Backlogu Produktu. Oszacowania obarczone nieznanym błędem.

Gdzie tu zatem można doszukać się nadziei na jakąkolwiek „większą precyzję” prognoz niż w przypadku użycia przepustowości?

Zwracam przy tym uwagę, że poszczególne elementy Backlogu Produktu, które realnie są podejmowane do realizacji w Sprintach, nie różnią się zasadniczo wielkością, bo muszą wszystkie być na tyle małe, by dało się prace nad nimi ukończyć przed końcem krótkiej iteracji. Czy nie lepiej użyć na development czasu, jaki Zespół traci na kłócenie się o to, ile np. story pointów ma jakiś element tylko po to, żeby potem „precyzyjnie” policzyć velocity?

Przecież w oczywisty sposób tak prędkość, jak i przepustowość Zespołu, jest bardzo zgrubną miarą. Do tego żadna z nich, jeśli używana jest do ekstrapolacji tempa prac w sposób opisany wcześniej, nie jest w żaden sposób lepsza, a prognozy sporządzane w ten sposób mają ściśle nieokreślone prawdopodobieństwo.

Prognozy zawierające ocenę prawdopodobieństwa

Czy sposób prognozowania, o jakim do tej pory pisałem, pozwala jakkolwiek oszacować poziom niepewności, z jaką się wiążą? I tak, i nie.

Jeśliby Zespół lub Product Owner użył wyłącznie wartości średniej velocity albo przepustowości, pozostając przekonanym, że w ten sposób tworzy najbardziej prawdopodobną prognozę, to można jedynie ciężko westchnąć. W zasadzie to prognoza klasy „wydaje mi się, że tak będzie”. Gorszy od niej może być tylko brak sporządzania prognoz jakichkolwiek. O żadnej ocenie prawdopodobieństwa w tym przypadku mowy być nie może.

Jeśli zamiast wartości średniej sporządzone zostały przynajmniej dwie prognozy, np. z użyciem uśrednionej wartości minimalnej (średnia z trzech najsłabszych Sprintów) i maksymalnej (średnia z trzech najlepszych iteracji), wtedy co prawda nie da się wyliczyć prawdopodobieństwa trafności żadnej z nich, ale obie razem pozwalają już jakoś ocenić ryzyko. Im większy jest rozziew między obiema prognozami, tym większe prawdopodobieństwo, że przyszłość okaże się zaskakująca. Procentowej wartości prawdopodobieństwa rzecz jasna nadal wyliczyć się nie da, ale lepsze to niż nic.

Jedynym sposobem, by uzyskać prognozę prawdziwie probabilistyczną, jest użycie historycznych danych do przeprowadzenia symulacji, która pozwoli nie tyle wyliczyć, ile zmierzyć prawdopodobieństwo związane z różnymi scenariuszami.

Symulacja Monte Carlo

Wróćmy do przykładowego Zespołu Scrum. Jeśli dysponuje on danymi o zakończonych w przeszłości elementach Backlogu Produktu (a dokładniej o datach ich zakończenia), może w prosty sposób przeprowadzić symulację Monte Carlo i uzyskać odpowiedź na pytanie, jaką przepustowość i z jakim prawdopodobieństwem może uzyskać w przyszłości. I nie będzie to jedna prognoza czy dwie, ale cały ich szereg, przez co ryzyko podjęcia błędnych decyzji jest możliwie najmniejsze.

Jak to działa? Symulowane są kolejne scenariusze przebiegu prac w taki sposób, by odtworzyć sytuacje, które miały miejsce w przeszłości. Przyjmując, że proces nie zmienił się fundamentalne i historyczne dane są reprezentatywne, jeśli przeprowadzonych symulacji będzie duża liczba (dziesiątki, albo jeszcze lepiej setki tysięcy scenariuszy), rozkład prawdopodobieństwa wystąpienia różnych zjawisk będzie w nich taki, jak w zakończonych Sprintach. W szczególności uzyskać w ten sposób można rozkład prawdopodobieństwa dla różnych wartości przepustowości, jakie Zespól Scrum może uzyskać.

I w ten sposób, po wykonaniu np. miliona symulacji (co zwykle zabiera kilka sekund, może minut – zależnie od efektywności użytego narzędzia), Zespół może powiedzieć, że prawdopodobieństwo zrealizowania w planowanym właśnie Sprincie trzydziestu elementów Backlogu Produktu wynosi ledwo 15%, natomiast dla dziesięciu jest o wiele wyższe i sięga 80%.

A Product Owner, którego interesariusze pytają, kiedy zakończy się praca nad pierwszymi dwudziestu elementami Backlogu Produktu, może powiedzieć, że na 90% w ciągu dwóch miesięcy, ale istnieje 50% prawdopodobieństwa, że potrwa to tylko cztery Sprinty.

Chcesz wiedzieć więcej?

Istnieje wiele sposobów przeprowadzenia symulacji Monte Carlo, jakimi Zespół mógłby posłużyć się w opisanym przypadku, pojawia się też pewnie od razu pytanie, czy zamiast przepustowości można symulować uzyskiwane velocity.

Tak naprawdę wymaga to dyskusji nie tylko o sposobie prognozowania, ale też cofnięcia się o jeden krok do rozważań na temat szacowania i sposobów, w jaki można go dokonywać. A jest to grunt niezwykle grząski, bo przesiąka go brudna woda wszelakich mitów, nieporozumień, „dobrych rad” samozwańczych „ekspertów” itd. Bardzo ciężko wyrwać się z takiego np. przekonania o „zbyt małej precyzji” przepustowości w stosunku do velocity, jeśli wierzy się w istnienie „precyzyjnych oszacowań”.

Dlatego każdego, kto chce używać symulacji Monte Carlo i w ogóle podejść bardziej pragmatycznie do planowania prac, jakie wykonuje oraz do sporządzania prognoz (nie tylko w Scrumie, bo to był jedynie przykład na potrzeby tego artykułu), powinien zadać sobie trud poznania najbardziej typowych praktyk i narzędzi, żeby potem świadomie wybrać niektóre z nich. Ciężko bowiem dywagować o wartości velocity wyliczanego np. w story pointach, jeśli nie do końca rozumie się, czym wspomniane punkty w ogóle powinny być.

Przy tej okazji zapraszam na warsztat Szacowanie i prognozowanie w Agile (SPA), które skupione są na tej tematyce. Kto był już u mnie na szkoleniu, ten z pewnością wie, że postaram się odpowiedzieć na wszystkie pytania. I oczywiście wyjaśnię, jak robi się symulacje Monte Carlo, bo choć są gotowe narzędzia do ich przeprowadzania, naprawdę warto rozumieć, jak działają, żeby świadomie wykorzystać zaprezentowane wyniki (i w ogóle je dobrze zrozumieć).