în acest articol introductiv ne uităm la mecanica unui Sprint și la modul în care se așteaptă ca membrii echipei să colaboreze pentru a produce o creștere a calității lansării.

prima zi: planificarea sprintului

întreaga echipă, inclusiv proprietarul produsului, se întâlnește în prima zi a sprintului și desfășoară o sesiune de planificare Sprint. Acesta este primul lucru care se întâmplă imediat ce începe sprintul.

pregătirea

planificarea Sprint ar trebui să fie pregătite pentru. Cea mai importantă pregătire este să se asigure că restanțele de produse au fost rafinate la un nivel adecvat de detaliu, cu estimări și criterii de acceptare (acesta este scopul rafinării restanțelor de produse). Apoi, proprietarul produsului ar fi trebuit să comande lucrul la restanțele produsului și să aibă o idee generală despre cum să negocieze un obiectiv Sprint valoros cu echipa. Opțiunile de negociere a unui obiectiv ar fi trebuit, de asemenea, luate în considerare în timpul rafinării și reflectate în ordonarea restanțelor. De asemenea, echipa ar trebui să aibă o idee despre capacitatea lor pentru acest Sprint, adică cât de multă muncă cred că pot prelua. Este posibil să își poată folosi experiența cu sprinturile anterioare pentru a-i ajuta să stabilească dimensiunea acestui buget.

mai întâi planificați valoarea care va fi livrată

fiecare Sprint ar trebui să aibă ca rezultat o creștere valoroasă a lucrărilor finalizate, potrivite și pregătite pentru eliberare imediată. Proprietarul produsului este în întregime responsabil pentru ceea ce înseamnă” valoare ” și ar fi trebuit să comande restanțele produsului în așa fel încât valoarea să poată fi maximizată de echipă, sprint-by-sprint. Primul lucru pe care trebuie să-l facă echipa este, prin urmare, să planifice ce elemente din restanțele de produse ar trebui să fie lucrate în acest Sprint, astfel încât cea mai bună valoare să poată fi livrată până la sfârșitul acesteia.

pentru a face acest lucru, Echipa lucrează cu Product Owner pentru a selecta cele mai valoroase elemente din Backlog-ul produsului care se potrivește capacității lor proiectate pentru Sprint. Țineți cont de faptul că fiecare element de pe Product Backlog ar fi trebuit să fi fost dat o estimare de echipa, astfel încât ei vor ști aproximativ cât de mult de lucru este probabil să fie implicate.

asigurați-vă că sunteți de acord cu un obiectiv Sprint

această selecție de lucru ar trebui să fie coezivă și nu doar o grupare de elemente independente și disparate. Amintiți-vă că un Sprint este o oportunitate de timp pentru a realiza ceva semnificativ. De exemplu, până la sfârșitul Sprintului s-ar putea să fi fost livrată o caracteristică coerentă sau un risc semnificativ va fi atenuat. Scopul Sprint este o expresie simplă a acestui scop, a semnificației generale a lucrării selectate și a coerenței din spatele selecției.

un obiectiv bun de Sprint va permite echipei să demonstreze concentrarea și angajamentul și să permită colaborarea și re-planificarea muncii, astfel încât să fie îndeplinită.

planul următor cum se va face munca

un Sprint Backlog este mai mult decât o selecție de lucru cu un scop final în minte. Este, de asemenea, un plan pentru modul în care acest obiectiv va fi atins și modul în care va fi efectuată munca asociată. Acest lucru se poate face prin identificarea și ordonarea sarcinilor tehnice care ar putea fi implicate. De fapt, Sprint Backlog este un plan pentru îndeplinirea obiectivului Sprint și o prognoză a muncii care va trebui făcută.

proprietarul produsului nu trebuie să fie prezent pentru această parte a planificării Sprint, deoarece depinde de echipă să planifice această prognoză la nivel tehnic. Cu toate acestea, proprietarul produsului ar trebui să fie disponibil, chiar dacă numai de la distanță, pentru a răspunde la orice întrebări pe care echipa le poate avea și pentru a oferi orice clarificare care ar putea fi necesară cu privire la domeniul de aplicare al lucrării. Dacă se așteaptă mai multe versiuni în timpul sprintului, acest lucru ar trebui convenit cu PO și contabilizat în Sprint Backlog.

până la sfârșitul planificării Sprintului, o echipă ar trebui să fie încrezătoare că a făcut o prognoză bună a muncii care va fi necesară pentru a îndeplini Obiectivul Sprintului. Acesta va fi capturat acest plan în restanțele Sprint pe care echipa le deține în întregime. Echipa ar trebui să poată începe implementarea acestui plan imediat și cu o înțelegere clară – cum ar fi o ardere Sprint – a cât de multă muncă rămâne la un moment dat.

în fiecare zi, în fiecare zi

odată ce echipa și-a planificat Sprint Backlog-ul, pot începe munca. Dacă au planificat lucrurile ca sarcini, vor colabora între ei, ca echipă, pentru a se asigura că aceste sarcini sunt finalizate. Ei vor fi capabili de a urmări progresul lor prin utilizarea lor bord sarcină și Burndown lor Sprint de lucru rămase.

fiecare membru al echipei va fi sigur de a păstra Scrum Task Board și Sprint Burndown actualizat, astfel încât informațiile pot fi invocate de către alții. Un radiator de informații ar trebui să spună întotdeauna adevărul.

țineți o grămadă zilnică

în fiecare zi lucrătoare, în același timp, echipa de dezvoltare se va întâlni și va planifica ce vor face pentru a-i apropia de Obiectivul Sprintului. Această întâlnire se numește Daily Scrum și nu ar trebui să dureze mai mult de 15 minute.

ar trebui să participe doar membrii echipei de dezvoltare, deoarece planul de lucru le aparține în întregime. Este o oportunitate în timp de a re-planifica restanțele Sprintului ca urmare a noilor descoperiri și lecții învățate în timpul sprintului. Întreaga echipă ar trebui să participe. Fiecare membru al echipei ar trebui să poată explica:

• ce au făcut ieri pentru a ajuta echipa să îndeplinească Obiectivul Sprintului
• ce intenționează să facă astăzi pentru a ajuta echipa să îndeplinească Obiectivul Sprintului
• orice impedimente care le stau în cale

până la sfârșitul grămezii zilnice, echipa ar trebui să aibă un plan clar pentru următoarele 24 de ore și o înțelegere a modului în care va trebui să colaboreze pentru a-l atinge. Ei ar trebui să aibă, de asemenea, o listă a oricăror impedimente care necesită atenția Scrum Master.

rafinați Product Backlog

în Scrum, rafinarea Product Backlog nu este un eveniment formal, ci o activitate continuă – procesul de adăugare a detaliilor, ordinii și estimărilor la elementele Product Backlog, cum ar fi poveștile utilizatorilor. Depinde de echipele Scrum să decidă cât de des să facă acest lucru, deși este cu siguranță o idee bună pentru ei să construiască rafinament în rutina lor zilnică. Rafinarea nu ar trebui să dureze mai mult de 10% din timpul total al unei echipe în timpul unui Sprint. Pentru majoritatea echipelor, o jumătate de oră pe zi poate fi adecvată, deși unii pot prefera să petreacă o oră sau două de câteva ori pe săptămână. Important este să vă asigurați că întârzierea produsului este rafinată în timp util, astfel încât planificarea sprintului să poată avea loc fără impediment. Întreaga echipă, inclusiv proprietarul produsului, ar trebui să participe.

o sesiune de rafinare începe de obicei cu proprietarul produsului care prezintă echipei Lista de produse curentă. Backlog-ul poate fi ținut în mai multe forme, cum ar fi un Scrum Board electronic sau alt instrument de colaborare, sau poate fi pur și simplu o foaie de calcul. Un proiector sau un ecran partajat poate fi foarte util.

echipa începe în partea de sus a Product Backlog și de a lucra drumul lor în jos, rafinarea fiecare element la rândul său. Ei vor examina fiecare și vor discuta domeniul său de aplicare și criteriile de acceptare care vor fi necesare pentru finalizarea acestuia. Fiecare element va fi apoi estimat folosind o tehnică, cum ar fi Planificarea Poker. Un element de mare pot fi defalcate în cele mai mici, care captura mai mare detaliu. Epopeile pot fi descompuse în povești de utilizator, de exemplu.

echipa se oprește după expirarea intervalului de timp al sesiunii. Ei vor reîncepe în cazul în care au rămas data viitoare, în cele din urmă începând de la partea de sus din nou, astfel încât restante este ținut la zi.

colaborați întotdeauna

în practica agilă, membrii echipei nu lucrează niciodată izolați – dacă ar face-o, nu ar fi o echipă. De fapt, munca în echipă este atât de importantă încât rolul este mai degrabă echipa de dezvoltare decât dezvoltatorul.

aceasta înseamnă că fiecare membru al echipei de dezvoltare trebuie să colaboreze cu colegii săi pe tot parcursul zilei, deoarece aceștia sunt responsabili în comun pentru progresul muncii. Orice probleme sau eșecuri sunt deținute în comun de echipă, precum și succesele acestora. Colaborarea nu este ceva care este limitat la evenimente, cum ar fi Scrum de zi cu zi, dar se aplică la tot ceea ce face echipa de-a lungul fiecărui Sprint întreg.

Exemple de colaborare includ:

• ajutarea colegilor să finalizeze lucrările în curs înainte de a aduce noi lucrări dintr-un backlog
• programare pereche, cum ar fi luarea pe rând pentru a utiliza tastatura și a ajuta și a verifica munca celuilalt
• Peer review
• cerând ajutor și dorind să-i dea
• mergând acolo unde este lucrarea și ajutând, în loc să aștepte ca munca să le fie transmisă
• asigurându-vă că toate lucrările îndeplinesc de fapt definiția făcut
• apelarea unei grămezi pentru a rezolva problemele care necesită atenția imediată a echipei
• ridicarea impedimentelor la Scrum Master, astfel încât acestea să poată fi manipulate în timp util
• actualizarea unei Scrum Task board și burndown chart, astfel încât informațiile să fie actualizate și să se poată baza pe
• schimbul de abilități și cunoștințe

ultima zi: revizuire și retrospectivă

țineți o recenzie Sprint

a colaborat eficient, vor fi lucrat împreună pentru a îndeplini Obiectivul Sprintului, gestionând orice riscuri și ajustându-și planurile după cum este necesar. Ei au demonstrat controlul pe tot parcursul Sprintului printr-o ardere uniformă a muncii rămase, în care fiecare membru a văzut-o ca pe responsabilitatea personală de a ajuta la finalizarea lucrărilor în curs. Vor avea o creștere valoroasă pentru a demonstra proprietarului produsului și oricăror părți interesate invitate. O revizuire este ceva la care o echipă ar trebui să aștepte cu nerăbdare.

este, de asemenea, ceva pentru care o echipă trebuie să se pregătească. Trebuie să se acorde suficient timp pentru demonstrarea lucrărilor efectuate. Sarcinile pot fi planificate pe un Sprint Backlog în acest scop, pentru a vă asigura că revizuirea face dreptate muncii efectuate și valorii care este acum disponibilă. De asemenea, dacă proprietarul produsului crede că ar fi o idee bună să invite părțile interesate, atunci acele invitații ar fi trebuit trimise. Revizuirea este o oportunitate de a sărbători munca care a fost făcută și de a prezenta realizările lor, astfel încât încrederea este inspirată și o investiție continuă în echipă ar putea fi justificată.

O revizuire Sprint este, de asemenea, o oportunitate de Inspectare și adaptare. Este un moment bun pentru Product Owner pentru a explica cât de bine produsul este performante, pentru a obține feedback-ul de prima mana de la orice părți invitate, și să tragă orice lecții care ar putea fi utilizate pentru a îmbunătăți produsul restante în continuare. Dacă orice lucrare nu a fost finalizată, indiferent de motiv, atunci aceasta va fi, de asemenea, revizuită și re-estimată pe lista de produse pentru o posibilă planificare în sprinturi viitoare.

apoi efectuați o retrospectivă Sprint

revizuirea Sprint a analizat produsul și valoarea livrată, la munca care a fost făcută și sincer și sincer la orice lucrare care nu a fost făcută, indiferent de motiv.
următorul lucru de făcut este de a efectua o retrospectivă Sprint. O retrospectivă ia în considerare procesul pe care echipa îl urmează. Funcționează cât se poate de eficient? În general, este mai bine să țineți retrospectiva imediat după revizuire, deoarece prima poate introduce idei pentru examinare în cea de-a doua.

întreaga echipă de dezvoltare, Product Owner-ul și Scrum Master-ul trebuie să participe la retrospectivă, deoarece toată lumea este responsabilă în comun pentru succesul muncii echipei. Este foarte important să aveți o sesiune liberă și deschisă, care să ajungă la inima oricăror probleme și să identifice acțiunile care vă vor ajuta să le rezolvați. O retrospectivă poate începe cu următoarea declarație:

„indiferent de ceea ce descoperim, înțelegem și credem cu adevărat că fiecare a făcut cea mai bună treabă pe care a putut-o, având în vedere ceea ce știa la acea vreme, abilitățile și abilitățile lor, resursele disponibile și situația la îndemână.”

într-un „Retro”, toată lumea are o voce egală. O abordare, pe care Scrum Master o poate facilita, este identificarea:

• lucruri care au mers bine
• lucruri care nu au mers atât de bine
• idei de îmbunătățire
• strigăte pentru membrii echipei care au făcut ceva excepțional

stabilirea unei linii de timp poate ajuta la împrospătarea amintirilor participanților despre evenimente semnificative în timpul sprintului.