Tehnici de estimare agile

Abstract

Stimarea efortului de lucru în proiectele agile este fundamental diferită de metodele tradiționale de estimare. Abordarea tradițională este de a estima folosind o tehnică „de jos în sus”: detaliați toate cerințele și estimați fiecare sarcină pentru a îndeplini aceste cerințe în ore/zile, apoi folosiți aceste date pentru a dezvolta programul proiectului. Proiectele agile, dimpotrivă, utilizează o abordare „de sus în jos”, folosind tehnici de estimare la nivel grosier pentru seturi de caracteristici, apoi utilizând metode de elaborare progresivă și de planificare în valuri pentru a detalia până la nivelul sarcinilor în timp util, descoperind în mod iterativ din ce în ce mai multe detalii la fiecare nivel inferior. Această lucrare va detalia două tehnici comune pentru estimarea agilă (pokerul de planificare și gruparea prin afinitate), precum și modul în care rezultatele acestor exerciții oferă date de intrare în prognozarea calendarului și a bugetului.

Top-down vs. Bottom-up

Metoda tradițională de estimare a proiectelor este de a petrece câteva săptămâni sau luni la începutul unui proiect pentru a defini cerințele detaliate pentru produsul care se construiește. Odată ce toate cerințele cunoscute au fost obținute și documentate, se poate realiza o diagramă Gantt care să arate toate sarcinile necesare pentru a îndeplini cerințele, împreună cu estimarea fiecărei sarcini. Resursele pot fi apoi alocate sarcinilor, iar acțiuni precum încărcarea și nivelarea ajută la determinarea datei finale de livrare și a bugetului. Acest proces este cunoscut sub numele de metoda ascendentă, deoarece toate detaliile referitoare la produs trebuie să fie definite înainte de a se putea estima calendarul și costul proiectului.

În industria software, utilizarea metodei ascendente are dezavantaje grave din cauza vitezei de schimbare din zilele noastre. Viteza schimbării înseamnă că viteza noilor instrumente de dezvoltare și viteza de acces la noi cunoștințe este atât de mare încât orice întârziere în livrare lasă deschisă alternativelor competitive și în pericolul de a livra un produs învechit (Sliger, 2010).

Metoda descendentă abordează această problemă cheie, utilizând informațiile disponibile în prezent pentru a furniza estimări la nivel brut. Planificarea în valuri rulante este apoi utilizată pentru a încorpora noi informații pe măsură ce se află, rafinând în continuare estimările și elaborând iterativ cu mai multe detalii pe măsură ce proiectul avansează. Această metodă de a învăța doar atât cât trebuie pentru a începe, cu un plan de a încorpora mai multe cunoștințe pe măsură ce rezultatele muncii evoluează, permite echipei de proiect să reacționeze rapid la adversități și la schimbarea cererii de pe piață.

Tehnici de estimare

Tehnicile de estimare la nivel brut sunt utilizate de echipele care folosesc abordări agile, cum ar fi Scrum și Extreme Programming, iar această lucrare va acoperi două dintre cele mai populare tehnici: Planning Poker și Affinity Grouping. Unitățile de estimare utilizate vor fi, de asemenea, examinate, deoarece aceste unități ar trebui să fie de așa natură încât să nu poată fi confundate cu timpul.

Planning Poker

Cea mai populară tehnică de estimare la nivel brut este Planning Poker, sau utilizarea secvenței Fibonacci pentru a atribui o valoare punctuală unei caracteristici sau unui element (Grenning, 2002). Secvența Fibonacci este o serie matematică de numere care a fost introdusă în secolul al XIII-lea și utilizată pentru a explica anumite aspecte formative ale naturii, cum ar fi ramificarea copacilor. Seria este generată prin adunarea celor două numere anterioare pentru a obține următoarea valoare din secvență: 0, 1, 1, 1, 2, 3, 5, 5, 8, 13, 21, și așa mai departe. În scopul estimării agile, unele dintre numere au fost modificate, rezultând următoarea serie: 1, 2, 3, 5, 8, 13, 20, 40, 100.

Aceste numere sunt reprezentate într-un set de cărți de joc (a se vedea exponatul 1). Membrii echipei joacă „Poker de planificare” (exponatul 2) pentru a furniza o estimare sub forma unei valori de puncte pentru fiecare element. Iată care sunt pașii:

• Care membru al echipei primește un set de cărți de joc.
• Proprietarul afacerii (care NU ajunge să estimeze) prezintă elementul care urmează să fie estimat.
• Elementul este discutat.
• Care membru al echipei selectează în mod privat o carte care reprezintă estimarea sa.
• Când toată lumea este pregătită, toate cărțile selectate sunt dezvăluite în același timp.
• Dacă toți membrii echipei au selectat aceeași carte, atunci valoarea punctului respectiv reprezintă estimarea.
• Dacă cărțile nu sunt identice, echipa discută estimarea, punând accentul pe valorile aberante:
  • Membrul care a selectat cea mai mică valoare explică de ce a selectat acea valoare.
  • Membrul care a selectat cea mai mare valoare explică de ce a selectat acea valoare.
• Se selectează din nou până când estimările converg.
• În cazul în care rezultă conversații lungi sau „în buruieni”, membrii echipei pot folosi un cronometru de două minute pentru a cronometra discuția, selectând din nou de fiecare dată când cronometrul se termină, până la conversie.
• Repetați pentru fiecare element (Cohn, 2006, pp. 56-57).

Există mai multe motive pentru care se folosesc numerele Fibonacci, și se folosesc în acest format. Primul este ideea că, odată ce echipele elimină timpul ca bază de estimare, este mai puțin probabil ca acestea să ceară mai multe detalii și să umfle estimările. În schimb, aceste numere reprezintă mărimea relativă, nu timpul. Ca urmare, exercițiul de estimare decurge destul de repede. În general, echipele petrec aproximativ două minute pentru fiecare element, ceea ce permite ca un backlog de 30 de elemente să fie estimat într-o oră. Faptul că echipele sunt limitate la numai 9 opțiuni (adică valori de puncte sau carduri) contribuie, de asemenea, la accelerarea procesului.

Secvența oferă, de asemenea, nivelul corect de detaliu pentru caracteristicile mai mici și mai bine înțelese, evitând în același timp un fals sentiment de precizie pentru estimările mai mari. De exemplu, un element cu o estimare ridicată (20 sau mai mare) înseamnă că elementul este mare și nu este încă bine înțeles. A dezbate dacă elementul este un 20 sau un 19 sau un 22 ar fi o pierdere de timp, deoarece pur și simplu nu există suficiente date disponibile. Odată ce elementul se apropie de iterația în care se va lucra cu el, acesta poate fi împărțit în bucăți mai mici și poate fi estimat în numere mai granulare (1-13). Elementele cu estimări de puncte de la 1-13 pot fi, în general, finalizate într-o singură iterație (1-4 săptămâni).

Este important să rețineți că punctele nu au aceeași semnificație între echipe; de exemplu, „cinci” al unei echipe nu este egal cu „cinci” al altei echipe. Astfel, viteza echipei, care este derivată din puncte, nu ar trebui să fie utilizată pentru a compara productivitatea între echipe.

Gruparea prin afinitate

O modalitate și mai rapidă de estimare, și una utilizată atunci când numărul de elemente de estimat este mare, este gruparea prin afinitate. Membrii echipei grupează pur și simplu elementele care sunt de dimensiuni similare, rezultând o configurație asemănătoare cu cea din figura 3. Metoda este simplă și rapidă:

• Se citește primul element membrilor echipei și se plasează pe perete.
• Se citește al doilea element și echipa este întrebată dacă este mai mic sau mai mare decât primul element; plasarea pe perete corespunde răspunsului echipei (mai mare este la dreapta, mai mic este la stânga).
• Se citește al treilea element și echipa este întrebată dacă este mai mic sau mai mare decât primul și/sau al doilea element; elementul este plasat pe perete în mod corespunzător.
• Controlul este apoi predat echipei pentru a termina gruparea prin afinitate pentru restul elementelor.

Echipele pot alege să continue în același mod, plasând câte un element pe rând pe perete după discuția în grup. Cu toate acestea, o modalitate mai rapidă este ca fiecare membru al echipei să selecteze un element și să îl plaseze pe baza celei mai bune înțelegeri proprii. Acest lucru se face cu toți membrii echipei lucrând în paralel până când toate elementele au fost evaluate și plasate pe perete. Câteva sute de elemente pot fi estimate într-un timp relativ scurt. Odată ce toate elementele sunt pe perete, echipa revizuiește grupările. Elementele despre care un membru al echipei consideră că se află într-o grupă greșită sunt discutate și mutate, dacă este cazul.

După ce gruparea prin afinitate este completă, se pot atribui valori unitare de estimare, cum ar fi punctele. În Anexa 3, primul set din extrema stângă ar fi etichetat ca având valoarea de 1 punct, al doilea set ar fi de 2 puncte, al treilea set de 3 puncte, al patrulea set de 5 puncte și ultimul set de 8 puncte.

Gruparea prin afinitate se poate face, de asemenea, pentru alte unități de estimare, cum ar fi mărimea tricourilor. Exponatul 4 prezintă un exemplu de articole grupate prin afinitate, etichetate cu dimensiuni de tricouri în loc de puncte.

Unități de estimare

Utilizarea mărimilor de tricou (Extra Small , Small , Small , Medium , Large , Extra Large ) este un alt mod de a ne gândi la mărimile relative ale caracteristicilor. Aceasta este o abatere și mai mare de la sistemul numeric și, ca toate unitățile de estimare bune la nivel brut, nu pot fi asociate în nici un fel cu o anumită durată de timp.

Alte simboluri arbitrare de măsurare includ Gummi Bears, NUTS (Nebulous Units of Time) și foot-pounds. Echipele își pot crea propriile unități de estimare și, după cum puteți vedea, adesea se distrează puțin făcând acest lucru.

Acest document nu acoperă utilizarea unităților bazate pe timp, cum ar fi zilele și/sau orele ideale de dezvoltare. Acestea sunt deja comune și bine înțelese, așa că explicațiile lor nu au fost incluse. Cu toate acestea, este demn de remarcat faptul că estimarea la nivel brut are potențialul de a avea mai mult succes atunci când este decupată de noțiunea de timp. Deoarece estimările de timp sunt adesea transformate în angajamente de către conducere și întreprinderi, membrii echipei se simt mai presați să fie cât mai exacți posibil. Ca urmare, aceștia solicită din ce în ce mai multe detalii despre elementul estimat. Acest lucru transformă estimarea la nivel brut în estimarea la nivel de detaliu, care consumă mai mult timp, și înfrânge intenția și scopul inițial.

Previzionarea programului și a bugetului

După ce sunt determinate estimările la nivel brut și viteza echipei, programul și bugetul pot fi prognozate. Echipele își determină viteza prin însumarea numărului total de puncte pentru toate elementele pe care le-au finalizat într-o iterație. De exemplu, este posibil ca o echipă să fi selectat cinci elemente cu o valoare totală a punctelor de 23 de puncte (a se vedea figura 5). La sfârșitul iterației lor de două săptămâni, au reușit să finalizeze doar patru din cele cinci elemente. Viteza lor este de 15, sau suma valorilor punctuale ale elementelor 1-4. Echipele nu primesc „credit parțial” pentru finalizarea unor porțiuni dintr-un item, astfel încât, chiar dacă ar fi început să lucreze la itemul 5, acesta nu ar fi contat, deoarece nu a fost finalizat.

Determinarea programului

Viteza medie a unei echipe este utilizată în prognozarea unui program pe termen lung. Viteza medie se calculează prin însumarea măsurătorilor de viteză din ultimele trei iterații ale echipei și împărțirea acestui total la trei. Astfel, dacă o echipă a realizat 15 puncte în prima iterație și 20 de puncte în fiecare dintre cele două iterații ulterioare, viteza medie a echipei este 18 (15+20+20+20 / 3). Dacă o echipă poate realiza în medie 18 puncte într-o iterație și există 144 de puncte de lucru în valoare de 144 de puncte care trebuie finalizate în cadrul proiectului, echipa va avea nevoie de opt iterații pentru a finaliza munca (144 / 18). Dacă fiecare iterație are o durată de două săptămâni, atunci finalizarea preconizată este de 16 săptămâni. Această metodă ne permite să răspundem la întrebarea: „Când vom termina toată această muncă?”

Dacă echipa are un istoric de date privind viteza, este posibil să se determine cea mai optimistă dată de finalizare, cea mai pesimistă și cea mai probabilă. Numărul mediu de viteză al echipei este utilizat pentru a calcula scenariul cel mai probabil, în timp ce numerele de viteză de la iterațiile cu cele mai slabe performanțe ale echipei sunt utilizate pentru a calcula data de finalizare prognozată cea mai pesimistă. Utilizarea vitezei de la iterațiile în care echipa a reușit să finalizeze mai mult decât se aștepta oferă cea mai optimistă prognoză.

De asemenea, putem folosi aceste numere pentru a răspunde la întrebarea: „Trebuie să livrăm ceva până la această dată – din aceste caracteristici, câte vom fi realizat până atunci?”. A se vedea figura 6 pentru un exemplu de prognoză a cantității cele mai probabile de realizat, prognoza pesimistă și prognoza optimistă. Acest exemplu este pentru o echipă a cărei viteză medie este de 20 și care are o viteză de cea mai proastă performanță de 12 și o viteză de cea mai bună performanță de 25. Având în vedere acest lucru și doar șase săptămâni (trei iterații), cât de mult poate fi finalizat? Previziunea pesimistă este că doar elementele 1-8 vor fi realizate în șase săptămâni. Prognoza optimistă este că elementele 1-18 vor fi finalizate. Iar cea mai probabilă prognoză, bazată pe viteza medie a echipei de 20, este că elementele 1-13 vor fi finalizate în șase săptămâni.

Dacă echipele foloseau unități de estimare non-numerice, cum ar fi dimensiunile tricourilor, algoritmii de prognoză vor fi mai complecși. Se recomandă ca dimensiunile să fie convertite într-un sistem numeric pentru a genera mai ușor date similare. De exemplu, un Small ar putea fi convertit într-o NUT de 3, un Medium într-o NUT de 5 și așa mai departe. Acestea pot fi, de asemenea, convertite în intervale de timp (un Small ar putea fi de 1-3 zile, de exemplu), dar acest lucru este în mod inerent riscant, din cauza problemelor deja citate în secțiunea Unități de estimare.

Determinarea bugetului

În această secțiune ne uităm la răspunsul la întrebarea: „Avem doar atât de mulți bani – cât timp vor dura și cât de mult vom termina înainte de a se termina?”. În primul rând, se folosește o formulă simplă pentru a determina costul pe punct:

Σ (salariile încărcate ale echipei pentru perioada n) / puncte finalizate în perioada n

Se ia suma salariilor echipei (încărcate) pentru o perioadă de timp, să zicem trei iterații de două săptămâni, și se împarte la numărul de puncte pe care echipa le-a finalizat în același interval de timp. Astfel, o echipă ale cărei salarii totale încărcate sunt de 240.000 de dolari în șase săptămâni și care a finalizat 60 de puncte de lucru în cele trei iterații ar avea un cost pe punct de 4.000 de dolari. Acum folosiți următoarea formulă pentru a determina bugetul:

(Costul pe punct x valoarea totală a punctelor care trebuie finalizate) + alte cheltuieli = buget previzionat

De foarte multe ori, nu toate caracteristicile unui produs sunt definite la începutul unui proiect, ceea ce este de așteptat pentru proiectele agile. Așadar, estimările bugetare se bazează pe ceea ce știm astăzi, plus un algoritm de prognoză care se bazează pe date istorice sau pe îndrumarea experților. De exemplu, să spunem că există doar 20 de caracteristici listate până în prezent, dar afacerea nu va fi în măsură să furnizeze solicitări de caracteristici suplimentare sau îmbunătățiri decât după ce va vedea cum este primită prima versiune de către client. Bugetul proiectului, care este prevăzut pentru trei versiuni, ar avea la dispoziție doar date de prognoză pentru prima versiune și nu pentru întregul proiect. Echipa ar putea folosi algoritmul de mai sus pentru a prognoza bugetul pentru prima versiune, apoi să presupună un plus de 20% pentru a doua versiune și un plus de 5% pentru ultima versiune, pe baza experienței anterioare.

Ca și viteza, previziunile de buget și previziunile de program sunt revizuite la fiecare iterație. Acest lucru face parte din procesul de planificare în valuri rulante la care aderă proiectele agile.

Cuvinte finale

În mod notabil, neacoperită în această lucrare este lipsa tehnicilor de estimare structurate utilizate în abordările lean, cum ar fi Kanban. În loc de a petrece (pierde) timp estimând elemente, timpii medii de ciclu și de execuție sunt calculați pe baza ratelor reale de producție ale echipei. Kanban utilizează teorema matematică Legea lui Little ca bază pentru formulele lor. Utilizând calculele privind timpii de execuție derivate din diagramele de flux cumulative, echipele previzionează calendarele proiectelor fără a cheltui timp în avans pentru a pregăti estimări. Cititorul este încurajat să facă cercetări independente pe această temă, care ar putea constitui o lucrare separată de sine stătătoare.

Proiectele agile au ca scop livrarea unui produs sau a unor creșteri de produs devreme și des, pentru a încorpora feedback-ul clienților și alte învățăminte în următoarea versiune. Petrecând mai mult timp pentru a experimenta, a executa și a învăța, și mai puțin timp pentru speculații, durata ciclului de livrare este redusă. Echipele agile sunt mai în măsură să concureze pe piață și să țină pasul cu viteza tot mai mare a schimbării.

.