Cum să estimați punctele de poveste pentru proiectul dvs.?

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.

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?
  Cum să vizualizați versiunea desktop a oricărui site pe mobil

#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

  • Alegeți un instrument de estimare pe care să îl folosească echipa, ceva precum Planning Poker, tabla Miro sau similar.
  • Pune o poveste pe tablă. Lăsați echipa să discute gândurile finale sau întrebările despre poveste. Asigurați-vă că întreaga echipă are deplina conștientizare a poveștii și că sunt gata să estimeze.
  • Începeți estimarea. Fiecare membru al echipei este rugat să aleagă un număr din scara Fibonacci.
  • Odată ce toate au fost estimate, priviți împreună rezultatele. Începeți discuția. De obicei, echipa va separa între două până la trei numere. Lăsați oamenii din partea de jos să dea motive pentru care estimarea ar trebui să fie atât de scăzută. Apoi, lăsați-i pe cei de la celălalt capăt să detalieze de ce estimarea finală ar trebui să fie atât de mare. Scopul este de a pune pe masă toate argumentele, considerentele și faptele, astfel încât întreaga echipă să fie pe aceeași pagină în a înțelege ce include această poveste.
  • După încheierea discuției, lăsați echipa să estimeze din nou. De cele mai multe ori, echipa se va converti acum la unul sau două numere distincte. Repetați discuția din nou. În funcție de caz concret, fie echipa se va pune de acord asupra numărului final din cele două alternative, fie vei decide asupra unei alte runde de estimare.
  • Estimarea se termină doar dacă toți membrii echipei sunt absolut în regulă cu estimarea finală. Ar trebui să fie un acord al întregii echipe, nu doar al câtorva indivizi. Potenţial, fiecare poveste poate fi atribuită ulterior oricui din echipă. De aceea, este important ca toată lumea să fie de acord cu privire la cât de complexă este povestea.
  •   Cum funcționează imprimarea 3D?

    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:

  • Viteza echipei – Măsurată în zile. Un membru al echipei este disponibil pentru o zi întreagă, echivalând cu unul în viteza echipei. De exemplu, o echipă de 10 pe deplin disponibile pentru un sprint care durează 2 săptămâni este egală cu o capacitate de echipă de 100.
  • Cantitatea obișnuită de puncte de poveste completate într-un sprint – Măsurată în puncte de poveste. Acest număr vine din experiența anterioară și este strâns legat de viteza echipei.
  • Este nevoie de timp și practică pentru a găsi punctul ideal.

      Cum se configurează Microsoft Teams

    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.