scrum artifacts product backlog
Introducere în artefacte Scrum:
În articolele anterioare din această serie, am fost introduși în agile și diferitele metodologii agile . De asemenea, am aflat despre diferitele metodologii în felul lor.
În ultimul nostru tutorial, am intrat în detaliile Scrum unde am discutat despre Roluri Scrum precum Product Owner, Scrum Master și echipa scrum și au văzut care erau responsabilitățile lor individuale.
În acest tutorial, continuăm cu Scrum și trecem mai departe la detaliile despre diferitele artefacte scrum.
Ce veți învăța:
- Diferite artefacte Scrum
- Restante produs
- Sprint Backlog
- Incrementări ale produsului
- Concluzie
- Lectură recomandată
Diferite artefacte Scrum
3 tipuri de artefacte scrum includ:
- Restante produs
- Sprint restante și
- Incrementări ale produsului
Acum vom vedea ce înseamnă acești termeni și cum să creăm aceste artefacte.
Restante produs
Pentru a spune acest lucru în termeni simpli, un restant de produse este o listă cu toate lucrurile care sunt necesare în produs. Este documentul final la care se referă echipa scrum pentru orice legătură cu produsul. Este o listă comandată de articole care este deținută de proprietarul produsului (PO).
OP este responsabil pentru crearea, menținerea și stabilirea priorității acestei liste. OP-urile folosesc acest backlog de produs pentru a explica echipelor scrum cerințele de top care trebuie îndeplinite în timpul sprintului.
Articolele din această listă pot fi sau nu într-un limbaj tehnic. Poate fi chiar un limbaj laic, dar ar trebui să conțină toate cerințele produsului și modificările însoțitoare. De asemenea, a avea un restant de produse nu înseamnă că echipa scrum va avea doar acest artefact de urmat.
Ei își pot crea propriile artefacte detaliate, dar acestea nu vor contrazice sau înlocui restanțele de produse. Acestea vor fi mai degrabă în conformitate cu cerințele privind restanțarea produselor.
Mai jos este un exemplu de cum poate arăta o restanță tipică de produse:
Poveste | Estima | Prioritate |
---|---|---|
Vreau să mă autentific | 4 | 1 |
Vreau să mă deconectez | Două | Două |
Vreau să schimb parola | 1 | 3 |
Vreau să actualizez adresa | 3 | 4 |
Vreau să adaug un nou număr de telefon de acasă | 1 | 5 |
Acest lucru ne aduce la întrebare, cum se creează un restant bun de produse?
O restanță de produs ar trebui să respecte în mod ideal regulile de mai jos:
(i) Ar trebui să se acorde prioritate - Articolele din restanța produselor trebuie comandate conform priorității lor. Această prioritate poate fi decisă de OP și de echipa scrum împreună. Factorii de stabilire a priorităților pot fi orice fel de beneficiu din punctul de vedere al istoriei, efortul implicat în crearea, complexitatea, prioritatea clientului etc.
Ajută echipa să înțeleagă ce trebuie livrat mai întâi.
(ii) Ar trebui estimat - Poveștile ar trebui întotdeauna estimate conform definiției convenite, oricare ar fi aceasta. Aceasta poate fi utilizată și pentru stabilirea de priorități.
(iii) Ar trebui să fie la nivel înalt - Poveștile din restanțele de produse sunt menite să fie de nivel înalt și nu ar trebui să intre în detalii. Crearea poveștilor detaliate ale utilizatorilor conform cerinței revine echipei scrum și nu OP-ului.
(iv) Ar trebui să fie dinamic - Restanța produsului nu este un document static final. Ar trebui revizuit pe măsură ce PO primește contribuții de la echipa de scrum și cerințele clienților devin din ce în ce mai clare. Astfel, cerințele documentului nu sunt înghețate chiar la început, deoarece se așteaptă adăugiri / ștergeri / modificări pe măsură ce proiectul progresează.
Ultimul punct este cel mai relevant. Scopul unei restanțe de produs este de a fi o sursă de cerințe active. Nu trebuie creat la început și apoi păstrat într-o locație de depozitare.
În schimb, este menit să fie partajat din nou și din nou pe măsură ce modificările continuă să apară. S-ar putea să apară noi cerințe pe măsură ce se realizează progresul și acest lucru ar putea schimba și prioritatea articolelor restante. Vor exista situații în care o nouă cerință depinde de un alt element din restanțare, astfel încât este posibil să fie necesară remodelarea priorității articolului.
Sau ar putea exista o poveste critică a utilizatorului care ar trebui să fie implementată mai întâi, deoarece clientul dorește să vadă acest lucru înaintea celorlalți, deși s-ar putea să nu aibă o prioritate ridicată, în funcție de factorii hotărâți de OP și de echipa scrum.
Astfel, restanța produselor este o listă ordonată de cerințe comerciale deținute de OP și vizitate la timp din nou și din nou pe măsură ce proiectul progresează.
Sprint Backlog
S-ar putea să vă amintiți că echipele scrum lucrează în iterații scurte de 2 până la 4 săptămâni numite sprint. În timpul acestor sprinturi, echipa scrum identifică articolele din restanțele de produse create de PO, pe care intenționează să le livreze ca parte a următoarei iterații. Elementele pe care echipa scrum le selectează pentru a lucra devin o parte a restantei sprintului.
Astfel, ei decid ce funcționalități vor fi acolo în următoarea iterație a produsului. Echipa scrum este cea care decide ce va intra în restul sprintului, deoarece ei vor lucra la asta.
Astfel, ei sunt cei care ar trebui să estimeze efortul implicat în implementarea acelor povești și să decidă cât de mult pot realiza.
Echipa nu numai că alege articolele din restanțele de produse pentru a lucra, dar a făcut și o estimare a timpului necesar pentru ca aceștia să dezvolte această funcționalitate. De asemenea, acestea se adaugă la poveștile utilizatorilor la nivel înalt, creând sarcini detaliate necesare pentru atingerea obiectivului sprint.
care este cel mai nou sistem de operare
Echipa scrum poate, de asemenea, să actualizeze în continuare sprint-ul restante pe măsură ce este necesar în timpul sprintului, dar numai echipa scrum poate face modificări în restul sprint-ului.
Un Sprint Backlog tipic va arăta așa cum se arată mai jos.
Echipa o poate actualiza în mod ideal o dată pe zi, iar comandantul scrum poate folosi aceste informații pentru a crea o diagramă sprint burndown. Această diagramă de descompunere va ajuta echipa să vadă cât mai rămâne de lucru pentru sprint și echipa își poate planifica munca în consecință. Pot chiar să adauge sau să elimine sarcini, dacă este necesar.
Unele dintre cele mai bune practici în timpul creării unui backlog sprint pot fi:
# 1) Luați decizii de grup - Nu ar trebui ca masterul de scrum sau orice alt membru al echipei de scrum să decidă restanța. Mai degrabă, ar trebui ca întreaga echipă să decidă împreună ce elemente să includă în restantei sprintului și cum să le planifice.
Fiecare membru al acestei echipe multifuncționale își aduce propriile abilități și este esențial să le folosim experiența pentru a crea cel mai bun backlog posibil.
# 2) Nu alocați sarcini - Așa cum a fost repetat de mai multe ori în literatura agilă, nu atribuiți niciodată sarcini membrilor echipei. O echipă de scrum ar trebui să fie autosuficientă și ar trebui să știe cum să își organizeze singuri munca.
Deci, în loc să atribuim o muncă, ar trebui să lăsăm echipa să aleagă munca pentru ei înșiși și să decidă între ei cum vor să procedeze.
# 3) Definiția a făcut - Nu ar trebui să fie convenit doar de către părțile interesate, ci și să fie făcut vizibil în mod clar pentru echipă în toate momentele, ori de câte ori trebuie să ia orice decizie cu privire la obiectivele sprintului. Acest lucru vă va reaminti ceea ce trebuie făcut înainte de a putea livra un produs care poate fi expediat.
# 4) Actualizați continuu restanța - Este imperativ ca pe măsură ce sprintul evoluează, echipa să câștige o mai bună înțelegere și, prin urmare, ar trebui să actualizeze în consecință restanța de sprint pentru a reflecta și această înțelegere mai bună. Nu ar trebui să devină în niciun moment un document static.
# 5) Adăugați orice activitate - Sarcina nu trebuie să fie legată doar de codificare, dar ar putea fi esențială livrarea unui produs expediat. De aceea, menționați astfel de sarcini și în restante.
Incrementări ale produsului
Acest lucru ne aduce la ultimul artefact scrum, care este măririle produsului. După cum este definit de ghidul scrum, un Increment este suma tuturor Articole din restante de produse finalizat în timpul unui Sprint și valoarea incrementelor tuturor Sprinturilor anterioare. După cum știm bine până acum, Scrum este un proces iterativ.
Rezultatul fiecărei iterații este acest increment al produsului și fiecare astfel de increment al produsului ajută echipa să facă un pas mai aproape de livrarea produsului final.
Ceea ce înseamnă acest lucru este că orice a fost rezultatul sprintului este o creștere. Evident, pentru ca rezultatul să fie considerat un increment, acesta ar trebui să îndeplinească mai întâi definiția predefinită a lui done, adică rezultatul final ar trebui să fie un produs utilizabil, care să poată fi „expediat”.
Poate fi verificat, utilizat și testat pentru a se asigura că este într-adevăr „realizat” conform definiției și, dacă proprietarul produsului dorește, poate fi eliberat și pentru a intra în direct.
Cel mai important lucru pentru a livra această creștere a produsului este să înțelegeți în comun „definiția faptului”, care este înțeleasă de toți.
Echipa scrum nu ar trebui să aibă niciodată dubii dacă ceea ce fac vor fi acceptate sau nu. Dacă există vreo îndoială, definiția „făcut” ar trebui să fie suficient de completă pentru a-i îndruma cu privire la modul de procedare în continuare. Bazându-se doar pe această definiție, echipa scrum decide câte articole din restanțe de produse să aleagă pentru sprint.
Acesta este minimul, așa cum se așteaptă din sprint.
Concluzie
Din acest tutorial, am înțeles care sunt cele 3 artefacte scrum, care le deține împreună cu unele dintre cele mai bune practici care ne-ar ajuta să creăm artefacte de calitate mai bună. În următoarele tutoriale ale acestei serii, vom discuta despre evenimentele Scrum și vom vedea cum să executăm aceste evenimente.
În viitorul nostru tutorial despre ‘Scrum Evenimente , ’Vom discuta în detaliu fiecare eveniment Scrum!
Lectură recomandată
- Evenimente Scrum: Time Boxing, Sprint Planning, Daily Stand-up și Backlog Refinement
- Roluri și responsabilități ale echipei Scrum: Scrum Master și proprietar de produs
- Tutorial JIRA Scrum Board: Manevrarea Scrum cu Jira pentru gestionarea Sprint-ului
- Test online Agile Scrum: testați-vă cunoștințele despre Agile Scrum
- Rolul analiștilor de afaceri în SCRUM și de ce este un QA cel mai bun pentru acest rol?
- Defect Triaging în Scrum: Cum este organizat într-o configurare Scrum
- Exemple de rapoarte de erori pentru aplicații web și produse
- Top 9 cele mai bune software PLM în 2021 pentru a vă gestiona ciclul de viață al produsului