Iată cum se începe un proiect Scrum pe scurt.
Alegeți un proprietar de produs. Această persoană este cea care are viziunea a ceea ce veți face, realiza sau împlini. Aceștia iau în considerare riscurile și recompensele, ceea ce este posibil, ceea ce poate fi făcut și ceea ce îi pasionează. Alegeți o echipă. Cine vor fi persoanele care vor face efectiv munca? Această echipă trebuie să aibă toate competențele necesare pentru a prelua viziunea proprietarului de produs și a o transforma în realitate. Echipele ar trebui să fie mici, între 3 și 9 persoane este regula de bază. Alegeți un Scrum Master. Acesta este persoana care va îndruma restul echipei prin cadrul Scrum și va ajuta echipa să elimine tot ceea ce o încetinește. Creați și prioritizați un Product Backlog. Aceasta este o listă la un nivel înalt a tot ceea ce trebuie construit sau făcut pentru a transforma acea viziune în realitate. Acest backlog există și evoluează pe parcursul duratei de viață a produsului; este foaia de parcurs a produsului. În orice moment, Product Backlog este o imagine unică și definitivă a tot ceea ce ar putea fi făcut vreodată de către echipă, în ordinea priorităților. Există doar un singur Product Backlog; acest lucru înseamnă că Product Owner este obligat să ia decizii de prioritizare pe întregul spectru. Proprietarul produsului trebuie să se consulte cu toate părțile interesate și cu echipa pentru a se asigura că reprezintă atât ceea ce doresc oamenii, cât și ceea ce poate fi construit. Rafinați și estimați Product Backlog-ul. Este esențial ca persoanele care vor finaliza efectiv elementele din Product Backlog să estimeze cât de mult efort vor necesita. Echipa ar trebui să se uite la fiecare element din Backlog și să vadă dacă acesta este de fapt realizabil. Există suficiente informații pentru a finaliza elementul? Este suficient de mic pentru a fi estimat? Există o definiție a lucrului finalizat, adică toată lumea este de acord asupra standardelor care trebuie îndeplinite pentru a numi ceva finalizat? Creează valoare vizibilă? Fiecare element trebuie să poată fi arătat, demonstrat și, sperăm, să poată fi livrat. Nu estimați Backlog-ul în ore, pentru că oamenii sunt absolut groaznici la acest lucru. Estimați în funcție de mărimea relativă: Mic, Mediu sau Mare. Sau chiar mai bine folosiți secvența Fibonnaci și estimați valoarea punctului pentru fiecare element: 1, 2, 3, 5, 8, 13, 21, etc. Planificarea Sprint. Aceasta este prima dintre întâlnirile Scrum. Echipa, Scrum Master și Product Owner se așează la masă pentru a planifica Sprint-ul. Sprinturile au întotdeauna o durată fixă de timp care este mai mică de o lună. Cei mai mulți oameni rulează acum Sprinturi de una sau două săptămâni. Echipa se uită la partea de sus a Backlog-ului și prognozează cât de mult din acesta poate finaliza în acest Sprint. În cazul în care echipa are câteva Sprint-uri, ar trebui să ia în considerare numărul de puncte pe care le-a realizat în ultimul Sprint. Acest număr este cunoscut sub numele de Viteza echipei. Scrum Master-ul și echipa ar trebui să încerce să crească acest număr în fiecare Sprint. Aceasta este o altă șansă pentru echipă și pentru Product Owner de a se asigura că fiecare înțelege exact modul în care aceste elemente vor îndeplini viziunea. De asemenea, în timpul acestei ședințe, toată lumea ar trebui să convină asupra unui Sprint Goal, adică asupra a ceea ce toată lumea dorește să realizeze în acest Sprint. Unul dintre pilonii Scrum este că, odată ce echipa s-a angajat la ceea ce crede că poate termina într-un Sprint, asta este tot. Acesta nu poate fi schimbat, nu poate fi adăugat la el. Echipa trebuie să fie capabilă să lucreze în mod autonom pe tot parcursul Sprintului pentru a finaliza ceea ce a prognozat că ar putea face. Faceți munca vizibilă. Cel mai comun mod de a face acest lucru în Scrum este de a crea un Scrum Board cu trei coloane: To Do, Doing, Done. Bilețelele autocolante reprezintă elementele care trebuie finalizate, iar echipa le mută pe Scrum Board pe măsură ce sunt finalizate, unul câte unul. O altă modalitate de a face munca vizibilă este de a crea o diagramă de ardere. Pe o axă se află numărul de puncte pe care echipa le-a dus în Sprint, iar pe cealaltă axa este numărul de zile. În fiecare zi, Scrum Master numără numărul de puncte finalizate și le reprezintă grafic pe graficul Burndown. În mod ideal, va exista o pantă descendentă abruptă care să conducă la zero puncte rămase în ultima zi a Sprintului. Daily Stand-up sau Daily Scrum. Aceasta este bătăile inimii Scrum-ului. În fiecare zi, la aceeași oră, timp de cel mult cincisprezece minute, echipa și Scrum Master se întâlnesc și răspund la trei întrebări: Ce ați făcut ieri pentru a ajuta echipa să termine Sprint-ul? Ce veți face astăzi pentru a ajuta echipa să termine Sprintul? Există vreun obstacol care vă blochează pe dumneavoastră sau pe echipă în calea atingerii obiectivului Sprintului? Asta e tot. Asta e toată ședința. Dacă durează mai mult de cincisprezece minute, înseamnă că o faceți greșit. Acest lucru ajută întreaga echipă să știe exact unde se află totul în Sprint. Toate sarcinile vor fi finalizate la timp? Există oportunități de a-i ajuta pe ceilalți membri ai echipei să depășească obstacolele? Nu se atribuie sarcini de sus – echipa este autonomă; ei fac acest lucru. Nu există o raportare detaliată către conducere. Scrum Master-ul este responsabil pentru a face să dispară obstacolele din calea progresului echipei, sau impedimentele. Sprint Review sau Sprint Demo. Aceasta este ședința în care echipa arată ce a realizat în timpul Sprintului. Oricine poate veni, nu numai Product Owner, Scrum Master și echipa, ci și părțile interesate, conducerea, clienții, oricine. Aceasta este o ședință deschisă în care echipa demonstrează ce a reușit să treacă la Realizat în timpul Sprintului. Echipa ar trebui să demonstreze doar ceea ce corespunde definiției de Done. Ceea ce este total și complet finalizat și poate fi livrat fără a mai fi nevoie de alte lucrări. Poate să nu fie un produs finalizat, dar ar trebui să fie o caracteristică finalizată a unui produs. Retrospectiva Sprintului. După ce echipa a arătat ceea ce a realizat în timpul ultimului Sprint – acel lucru care este gata și care poate fi eventual livrat clienților pentru feedback – se așează și se gândește la ceea ce a mers bine, ce ar fi putut merge mai bine și ce poate fi îmbunătățit în următorul Sprint. Care este îmbunătățirea procesului pe care ei, ca echipă, o pot implementa imediat? Pentru a fi eficientă, această întâlnire necesită o anumită maturitate emoțională și o atmosferă de încredere. Principalul lucru de reținut este că nu căutați pe cineva pe care să dați vina, ci analizați procesul. De ce s-a întâmplat așa? De ce am ratat asta? Ce ne-ar putea face să fim mai rapizi? Este esențial ca oamenii, în calitate de echipă, să își asume responsabilitatea pentru procesul și rezultatele lor și să caute soluții în echipă. În același timp, oamenii trebuie să aibă tăria de a aduce în discuție problemele care îi deranjează cu adevărat, într-un mod orientat spre soluții și nu spre acuzații. Iar restul echipei trebuie să aibă maturitatea de a asculta feedback-ul, de a-l asimila și de a căuta o soluție, în loc să fie în defensivă. Până la finalul ședinței, echipa și Scrum Master-ul ar trebui să convină asupra unei îmbunătățiri a procesului pe care o vor implementa în următorul Sprint. Acea îmbunătățire a procesului, numită uneori kaizen, ar trebui să fie introdusă în backlogul următorului Sprint, cu teste de acceptare. În acest fel, echipa poate vedea cu ușurință dacă a implementat cu adevărat îmbunătățirea și ce efect a avut asupra vitezei. Începeți imediat următorul ciclu Sprint, ținând cont de experiența echipei cu impedimentele și îmbunătățirile de proces.
Sursa: Jeff Sutherland, SCRUM The Art of Doing Twice the Work in Half the Time, Penguin Random House, 2014, ISBN: 9781847941107.
