Agile Planning Poker

EXELO – AGILE Project Management Boot Camp 28-30 martie 2013

Autor: Ion Moldoveanu, MBA

Estimarile sunt printre cele mai stresante activitati pentru echipele de dezvoltare software. Aceasta deoarece sunt fortate sa  vina cu valori exacte, intr-un timp foarte scurt si in lipsa tuturor informatiilor necesare. Indiferent de experienta echipei si metodologia folosita, membrii echipelor stiu foarte bine ca aceste estimari se vor dovedi nerealiste iar in final vor intra in criza de timp si vor aparea  frustrari pentru echipa, client si management.

Abordarea Agile:

Metodologia agile este gandita pentru proiectele cu un grad ridicat de incertitudine si multe schimbari. Manifestul agile introduce o noua paradigma:

• Indivizi si interactiuni in loc de Procese si unelte
• Livrarea de software functional in loc de Documentatie
• Colaborarea cu clientul in loc de Negocierea unui contract
• Adoptarea schimbarilor in loc de Urmarea unui plan

Aceste principii sunt urmate si in metodologia de estimare:

In prima etapa cerintele sunt definite grosier si deci estimarile sunt probabil inexacte. Pornind de la premiza ca vor fi schimbari, nu dorim sa investim timp in estimarea detaliata a sute de cerinte, cand este posibil ca atat continutul cat si numarul lor sa se modifice. Este de asemenea nerealist, in prezenta incertitudinii, sa credem ca putem defini toate cerinte complete si finale inainte de a incepe lucrul la proiect.

Estimarile initiale sunt de regula in puncte. Acestea reprezinta o masura relativa a complexitatii riscului tehnic si marimii unei cerinte. Numarul de puncte se defineste relativ fata de estimarea unei functionalitati, considerata standard. Estimarile exprimate in acest fel sunt specifice unei echipe si nu pot fi comparate cu estimari facute de alte persoane.

Estimarile detaliate se fac doar la inceputul unei noi iteratii. In acest moment cerintele sunt definite in detaliu, echipa le clarifica cu managerul de produs, sunt definite taskuri  si se estimeaza in ore. Este esential ca echipa sa poata discuta cu clientul pentru a clarifica cerintele si ca acesta sa vada cum sunt definite taskurile pentru a se asigura ca implementarea cuprinde toate actiunile necesare.

Taskurile se estimeaza in zile sau ore ideale. Acesta reprezinta timpul in care o persoana implementeaza un task fara nici un fel  intreruperi. In realitate, fiecare dintre noi petrece mult timp in sedinte, probleme de suport etc. Timpul petrecut efectiv variaza de la proiect la proiect, de la o persoana la alta si in timp. Aceasta prin comparatie cu „zilele ideale” care sunt o masura unitara a efortului.

Estimarile groisiere se fac prin „planning poker” de catre intreaga echipa. In timp ce estimarea in ore a taskurilor de face de catre cel care va lucra efectiv la ele.

Planning Pocker, jocul:
Fiecare persoana are un pachet de carti cu posibilele estimari. Acestea sunt 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 si ?. Semnificatia cartii „2” este ca activitatea este de doua ori mai complexa decat „1” (cartea „1” reprezinta referinta) etc. 100 inseamna ca cerinta este prea mare pentru o singura iteratie si trebuie impartita. – cerinta este neclara. Nu exista estimari cum ar fi 21, 30…. Cu cat estimarea este mai mare implica un nivel mai scazut de precizie.

Procesul:
1. Se discuta cerinta pana aceasta este clara intregii echipe.
2. Fiecare alege o estimare, dar nu o arata.
3. Cartile sunt intoarse simultan. Se evita astfel ca ca seniori echipei  sa influenteze pe ceilalti.
4. Cei care au estimarile minime/maxime isi justifica alegerea.
5. Se reia jocul pana se ajunge la aceeasi estimare sau se negociaza un consens.
6. In cazul in care nu se ajunge la un consens intr-un timp dat se amana discutia.

Nu este nevoie sa jucam un „poker” pentru toate cerintele. Jocul are avantajul de a discuta cerinta si de a o privi din mai multe perspective. Insa consuma mult timp. In cazul in care avem cerinte similare echipa poate decide sa aplice aceleasi estimari.

Estimarea include toate activitatile necesare pentru ca functionalitatea sa fie „gata” pentru a fi pusa in productie.

Estimarea nu tine cont de cine va lucra efectiv la implementare. Aceasta va fi inclusa doar in momentul in care functionalitatea este planificata intr-o iteratie.

Posibile probleme?

Managementul si clientii vor ca echipa sa poata planifica exact si de la inceputul proiectului ce functionalitati vor fi livrate si cand. Desi aproape niciodata specificatiile nu sunt complet definite  de la inceput, riscurile tehnice pot fi considerabile si inevitabil vor aparea modificari.

Pentru a putea implementa agile si a accepta o estimare detaliata doar la inceputul fiecarei iteratii este necesar ca:
Stakeholderii sa impartaseasca toate principiile agile, si in special:

• schimbarile sunt binevenite
• colaborare intre client si echipa,
• satisfactia clientului prin livrari rapide de software functional.

Echipa de proiect, clientul, managerul de produs si managementul sa cunoasca metodologia agile, sa inteleaga modul in care sunt facute estimarile si de ce se fac in acest fel.

Managerul de produs sa participe activ la toate sedintele de estimare pentru a raspunde la intrebarile dezvoltatorilor.

Concluzii:

Ca si in jocul de poker:

• Recunoaste ca exista incertitudine, dar nu este un joc de sansa.
• Este o metodologie cu reguli clare si necesita disciplina.
• Cicluri scurte, cu rezultate masurabile.
• Functioneaza mult mai bine fata in fata, decat la distanta
• „Jucatorii’ sunt pasionati si impartasesc aceleasi principii.

Ion Moldoveanu, MBA

Ion este trainer EXELO pentru cursurile: Agile Boot Camp, Management de Proiect in IT.
Are o experenta de 13 ani in proiecte software enterprise, lucrand cu cu echiple multinationale. Ion are un master in Automatica si Calculatoare, a lucrat ca inginer software si are o experienta de 9 ani in managementul proiectelor si al echipelor distribuite. A format echipa de Service Engineering pentru Oracle in Romania si in present livreaza proiecte de business intelligence, portaluri client, aplicatii mobile si solutii SOA pentru Oracle Cloud. El este de asemenea implicat in programele Oracle Academy sustinand astfel invatamantul de specialitate in mediul universitar si post universitar. Este absolvent de MBA, a participat si a oranizat traninguri de project management cat si de agile/scrum.