Am auzit multe explicații diferite de ceea ce Povestea Puncte înseamnă și cum ar trebui să le utilizeze. Aproape fiecare echipă Scrum le folosește, dar nu fac parte din Ghidul Oficial Scrum. Acest articol își propune să elimine unele dintre punctele de poveste din jurul misterului., Voi împărtăși, de asemenea, cele mai frecvente concepții greșite pe care le-am întâlnit.
Ceea ce face Povestea Puncte reprezintă?
punctele de poveste reprezintă efortul necesar pentru a pune în direct un PBI (produs Backlog Item). Fiecare punct de poveste reprezintă o distribuție normală a timpului. De exemplu, 1 punct de poveste ar putea reprezenta un interval de 4-12 ore, 2 puncte de poveste 10-20 ore și așa mai departe., Această distribuție a timpului nu este cunoscută în timpul estimării. Prin utilizarea referinței PBI în raport cu care să se estimeze, nu este necesar să se știe cât timp este nevoie. Vrei doar să aibă o indicație dur de cât de mult timp PBI va lua pentru a finaliza.
care sunt avantajele utilizării punctelor de poveste?
punctele de poveste permit unei echipe să:
- estimeze rapid problemele. Estimarea este relativă la produsele deja finalizate. Acest lucru este mai rapid decât estimarea fără nicio referință.
- estimare fără a da un angajament de timp specific., Când estimați în ore, faceți un angajament precis de timp. Estimarea în punctele de poveste împiedică acordarea unui angajament exact. Nimeni nu știe exact câte ore numiți într-o anumită problemă.
- îmbrățișați incertitudinea care vine cu estimarea. Punctele de poveste specifică un interval de timp necunoscut. Selectarea dintr-o secvență specifică de puncte de poveste asemănătoare lui Fibonacci ne permite să surprindem incertitudinea.
- suficient de precis pentru a planifica sprinturi înainte. Acest lucru ne permite să gestionăm mai bine așteptările de timp ale părților interesate pentru activitatea viitoare.,
12 greșeli comune făcute atunci când se utilizează puncte poveste
- echivalarea puncte poveste la doar complexitate, incertitudine, sau valoare
unele PBI pot fi complexe și nu necesită o mulțime de timp. Un PBI implică implementarea unui algoritm sofisticat. Echipa a făcut deja acest lucru înainte, așa că vor putea să o facă rapid. Opusul poate fi, de asemenea, adevărat, un simplu PBI care necesită mult timp. Echipa trebuie să refactoreze o mică bucată de cod, afectând o mulțime de funcționalități. Ca urmare, o mulțime de funcționalitate trebuie să regresie testate, ceea ce va dura mult timp.,
incertitudinea în estimarea este capturat în punctul poveste Fibonacci-ca secvență în sine: 1, 2, 3, 5, 8, 13, 20, 40, 100. Alegerea unui număr specific din această secvență reflectă cantitatea de incertitudine. Desigur,în cazul în care incertitudinea este prea mare pentru a estima, puteți utiliza”? carte.
punctele de poveste nu spun nimic despre valoarea unui PBI. Punctele de poveste oferă o estimare aproximativă. S-ar putea ca acest element să fie extrem de valoros sau să nu adauge deloc valoare. Punctele de poveste ajută la determinarea ROI-ului unui PBI., Puteți utiliza Story Points pentru a lua în considerare efortul de a furniza această funcționalitate împreună cu valoarea. Dar, deoarece valoarea este incertă, de asemenea, nu te socoti bogat încă.
punctele de poveste sunt despre efort. Complexitatea, incertitudinea și riscul sunt factori care influențează efortul, dar fiecare singur nu este suficient pentru a determina efortul.
2. Traducerea punctelor de poveste în ore
prin traducerea punctelor de poveste în ore, nu mai beneficiați de viteza estimării relative. Începeți să lucrați în ore și riscați să vă angajați., Oferă un fals sentiment de precizie pe măsură ce REduceți un punct de poveste cu un interval de timp de 10-20 de ore la un număr precis, cum ar fi 15 ore. Va fi mai dificil să ajungeți la un acord în estimări atunci când lucrați în domeniul exact al orelor.
3. Media punctelor de poveste
într-o sesiune de poker de planificare, jumătate din echipă estimează un PBI la 3 puncte de poveste, iar cealaltă jumătate la 5 Puncte de poveste. Este ușor să rezolvați discuția punând doar 4 puncte de poveste ca estimare. Echipa nu ar trebui să facă acest lucru, deoarece încearcă din nou să ofere un fals sentiment de precizie., Ideea nu este de a fi 100% exacte. Ideea este să fii suficient de precis pentru a planifica din timp. În plus, puteți pierde o discuție valoroasă prin mediere. Poate 5 Puncte de poveste a fost o estimare mai bună.
4. Ajustarea estimărilor punctelor de poveste ale problemelor în timpul sprintului
când echipa începe să lucreze la o problemă, echipa nu ar trebui să ajusteze estimarea punctului de poveste. Chiar dacă se dovedește că estimarea lor a fost inexactă. Dacă estimarea a fost inexactă, face parte din viteza finală de Sprint. Este normal ca estimările să fie uneori oprite., Nu veți pierde aceste informații și va face parte din viteza istorică a unei echipe.
5. Niciodată poveste arătând bug-uri
un bug care nu au legătură cu Sprint curent ar trebui să fie doar povestea a subliniat. Bug-ul reprezintă munca pe care echipa trebuie să o finalizeze. Acest lucru nu se aplică dacă echipa își rezervă un procent fix de timp pentru a lucra la bug-uri în timpul sprintului. Un bug legat de o problemă în sprint nu ar trebui să fie povestea a subliniat ca aceasta face parte din estimarea inițială.
6. Adăugarea punctelor de poveste la sarcini mici
Un mic vârf pentru investigarea a ceva ar trebui să fie doar în cutie de timp., Este clar că va dura 4 ore și nu este nevoie să aduceți puncte de poveste în amestec.
7. Ajustarea referinței PBI la fiecare Sprint
când o echipă ajustează referința PBI la fiecare sprint, viteza diferitelor sprinturi nu mai este comparabilă. Echipa pierde informații pe care nu le mai puteți folosi viteza istorică pentru a planifica. Este mai bine să utilizați o serie de PBI recente ca referință.
8. Când mutați un PBI neterminat la următorul sprint, nu este necesar să reestimați., Este posibil ca estimarea să nu fi fost exactă, dar aceasta nu este o problemă. Ca urmare a planificării Sprintului, echipa va cunoaște toate sarcinile necesare pentru a finaliza problema. Estimarea acestor sarcini este în ore. Deci, următorul Sprint, echipa va ști cât timp este încă necesar pentru a finaliza PBI. Faptul că PBI nu a fost finalizat va face parte din viteză.
9. Ajustarea estimării punctului de poveste, deoarece un dezvoltator specific va lucra la acesta
Story arătând un PBI este relativ la povestea utilizatorului de referință și făcut de echipă., Membrii echipei punct poveste PBI și să ajungă la un acord cu privire la estimarea într-o sesiune de poker de planificare. Un PBI poate fi 3 puncte de poveste pentru un dezvoltator senior, dar 8 Puncte de poveste pentru un dezvoltator junior. Echipa ar trebui să ajungă la un acord cu privire la cantitatea de muncă pe care o reprezintă pentru echipă și să o folosească pentru planificare. Nu trebuie să ajustați punctele de poveste, deoarece o anumită persoană va face munca. Poate că până când vor începe să lucreze la această problemă, dezvoltatorul Senior lucrează la o problemă de producție. Poate fi necesar ca dezvoltatorul Junior să-l ridice.
10., Nu ajustați niciodată referința PBI
atunci când compoziția echipei se schimbă ,acest lucru poate afecta estimările vitezei și punctului de poveste. Ambele depind de echipa care efectuează lucrarea. Imaginați-vă că ați subliniat problema când au fost prezenți doi dezvoltatori seniori. Până când doriți să începeți să lucrați la aceste probleme, amândoi au părăsit compania. Acum doi noi Dezvoltatori juniori sunt în echipă. Este o bună practică să stabiliți o nouă poveste de utilizator de referință la care a lucrat întreaga echipă., Acest lucru asigură că toată lumea este pe aceeași pagină atunci când indică povestea și oferă echipei ceva timp pentru a stabili o nouă viteză. Pe măsură ce echipa devine mai matură și mai bună la estimare, poate fi o idee bună să stabilim noi PBI-uri de referință.
11. Conform expertului din cameră.
atunci când faci poker de planificare, există riscul ca echipa este conformă cu expertul evident în cameră. O modalitate de a rezolva acest lucru este de a lăsa expertul să elaboreze lucrarea. Apoi, restul echipei estimează fără expert. Construirea expertizei specifice este inevitabilă., Nu lăsați acest lucru să submineze faptul că estimarea este un efort de echipă.
12. Nu se discută în mod incorect probleme punctate de poveste în retrospectivă.din când în când, povestea echipei indică o problemă în care este clar că estimarea a fost complet oprită. Este important să discutăm aceste probleme și să încercăm să învățăm, astfel încât estimările viitoare să fie mai precise. Într-una din echipele mele, am uitat să luăm în considerare crearea datelor de testare la estimare. Așa că am făcut un punct special pentru a discuta pentru fiecare problemă dacă crearea datelor de testare a fost aplicabilă., Atunci când este cazul, ne-ar întreba dacă au luat crearea de date de testare în considerare. Acest lucru ne-a îmbunătățit foarte mult estimările.
concluzie
conceptul de puncte de poveste este simplu, dar dificil de aplicat. Aproape fiecare echipă Scrum le folosește, dar nu fac parte din Ghidul Oficial Scrum. Din acest motiv, oamenii au opinii diferite cu privire la modul în care ar trebui să le folosească. Termenul punct de poveste în sine este deja confuz, deoarece îl puteți folosi pentru alte tipuri de lucrări decât poveștile utilizatorilor. În plus, „punct” sugerează că un punct de poveste reprezintă valoare., După cum a subliniat un coleg, poate că termenul „factor de planificare” ar ajuta la reducerea confuziei pe care o experimentează mulți oameni. A fi conștient de greșelile care pot fi făcute atunci când folosiți punctele de poveste vă ajută să le aplicați corect.
