Estimarea în proiectele Agile este un subiect controversat și parte a unei dezbateri nesfârșite. O bună parte dintre cei care activează în diverse echipe de proiect nu înțeleg de ce anume avem nevoie de o abordare diferită în estimare. De ce estimarea în timp (și eventual în valoarea în bani asociată acestui timp) nu este una potrivită într-un context agil. De-a lungul timpul s-a vorbit de tehnici și instrumente tot mai sofisticate sau chiar exotice, începând cu binecunoscutele Story Points, T-shirt Sizes, Planning Poker sau Estimarea prin Afinitatea și continuând cu mult mai neobișnuitele Puncte Zoo sau #noestimates. În continuare nu este însă clar cum ar trebui să le integrăm în viața unei echipe Agile, care este valoarea pe care acestea o aduc unei astfel de echipe și cum afectează ele modul în care comunicăm clientului planul și progresul proiectului.
Voi încerca să aduc puțină lumină legat de acest subiect, începând prin a sublinia diferența majoră dintre proiectele predictive și cele adaptive.
Proiectele predictive sunt în general proiecte complicate, care necesită expertiză și experiență în domeniul proiectului, dar care sunt relativ predictibile. Evident, există elemente de unicitate care induc anumite incertitudini, incertitudini ce ulterior se pot reflecta prin concretizarea unor riscuri care se materializează în timpul derulării proiectelor. Cu toate acestea, așteptările sunt că o bună parte dintre specificațiile acestor proiecte sunt cunoscute și clarificate înainte de începerea execuției proiectului, și că ele nu se modifică în timpul execuției. Mai mult, nivelul de experiență și maturitate al echipei de proiect îi permite acesteia să identifice o bună parte din factorii de risc, minimizând numărul de potențiale riscuri imprevizibile (așa-numitele unknown unknowns) și care face echipa să fie mai pregătită în contracararea neprevăzutului.
Pe de altă parte, proiectele adaptive sunt caracterizate, în general, de cele patru componente ale termenului VUCA (VUCA este un acronym pentru Volatility, Uncertainty, Complexity, Ambiguity): specificațiile sunt adesea vagi sau ambigue, ne așteptăm la modificări (chiar majore) în timpul execuției proiectului, nivelul de complexitate este unul ridicat iar probabilitatea apariției unor riscuri neprevăzute este, în general, mare. Într-un astfel de context este necesar ca echipa de proiect să valideze mereu direcția spre care se îndreaptă dezvoltarea produsului și să ajusteze cât mai repede această direcție în funcție de feedback-ul primit.
La începutul carierei mele de programator categoria proiectelor adaptive nu exista. Sau, mai bine zis, nu ne doream să existe. Atitudinea obișnuită relativ la aceste proiecte era ca acestea fie să fie respinse ca nefezabile, nivelul de risc fiind considerat unul mult prea ridicat, sau să fie acceptate sub constrângerea că toate neclaritățile se vor lămuri cât mai curând posibil, în fazele incipiente ale proiectului. Iar când acest lucru nu se întâmpla, un astfel de proiect era sortit eșecului în cele mai multe cazuri.
Motivul pentru care se întâmpla acest lucru era acela că aveam o imagine foarte rigidă asupra modului cum ar trebui abordat un proiect, imagine dată de waterfall, cel mai popular mod de abordare al proiectelor de atunci.
Între timp însă percepția asupra a ceea ce este un proiect s-a schimbat mult, iar Manifestul Agile a avut rolul său în tot acest proces. Astăzi știm că a doua categorie de proiecte este una foarte importantă în tot mai multe industrii, iar un mod de abordare agil, bazat pe cicluri experimentale repetate, reprezintă un mod de abordare eficient al acestora.
Acest mod diferit de abordare vizează, evident, și estimarea. Tehnici de estimare care funcționează acceptabil într-un mediu predictiv/complicat nu au cum să dea rezultate satisfăcătoare într-un mediu VUCA. Iată de ce estimarea parametrică sau cea în trei puncte au fost treptat înlocuite cu estimările prin afinitate sau folosind puncte abstracte.
Există patru diferențe remarcabile între modul în care se realizează estimarea în proiectele predictive și cele adaptive. Le voi enunța pe rând și explica pe scurt în cele ce urmează.
Individual vs colectiv
În proiectele predictive măsurăm progresul în număr de task-uri finalizate. Prin urmare ne interesează cât ar putea dura un task, iar cel care ne poate da cea mai bună estimare cu privire la această durată este exact cel care urmează să execute acel task. Pe baza experienței pe care o are respectiva persoană valoarea, dar și eroarea estimării pot varia considerabil, însă e puțin probabil că altcineva s-ar putea descurca mai bine decât ea însăși în a estima ce poate face.
În proiectele adaptive măsurăm progresul prin funcționalități finalizate cap coadă (așa numitele felii verticale). Nevoia continuă de validare impune acest mod de abordare. O funcționalitate, însă, nu este mai niciodată implementată de o singură persoană, ea fiind descompusă în task-uri ce necesită expertize sau specializări diferite. Acest aspect, alături de complexitatea ridicată a funcționalităților, induc faptul că mai multe opinii și puncte de vedere diferite, venite de la toți membri echipei, să influențeze pozitiv calitatea estimării.
În proiectele adaptive nu este o idee bună ca funcționalitățile/feliile verticale ale unui produs să fie analizate și estimate în izolare. Estimarea relativă, prin comparație cu funcționalități deja estimate, face ca viteza de estimare să crească fără a avea impact asupra acurateții estimării.
Un exemplu pe care îl folosesc des și pe care l-am preluat de la Mike Cohn este cazul estimării cantității de lichid dintr-o cană: ne va fi mai greu și eroarea de estimare va fi mai mare dacă vom încerca să estimăm numărul de mililitri de lichid. În același timp, dacă comparăm cu lichidul aflat într-o altă cană, ne este mult mai ușor să spunem în care e mai mult și în care mai puțin lichid, și asta fără a avea în mod necesar cine știe ce experiență.
Am ajuns și la story points! Pentru proiectele complexe/adaptive se consideră că estimările de timp au, în general, o acuratețe redusă. Un concept mai abstract care să includă atât timpul cât și experiența, nivelul de complexitate, nivelul de risc sau incertitudinea este mult mai potrivit. Astfel, secvența Fibonacci, T-shirt sizes sau punctele Zoo nu fac decât să ordoneze funcționalitățile relativ la efortul necesar de a le finaliza.
Din nou, folosirea punctelor, de exemplu, simplifică modul de estimare și face ca persoanele implicate în estimare să cadă mult mai ușor de acord. De exemplu, două persoane cu experiențe diferite nu vor cădea de acord asupra timpului de execuție a mai multor task-uri, dar vor agrea mai ușor care dintre ele e cel mai simplu (deci e de un punct) și care ar fi de două ori mai dificil (deci e de 2 puncte) etc.
În paragrafele anterioare am folosit deseori termenul de acuratețe când am caracterizat estimarea și m-am ferit să folosesc atributul "precis". Iar acest lucru se datorează faptului că precizia estimărilor este foarte apreciată într-un context predictiv (desigur, ar fi apreciată și într-un context adaptiv însă este absurd să ne străduim să atingem un nivel de precizie ridicat în condiții de incertitudine, ambiguitate și volatilitate ridicate).
De aceea, majoritatea tehnicilor de estimare Agile urmăresc atingerea unui nivel de acuratețe ridicat într-un timp cât mai scurt, rezultatul fiind deseori exprimat sub formă de interval. Intervalul acesta este mai larg la începutul proiectului și scade gradual pe măsură ce avansăm în proiect, istoricul contribuind substanțial la creșterea predictibilității.
Un foarte bun mod de a vă convinge de utilitatea tehnicilor de estimare Agile în proiecte complexe este să utilizați un joc pe care l-am creat special în acest scop alături de colegii de la Colors in Projects. Jocul se numește Colors Affinity Estimation și folosește culori și aria acoperită de acestea pentru a demonstra beneficiile estimărilor relative și colective.
Jucătorii vor simula astfel pașii pe care îi urmează de obicei o echipă agilă în estimarea de user stories, doar că estimarea va viza culori distincte în loc de incertitudine, complexitate sau timp, fiind un foarte bun instrument de înțelegere comună a conceptelor specifice estimărilor Agile.
Estimarea în proiectele Agile rămâne un subiect dezbătut intens, dar este evident că tehnicile tradiționale de estimare nu funcționează bine într-un mediu caracterizat de incertitudine și complexitate. Pe măsură ce industriile adoptă tot mai mult metodologiile Agile, înțelegerea și utilizarea tehnicilor de estimare adaptate pentru aceste proiecte devine esențială.
Abordările de estimare relativă, colectivă și abstractă sunt mult mai potrivite pentru proiectele adaptive. Ele oferă o acuratețe mai bună în condiții de ambiguitate și incertitudine, permițând echipelor să ajusteze rapid estimările și să ofere un progres mai clar. Tehnici, precum Story Points sau Estimarea prin Afinitate, sunt extrem de valoroase pentru a naviga provocările unui mediu VUCA.
Jocuri, precum Colors Affinity Estimation, pot ajuta echipele să înțeleagă mai bine beneficiile estimărilor Agile și să dezvolte o abordare comună, facilitând colaborarea și progresul. Aceasta dovedește că estimarea în Agile nu trebuie să fie complicată, ci doar să fie flexibilă, eficientă și să reflecte realitatea unui proiect adaptiv.
Agile Craftsmanship
joi, 24 Octombrie, ora 18:30
Colors in Projects (București)
Facebook Meetup StreamEvent YouTubeAgile Leadership &
Ways of Working
miercuri, 30 Octombrie, ora 18:00
ING Hubs Romania (Cluj)
Facebook Meetup StreamEvent YouTubede Ovidiu Mățan
