Duży nacisk w metodykach zwinnych kładzie się na prognozowanie, czyli „przewidywanie przyszłości”. Zespoły mają prognozować po to, żeby wiedzieć ile i co zostanie dowiezione na koniec każdej iteracji. Czym jest prognozowanie i jaki ma wpływ na podejmowane przez nas decyzje?
Zwinne prognozowanie
Z prognozowaniem w metodykach agile jest trochę tak, jak z prognozą pogody w telewizji. Ta druga co prawda przewiduje zjawiska atmosferyczne czy temperaturę powietrza, ale wszyscy dobrze wiemy, że nie można jej zaufać w stu procentach. Jakikolwiek postęp nie dokonałby się w modelowaniu pogody i tak zawsze będziemy mieć do czynienia z pierwiastkiem niepewności.
Nasz Scrum Team ma to do siebie, że analizuje wydarzenia, które miały miejsce w przeszłości. Na ich podstawie wyciąga wnioski i prognozuje ile dostarczą wymagań w przyszłości, w kolejnych iteracjach. To wszystko oczywiście pod warunkiem, że wymagania są nam dobrze znane, a kolejne Sprinty – przewidywalne.
Co do zasady, należy rozróżnić prognozowanie od zobowiązania. Prognozowanie to nic innego jak próba odpowiedzi sobie na pytanie ile wymagań postaramy się zakończyć, zgodnie z Definition of Done, na koniec kolejnego sprintu. Zobowiązanie jest czymś zupełnie innym. Jest to niejako przyrzeczenie do wykonania tego, co obiecaliśmy.
Zespół Deweloperski się nie zobowiązuje, a „jedynie” prognozuje.
Prognozowanie realizacji backlogu
Zespół Deweloperski, na podstawie priorytetów ustalonych przez Produkt Ownera podejmuje decyzję, które elementy z listy wymagań (Backlogu Produktu) znajdą się w Backlogu Sprintu. Brane są pod uwagę zarówno możliwości zespołu, jak i oszacowania każdego z wymagań znajdujących znajdujących się w backlogu. W porównywaniu ich między sobą pomoże jednolity format zapisu, np. popularne User Stories.
Cały czas musimy pamiętać o tym, że Backlog Sprintu to prognoza i może skończyć się tak, jak z latem nad polskim morzem. Prognozy długoterminowe wskazują na upalna słoneczna pogodę, a kończy się jak w każdy długi weekend.
Nic się nie stanie, kiedy nie dowieziemy prognozowanego zakresu sprintu! A przynajmniej nic złego nie powinno się stać. Zgodnie ze sztuką, wymagania nieskończone i nie spełniające Definition of Done wracając do Backlogu Produktu i podlegają ponownej priorytetyzacji. Może się zdarzyć, że z punktu widzenia naszych interesariuszy są to bardzo istotne wymagania i trafią do nas już w kolejnym Sprincie. Czasami też okazuje się, że nie ma sensu kontynuować prac nad daną funkcjonalnością, bo pojawiły się bardziej atrakcyjne możliwości.
Wiatr, ciśnienie i inne czynniki
Ustalenie prognozy pogody wymaga wzięcia pod uwagę najróżniejszych czynników atmosferycznych. Jeśli chodzi o prognozowanie na kolejny Sprint, liczą się aspekty psychologiczne oraz twarda matematyka.
Najcenniejszym źródłem informacji będzie spojrzenie na dotychczas zrealizowane wymagania i średnią sumę punktów dowiezionych w poprzednich iteracjach, czyli Velocity. Trzeba jednak pamiętać, że każdy Sprint jest inny i na każdy należy spojrzeć z osobna. Wyciąganie średniej w niektórych przypadkach może nie dać nam wiarygodnych informacji.
Szczególnie dotyczy to sytuacji, w których mamy do czynienia z nowymi rzeczami lub z wymaganiami, których najzwyczajniej w świecie nie znamy. Prognoza, której dokonamy, bazować będzie wyłącznie na naszym przeczuciu. Ale zgodnie z Inspect and Adapt, nawet pomyłka w oszacowaniu przełoży się korzystnie na nasze przyszłe działania w zakresie prognozowania kolejnych iteracji.
Równie trudno będzie opierać nam się o statystyki wyciągane z sezonu urlopowego lub gdy będziemy prognozować tuż przed nim. Tak naprawdę nie wiemy, jak brak dwóch konkretnych osób przełoży się na naszą prędkość i zdolność do realizowania wymagań. Chociaż, zapewne, z czasem będzie nam to szło coraz lepiej.
Prognozowanie długoterminowe w Scrumie
O ile Zespół Deweloperski prognozuje co chciałby zrealizować w następnym Sprincie, tak Product Owner jest bardziej zainteresowany prognozowaniem długoterminowym. To właśnie PO odpowiada na pytania interesariuszy i klientów, w szczególności zaś na nieuchronne „to kiedy to będzie zrobione?”
Sam Scrum Guide podkreśla, że Product Owner monitoruje postęp do celów określonych jako np. cele biznesowe bądź Epic. Co najmniej w trakcie Sprint Review aktualizuje swoje prognozy co do pozostałej pracy dla poszczególnych celów. To przecież Product Owner decyduje o ewentualnych wydaniach naszego Inkrementu i nie zawsze mogą się one odbyć ad hoc. Czasami muszą być zaplanowane z wyprzedzeniem.
Wracając jednak do najtrudniejszego pytania, czyli „kiedy która funkcjonalność zostanie zrealizowana”, warto jest je odczarować. Działając zwinnie pogodziliśmy się z nieprzewidywalnością. Dlatego też obierając dowolny punkt w przyszłości i próbując utworzyć prognozę realizacji backlogu na ten dzień nie dostaniemy prostej listy.
Dobry Product Owner swoje prognozy zaprezentuje w podziale na co najmniej trzy grupy. Jest pewna część wymagań, która na pewno zostanie zrealizowana, nawet przy najniższym historycznym Velocity, urlopach i problemach. Zwykle jest to około 60% całej prognozy. Pozostała część dzieli się na dwie grupy: raczej uda się zrealizować i raczej nie uda się zrealizować.
To jest świetny punkt wyjścia dla Product Ownera do rozmów z interesariuszami i klientami na temat priorytetyzacji, a także temat na zupełnie inny tekst.
Prognoza, a rutyna
Często wydaje się nam, że znamy się już dobrze na tym, co robimy. Wiemy o sobie na tyle dużo, że nie prognozujemy świadomie, a używamy tak zwanej prognozy eksperckiej. Oczywiście, im dłużej razem pracujemy, im więcej czasu spędziliśmy nad realizacją wymagań z danej kategorii, tym większymi stajemy się ekspertami.
Musimy jednak zdawać sobie sprawę z czyhających na nas pułapek. Dziś, w szybko zmieniającym się świecie, te same wymagania mogą zostać zrealizowane na różne sposoby. Nie popadajmy w rutynę, podchodźmy do każdego z wymagań indywidualnie. Prognozując, co zostanie dostarczone na koniec każdej iteracji, zastanówmy się czy faktycznie jest to realizowalne.
Rutynowe niedoszacowywanie wielkości wymagań kwitowane suchym „Skończymy to w kolejnym Spricie” zaburzy nam nasze obserwacje. Sprawi, że prognozowanie w długim horyzoncie czasowym nie będzie możliwe albo po prostu skrajnie niewiarygodne.
Prognozować czy nie?
Bez forecastowania nie będziemy w stanie realnie zaplanować sobie pracy na przyszłość. Wiemy, że wszystko się zmienia. Każde z wymagań może być przeszacowane lub niedoszacowane. Jednak obserwacja naszych zachowań i pracy Zespołu Deweloperskiego w kontekście przewidywania będzie cenną lekcją na przyszłość.
Im więcej razem przeszliśmy, tym więcej jesteśmy w stanie wyciągnąć wniosków na przyszłość. Prawdziwą skarbnicą wiedzy jest lista już zrealizowanych wymagań, która niesie ze sobą informacja na temat wycen i realizacji wymagań. A gdy będziemy mieli do czynienia z podobnymi funkcjonalnościami bądź tymi samymi częściami systemu co kiedyś, będziemy mieli się do czego odnieść.
Nie bójmy się więc prognozować, nawet kiedy nasze szacunki początkowo nie będą dobre. Przykładem godnym naśladowania mogą być prognozy pogody. One, w przeciwieństwie do naszych forecastów, spełniają się dużo rzadziej.
