Știm că planificarea pe termen lung (Planificarea lansării) ar trebui să fie în puncte istorice.
Dar pentru planificarea sprint, ar trebui să fie angajament bazat pe.
Descompunerea articolului restantei produsului / povestea utilizatorului în sarcini și estimarea sarcinilor, echipa se întreabă dacă se poate angaja să livreze elementul restantei produsului și apoi repetă până când sunt pline?
Pentru un sprint de trei săptămâni, cât de mare ar trebui să fie fiecare poveste pentru o persoană?
De asemenea, am văzut că unele echipe elimină această planificare bazată pe sarcini și au povești care durează doar 2 zile ?
Ar trebui să standardizez acest lucru pentru echipa mea?
Deci, înainte de un sprint, îmi împart poveștile la povestiri atât de scurte încât să se încadreze în acest standard.
Vă rog, anunțați-mi punctele de vedere despre acest lucru. Și care este practica generală?
Comentarii
- Ghidul Scrum s-a schimbat din ” angajament ” la ” prognoza „. Puteți citi despre motivul acestei modificări aici.
- Acest link vă poate fi de ajutor pm.stackexchange.com/questions/10119/ …
Răspuns
TL; DR
Practic, întregul set de presupuneri de planificare nu este agil. Trebuie să revizuiți modul în care vă planificați iterațiile și modul în care echipa dvs. intenționează să estimeze munca pe care o crede că poate fi finalizată pentru iterația curentă. Urmează o analiză mai detaliată.
Analiza detaliată
Știm că planificarea pe termen lung (Planificarea lansării) ar trebui să fie în puncte de poveste. [sic]
Nu. Planificarea agilă a lansării se face în iterații . Prin urmare, un plan de proiect Scrum va estima o gamă aproximativă de iterații necesare pentru a atinge produsul minim viabil sau pentru a finaliza restanța inițială a produsului. Aceasta este doar o estimare, deoarece conținutul restanțelor se va schimba în timp, iar lungimea și precizia estimărilor se vor schimba, de asemenea, împreună cu Conul de incertitudine .
Dar pentru planificarea sprint, ar trebui să se bazeze pe angajament.
Din nou, nu. Planificarea Sprint este bazat pe capacitate . Singurul punct de urmărire (sau creând o estimare inițială a) vitezei medii a echipei este de a găsi capacitatea durabilă a echipei de a lucra în timp. În timp ce echipa trebuie să fie sigură că nu se angajează excesiv să lucreze într-un Sprint doar pentru că intervalul de viteză sau media spune că ar trebui să existe capacitate disponibilă, este responsabilitatea echipei să planifice iterația curentă luând compoziția echipei, disponibilitatea și alți factori care afectează Sprint-ul actual în considerare.
Spunând că Sprint-urile sunt „bazate pe angajament” este probabil să fie folosit ca o lovitură emoțională pentru a determina echipele să se angajeze în Mai mult muncesc decât ar trebui, deoarece, desigur, membrii echipei ar trebui să fie „comis”. Totuși, aceasta este o utilizare greșită; în lumea reală, capacitatea echipei ar trebui în general redusă, dar rareori umflată în timpul planificării. În cazul în care echipa s-a angajat prea puțin, atunci lucrările suplimentare pot fi îndepărtate din Backlog-ul produsului, după cum este necesar, dar limitarea domeniului de aplicare este aproape întotdeauna încărcată din punct de vedere politic și pune adesea în pericol obiectivul Sprint. Deci, nu faceți acest lucru.
Capacitatea poate să fie o valoare relativ obiectivă. Pe de altă parte, angajamentul (la fel ca patriotismul) nu poate fi „măsurat decât dacă dvs.” Cerem oamenilor să „facă sacrificiul suprem”, care este un fel de antitetic pentru întreaga premisă a durabilității agile. Nu vă angajați niciodată într-un marș-moarte .
Pentru un sprint de trei săptămâni, cât de mare ar trebui să fie fiecare poveste pentru o persoană?
Acest lucru merită o carte întreagă plină de „nu”. Poveștile nu sunt niciodată dimensionate pentru sau acceptate de un individ. Toate poveștile sunt estimate pe baza resurselor complete și coordonate ale unei echipe multifuncționale care lucrează împreună pentru a completa fiecare poveste. Poveștile sunt acceptate sau respinse în funcție de:
- Sunt esențiale pentru obiectivul Sprint actual.
- Se vor încadra în capacitatea estimată disponibil pentru Sprint-ul curent.
Un singur articol cu restante de produs poate fi oricând Re de la 0 puncte de poveste până la maximul disponibil pentru întregul Sprint. Cu toate acestea, o poveste bună care îndeplinește criteriile INVEST este în general compusă din sarcini Sprint Backlog de aproximativ 0,5 zile până la 2,0 zile. Amintiți-vă că cu cât sarcina sau povestea este mai mică, cu atât estimarea este de obicei mai precisă, deci o duzină de povești de 5 puncte (atunci când sunt estimate cu exactitate) sunt, în general, mai fiabile decât o singură poveste de 60 de puncte. Cu toate acestea, maturitatea echipei și precizia estimării pot varia cu siguranță.
Răspuns
Povestirile utilizatorilor nu sunt pentru fiecare membru al echipei
Mai mulți membri ai echipei ar trebui să lucreze la același utilizator poveste în același timp. Aceasta nu este o cerință, ci o recomandare. Esența terminologiei rugbyului, scrum , în care echipa se îndreaptă spre linia de poartă ca unitate. Conceptul se numește roire . Toată lumea se concentrează pe una (sau mai puține) sarcini la un moment dat, o finalizează și abordează următoarea lucrare (repetați). Avantaje:
- Păstrează_ în progres_ elemente mai puține.
- Permite completarea articolelor de restante sprint răspândite în tot sprintul, în loc ca totul să fie finalizat aproape de sfârșitul sprintului.
- Păstrează încărcarea qa / testare distribuită uniform pe durata sprintului.
- Toată echipa obține cunoștințele de cod și poate oferi sugestii tehnice.
Echipa ar trebui alege o poveste și împarte-o în sarcini tehnice. O singură persoană ar trebui să lucreze la o sarcină tehnică, deoarece responsabilitatea este clară în acest caz, ceea ce ajută în timpul întâlnirilor zilnice de scrum. În mod ideal, o sarcină tehnică ar trebui să fie suficient de mică, astfel încât să fie finalizată pe parcursul unei zile.
Dimensiunea povestirilor utilizatorilor
Scrum nu definește nicio dimensiunea recomandată a unei povești de utilizator. Cu toate acestea, o poveste ar trebui să fie dimensionată astfel încât să poată fi finalizată în timpul unui sprint. „Finalizare” înseamnă că acoperă „Definiția finalizată”.
O poveste trebuie înțeleasă în mod clar și să aibă criterii de acceptare explicite, care să fie verificate în același sprint. În mod normal, este mai greu să calci o poveste mare și să explici toate criteriile de acceptare, astfel încât o poveste ar trebui să fie mică, unde poate fi estimată suficient de bine și testată.
O poveste ar trebui să fie, de asemenea, suficient de mare, astfel încât să oferă o valoare comercială concretă părților interesate.
Deci, răspunsul nu este nici prea mic, nici prea mare . Cu practică și experiență, vă îmbunătățiți scrierea și împărțirea poveștilor utilizatorilor. Este mai mult o artă decât știința.
Răspuns
Planificarea Sprint ar trebui să fie și în puncte de poveste. Procesul este același ca și pentru planificarea pe termen lung. Vă verificați viteza și capacitatea (câți membri ai echipei vor fi acolo, din cauza sărbătorilor etc.) și veniți cu un număr.
Dacă intenționați pentru sprintul 2, vă verificați viteza în sprintul 1 – de exemplu, 10 puncte – și introduceți 10 puncte în valoare de povești ale utilizatorilor în restanța dvs. de iterație.
Dacă intenționați pentru sprintul 3, vă verificați tendința de viteză de la sprintul 1 la 2 și găsiți suma la care vă puteți angaja.
Dacă intenționați pentru sprintul 1, adăugați cât mai mult consideri potrivit.
Încearcă să nu vezi câte puncte poate face o persoană , deoarece scrum este despre echipe nu persoane. De exemplu, un junior poate face mai puțin decât un senior, totuși oamenii se ajută reciproc, nu vor putea să livreze la fel de mult ca „pe hârtie”. Lucrați și calculați cu echipele , deoarece are mai mult sens (și este mai ușor).
Comentarii
- Da, Sunt de acord cu dvs., trebuie să faceți referire la toate punctele istorice ale sprinturilor anterioare și, așa cum ați spus dvs. / CodeGnome, trebuie luată în considerare și capacitatea. De fapt, sunt confuz că cât de scurt ar trebui să fie ” fiecare poveste „, astfel încât să poată fi testată în paralel, deoarece nu există o fază de testare separată.
- De asemenea, am făcut referire anterior la următoarele: mountaingoatsoftware.com/blog/…
- @Roop, așa cum au spus alții, ” fiecare ” nu trebuie să fie suficient de scurtă. Va fi lucrat de mai mulți membri ai echipei, dar sarcinile din poveste ar trebui să fie păstrat de la 0,5 zile la 2 zile