V prejšnjih dveh člankih (1. del, 2. del) smo spoznali deterministično in probabilistično metodo ocenjevanja ter kdaj sta koristni. Tokrat pa bom predstavil lastno metodo, ki sem jo pripravil na zgodovinskih podatkih teamov. Uporabna naj bi bila za planiranje releasa s fiksnim datumom in/ali fiksno določenimi funkcionalnostmi. Metoda je trenutno le minimalno preizkušena.
SLE za Story Point (SLESP) faktor
V seriji člankov se posvečamo trem horizontom planiranja. Sprintom, releasom in projektu kot celoti. Če na kratko povzamem…
Sprinti
Spoznali smo, da za planiranje naslednjega enega do treh Sprintov lahko uporabimo deterministično ali probabilistično metodo. Ni pomembno ali delamo po Scrum ali Kanban frameworku. Nič nas namreč ne omejuje, da za namene planiranja Kanban koledar razdelimo na navidezne Sprinte, ki jim nato izračunamo SLE.
V praksi bi deterministične in probabilistične ocene izgledale tako.
Scrum
- Na osnovi povprečne velocity preteklih Sprintov predvidevamo, da lahko v naslednji Sprint prevzamemo za 24 Story Points (SP) funkcionalnosti.
- Na osnovi velocity preteklih Sprintov lahko s 85% gotovostjo trdimo, da lahko v naslednjem Sprintu realiziramo za 16 SP funkcionalnosti (probabilistična ocena).
Kanban
- Glede na trenutni SLE lahko s 65% verjetnostjo trdimo, da bomo v naslednjem Sprintu sposobni realizirati 3 funkcionalnosti.
- Na osnovi velocity preteklih Sprintov lahko s 85% gotovostjo trdimo, da lahko v naslednjem Sprintu realiziramo za 16 SP funkcionalnosti.
Projekt
Pri planiranju projekta smo omejeni s finančnimi sredstvi oziroma ROI funkcionalnosti, ki jih razvijamo. Natančno planiranje tukaj ni smiselno.
Če moramo zagotoviti fiksni scope in delamo na osnovi pogodbe s fiksnimi stroški, lahko tak projekt vodimo tudi po waterfall modelu. Verjetnost uspeha projekta bo v tem primeru približno enaka, cenovna rezerva, ki jo bomo morali zaračunati naročniku pa precej velika.
Kaj pa release?
Ostane nam samo še planiranje releasov, kjer smo soočeni z dvema neznankama, ki nam otežujeta planiranje:
- Daljši časovni horizont kot pri Sprintu.
- Nedefiniranost in nepoznavanje zahtevanih funkcionalnosti za release.
Če optimiziramo organizacijske dejavnosti, ki so odvisne od datuma releasa, se lahko v precejšnji meri izognemo potrebi po zgodnjemu napovedovanju release datuma. Žal to ni vedno realistično in razvojni team se bo slej ko prej znašel v položaju, ko bo moral napovedati kdaj bodo planirane funkcionalnosti pripravljene za release.
Kompliciranih rešitev tega problema je veliko. Gibajo se od COCOMO II modela, product roadmap, pa do Monte-Carlo analize. Ker pa mi ne želimo izgubljati preveč časa s planiranjem neznanega, je naš cilj čim hitrejša, pa kljub temu relativno natančna ocena. Tudi če si bomo zato privoščili par divjih predpostavk in bližnjic.
Rešitev, ki jo predlagam, je izračun SLE za Story Point faktorja (SLESP faktor). Oglejmo si tri korake za izračun:
1. korak
Najprej bomo planirane funkcionalnosti po velikosti primerjali z že razvitimi funkcionalnostmi katerim poznamo velikost v SP.
Metoda je podobna T-Shirt sizing, le da v tabelo planirane funkcionalnosti sortiramo glede na velikost že razvitih funkcionalnosti in ne po relativnih velikostih (S, M, L, XL).
Tabela nam omogoči ne samo primerjave planiranih funkcionalnosti z že razvitimi, ampak tudi primerjave med stolpci (Npr.: Ali je funkcionalnost 14 res približno dvakrat večja od funkcionalnosti 12).
2. korak
Ko smo planirane funkcionalnosti razporedili v tabelo, za vsako velikost posebej potrebujemo še nivo zaupanja. Se pravi kako natančne so bile naše ocene zgodovinsko, ko smo planirali in na koncu razvili referenčne funkcionalnosti.
Na tej stopnji sem eksperimentiral z različnimi načini statistične analize odklonov med planirano in realizirano količino SP. Večkrat se je zdelo, da sem se približal cilju a teorije žal niso zdržale soočenja z zgodovinskimi podatki teamov. Po tej zamudni izkušnji s precejšno gotovostjo trdim, da kvantitativne metode za planiranje releasa niso primerne.
Nezmožnost uporabe statistične analize izhaja predvsem iz dveh faktorjev:
- Zavedanja, da večje funkcionalnosti vsebujejo več neznank, ki bojo nepredvideno podaljšale njihov razvoj.
- Dejstva, da med Sprintom pogosto vzporedno razvijamo uporabniške zgodbe, ki pripadajo različnim funkcionalnostim. To nam brez pretirane dodatne birokracije (beleženje porabe časa), onemogoča zajem relevantnih metrik.
Za ocenjevanje zaupanja v teamske ocene velikosti, se bomo torej morali poslužiti kvalitativnih metod.
Kako bi to lahko izvedli?
Izbrali si bomo Sprint Review, kjer team tako ali tako vrednoti in ocenjuje delo preteklega Sprinta. Temu vrednotenju naj doda še oceno kompleksnosti za funkcionalnosti, ki so jih zaključili v Sprintu (funkcionalnosti – ne uporabniških zgodb).
Uporabimo preprosto lestvico od 0 do 3*:
- 0 točk: razvoj funkcionalnosti je vzel toliko časa kot smo zanjo planirali
- 1 točka: razvoj funkcionalnosti je vzel malo več časa kot smo zanjo planirali
- 2 točki: razvoj funkcionalnosti je vzel vsaj polovico več časa kot smo zanjo planirali
- 3 točke: razvoj funkcionalnosti je vzel dvakrat toliko (ali več) časa kot smo zanjo planirali
* Po potrebi lahko uporabimo tudi bolj granularno lestvico, vendar mislim, da več kot 6 vrednosti ni smiselnih.
3. korak
Povprečje ocen dodamo tabeli iz prve točke. Dobimo oceno, ki jo imenujem SLE za Story Point (SLESP) faktor.
Rezultat v zgornji tabeli nam pove, da za planirane funkcionalnosti, ki smo jim velikost ocenili na 80 SP, moramo planirati približno 50 – 100% (med 2 in 3 točkami odklona) več časa kot se nam trenutno zdi, da ga potrebujemo. Lahko vzamemo kar povprečje 75%.
Za funkcionalnosti, ki pa smo jih ocenili s približno velikostjo 45 SP pa 10 – 50% več časa (odklone manjše od 10% bo team verjetno ocenil z 0 točkami). Če bi se odločili za povprečje bi to bilo 30%.
Večji kot bomo imeli vzorec že zaključenih funkcionalnosti, bolj realistična bo njihova povprečna ocena zaupanja.
Zakaj metoda (verjetno) deluje?
Metoda SLESP faktorja upošteva večino spremenljivk, ki nam pri običajnem planiranju onemogočajo datumsko oceno releasa.
To so:
- Različne velikosti planiranih funkcionalnosti.
- Različne nivoje negotovosti glede na velikost planirane funkcionalnosti.
- Nepoznavanje korakov potrebnih za realizacijo časovno oddaljenih funkcionalnosti.
- Hitrost razvoja (velocity) preteklih Sprintov.
- Izkušnje teama pri ocenjevanju količine dela.
Ali so relacije med naštetimi spremenljivkami v resnici takšne kot jih prikaže SLESP faktor niti ni pomembno. Ideja je, da tako kot pri probabilističnem planiranju, zanesljivosti ocen s časom konvergirajo proti določenim vrednostim.
Ko opazimo, da se je SLESP faktor za določeno velikost funkcionalnosti izkazal kot neprimeren (to se bo gotovo zgodilo), rezultat pri naslednjem planiranju enostavno utežimo s faktorjem, ki bi prejšnje planiranje izenačil s končnim rezultatom in ga uporabimo v prihodnjem planiranju.
Zaključek
Uporaba SLESP faktorja je kompromis med dodajanjem obsežnega administrativnega bremena, ki bi teamu skozi statistično analizo (mogoče) omogočilo natančnejšo kvantitativno oceno datuma releasa in prepričanjem, da je za takšno oceno preveč neznank.
Agilne organizacije vzpodbujam k razmisleku o opisani metodi v primeru, ko so teami soočeni s fiksnim release datumom ali pa določanjem datuma releasa, ki mora vsebovati v naprej določene funkcionalnosti.
Vabim vas, da delite svoje izkušnje. Ko bom zbral dovolj povratnih informacij s terena, pa bom o tem tudi kaj napisal.
