Velocity metrika je zaradi določenih anti-vzorcev, ki se pojavljajo v zvezi z njo, na precej slabem glasu. V pričujočem članku opisujem kakšna je vloga Velocity metrike v več teamskem okolju, čemu ne služi in kako jo lahko proaktivno uporabimo za planiranje releasa v produkcijo.
STORY POINTS
Predno, Agilni team funkcionalnost ali uporabniško zgodbo prevzame v razvoj, jo oceni glede zahtevnosti/velikosti. Enota za oceno velikosti je običajno Story Point, čeprav nekateri teami uporabljajo lastno izrazoslovje (Gummy Bears, NUTs – Nebulous Units of Time…). Velocity
To ni samo Scrum praksa, ampak “sizing” izvajata tudi Kanban in Scrumban, čeprav promotorji teh frameworkov to radi zanikajo. Kanban team sizing običajno izvaja na Weekly Replenishment in Delivery Planning dogodkih, ko team ocenjuje verjetnost, da bo neki feature dokončan v npr. 10 dnevih. Scrumban pa pozna Trigger Planning, ki je dinamičen glede na hitrost razvoja in pravtako služi ocenjevanju zahtevnosti izvedbe backlog elementov.
Namen “sizinga” je:
- Razgovor o funkcionalnostih in uporabniških zgodbah, kar vodi v njihovo boljše razumevanje, identifikacijo mogočih problemov, razkritje nefunkcionalnih (backend) zahtev in izločanje funkcionalnosti z nizko poslovno vrednostjo. V tem razgovoru so poleg razvojnikov ključni Product Owner in po potrebi predstavniki končnih uporabnikov, ki najbolje poznajo problematiko in pričakovano poslovno vrednost.
- Preverjanje ali je team predlagano uporabniško zgodbo sposoben realizirati v naslednjem Sprintu in po potrebi njeno razbijanje na manjše pod zgodbe. To je pomembno, saj naj bi team na koncu vsake iteracije predstavil produktni inkrement z neko poslovno vrednostjo. Ta inkrement je (idealno) tudi pripravljen za takojšnjo vključitev v produkcijo (Done). Za Kanban teame je ta meja običajno večji release v produkcijo.
- Team prevzame v razvoj toliko uporabniških zgodb kot je njegova kapaciteta (Velocity) glede na izkušnje preteklih iteracij. Idealno to ni ena sama velika uporabniška zgodba, saj team na ta način tvega, da na koncu iteracije ne bo imel Done inkrementa. Če team razvija več manjših zgodb, vsako s svojo poslovno vrednostjo, blokada ene zgodbe, verjetno ne bo ogrozila cilja iteracije (Sprint Goal), team pa bo kljub temu generiral določeno poslovno vrednost. Tipična uporabniška zgodba naj bi predstavljala 2 do 3 dni dela enega razvojnika. Seveda pa je to odvisno od konteksta.
Story Point je manjša enota dela, ki jo poznajo vsi člani teama in se strinjajo o njeni velikosti. Velikost ostalih uporabniških zgodb se nato ocenjuje kot večkratnik “bazne” Story Point. Običajno se uporabljajo faktorji Fibonaccijevega zaporedja (1, 2, 3, 5, 8, 13,…).
Primeri bazne (1) Story Point uporabniške zgodbe:
- Dodajanje login gumba na WEB stran
- Vsebina tabele na WEB strani prebrana s SQL strežnika
- Priprava darilnega paketa za povprečno pridnega otroka (Božičkova metrika)
- Inštalacija in konfiguracija SQL strežnika
- WEB stran s 50 samostojnimi tekstovnimi polji
- Pojesti eno čokoladno ploščico
- Prikaz GDPR pop-up na WEB strani
- API poizvedba in vpis preračunane vrednosti v polje
- …
Velikost Story Point je specifična za team. Tekom razvoja naj se nebi spreminjala, saj nam to pokvari metrike. Velocity je število Story Points, ki jih je team razvil v eni iteraciji. V več teamskem okolju ni potrebe po standardizaciji Story Point med teami. Edini možni razlog za to, bi bila želja po medsebojni primerjavi produktivnosti teamov, kar pa je v popolnem nasprotju z Agilno filozofijo.
VELOCITY
V Scaled Agile, kjer več teamov razvija skupni produktni inkrement, se nam glede različnih velikosti Story Points in povezane Velocity postavi par vprašanj:
- Kako planirati, če ima vsak team svojo lastno bazno Story Point?
Velikost Story Pointa posameznega teama ne vpliva na planiranje. Team prevzame v razvoj toliko uporabniških zgodb, kot je njegova Velocity. Velikost uporabniške zgodbe team pač oceni z lastnim merilom. Predvidevamo, da imajo enako veliki teami, enako izkušenih razvojnikov približno enako kapaciteto. Neglede na to s koliko internih teamskih Story Points je bila ocenjena določena uporabniška zgodba. - Kako primerjamo produktivnost različnih teamov?
Tega ne počnemo. - Na čemu baziramo nagrajevanje teamov?
Nagrajevanje bazira na principu “nivoja višje”. To pomeni, da se ne nagrajuje individualnih teamov glede na njihovo produktivnost, ampak celoten team-teamov glede na poslovno vrednost, ki so jo ustvarili. Ta način nagrajevanja vzpodbuja med-teamsko sodelovanje in deljenje informacij, kar je navsezadnje cilj Scaled Agile praks. - Ali lahko predvidimo datum releasa glede na to, da so Velocity teamov neprimerljivi?
Da, metoda je opisana nižje v članku. - Kako managementu poročati o produktivnosti teamov?
Tega ne počnemo. Če poročamo, je metrika ustvarjena poslovna vrednost. Če ustvarjena poslovna vrednost s časom pada, je to predvsem odgovornost produktnega managerja ali Product Ownerja in ne razvojnikov. Določen padec poslovne vrednosti skozi iteracije je pričakovan, saj teami vedno najprej razvijajo funkcionalnosti, ki imajo najvišjo poslovno vrednost/ROI. Ko se pomikamo nižje po backlogu, se vrednosti nižajo. Razvoj novih funkcionalnosti je priporočljivo prekiniti, predno njihov ROI pade v negativo.
Velocity ni:
- Osnova za nagrajevanje teamov
- Metrika produktivnosti teama
- Indikator zagnanosti teama
- Sestavljen iz časovnih enot
- Status report za management
- Zagotovilo prihodnje produktivnosti teama
- Orodje za planiranje releasa
- Indikator ustvarjene poslovne vrednosti
RELEASE PLANNING V VEČ TEAMSKEM OKOLJU
Kako v Scaled Agile okolju napovemo release glede na to, da vsak team uporablja lastno definicijo bazne Story Point?
Napoved bomo naredili s pomočjo Burndown grafov*. Iz njih bomo odstranili Story Points vrednosti, ter primerjali njihovo strmino.
* V članku pred časom sem zagovarjal tezo, da je burnup graf za team koristnejše orodje kot burndown – zdaj pa delam reklamo za burndown. Trditev še vedno drži. Primerjava Velocity, ki se izvaja z burndown grafom, je orodje za Product Ownerja in Scrum Mastra. Teamu ne nudi koristnih informacij in bi lahko vodila v nekoristno rivalstvo med teami.
Iz grafa vidimo da:
- Team C bo prevzete uporabniške zgodbe verjetno zaključil pred predvidenim datumom releasa.
- Team B “zaostaja” in verjetno dela ne bo zaključil pred predvidenim release datumom.
- Teama A in D bosta razvoj verjetno zaključila do predvidenega release datuma.
Kaže, da je (glede na trenutno stanje) verjetnost releasa na predvideni datum nizka. Na voljo imamo več rešitev.
Zmanjšamo scope
Product Owner se sestane z deležniki in poizkuša doseči konsenz glede zmanjšanja obsega planiranega releasa. Mogoče se da izločiti par funkcionalnosti z najnižjo poslovno vrednostjo? Ali pa se določeno funkcionalnost razdeli na dve pod funkcionalnosti. Tisto z višjo poslovno vrednostjo se razvije za trenutni release, funkcionalnost z nižjo poslovno vrednostjo pa se prestavi na enega od naslednjih releasov.
Zamaknemo release datum
Release se v podjetju pogosto usklajuje z ostalimi povezanimi dejavnostmi kot na primer marketinško kampanjo, predstavitvami investitorjem, dopusti itd.. Glede na to, da razvoj in izvajanje/organiziranje povezanih dejavnosti potekajo vzporedno, je zamik release datuma pogosto nerealen.
Če pa podobnih odvisnosti ni, je tudi zamik releasa realna možnost.
Reorganizacija dela
Tretja možnost bi bila aktivacija notranjih rezerv. V našem primeru bi to lahko pomenilo:
- Team C razbremeni team B, tako da v razvoj prevzame nekaj njihovih uporabniških zgodb.
- Eden ali več razvojnikov iz teama C se prostovoljno začasno premakne v team B.
- Pravtako lahko teamu B pomagajo razvojniki iz teamov A in D (swarming), ki bojo v zadnjih iteracijah pred releasom verjetno manj zaposleni (pogosto stanje pred releasom, ko breme z razvojnikov počasi prehaja na testerje – ni vsak razvojnik tudi tester).
- Teamu B se doda nove člane od zunaj ali iz organizacije. Pri tem se je potrebno zavedati, da bo kratkoročno, produktivnost teama B verjetno padla, dokler se novi člani ne integrirajo v team (Tuckmanove faze).
Naloga organizacije in Scrum Mastra je, da ustvarita delovno okolje in vzdušje, kjer si bojo člani samo-organizirajočih teamov medsebojno pripravljeni pomagati in si prizadevali za dosego skupnega cilja. Da ne bomo preveč naivni; pomembno orodje v tem prizadevanju je tudi nagrajevanje “nivoja višje”.
