Istoria Scrum
De la publicarea raportului lui Winston Royce „Managing the Development of Large Software Systems” în 1970, mulți au încercat să găsească o metodologie care ar putea elimina dezavantajele modelului de dezvoltare Waterfall. O alternativă la „cascada” a fost metoda Scrum, care va fi discutată acum.
Scrum și-a primit numele în 1986 din lucrarea lui Takeuchi și Nonaki The New Rules for New Product Development. Acest document susține că cea mai eficientă modalitate de a atinge obiectivul este de a oferi dezvoltatorilor un plan clar de acțiune.
În 1995, a apărut un alt ghid, „Software Development with Scrum”, de Sutherland și Schweiber. Această publicație a fost actualizată de mai multe ori. Acum este considerat ghidul principal pentru dezvoltarea acestei metode. Versiunea actuală a Ghidului Scrum conține informații actualizate în 2020.
Principalele prevederi ale Ghidului Scrum sugerează că șablonul de management al proiectului ar trebui să se bazeze pe faptul că dezvoltatorii livrează produsul finit în intervalul de timp convenit - sprinturi. Pentru implementarea cu succes a Scrum, se recomandă utilizarea unei structuri formate din mai multe elemente: roluri, evenimente, reguli și artefacte.
Roluri în Scrum
Există trei roluri în Scrum, toate formând o echipă Scrum:
Clientul produsului software este cea mai importantă persoană din proiect, deoarece numai el înțelege pe deplin valoarea acestuia pentru afacere. Clientul explică dezvoltatorilor nevoile utilizatorilor viitorului produs, dar nu este responsabil pentru partea tehnică a procesului de dezvoltare. Clientul stabilește și prioritatea atunci când creează anumite elemente sau funcții în produs.
Dezvoltatorii sunt încredințați cu implementarea sarcinilor tehnice, a căror funcționalitate transversală depinde de domeniul de aplicare. Dezvoltatorii sunt ocupați cu crearea stocului de sprint, scrierea codului, adaptarea proiectului la obiectivul sprintului și alte sarcini.
Scrum Master este facilitatorul echipei Scrum. Oferă asistență clienților și dezvoltatorilor. Mai simplu spus, Scrum Master este ocupat să comunice între cei care nu sunt implicați în proiect și cei care scriu codul. Uneori, diferite echipe de codificatori din aceeași companie mare comunică și coordonează la adunările generale ale scrum master-ilor acestor echipe.
Evenimente în Scrum
Există 5 tipuri de evenimente scrum:
Sprintul este cea mai importantă parte a Scrum. Include planificarea sprintului, stand-up-urile zilnice (scrum zilnic), revizuirea și retrospectiva sprintului.
Planificarea sprintului. Toți membrii echipei Scrum participă la elaborarea unui plan pentru viitorul sprint. Aici este prezentată ideea de produs și fiecare membru al echipei își poate exprima părerea, ce crede despre asta. Apoi, la întâlnire, se stabilesc prioritățile și se anunță termenele limită.
Daily Scrum este un eveniment zilnic scurt de scrum, care nu durează mai mult de 15 minute. De obicei, se face pentru a planifica munca codificatoarelor pentru azi sau mâine. La Daily Scrum, puteți discuta probleme actuale. Toți dezvoltatorii implicați în proiect sunt obligați să participe la un astfel de atelier. Prezența unui Scrum Master este permisă, dar nu obligatorie.
Sprint Review (Demo) - Afișează rezultatele create în timpul sprintului. De obicei, acest eveniment are loc în etapa finală. La ea participă toate persoanele interesate.
Sprint Retrospective - discutarea rezultatelor sprintului. Membrii echipei își împărtășesc părerea despre modul în care au făcut față sarcinilor care le-au fost atribuite și despre cum să îmbunătățească rezultatele muncii în viitor.
În plus, rafinarea backlog-ului este uneori efectuată - Backlog Refinement. Se discută despre elementele din restante, pregătirea pentru următorul sprint și prioritizarea sarcinilor curente.
Artefacte
Artefactele Scrum sunt munca care are loc la sfârșitul unui proiect sau sprint. Există trei artefacte - backlog de produs, backlog de sprint și increment. Fiecare dintre ele este necesar pentru livrarea la timp a software-ului către utilizatori. Există și artefacte auxiliare (diagrame de ardere și multe altele).
Componente incluse în artefactele de sprint:
Product backlog - funcții de interfață și backend.
Un sprint backlog este o listă de sarcini care trebuie efectuate în timpul unei iterații. Ele sunt convenite înainte de începerea sprintului.
Increment - Numărul total de elemente de backlog software create în timpul sprintului și valoarea incrementelor care au fost făcute înainte de acesta. Noul increment terminat trebuie afișat înainte de sfârșitul sprintului. Aceasta înseamnă că aveți o versiune de lucru care îndeplinește cerințele echipei scrum.
Element de backlog de produse - trebuie completat în timpul iterației de sprint. De regulă, elementul este împărțit în mai multe sarcini mici.
Scopul sprintului sunt sarcinile care trebuie finalizate (creați un element de backlog sau altă sarcină).
Un burndown de sprint este munca rămasă înainte de sfârșitul unui sprint. Graficul de ardere este fie ascendent, fie descendent. Totul depinde de dificultățile cu care se confruntă membrii echipei în timpul lucrului. Nu este un indicator al progresului, ci doar o modalitate de rezolvare a problemelor și un stimulent.
Product Release/Product Burn-Down Chart este un grafic desenat de Scrum Master înainte de sfârșitul următorului sprint. Axa orizontală este sprinturile, axa verticală este cantitatea de muncă rămasă.
Reguli-cadru Scrum
Rolurile, evenimentele și artefactele sunt baza Scrum, dar există și alte reguli în afară de aceasta. Toate acestea sporesc eficiența procesului de lucru. Iată o listă a acestor reguli:
- Echipa Scrum include clientul software, Scrum Master și dezvoltatorii.
- Toate sprinturile ar trebui să aibă aceeași lungime.
- După finalizarea unui sprint, începe imediat munca la unul nou.
- Un sprint începe întotdeauna cu un plan.
- Membrii echipei au o scrum de dimineață la începutul zilei de lucru.
- Fiecare sprint este revizuit în timpul fiecărui sprint. Acest lucru îmbunătățește comunicarea dintre echipă și părțile interesate.
- Nu este recomandat să schimbați acumularea de sprint în timpul sprintului.
Limitări în Scrum
Alături de avantajele evidente, Scrum are și dezavantaje:
- Scrum duce adesea la o scădere a cantității de muncă prestată din cauza lipsei unui termen comun.
- Cu o implicare scăzută sau lipsă de dorință de a coopera între participanții la proiect, există șanse considerabile de a eșua rezultatul.
- Structura Scrum este dificil de utilizat în echipe mari, dar totuși este posibilă. Există cadre de scalare pentru aceasta: LeSS, SAFe, Nexus și altele.
- Plecarea unuia sau mai multor membri din echipa in mijlocul proiectului nu afecteaza foarte bine proiectul.