Când lucrează la un proiect Agile, echipa planifică munca pentru sprinturile viitoare prin crearea de povești. O poveste definește o singură activitate încapsulată în funcționalități cu descriere și criterii de acceptare.
Sprinturile durează de obicei de la două până la patru săptămâni. În acest timp, echipa trebuie să înțeleagă cât de mult conținut poate prelua într-un sprint, astfel încât să poată face în continuare în timpul de sprint dat.
Într-un proiect non-agil, ați estima munca de obicei în zile-om. Asta înseamnă de câți angajați cu normă întreagă aveți nevoie pentru a finaliza această activitate? În acest caz, vă gândiți întotdeauna la zilele și la numărul de persoane când creați estimări.
Într-un proiect agil, lucrurile stau altfel. Nu mai numărați zilele sau oamenii pentru a calcula estimarea finală. De fapt, vom interzice chiar și calculul efortului în ceva de genul zilelor omului. În schimb, lăsați echipa să se transforme la o valoare general acceptată pentru poveste, care va reprezenta estimarea generală.
Acum, pentru care este valoarea exactă, acest lucru nu contează cu adevărat. Adevărat, cel mai comun reprezentant al estimărilor poveștii sunt Story Points. Acestea sunt practic numere Fibonacci care încep de la 0, 1, 2, 3, 5, 8, 13, 21 etc. Următoarea valoare este o sumă a celor două numere anterioare. Acest lucru va ajuta la diferențierea complexității generale a poveștii, deoarece fiecare număr mai mare este semnificativ mai mare decât cel anterior.
Dar nu trebuie să rămâneți la punctele de poveste. Pot fi estimări ale mărimii tricoului (XXS, XS, S, M, L, XL, XXL). Dacă doriți să fiți cu adevărat creativ, puteți introduce animalele ZOO și le puteți folosi pentru estimarea dimensiunii.
Oricum ar fi, acum este mult mai mult despre sentimentul întregii echipe despre ce număr (sau animal) reprezintă cel mai bine complexitatea generală a acestei povești. Cu siguranță nu este vorba despre reprezentarea timpului. În cele din urmă, echipa ar trebui să completeze fiecare poveste luată în sprint din acel sprint. Deci timpul este deja dat la început și este un număr constant.
Cuprins
Componentele estimării punctelor de poveste
O estimare a punctului de poveste nu se referă în mod absolut doar la cât de complexă/dificilă este o anumită poveste. Atunci când estimează o poveste, echipa ar trebui să ia în considerare mai multe aspecte și să le reflecte în valoarea estimată finală.
Estimarea finală este apoi o valoare care reprezintă o combinație a tuturor aspectelor formate într-un singur număr. Iată ce va include o astfel de estimare.
#1. Dificultate tehnică
Presupunând că estimăm povești pentru o echipă de dezvoltare, dificultatea tehnică a poveștii va fi unul dintre primele domenii pe care echipa se va concentra în mod implicit.
Și aceasta este, fără îndoială, abordarea corectă. Echipa plină de experți tehnici ar trebui să știe cel mai bine cum să evalueze o astfel de zonă a unei povești. Aici echipa poate lua în considerare diverse abordări sau indicii, cum ar fi:
- Cum se compară această poveste cu altele deja livrate din perspectiva complexității tehnice?
- Câte fișiere de cod va trebui să creeze/actualizeze echipa pentru a finaliza povestea?
- Câte modificări suplimentare de cod va genera această poveste în procesele de sistem din jur?
- Cât de complex va fi implementat algoritmul sau logica procesului?
#2. Dependențe și riscuri externe
Ar fi surprins, dar, de cele mai multe ori, succesul poveștilor din sprintul echipei depinde de contribuțiile altor echipe sau persoane externe echipei în sine.
Povești în care tot ceea ce echipa poate realiza singură este cel mai ușor de estimat. Lucrurile se complică dacă echipa are nevoie de ajutor extern pentru poveștile lor. Pentru oamenii din afara echipei, această activitate nu va fi o prioritate, desigur. Echipa trebuie doar să se bazeze pe acel factor și să-l ia în considerare în estimare.
Cât de mult va crește acest factor estimarea totală va depinde în mare măsură de experiența anterioară a echipei și de „nivelul de externalitate”. De obicei, în unele sprinturi, echipa va stabili un sentiment natural unificat pentru cât de mult ar putea complica această dependență de oameni externi finalizarea cu succes a poveștii.
#3. Factorul de reutilizare
Următorul domeniu de luat în considerare este cât de mult din conținutul existent poate reutiliza echipa pentru a finaliza povestea. Evident, dacă unele dintre părți sunt deja prezente într-un fel sau altul, nu este necesar să o construiți de la zero. Mai degrabă, echipa poate reutiliza soluția deja creată pentru a construi una nouă mult mai rapid.
În acest fel, aceste cunoștințe pot scădea estimarea totală, chiar dacă în mod normal (fără această reutilizare), povestea ar fi mai complexă pe baza conținutului definit.
#4. Înțelegerea propriei echipe
Un factor remarcabil pe care nicio estimare bazată pe zile nu îl poate lua în considerare este autocunoașterea vechimii și a capacității echipei.
Pe măsură ce echipa lucrează împreună și realizează mai multe sprinturi, oamenii din interior vor ajunge să se cunoască. Vor începe să înțeleagă cine știe ce și cât de bun este la asta. Și odată ce toată lumea cunoaște restul echipei, împreună, ca echipă, pot lua în considerare acest lucru în timpul estimării.
Dacă povestea este grea pe o anumită abilitate tehnică concretă și acea abilitate este foarte puternic prezentă în interiorul echipei, este că realizarea clară a poveștii nu va fi atât de o bătaie de cap. Sau invers, dacă abilitățile necesare lipsesc în cadrul întregii echipe, atunci echipa va avea nevoie de mult mai mult timp pentru a intra în subiect și va reflecta acest lucru în estimare.
Estimarea poveștii
Fiecare estimare a poveștii ar trebui să fie un efort de echipă. Nicio voce nu ar trebui să predefinite complexitatea poveștii. Scopul final ar trebui să fie acela de a lăsa echipa să discute estimarea până când toți membrii vor conveni asupra unei singure valori care va reprezenta estimarea finală.
Echipa poate face estimarea direct în timpul discuției de rafinare a sprintului (o întâlnire în care poveștile sunt discutate și clarificate între echipă) sau, alternativ, își pot rezerva un timp dedicat pentru a face exact asta.
Exemplu de proces de estimare
Angajamentul Planului Sprint
Echipa are acum un întârziere cu povești care au trecut deja prin sesiunile de estimare. În mod ideal, poveștile au fost atribuite (în afară de valoarea estimată finală) și o prioritate, astfel încât echipa să știe ce povești vor urma în următorul sprint.
Urmează sesiunea de planificare, în care echipa va alege câteva dintre poveștile pentru următorul sprint. Decizia asupra poveștilor pe care să le alegeți ar trebui să se bazeze pe următoarele:
✅ Povești cu cele mai înalte priorități pe care echipa le ia în considerare mai întâi.
✅ O experiență a echipei despre câte puncte de poveste sunt capabile să termine într-un sprint. Aceste cunoștințe vin doar cu timpul și experiența echipei. Aveți nevoie de mai multe sprinturi pentru a regla fin și pentru a înțelege corect această capacitate.
✅ Nu ar trebui să luați în considerare numai numărul total de puncte de poveste și prioritatea. Un alt aspect este modul în care abilitățile din interiorul echipei se vor răspândi în poveștile selectate. De exemplu, dacă echipa are doar doi dezvoltatori front-end, ei s-ar putea să nu aleagă doar povești care constau doar din dezvoltare front-end. Asta ar duce la suprautilizarea celor doi tipi, în timp ce restul echipei nu este atât de mult. Așadar, cunoștințele echipei vin mână în mână cu eficiența creării de conținut de sprint.
Factorul de viteză
Mai presus de toate se află viteza echipei (pentru sprintul viitor). Acest număr nu este în niciun fel legat de numărul total de puncte de poveste. Cu toate acestea, indică cât de mult va fi echipa disponibilă pentru muncă pentru următorul sprint.
Pentru a putea planifica cu precizie conținutul unui sprint, punem împreună ambele aspecte:
Este nevoie de timp și practică pentru a găsi punctul ideal.
Beneficii și greșeli frecvente
Este surprinzător cât de mult sunt echipele dispuse să complice singure procesul de transformare într-o echipă agilă. Literal, se simte că trebuie să „obțineți” înainte de a putea începe să lucrați în acel mod.
Acest prim pas este, din păcate, și cel mai dificil. În unele cazuri, durează chiar și ani, mai ales în mediile corporative strict conservatoare, în care timpul singur se blochează în timp.
Oricum, iată ce se va întâmpla odată ce echipa „obține”:
- Nu mai trebuie să calculați oameni sau zile pentru a ști când se poate finaliza ceva.
- Echipa va învăța să creeze povești atât de complexe încât să se încadreze într-un sprint. Dacă o poveste este mai complexă, este împărțită automat în mai multe povești.
- Echipa are estimări bune ale fiecărei lucrări și, odată ce o planifică pentru un sprint, știi exact când trebuie.
- Va crește fiabilitatea și predictibilitatea echipei.
- Toți oamenii din cadrul echipei vor fi „pe aceeași frecvență”. Se vor uita la o poveste și vor înțelege lucruri similare. Poate că după ceva timp nici nu se obosesc să estimeze. Ei văd numărul în cap și, din moment ce toți văd același număr, se pot angaja la povești într-un sprint chiar și fără această estimare explicită.
Și asta se întâmplă de obicei dacă echipa este încă incapabilă să înțeleagă procesul sau modul de lucru:
- Ei, cumva, încă se țin de estimările pentru zilele omului de modă veche. Ei transformă totul în zile sau în oameni implicați. Punctele de poveste sau numerele Fibonacci înseamnă cantitatea de zile, direct sau indirect, prin diferite transformări.
- Leadership-ul compară echipele pe baza numărului de puncte de poveste livrate la fiecare sprint. Acest lucru este atât de greșit cât ar putea fi. Un fapt substanțial nu este atunci înțeles: fiecare echipă estimează punctele poveștii în mod diferit. Nu există absolut niciun motiv pentru a face eforturi pentru a sincroniza două echipe pentru a-și estima poveștile în „același mod”.
- În timp ce povestea unei echipe înseamnă desenarea unui cerc, pentru o altă echipă, ar putea însemna desenarea unei case cu un acoperiș plat, patru ferestre și două uși. Și e absolut bine.
- Uneori, echipele tind să estimeze aproape totul între două până la patru numere diferite. Poate pentru că se tem că o poveste are numărul 123, cineva va crede că are ceva de-a face cu numărul de zile. Dar adevărul este că scara Fibonacci are o cantitate infinită de numere. Nu trebuie să ne limităm doar la estimări de 3, 5 sau 8. Cu siguranță putem (și poate că creăm poveștile deja cu acest scop în minte să fie atât de complexe, caz în care este bine), dar noi cu siguranta nu trebuie.
- Estimarea este condusă de oameni seniori care vor predefini așteptările întregului grup. Nu ar trebui să permitem niciodată influențarea estimării de către un membru al echipei. Fiecare are dreptul egal de a-și exprima opinia și de a fi ascultat.
Cuvinte finale
Trecerea la estimarea agilă de la abordările mai tradiționale nu este întotdeauna ușoară și necesită acomodare – atât pentru echipe, cât și pentru conducerea de mai sus. Pentru ca acesta să funcționeze, ambele părți trebuie să înțeleagă procesul. Dacă unul dintre ei nu înțelege, perioada de tranziție este un drum anevoios și plin de așteptări contradictorii.
Dar odată ce toate se vor transforma, unele lucruri magice vor începe să se întâmple. Echipele vor putea să-și estimeze și să planifice mai bine munca, iar conducerea va avea versiuni și foi de parcurs mai previzibile pe care să se bazeze.
Apoi, verificați procesele nesănătoase care vă pot distruge sprintul.