ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 149
Numărul 148 Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 68
Abonament PDF

Estimări în Scrum: un mic efort. O altă perspectivă.

Daniela Stuparu
Scrum Master @ SDL Language Technology



MANAGEMENT


"A key tenet of Agile estimating and planning is that we estimate size, but derive duration."  - Mike Cohn, Agile Estimating and Planning

Despre estimări s-a discutat intens și se discută mult în continuare. Probabil tuturor ni s-a cerut la un moment dat să apreciem efortul necesar pentru o anumită activitate. Este în natura noastră să ne estimăm activitățile de zi cu zi, iar Scrum-ul nu face excepție.

Estimările reprezintă o parte importantă a acestui proces, fiindcă o mare parte a deciziilor luate la ședințele de planning se bazează pe acestea. Ar trebui să privim estimările ca un ajutor în a ne realiza un plan și în a ne măsura progresul în raport cu acest plan. Cu cât ne îndepărtăm mai mult de această idee, cu atât vom pierde încrederea stakeholderilor și a Product Ownerului, ceea ce este de nedorit.

Pentru cei familiarizați cu textele homerice sau cu tragedia greacă, legenda Casandrei, profeta menită să spună adevărul, prezintă cel mai bine "capcana" în care putem cădea dacă încercăm o abordare perfecționistă a estimărilor. Pe scurt, legenda povestește despre Casandra, care a primit darul profeției de la zeul Apollo, însă nu și darul persuasiunii; cu alte cuvinte, oricât de bine ar fi prevăzut viitorul, nimeni nu credea în profețiile Casandrei și în avertismentele ei. Deci, Scrum Teams, don't become like Casandra!

Pentru a evita astfel de situații, nu uitați că, atunci când ni se cere să estimăm, scopul urmărit este de a avea o marjă cât mai mică de eroare și de a fi cât mai previzibili în contextul Scrum. Estimarea este un instrument al ECHIPEI, iar tehnicile de estimare sunt bazate pe colaborare. Trebuie să includem întreaga echipă în acest proces de estimare a efortului pentru product backlog items.

Atenție mare, însă! Estimarea și angajamentul sunt două lucruri total diferite. Gândiți-vă, spre exemplu, la drumul către casă. Dacă ați fi întrebați la ce oră apreciați că ajungeți acasă într-o după-amiază și răspundeți, de pildă, cu ora 18:30, aceasta nu înseamnă că v-ați luat angajamentul ca la ora respectivă să ajungeți. Nu lăsați estimările să devină angajamente. Amintiți-vă întotdeauna să faceți distincție între cele două concepte.

Pentru început, doresc să prezint trei dintre cele mai folosite tehnici de estimare în Agile:

Planning Poker

Planning Poker rămâne cea mai cunoscută și cea mai utilizată tehnică de estimare. Aceasta presupune folosirea de către participanți a unui set special de cărți, reprezentând numerele din șirul lui Fibonacci, pentru a vota estimările. Este recomandată pentru un număr mic de user stories și generează discuții în care fiecare membru al echipei trebuie să își argumenteze estimarea. Votul se repetă până când există unanimitate.

Adeseori, alegem șirul lui Fibonacci pentru a reflecta incertitudinea în estimarea elementelor mai mari, iar folosirea lui ne ajută să recunoaștem această incertitudine și să ajungem la o velocitate stabilă. Dar nu este obligatoriu să folosim valori numerice. Există situații în care utilizarea unor valori non-numerice poate ajuta echipele să estimeze mult mai exact. Pe de altă parte, o astfel de abordare poate duce și la apariția unor situații:

Estimarea relativă (Relative Estimation)

Dacă am întreba echipa cât de mare este un item și cât de mare este altul, vom obține probabil un răspuns inconsistent. Estimarea relativă se bazează pe reformularea acestei întrebări și cere echipei să compare cele două itemuri, adică să decidă cu cât este mai complex un item față de celălalt. Spre exemplu, un item cu o valoare de 2 story points trebuie să fie de două ori mai complex decât unul cu valoarea de 1 SP, iar unul cu o valoare de 3 SP va fi de trei ori mai complex decât unul cu valoarea de 1 SP.

Astfel, se pornește de la premisa că putem să comparăm itemurile între ele mult mai rapid și mai precis decât dacă le-am descompune și am analiza fiecare item în parte. Mai exact, în loc să împartă un story în taskuri (iar apoi să estimeze aceste taskuri), echipa compară efortul necesar pentru a realiza story-ul cu efortul depus anterior pentru un alt story pe care l-a estimat deja. Ideea este ca echipa să determine efortul necesar pentru a finaliza un story bazându-se pe trei factori: complexitate, repetiție și risc. În acest sens, putem avea un story care să nu presupună un număr mare de linii de cod, dar să presupună multă analiză sau putem avea un story care să necesite modificări semnificative la nivel de HTML pe mai multe tipuri și versiuni de browser. Deși nu este o muncă complexă, este una repetitivă, care poate duce la multe încercări și erori. Un alt scenariu poate fi integrarea unei componente noi, nemaifolosită anterior. Aceasta poate aduce cu sine numeroase riscuri, cu toate că munca propriu-zisă nu pare foarte complexă. Din acest motiv, sfătuim echipele să ia în calcul toți acești factori atunci când estimează relativ.

Ca un plus, această tehnică încurajează utilizarea estimărilor în alte unități de măsură decât timpul și, astfel, ne ajută să evităm confuzia dintre estimări și angajamente (estimation vs. commitment).

Estimarea bazată pe afinitate (Affinity Estimation)

Recomandăm folosirea acestei tehnici pentru a estima un număr mare de user stories (unele articole o recomandă pentru mai mult de 25 de stories). Dacă trebuie să estimăm mai puține, putem utiliza cu succes tehnica Planning Poker.

Pentru estimările bazate pe afinitate, avem nevoie de un backlog ordonat, iar story-urile le grupăm în funcție de asemănări. Putem să creăm o coloană specială pentru story-urile care implică un anumit grad de necunoscut sau care nu respectă sintagma Definition of Ready. De obicei, echipa alege un story de referință, pe care îl plasează în coloana aferentă, iar în funcție de acesta, fiecare membru aranjează story-uri pe categorii sau mută story-urile pe cele deja clasificate. Această tehnică implică discuții și argumente pentru plasarea story-urilor în diferitele categorii existente.

Story points - o unitate de măsură relativă?

Orice estimare are ca punct de plecare unitatea de măsură și definirea complexității itemului în story points. De-a lungul timpului s-a observat faptul că, în cadrul echipelor Scrum, încep să apară percepții greșite despre ce înseamnă o estimare în story points, lucru care duce la apariția următoarelor situații:

Toate acestea duc la o alterare a modului de a estima efortul într-o echipă Scrum și afectează velocitatea echipei. Pornind de la experiența mea ca Scrum Master, sfătuiesc echipele Scrum să nu uite de ce estimează. Atunci când ne estimăm efortul, secretul este să avem o înțelegere comună, pentru a lăsa pe un loc secund problematica cifrelor.

O mare parte a criticilor aduse story pointurilor se concentrează asupra faptului că însemnătatea lor diferă pentru fiecare membru al echipei. Acest lucru se observă foarte ușor în cadrul sesiunilor de estimări, iar cea mai bună cale pe care am găsit-o, a fost să ajut echipa să ajungă la o viziune comună asupra estimării efortului în SP pentru story-uri.

Totuși, un anumit număr de SP atribuite unui user story nu măsoară complexitatea unui feature; ceea ce trebuie să înțelegem este faptul că SP reprezintă o unitate de măsură a efortului necesar pentru dezvoltarea acelui feature. Din acest motiv, nu este obligatoriu să ne raportăm întotdeauna la cifre. Putem folosi valori non-numerice precum T-shirt size sau chiar gummy bears (culori). De asemenea, nu trebuie să uităm faptul că un SP reprezintă o unitate de măsură arbitrară folosită pentru a estima "dimensiunea" unui story raportat la alte user stories similare.

Un alt aspect al estimării în Agile este faptul că, în general, presupunem că persoana "potrivită" va face munca propriu-zisă. Dar realitatea ne arată că ocazional, o persoană "nepotrivită" pentru un task va munci la el, iar acest lucru va fi rareori atât de dramatic precum sună în acest exemplu. Așadar, SPs reprezintă efortul necesar pentru realizarea acelui story.

Echipe, ajustați estimările astfel încât să înglobeze riscurile și incertitudinea. Asta așteaptă și stakeholderii!

Experimentul estimărilor într-o echipă Scrum

Împreună cu echipa în care sunt Scrum Master, am realizat un experiment care s-a dovedit a fi benefic și de succes. Tocmai pentru a evita situațiile în care ne raportăm prea mult la cifre, am decis cu toții să ne dezvoltăm un sistem propriu de estimări folosind valori non-numerice pentru SPs. Astfel, am luat niște etaloane legate de produsul nostru și le-am ordonat crescător. Le-am asociat valori din șirul lui Fibonacci, dar inițial, (timp de mai multe sprinturi), aceste valori au fost ascunse echipei. Doar Scrum Masterul avea această evidență pentru a putea cunoaște și calcula velocitatea echipei. Am folosit tehnica de estimare relativă pentru fiecare sesiune de grooming și am estimat/grupat storyurile în categoriile (ordonate) pe care le-am stabilit de la început. După scurt timp s-a observat o stabilizare a estimărilor acestei echipe. La momentul actual, valorile numerice echivalente etaloanelor non-numerice sunt cunoscute, însă acest fapt nu mai influențează modul de estimare al echipei, deoarece membrii acesteia și-au dezvoltat o înțelegere comună asupra efortului necesar pentru un story, încadrându-l în același etalon.

Tot legat de tehnicile de estimare, aș dori să vă împărtășesc impresiile pe care le-am adunat de la diferite echipe participante la un workshop despre estimări pe care l-am organizat:

Grup 1

Relative estimation: "Estimarea relativă pare să meargă cel mai bine."

"E mai ușor de estimat așa. Ne ajută să calculăm de câte ori e mai mare un story față de altul. Minimul și maximul sunt dificil de estimat. Per total, e o tehnică de estimare ușoară pentru grupuri."

Affinity estimation: "Merge mai lent, membrii echipei se contraziceau des."

"Seamănă a Waterfall și e mai greu de estimat așa. Este o estimare individuală, în care ești influențat de către ceilalți. E OK atunci când membrii echipei se cunosc bine."

Planning Poker: "Pare cumva mai ușor să ajungi la un consens cu această tehnică."

Grup 2

Relative estimation: "90% din timp ne-a luat să decidem dimensiunile. E foarte bine că există referințe. Ca tehnică, pare mai aproape de realitate și este mai precisă."

Affinity estimation: "Durează mult. Forțează fiecare individ să estimeze, e greu de trișat/eschivat de la asta, dar influența celorlalți se simte."

Planning Poker cu story-uri relative pare sa meargă.

Grup 3

Relative estimation: "În mod cert, a fost mult mai ușor decât cu alte tehnici. Faptul că are un punct de referință ajută foarte mult; cel mai greu e să găsești acea referință. Cel mai ușor este să lucrezi cu story-uri cât mai mici."

Affinity estimation: "E foarte greu pentru echipe care conțin persoane remote. Merge prea încet și influențează deciziile celorlalți. Nu e practică, mai ales pentru echipe mari. E mai interactivă decât Planning Poker, deoarece provoacă lumea la discuții."

Planning Poker: "E o tehnică familiară. Durează mai mult decât altele. Forțează echipa să discute."

Ca o concluzie, estimarea relativă a dat rezultate pozitive pentru echipa noastră, însă și celelalte tehnici de estimare au avantajele lor. Fiecare echipă e diferită, iar etalonul folosit de o anumită echipă poate să nu se potrivească alteia. Folosiți-vă de ședințele de retrospectivă pentru a analiza modul în care echipa își estimează efortul și pentru a alege tehnica cea mai potrivită pentru fiecare situație.

Analizați estimările din iterațiile trecute și răspundeți cinstit la întrebarea: "Cât de încrezători sunteți în aceste estimări?"

Bibliografie:

NUMĂRUL 149 - Development with AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects