Iuliana Boca 
Cristina Brădescu În era tehnologiei și a inovației, apare automat nevoia de a fi predictibili și de a măsura cât mai precis performanța, totul cu scopul de a deveni mai buni și competitivi într-o piață care este în continuă schimbare și în care dezvoltarea de produse software trebuie să fie agilă și adaptabilă. În cadrul multor proiecte identificăm nevoia de a crea o nouă echipă, care să dezvolte proiectul și să-l livreze cu succes. Astfel, ajungem la întrebarea: "Când putem să livrăm proiectul?". Pentru echipele nou formate, care încep să lucreze într-un cadru Agile Scrum, a avea o predictibilitate în procesul de dezvoltare este crucial pentru succesul acestora.
Provocarea unei astfel de echipe este lipsa unei experiențe comune de lucru (din punctul de vedere al software developmentului) și a unor date anterioare pe care să se bazeze. Vom descoperi împreună, pe parcursul articolului, cum pot fi depășite aceste provocări.
Într-o echipă nou formată există avantaje și dezavantaje, ce pot influența livrarea cu succes a proiectului. Dintre avantaje putem enumera: entuziasmul, voința de a învață lucruri noi și de a socializa, iar ca dezavantaje menționăm: predictibilitatea scăzută, lipsa datelor legate de progresul/performanța echipei, sentimentul de a nu fi integrat în echipă și, câteodată, chiar și anxietate. Nivelurile diferite de expertiză și de cunoștințe tehnice pot reprezenta atât un avantaj, cât și un dezavantaj.
În general, primul sprint are ca scop solidificarea bazelor prin care vom implementa o strategie. Acum este momentul să învățăm despre viziunea și scopul proiectului și facem pregătirile necesare pentru a începe implementarea.
Astfel, ajungem să discutăm despre Definition of Done și stabilim prin Reference Story Points, efortul sau complexitatea, regăsite de către fiecare coleg din echipă pentru 1, 2, 3, 5, 8, 13 Story Points. Vom vizita valorile alese după o lună, pentru a adăuga mai multă informație relevantă și în concordanță cu proiectul curent.
Product Ownerul va avea deja pregătit un Backlog prioritizat în funcție de claritatea cerințelor, de sus în jos, pornind de la specificații mai detaliate, până la specificații mai puțin cunoscute.
Prima estimare pentru data livrării se poate stabili prin tehnica T-shirt sizing, tehnică des întâlnită la începutul proiectului, când sunt puține date și detalii cunoscute sau stabilite. Astfel, identificăm o dată de livrare probabilă, care este mai puțin precisă.
Acesta este punctul de pornire în care analizăm ca echipă dacă suntem predictibili și ne putem încadra în timpul stabilit.
Totuși, încă nu avem certitudinea unui termen limită pentru finalizarea proiectului. Pentru a avea o părere mai informată va trebui să parcurgem niște pași suplimentari și să adunăm date din următoarele iterații. Mai întâi, să vedem ce înseamnă de fapt forecast și de ce avem nevoie de acesta.
Forecast (în română - prognoză): este un calcul bazat pe date, realizat pentru a ști în avans anumite detalii sau aspecte. În software development, acest termen se referă la procesul de estimare a timpului sau a efortului necesar pentru a finaliza anumite sarcini sau funcționalități în cadrul mai multor Sprinturi.
Dacă în Sprintul 1 ne-am concentrat mai mult pe arhitectură, infrastructură și pe alinierea echipei la scop, în Sprintul 2 ne orientăm atenția asupra împărțirii Backlogului în PBIs (Product Backlog Items) relativ egale, cu un Acceptance Criteria mai sumarizat. Obiectivul este de a ne pregăti datele, prin aflarea numărului total de PBIs și a utiliza ulterior tehnica de forecasting Monte Carlo.
Ne aflăm acum în Sprintul 3 și considerăm că este un moment oportun să încercăm primul forecast. Chiar dacă nu avem toate datele necesare, iar în trei Sprinturi nu am obținut un velocity echilibrat, considerăm că ne aflăm într-un moment potrivit pentru a observa unde ne situăm. Prin simulările obținute cu tehnica Monte Carlo, putem afla mai multe perspective: optimiste, realiste sau pesimiste asupra termenului de livrare.
Metoda Monte Carlo se bazează pe un model folosit pentru a prezice probabilitatea mai multor rezultate și se concentrează asupra variabilelor care sunt incerte. Variabilelor incerte le sunt atribuite valori aleatorii în rânduri repetate, obținându-se astfel un rezultat/o probabilitate. După mai multe rulări ale modelului, media acestor rezultate reprezintă prognoza finală.
Partea esențială a tehnicii Monte Carlo constă în definirea precisă a scopului, ce va fi inclus în termenul de livrare, acesta fiind stabilit de către echipa Scrum și Product Owner în primele Sprinturi.
Strângerea de date pentru echipă constă în a urmări câte taskuri (nr. exact de cerințe) au fost realizate în primele trei Sprinturi.
Bazat pe numărul de taskuri finalizate în fiecare Sprint de până acum și introducerea numărului total de Sprinturi, tehnica ne prezintă ce număr de taskuri este nevoie să livrăm în fiecare dintre Sprinturile rămase, astfel încât să reușim finalizarea întregului Backlog.
Fig.1 - Nivelurile de încredere
Cu aceste informații, putem analiza, ca echipă, dacă ne încadrăm în termenul setat de livrare sau dacă este necesară prelungirea acestuia.
În tabelul de mai sus (Figura 1), regăsim pe fiecare rând o perspectivă nouă asupra livrării indicând următoarele:
Percent Chance: Nivelul încrederii asupra livrării numărului total de taskuri;
Bet: Tipul perspectivei;
Sprint Story Count: Media numărului de taskuri care ar putea fi îndeplinite cu fiecare iterație.
Exemplu: Ca echipă, suntem 80% siguri că vom reuși să livrăm un total de 132 de taskuri în timpul stabilit. Astfel, în fiecare iterație este probabil să finalizăm, în medie, câte 17 taskuri.
În dreapta tabelului (Figura 2), observăm histograma care afișează distribuția numărului total de taskuri. Acest grafic este generat pe baza rezultatelor simulării Monte Carlo și oferă o reprezentare vizuală a probabilității unor intervale specifice.
Fig.2 - Histogramă cu numărul de simulări realizate prin tehnica Monte Carlo
Fiind vorba de o echipă nou formată, trebuie să conștientizăm că nu avem multe date istorice pe care ne putem baza, astfel predictibilitatea oferită de această tehnică (Monte Carlo) nu are o precizie absolută.
Totuși, un avantaj adus de către această tehnică este faptul că oferă un punct de pornire și stârnește conversații valoroase. Astfel, în cadrul Sprinturilor viitoare, echipa va reface simularea prin noile date obținute și își va reanaliza progresul, pentru a determina eficiența actuală în raport cu obținerea scopului stabilit.
Cu ajutorul noilor date generate și prin explorarea unor asumpții diverse, încercăm optimizarea planului, prin adaptarea/simplificarea scopului, mărirea echipei sau negocierea unui nou termen de livrare. Simulările ne ajută să identificăm și să rezolvăm riscurile în timp util.
Toate informațiile pe care le adunăm cu ajutorul simulării Monte Carlo vor fi prezentate echipei și stakeholderilor. În timpul Sprint Review-ului, inspectăm și analizăm noile date, pentru a obține o transparență crescută în echipă și a spori implicarea acesteia în cadrul proiectului.
În mediul online există o multitudine de informații și instrumente, care calculează aceste simulări, folosind algoritmul Monte Carlo. Aceste simulări pot fi calculate prin două moduri: fie folosind ca date de intrare Story Points (velocitatea echipei pentru fiecare Sprint) sau Story Count (numărul total de taskuri finalizate în fiecare Sprint). Sugestie: pentru a observa Monte Carlo în acțiune, încurajăm realizarea unei comparații Story Points vs. Story Count vs. metoda pe care ați folosit-o până acum pe un proiect deja finalizat.
Alături de metoda Monte Carlo, regăsim și alte practici/abordări pentru îmbunătățirea imaginii de ansamblu a livrării, precum facilitarea unei sesiuni Pre-mortem, care poate exista în cadrul unui Sprint Retrospective. În cadrul acestei sesiuni, echipa va identifica toate riscurile și obstacolele ce ar putea genera o direcție greșită. Alături de stakeholderi, prioritizăm riscurile identificate, căutăm soluții și facem anumiți pași pentru prevenirea acestora. Astfel, este realizat un plan, ce poate fi revizitat cu ocazia următoarelor Sprint Retrospectives.
Fig.3
Pe măsură ce proiectul și Backlogul se dezvoltă, iar echipa estimează tot mai mult din taskurile rămase, ne putem folosi și de predicțiile deja existente în raportul din Jira - Version Report (Figura 3). Acest raport nu are în spate metoda Monte Carlo, ci se bazează pe media zilnică a velocității și a numărului total de Story Points pentru taskurile nefinalizate. Acest instrument vine în completare și ne ajută să conturăm mai bine data livrării.
Indiferent de combinația practicilor alese, este esențial să le continuăm cu fiecare iterație. Finalurile de Sprint aduc date noi, care vor contura un rezultat din ce în ce mai precis/exact. Unul dintre scopurile ceremoniei Sprint Review este să apreciem unde ne situăm în raport cu termenul de livrare - continuous forecasting.
În încheiere, subliniem faptul că nici unul dintre instrumentele menționate mai sus nu aduc rezultatele dorite și că nimic nu ar fi posibil fără o echipă bine închegată, comunicativă și care are la bază încrederea.
Oricât de atractive și performante ar părea aceste metode, ele nu înlocuiesc integritatea unei echipe eficiente și ambiția comună de a îndeplini scopul stabilit. Prin folosirea acestor metode, echipele Agile pot explora potențialul lor ascuns, prin experimentarea dinamicii de lucru și a capacității de adaptabilitate.
Stay agile and passionate about what you do!
de Nóra Dobre
