În continuarea articolului „În grafic”.
Când Corneluș avea 3 anișori, am construit un zid din lego și l-am rugat să-mi spună cât este de mare. Mi-a răspuns că zidul este cât el de mare. În altă zi am construit un zid mai mic și l-am întrebat din nou. Primul răspuns a fost doar că e un zid mare. Am repetat întrebarea, și mi-a spus că-i cât camionul de mare. De notat că până la acea vârstă, tot jucându-ne de-a matematica, Corneluș știa să numere binișor – parcă până la 30. Astfel, în altă zi am numărat piesele de lego cu voce tare, încercând să-i influențez modul în care ar putea răspunde la întrebare. Am spus că pentru mine este atât de mare cât numărul de piese. Am mai scos două piese subliniind că acum zidul este mai mic având cu două piese mai puțin, și tot așa. Degeaba. Când i-a venit rândul să estimeze, tot raportându-se la altceva a făcut-o. Se pare că lui Corneluș îi este mult mai simplu și mai natural să estimeze relativ la altceva.
Am fost solicitat să ajut o echipă care părea să aibă dificultăți cu estimările. Ca de fiecare dată, problema evocată s-a dovedit a fi paravanul multor alte nereguli:
- Așa numitele User story-uri erau de fapt și de drept niște dorințe tehnice,
- Puținele User Story-uri care aveau legătură cu cerințele funcționale nu corespundeau criteriilor INVEST,
- Iterațiile conțineau mini-cicluri în cascadă (waterfall),
- Exista o definiție a unei cerințe finalizate, dar nu era respectată,
- etc.
Să revenim însă la chestiunea estimărilor. Echipa le făcea deja în puncte relative, sau story points, pe 6 categorii de efort: 1,2,3,5,8,13. În sprintul în curs aveau 5 User Story-uri estimate astfel:
| Cerința | Puncte relative |
|---|---|
| User Story 1 | 13 |
| User Story 2 | 13 |
| User Story 3 | 13 |
| User Story 4 | 8 |
| User Story 5 | 8 |
Experiența îmi spunea că ar fi ales 100 pentru fiecare User Story dacă aveau opțiunea.
…
– Eu nu văd sensul la planning poker-ul ăsta, îmi spune Scrum Master-ul echipei.
– Nu jocul în sine contează cel mai mult. Care parte ți se pare mai ciudată? Estimarea în grup, estimarea în puncte relative sau ideea pachetului de cărți?
– Cred că partea cu estimările relative. Nouă ne e totuna. Oricum ne gândim la zile sau ore.
– Mai bine luăm un exemplu. Să zicem că ai o cerință X și întrebi programatorii care este efortul de implementare. Primul îți va răspunde 3 zile, iar cel de-al doilea 6 zile. Culmea că cele două estimări s-au adeverit a fi realiste. De unde crezi că vine diferența?
– Unul era mai experimentat decât celălalt.
– Bun. Dar dacă le ceri să-ți dea efortul de implementare față de cerința Y – o experiență comună – și ambii agrează că efortul de finalizare este de două ori mai mare?
– Are sens.
– Discuțiile menite să decidă care din valorile absolute este estimarea corectă, 3 zile sau 6 zile, pot fi inutile dacă diferențele vin din abilitățile și experiența individuală.
…
Mi-au trecut foarte multe simulări de proiecte prin fața ochilor, și de fiecare dată când văd presupuneri de genul:
| Cerința | Efort estimat în ore |
|---|---|
| Cerința 1 | 3 |
| Cerința 2 | 2,5 |
| Cerința 3 | 1,5 |
| Cerința 4 | 8 |
| Cerința 5 | 30 |
| Cerința 6 | 4.5 |
și știind că oamenii nu sunt capabili să facă estimări la un astfel de nivel de precizie, mă întreb dacă este e vorba de o minune sau pur și simplu estimatorul și-a pierdut din nou concentrarea. Dacă totul este atât de relativ în lumea aceasta, poate că n-are sens să ne batem capul estimând efortul atât de precis, în valori absolute de ore sau zile, efort care oricum este doar cea mai bună presupunere a noastră ținând cont de ipotezele date. 
Estimări în valori absolute sau relative? – Găsiți mai multe detalii despre Cornel Fătulescu în categoria despre mine sau la pagina de contact.
Dacă doriți să aflați mai multe despre mine, Cornel Fătulescu, sau proiectele în care sunt implicat, vă invit să mă descoperiți și ca Chief Platform Officer la Pentalog, să mă urmăriți pe Facebook, ca investitor la wanttolearn, să citiți unul dintre primele articole despre mine și să mă contactați urmând ghidul de pe pagina de contact.
Acest articol a fost citit de 5256 ori