Estimări vs. agilitate
Cum împăcăm și capra și varza, sau cum păstrăm agilitatea fără să aruncăm în aer bugete și deadlines
Cred că una dintre cele mai dificile momente la începutul unui sprint, sau al unui deliverable este acela al estimărilor. Am lucrat atât în proiecte care adoptau procese ”agile” cât și în echipe cu waterfall sau pe cont propriu ca freelancer, unde nu prea ai ce tehnică să adopți. Dar în majoritatea cazurilor, cu câteva excepții notabile - când am fost implicat în echipe de produs, am fost în situația de a da estimări.
Eu mă poziționez împotriva estimărilor: cum să știi cât o să dureze ceva ce nu ai făcut niciodată? Acel modul sau feature va fi creat, fie cu ajutorul unor librării sau alte module, însă dacă ți-e dat să-l faci, e pentru că nu există ceva identic. În concluzie orice estimare de timp va fi o încercare de a prevedea viitorul - un exercițiu riscant ținând cont de faptul că de previziune depinde bugetul. Plus că sunt atâtea variabile: poate ești nevoit să îți iei concediu, sau poate îți dai seama că ai nevoie de mult mai mult timp, dar asta după ce ai început implementarea, și s-a scurs deja jumătate din timpul alocat.
#Deadlines
O altă problemă, mai ales pentru echipele agile, este că estimările se transformă în deadlines. Nu de puține ori mi s-a întâmplat să dau o estimare și apoi data respectivă să apară într-un comunicat de presă, sau toată compania să afle că din data X vor avea gata respectivul modul, sau să se felicite pentru această reușită. În aceste cazuri, mai ales pentru juniori este foarte greu să dea estimări - deoarece au puțină experiență pe proiect nu vor reuși să livreze în același timp ca un senior, și de multe ori vor fi puși în situația de a da estimări mai mici, pentru că un coleg senior este de altă părere. Sau juniorii vor primi întodeauna task-uri ușoare, pentru a se înscrie în sprint, ratând astfel oportunitatea de a învăța și a deveni mai experimentați pe proiect.
Desigur, pe termen lung, echipa va deveni mai rigidă, mai puțin dispusă să-și asume riscuri și condusă mai degrabă de aceste deadline-uri. Pentru că cine se înscrie în estimare, este văzut ca un performer în ochii managerilor.
#NoEstimates
Allen Holub1 susținea această cauză - dacă estimările nu se respectă, ce rost mai are să le dăm? Agile, nu este un proces dependent de timp, și de mult ori estimările au de fapt rolul de a stabili direct costurile clientului, ceea ce îi face pe manageri să fie obsedați de durată mai degrabă decât de rezultat. Iar aici este un conflict: devreme ce managerul dorește să știe cât îl costă un modul, pe mine ca inginer mă pasionează să livrez în producție acel modul - adică rezultatul este acel moment în viitor când am trecut de toate fazele pentru livrare în mediul de producție: arhitectură, inventariere cerințe și dependințe, evaluarea implementării inițiale, testarea și demonstrație. Fiecare dintre acești pași va necesita o bucată de timp, și de cele mai multe ori depind de alți colegi să poată fi duse la bun sfârșit. Mă pregătesc pentru acel moment din viitor, când voi putea livra modulul, însă când va fi acel moment este foarte greu de stabilit. E similar cu a cere unei persoane care tocmai a început cursurile de înot, cât timp îi ia până să înoate în mare.
Se poate agile fără estimări!? Da se poate, și o să revin asupra subiectului într-un articol viitor. Însă acum o să dezbat problema estimărilor, atunci când sunt necesare:
#Bugete - dar de timp
Din păcate, în multe situații nu putem aplica sfatul lui Allen Holub, și să renunțăm la estimări. De exemplu, dacă ești freelancer clientul îți va cere un buget, și vei fi nevoit să îți faci un calcul de timp. La fel și la modelul Time and Material, practicat în companiile de outsourcing. Clientul se așteaptă să știe, orientativ, cât va costa implementarea.
Dar, în același timp dorim să reducem presiunea și pericolul ca estimările să se transforme în deadlines, mai ales pentru juniori sau teams leads care vor fi puși în situația de a-i ajuta pe colegi în cazul în care au dificultâți de a se încadra în sprint.
O metodă pe care am aplicat-o cu succes, este aceea de a crea bugete de timp, adică îți rezervi un număr de ore/zile pentru un anumit task. Dar nu numai că indici acest lucru în sistemul de tracking cu story points de exemplu, ci și pontezi sau pui acel timp în avans pentru acel task. Această simplă operație, mă face să mă concentrez mai ușor, pentru că nu mai am grija duratei - timpul e deja alocat.
Apoi dacă azi am bugetat timp pentru un modul din acest sprint, atunci orice alte întâlniri sau task-uri la care le voi acorda timp în sprint, le voi ponta separat și îmi voi da seama imediat dacă aceste extra task-uri depășesc capacitatea rezervată de mine sau nu. Îmi va fi mai ușor să comunic timpul pe care îl pot aloca meeting-urilor sau suportului pentru colegi. Și aceste interacțiuni sunt foarte importante, pentru a fi eficace fiecare coleg din echipă va avea nevoie de timp rezervat pentru ele.
Desigur, dacă a luat mai puțin, la sfârșit poți corecta pontajul să reflecte timpul efectiv, dar aceste corecturi se fac oricum la estimări.
O altă mențiune importantă, pentru bugetele de timp, este să nu rezervi timp pentru task-uri pe care nu le iei tu, deci fiecare coleg decide de cât timp are nevoie. Și se evită bugetarea de timp pentru task-uri care nu sunt începute în sprint. Pe principiul dacă nu este important atunci nu se estimează.
Eu folosesc de aproape un an tehnica bugetelor de timp. De multe ori este combinată cu story points și se complementează chiar bine, deoarece evităm confuzia dintre dificulate și durată. Sper că îi ajută și pe cei care fac freelancing, pentru că poate fi dificil să jonglezi cu mai mulți clienți, unde estimările influențează în mod direct bugetele clienților.
(c) Photo by Jason Goodman on Unsplash