by Fata de abordarile standard unde responsabilitatea revine echipei de management de proiect, in Agile, o buna parte a activitatilor de planificare si implicit estimarea sunt facute impreuna cu echipa.
Echipele sunt mixte si cumuleaza toate disciplinele necesare realizarii livrabilului: spre exemplu dezvoltatori, testeri, business analyst, specialist UX (user experience), technical writer.
Defalcarea nu se bazeaza atat de mult pe WBS, pentru ca se lucreaza foarte mult inter-disciplinar si e greu de separat efortul de dezvoltare de cel de testare sau sau documentare.
In schimb se defalca produsul (ca in PBS) in functionalitati, use case-uri, sau “user stories” asa cum le numesc agilistii.
Din toate aceste user stories identificate, Product Ownerul construieste o lista ierarhizata in functie de prioritate (si aici cel mai comun termen pentru ierarhizare este valoarea de business a functionalitatilor). In Scrum, cea mai folosita metoda Agile, lista poarta de numirea de “Product Backlog”. V-o puteti imagina ca pe un papirus pe care incape un singur user story pe rand, dar foarte foarte lung, cuprinzand intreaga lista de functionalitati de care e nevoie in produs.
Dupa cum stiti, estimarea Agile se apropie foarte mult de conceptul de “rolling wave planning”. Asta inseamna ca tipic, la in inceputul proiectului, Product Backlog-ul e compus din functionalitati mai mari, a caror estimare se face grosier si comparativ intre ele, avand in general in vedere experiente anterioare si referinta unor functionalitati mai mici. Pe parcurs ce proiectul avanseaza, unele user stories de anvergura mare (numite “epics”) sunt sparte mai departe, creand posibilitatea detalierii estimarii pe “sub-functionalitati” care devin user stories in toata regula si inlocuiesc “epic-ul” in lista Product Ownerului.
Voi vorbi in acest articol strict despre estimarea initiala, primul pas din “rolling wave”, o estimare generala la nivel de proiect sau hai sa spunem la nivelul unui release (3-6 luni).
Partea a doua, detalierea estimarii se realizeaza pe parcurs si mai ales in momentul planificarii fiecarei iteratii.
Ce concepte noi apar in estimare?
Exista doua concepte de estimare folosite in mod uzual: ideal days si story points. Sunt ambele folosite cu success, cateodata chiar complementare.
Estimarea cu Ideal Days
este mai apropiata de tehnicile standard. O “Ideal day” sau “ziua de programator in vid” cum o mai numesc colegii mei, este volumul de munca pe care un membru al echipei il poate finaliza in 8 h de lucru neintrerupt.
Plecand de la aceasta masura, putem estima intregul “product backlog” mai intai grosier, pe user stories si epics mari, apoi pe parcursul proiectului detaliind acolo unde e nevoie ca urmare a spargerii functionalitatilor in stories mai mici.
Estimand grosier functionalitatile in ideal days, avand in vedere si numarul membrilor echipei si overheadul datorat iterarii (tipic se pierde aproape o zi cu planificarea fiecarei iteratii si cam jumatate de zi cu review si retrospectiva de la final) ajungem la o estimare initiala de timp pentru intreg proiectul.
Pentru estimarea de timp se tine evident seama de faptul ca o zi ideala nu e egala cu una de lucru. Aici trebuie inmultit rezultatul cu un coeficient de, spre exemplu, 1,3 (in functie de implicarea membrilor echipei si in alte activitati), pentru a obtine rezultatul in zile de lucru.
Dezavantajul pornirii la drum cu o estimare aproximativa e compensat de faptul ca functionalitatile sunt prioritizate! Cele mai importante sunt in varful listei si sunt defalcate mai atent inca de la inceput.
Diferenta esentiala in acest caz este faptul ca estimarile se dau de catre echipa, de cei care vor realiza efectiv munca, si nu de catre PM sau experti externi echipei.
Story Points
1 story point este valoarea atribuita unei activitati relativ simple (intre 1/2 si 2 ideal days) al carei volum de munca si complexitate sunt intelese cat mai bine de toti mebrii echipei
Pentru folosirea practica a story points se porneste de la una din functionalitatile (user stories) mai simple, cat mai comuna si usor de inteles si agreat ca si complexitate si efort de realizare. Acestui story i se atribuie valoarea de 1 story point. Apoi, in cadrul activitatilor de estimare, toate functionalitatile din backlog se compara, relativ la taskul initial, si primesc rand pe rand un numar de puncte.
Fiecare story e citit, dezbatut, analizat, apoi membrii echipei dau un “guesstimate” relativ la story-ul initial. Tehnica folosita, desprinsa din estimarea wideband Delphi poarta denumirea de “poker planning” – fiecare membru ofera o estimare, pe o “carte de joc”, fara sa vada initial estimarile celorlalti.
Pentru a diminua dezbaterile, valoarea pe care o poate vota e de obicei restransa la numerele sirului Fibonacci: 1,2,3,5,8,13,21 etc.
Evident, rezultatele nu sunt totdeauna convergente. Cei care au dat estimarile extreme argumenteaza si procesul de votare se reia pana cand se agreeaza in echipa o valoare acceptabila.
Daca valoarea agreata este foarte mare (ex: 20 story points sau mai mult) se cheama ca am identificat un “epic”, adica un story care va trebui ulterior defalcat.
Se reia procesul pana la atribuirea unei valori in story points fiecarei functionalitati din backlog.
Ajungem la sa spunem 500 de Story Points.
Bun, dar cat va dura proiectul? 😉
Avem 3 variante de forecast:
1. Fie avem o echipa care a mai rulat in proiecte Agile si stim ca realizeaza o medie de x story points in fiecare iteratie. Astfel aflam usor de cate iteratii avem nevoie si stiind durata iteratiilor calculam durata proiectului.
2. Fie rulam o iteratie initiala “in bezna” si vedem cate story points putem sa inchidem, reluand apoi calculul de la punctul anterior.
3. Fie ne folosim din nou de “ideal days”. Am spus mai sus ca story-ul de referinta e usor de estimat si in timp. Daca inmultim valoarea in timp a taskului de 1 story point cu estimarile in puncte, obtinem din nou estimatul in ideal days.
Si atunci de ce mai folosim story points? Pentru ca:
- Ii fac pe estimatori sa foloseasca estimarea relativa, intre stories, in loc de estimare directa in timp (si exista studii care confirma ca estimarile sunt mai bune).
- Focalizeaza estimarea pe efort/complexitate, nu pe durata.
- Ne permit sa evaluam productivitatea dupa fiecare iteratie (duarata fixa).
- Estimatorii (membrii echipei) trebuie sa isi justifice valorile, atunci cand nu exista consens din prima incercare.
- Glasul fiecaruia poate fi auzit.
- E o metoda mai rapida de estimare.
Si din aceste motive ne place Agile!
