V prvem delu članka smo spoznali kako lahko priljubljeno waterfall metriko Earned Value Management (EVM) uporabimo tudi v Agilnih okoljih. Kazalci zaradi katerih smo uporabili EVM so bili naslednji:
- Cost Performance Index (CPI), ki nam pove koliko vrednosti v resnici realiziramo za vsak vložen evro.
- Schedule Performance Index (SPI), ki predstavlja tempo izvajanja glede na plan in omogoča določanje datuma zaključka projekta.
- Estimate At Completion (EAC), ki predvidi končni strošek projekta glede na trenutno hitrost izvajanja.
- Estimate To Complete (ETC), ki podaja preostanek stroškov do zaključka projekta ob trenutni hitrosti napredka.
- Estimated Completion Date (ECD), ki nam pomaga predvideti realizacijo vsega dela, ki se trenutno nahaja v product backlogu.
Agilna alternativa EVM kazalnikom je lahko burnup graf. Oglejmo si kako ga uporabljamo.
Burnup graf namesto ECD
Slika za tisoč besed. Kdaj bo projekt zaključen?
Realizaciji dodamo linearni trend. Vidimo, da ob trenutnem tempu razvoja, lahko realistično pričakujemo, da bomo projekt zaključili do konca novembra. Seveda, če ne bo dodan scope.
Burnup graf namesto EAC
Koliko nas bo stal celoten projekt?
Grafu dodamo:
- Budget, ki se povečuje tako kot dodajamo scope. Vsaj naj bi se 😊
- Cumulative cost, ki je večkratnik naših mesečnih stroškov ocenjenih na 18.000 EUR.
Konec novembra, ko bomo glede na trenutni tempo predvidoma končali projekt, bomo akumulirali za približno 162.0000 EUR razvojnih stroškov.
Ob predvidenem budgetu 155.000 EUR nam bo denarja zmanjkalo že sredi novembra.
Imamo dve možnosti:
- Zmanjšamo scope na približno 220 story points – kjer kumulativni stroški sekajo linijo od budgeta je predviden trend realizacije 220 story points – zelena puščica.
- Zvišamo budget na 162.000 EUR, kar nam bo omogočilo razvoj do konca novembra, ko je predvidena realizacija vseh funkcionalnosti (trend realizacije).
Burnup graf namesto ETC
Preostali stroški projekta.
V našem primeru 162.000 EUR -126.000 EUR = 36.000 EUR.
Kaj pa SPI in CPI?
Ti metriki imata v Agilu smisel samo v primeru če:
- Imamo fiksiran datum zaključka projekta in nas zanima koliko zamujamo (SPI).
- Imamo fiksen budget za projekt in nas zanima ali trošimo preveč (CPI).
SPI
S kakšnim tempom napredujemo glede na plan?
Smo na začetku oktobra in smo uspeli realizirati 185 točk funkcionalnosti. Po planu bi morali realizirati 200 točk. Indeks napredka oz. Schedule Performance Index (SPI) je 0,92 (185/200).
V to praksi pomeni, da smo v povprečju 8% prepočasni.
Če zanemarimo dejstvo, da je 92% hitrost realizacije glede na plan kar dober dosežek, v enem mesecu verjetno ne bomo uspeli realizirati zahtevanega obsega. Neglede na to kakšne spremembe v procesu naredimo. Edina rešitev so pogajanja o zmanjšanju scopea ali pa podaljšanju izvedbenega roka za en mesec.
SPI smo izračunali na enak način kot v prvem delu tega članka le da smo vrednosti tokrat prebrali iz grafa.
Lahko se odločimo, da namesto (v tem primeu višje) vrednosti realizacije upoštevamo trend realizacije. Na ta način si zagotovimo rezervo, ki pokrije nihanja v realizaciji za katera zgodovinsko vemo, da so se pojavljala – iz tega razloga trend realizacije kaže drugačno vrednost kot trenutna realizacija.
SPI nam lahko pomaga izvesti preventivne ukrepe, če mu začnemo slediti dovolj zgodaj. Pravtako bi pomagalo, če bi imeli krajše iteracije. Dolge na primer 2 tedna, ki bi omogočale pogostejši feedback naročnika in s tem manj večjih popravkov.
CPI
S kakšnim tempom trošimo sredstva?
Smo na začetku oktobra in smo porabili 126.000 EUR. Po planu bi jih lahko le 120.000. Stroškovni indeks oz. Cost Performance Index (CPI) je 0,95. (120.000/126.000).
V praksi to pomeni, da se nam za vsak vloženi evro povrne 95 centov.
95% stroškovna učinkovitost je odličen rezultat. Pri projektu z proračunom 155.000 EUR nebi smel biti problem pridobivanje dodatnih 7.000 EUR, ki bi pokrili dodatne stroške do 162.000 EUR.
Pomembno:
Če bi CPI za iste podatke izračunali po formuli iz prvega dela tega članka bi dobili vrednost 1,03. Razlika je nastala, ker smo na burnup grafu upoštevali trend realizacije, pri CPI formuli iz prvega dela članka pa bi upoštevali samo trenutno stanje realizacije, ki je višja od plana.
Če smo presodili, da bo obstoječa hitrost razvoja nadaljevala tudi v naslednjih dveh iteracijah, lahko trend zanemarimo. Odločitev je naša, ne smemo pa mešati obeh pristopov.
Seveda je CPIju dobro začeti slediti že zgodaj v projektu, ko še lahko uvedemo spremembe za nižanje stroškov. Takšne spremembe bi lahko na primer bile večanje interdisciplinarnosti razvojnikov, kar bi omogočilo odpravljanje ozkih grl v procesu ali na primer uvajanje unit testinga, ki bi odkril najpogostejše napake v kodi. Pravtako bi lahko pomagalo krajšanje iteracij, saj bi s tem v primeru, da je team razvijal napačne funkcionalnosti, dobili hitrejši feedback naročnika in torej hitreje korigirali smer razvoja.
Zaključek
Burnup graf je koristno orodje, ki omogoča hitro določanje kritičnih razvojnih kazalnikov. Paziti pa moramo, da se ne začnemo izgubljati v malenkostih. 1000 EUR variacije v 20.000 EUR vrednem projektu mora biti zanemarljivo odstopanje (common cause variation). Pravtako se ne splača računati stroškov z natančnostjo enega ali deset evrov. “Razvojno delo je preveč nepredvidljivo za decimalke.”
Team in vodstvo lahko svoj čas porabijo za produktivnejše stvari, kot so na primer:
