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 dużo 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ści 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 zarówno 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, albo nawet kilkanaście Sprintów.

W trakcie Planowania Sprintu Zespół używa tej wiedzy jako podpowiedzi, jak wiele elementów Backlogu Produktu powinno potencjalnie 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 wykonania 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 – dokonuje też 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ę zwykle 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 powie większość osób – 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 elementów Backlogu Produktu. Przypominam, że throughput to 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 punktów 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 na iterację, podczas gdy mediana to 10 na iterację. 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 być zmienny w czasie, np. rozrastając się (wartości minimalne są coraz niższe, maksymalne rosną). Średnia niekoniecznie będzie się przesuwać, mediana być może również nie ulegnie zmianie. 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ń obarczonych zawsze jakimś błędem, którego wartości nie da się realnie ustalić. Mało tego: bierze się następnie uśrednione wartości tak liczonego velocity i nakłada się je na wyceny elementów znajdujących się w Backlogu Produktu – również 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 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 czas, 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ą. Żadna z nich nie jest lepsza lub gorsza jako podstawa do ekstrapolacji tempa prac w sposób opisany wcześniej, a prognozy sporządzane z użyciem którejkolwiek z nich mają dokładnie takie samo – ś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ę, 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 tego 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 wciąż nie da się wyliczyć prawdopodobieństwa trafności żadnej z nich, ale obie razem pozwalają już jakoś ocenić skalę niepewności. Im większy jest rozziew między obiema prognozami, tym większe prawdopodobieństwo, że przyszłość okaże się zaskakująca. 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 zrealizowanych w przeszłości elementach Backlogu Produktu (a dokładniej o datach zakończenia prac nad nimi), 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ą dla niego 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% nastąpi to w ciągu trzech 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żdy, 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ć.