Tako kot klasični projektni teami se tudi Agilni pogosto znajdejo v položaju, ko je potrebno napovedati svoj napredek. Planiranje
V seriji treh člankov si bomo ogledali izzive povezane z napovedovanjem v negotovih in dinamičnih Agilnih okoljih.
Če se osredotočimo samo na Scrum in Kanban, bi napovedovanje lahko bilo zahtevano v naslednjih primerih:
- Scrum:
- Za koliko Story Points funkcionalnosti naj team prevzame v naslednji Sprint?
- Kdaj naj podjetje planira release na trg in katere funkcionalnosti bojo v tem releasu?
- Kdaj bo projekt zaključen?
- Kanban:
- Kakšna je verjetnost, da bo prioritetna kartica dokončana v nekem časovnem obdobju?
- Določanje Service Level Agreement (SLA) za pogodbe.
- Določanje Service Level Expectation (SLE) za tekoče delo.
- Kdaj naj podjetje planira release na trg in katere funkcionalnosti bojo v tem releasu?
- Kdaj bo projekt zaključen?
Obstajata dva pristopa s katerima lahko teami napovedujejo svoj napredek.
Deterministično napovedovanje rezultira v enoznačni vrednosti, ki predstavlja odgovor na zgoraj postavljena vprašanja.
Nekaj primerov:
- Na osnovi dosedanjega tempa razvoja ocenjujemo, da lahko v Sprint prevzamemo naslednje uporabniške zgodbe…
- Če želimo v releasu imeti naslednje funkcionalnosti…, ga moramo premakniti na 30. julij.
- Strankin problem povezan z vnosom napačnih podatkov bomo odpravili v dveh urah.
- Ocenjujemo, da bo projekt zaključen do 30. aprila.
Probabilistično napovedovanje projektnim teamom omogoča, da upoštevajo negotovosti razvojnega okolja. Napovedi so namesto eno točkovnih ocen v obliki obsegov možnih vrednosti.
Nekaj primerov:
- Glede na dosedanjo hitrost razvoja ocenjujemo, da je 85% verjetnost, da naslednje funkcionalnosti razvijemo do 1. julija oziroma 95% verjetnost, da jih razvijemo do 1. oktobra.
- Obstaja 85% verjetnost, da bo release z naslednjimi funkcionalnostmi realiziran do 15. maja in le 50% verjetnost, da do 15. marca..
Napovedi za prihodnost so vedno nehvaležne, a v projektnem svetu pogosto neizogibne.
Ko podjetje planira release nove verzije aplikacije na trg, to ni le aktivnost razvojnega teama, ampak vključuje vzporedne dejavnosti mnogih povezanih funkcij:
- Marketing mora pripraviti promocijsko kampanjo.
- UX raziskovalec mora v produkt integrirati prave metrike.
- Tehnična podpora se mora seznaniti z novimi funkcionalnostmi.
- Obstoječe uporabnike je potrebno dodatno izobraziti.
- Finance morajo planirati in odobriti sredstva za realizacijo releasa.
- Management planira predstavitve investitorjem.
- …
Marketing oddelku, je v praksi precej vseeno, ali jim team javi, da bojo v releasu čez pet mesecev PREDVIDOMA naslednje funkcionalnosti (deterministična ocena), ali pa da obstaja 85% VERJETNOST da bojo omenjene funkcionalnosti razvite do datuma releasa (probabilistična ocena).
Oboje je nezadovoljivo, tako da ne moremo trditi, da je ena vrsta napovedovanja boljša od druge. Zakaj se potem sploh trudimo?
Odgovorov na to vprašanje je več:
- Product Owner/Product Manager za vsako novo funkcionalnost v Backlogu ocenjuje ROI. Ko se ta približa ničli ali celo pade v negativo, nadaljnji razvoj ni več ekonomičen in ga je potrebno prekiniti.
- Podjetje mora biti sposobno alocirati sredstva potrebna za realizacijo projekta. Pri razvojnih iniciativah je to v veliki meri cena dela in licenc.
- Že omenjena koordinacija dejavnosti z drugimi oddelki v podjetju.
- Planiranje zaposlovanja oz. relokacije zaposlenih v razvojne teame.
- Komunikacija z naročnikom.
- …
Planiranje torej ostaja. Poglejmo si kako se ga lahko lotimo.
Deterministično planiranje
V prejšnjih petih Sprintih smo namerili Velocity prikazan v spodnjem grafu in mu dodali povprečje.
Povprečna Velocity (v Story Points) teamu pomaga oceniti koliko funkcionalnosti lahko prevzame v naslednji Sprint z realno možnostjo, da jih bojo uspeli razviti.
Na nivoju naslednjega enega do treh Sprintov je ocenjevanje zahtevnosti uporabniških zgodb s Story Points koristno.
Še pomembnejši aspekt ocenjevanja zahtevnosti kot numerična ocena, je skupinska debata ob tem procesu. Ta razkrije skrita tveganja, odvisnosti in priložnosti, ki teamu omogočijo razčlenjevanje Uporabniških Zgodb na optimalne Taske, določanje njihovih izvajalcev in optimizacijo arhitekture.
Kako pa si s povprečno Velocity lahko pomagamo pri predvidevanju trajanja projekta?
Če na primer vemo, da je naš povprečni Velocity 60 Story Points (SP), preostali scope projekta pa 360 SP, lahko predvidevamo, da bo delo zaključeno v šestih Sprintih.
Problem je, ker mi v resnici ne moremo vedeti ali je preostali scope projekta v resnici 360 SP. O funkcionalnostih, ki so v Product Backlogu nižje, namreč vemo najmanj, niso še bile razbite na primerno majhne uporabniške zgodbe in posledično ocenjene glede zahtevnosti.
Razloga za to sta dva:
- Negotovost glede tega ali bojo omenjene funkcionalnosti sploh kdaj prišle na vrsto za potisk v razvoj.
- Neznanke glede načina in pristopa k realizaciji omenjenih funkcionalnosti. V iterativnem razvoju (Agilu) namreč računamo na to, da nam bojo spoznanja predhodnih iteracij olajšala delo v naslednjih iteracijah.
V času, ki bo potekel do trenutka, ko bi bilo omenjene funkcionalnosti mogoče razbiti in kvalitetno oceniti za potisk v razvoj, mogoče le te sploh več ne bojo relevantne. Mogoče bomo tekom dotedanjega razvoja identificirali boljše načine za dosego produktnega cilja. Mogoče se bojo spremenile tržne zahteve, se zaprlo okno poslovne priložnosti, ali pa si bo naročnik enostavno premislil. Vlaganje časa v razčlenjevanje in ocenjevanje nižje ležečih funkcionalnosti bi bil v tem primeru izgubljeni čas. Zato so v Product Backlogu kvalitetno razbite in ocenjene samo funkcionalnosti, ki jih planiramo potisniti v naslednji en do tri Sprinte.
Rešitev v tem primeru ni neka nova metoda ocenjevanja časa do zaključka projekta, ampak sprejetje dejstva, da bomo funkcionalnosti razvijali tako dolgo, kot bojo za to na voljo sredstva.
Predno začnemo hiperventilirati, razmislimo zakaj bi temu lahko bilo tako. Opisani pristop ni problematičen, ker teami v Agilu vedno najprej razvijajo funkcionalnosti z najvišjo poslovno vrednostjo. Tako je organiziran tudi Product Backlog. Če bo denarja zmanjkalo pred realizacijo vseh planiranih funkcionalnosti, zaradi tega ne bo velike škode. Funkcionalnosti z najvišjim ROI so bile že razvite. Še vedno se da projektu alocirati dodatna sredstva. Naloga Product Ownerja/Product managerja je, da oceni ali se to izplača. Pri tem se je dobro spomniti na 80/20 pravilo.
Takšna dinamika pri internih projektih praviloma ni problematična. Kadar pa razvijamo funkcionalnosti za zunanjega naročnika, jo je potrebno formalizirati s pravo obliko pogodbe. Navsezadnje tudi stranka ne želi, da razvijamo funkcionalnosti, ko ji te več ne bojo prinašale poslovne vrednosti. Več o tipih Agilnih pogodb si lahko preberete v mojem obširnem članku s presenetljivim naslovom: Agilne Pogodbe.
Zaključek 1. dela
Če povzamem. Deterministično ocenjevanje:
- je pri planiranju par naslednjih Sprintov koristno
- pri planiranju releasa je zaradi preveč neznank nesmiselno. Namesto tega raje:
- optimizirajmo podporne procese (finance, marketing, komunikacijo z investitorji…), da ne bojo tako odvisni od datuma releasa ali funkcionalnosti v releasu.
- planirajmo časovno rezervo. Agile ne prepoveduje bufferjev.
- sledimo svojemu občutku in intuiciji. Agile ne pričakuje robotov.
- posezimo po probabilističnem planiranju.
- je pri določanju trajanja projekta nesmiselno, saj smo omejeni s sredstvi in/ali časom.
V naslednjem članku bomo spoznali še probabilistično planiranje, ki je pogostejše v Kanbanu in nekaj njegovih orodij. V tretjem članku pa še mojo lastno (beta) metodo.
