Scrum este un cadru de lucru agil prin care o echipă mică transformă o listă ordonată de cerințe în rezultate utilizabile, livrate în cicluri scurte și fixe numite sprinturi. Este probabil cel mai răspândit cadru agil și, deși s-a născut în dezvoltarea de software, este folosit și în marketing, în echipe de produs sau în proiecte interne. Regulile lui sunt puține și sunt descrise într-un document scurt, Ghidul Scrum (The Scrum Guide), scris de Ken Schwaber și Jeff Sutherland și revizuit periodic.
Scrum se bazează pe empirism: decizi pe baza a ceea ce observi, nu a ceea ce ai presupus la început. Cei trei piloni sunt transparența (munca și progresul sunt vizibile pentru toți), inspecția (verifici des rezultatele și modul de lucru) și adaptarea (schimbi ce nu funcționează cât mai repede). Toate rolurile, evenimentele și artefactele de mai jos există ca să susțină acești trei piloni.
Cum funcționează Scrum, pe scurt
Scrum funcționează ca un ciclu care se repetă: echipa alege din lista de cerințe ce poate livra într-un sprint, lucrează, prezintă rezultatul, discută cum poate lucra mai bine și începe imediat sprintul următor. Fiecare sprint are aceeași durată, de cel mult o lună, iar un sprint nou începe imediat după încheierea celui precedent.
Fluxul unui sprint arată așa:
- Planificarea sprintului: echipa stabilește obiectivul sprintului și alege elementele din backlog.
- Lucrul zilnic, cu o întâlnire scurtă de sincronizare în fiecare zi.
- Analiza sprintului: rezultatul este prezentat părților interesate și se discută ce urmează.
- Retrospectiva sprintului: echipa analizează modul de lucru și alege îmbunătățiri.
Dacă vrei să înțelegi mai întâi locul lui Scrum printre metodologiile de proiect, comparația dintre abordarea predictivă și cea agilă este în Agile și Waterfall: comparație între metodologiile de proiect.
Cele trei roluri din echipa Scrum
O echipă Scrum are trei responsabilități distincte: Product Owner, Scrum Master și Developers (dezvoltatorii). Echipa este mică, de regulă de cel mult zece oameni, multidisciplinară (are toate competențele necesare pentru a livra) și se autoorganizează: decide singură cine face ce și cum.
| Rol | Ce face | Ce nu face |
|---|---|---|
| Product Owner (responsabilul de produs) | maximizează valoarea produsului, ordonează backlogul, formulează obiectivul produsului, decide ce intră și ce iese | nu împarte sarcini oamenilor și nu le spune cum să lucreze |
| Scrum Master | ajută echipa și organizația să aplice Scrum, înlătură obstacolele, facilitează evenimentele, sprijină îmbunătățirea continuă | nu este șeful echipei și nu ia decizii de produs |
| Developers (dezvoltatorii) | planifică sprintul, realizează incrementul, respectă definiția lui „gata”, se adaptează zilnic spre obiectivul sprintului | nu primesc sarcini atribuite din afară în timpul sprintului |
Termenul „dezvoltatori” nu înseamnă doar programatori: include pe oricine face munca efectivă, de la designeri și testeri la specialiști în marketing sau analiști.
Product Owner: o singură persoană, nu un comitet
Product Owner-ul este o persoană, nu un grup. Poate consulta mulți oameni, dar deciziile despre ordinea priorităților îi aparțin, iar organizația trebuie să le respecte. Un Product Owner indisponibil sau fără autoritate reală este una dintre cauzele principale pentru care Scrum nu dă rezultate.
Scrum Master: lider care servește echipa
Scrum Master-ul este un lider care își măsoară succesul prin eficiența echipei, nu prin autoritate. Facilitează, învață echipa practicile, protejează sprintul de întreruperi și lucrează cu restul organizației ca obstacolele să fie înlăturate. Pentru un manager obișnuit cu controlul direct, rolul cere o schimbare de stil asemănătoare celei descrise în ghidul despre delegare.
Sprintul, inima cadrului
Sprintul este un interval fix, de cel mult o lună, în care echipa creează un increment utilizabil care se apropie de obiectivul produsului. Multe echipe aleg sprinturi de două săptămâni: suficient de lungi pentru un rezultat util, suficient de scurte pentru feedback des.
Reguli importante ale sprintului:
- nu se fac schimbări care ar pune în pericol obiectivul sprintului;
- calitatea nu scade pentru a încăpea mai mult în sprint;
- backlogul produsului este rafinat pe parcurs, după nevoie;
- domeniul sprintului poate fi clarificat și renegociat cu Product Owner-ul pe măsură ce echipa află mai multe.
Un sprint poate fi anulat doar dacă obiectivul lui devine inutil, de exemplu pentru că firma a schimbat direcția, iar decizia aparține Product Owner-ului. Anularea este rară și costisitoare, de aceea sprinturile scurte reduc riscul.
Cele patru evenimente și duratele lor maxime
Scrum are patru evenimente formale în interiorul sprintului, fiecare cu o durată maximă (în engleză timebox). Duratele din tabel sunt limitele pentru un sprint de o lună; la sprinturi mai scurte, evenimentele sunt de regulă mai scurte.
| Eveniment | Scop | Participanți | Durată maximă (sprint de o lună) |
|---|---|---|---|
| Planificarea sprintului (Sprint Planning) | de ce contează sprintul, ce se livrează, cum se face munca | toată echipa Scrum, invitați după nevoie | 8 ore |
| Întâlnirea zilnică (Daily Scrum) | inspectarea progresului spre obiectivul sprintului, ajustarea planului zilei | dezvoltatorii | 15 minute |
| Analiza sprintului (Sprint Review) | prezentarea rezultatului, discutarea pașilor următori cu părțile interesate | echipa Scrum și părțile interesate | 4 ore |
| Retrospectiva sprintului (Sprint Retrospective) | îmbunătățirea modului de lucru, a calității și a colaborării | toată echipa Scrum | 3 ore |
Planificarea sprintului
Planificarea răspunde la trei întrebări: de ce este valoros sprintul (obiectivul sprintului), ce se poate termina (elementele alese din backlog) și cum se va face munca (descompunerea în sarcini, de regulă de cel mult o zi). Dezvoltatorii aleg cât pot livra, pe baza capacității lor și a rezultatelor din sprinturile anterioare.
Întâlnirea zilnică
Întâlnirea zilnică durează cel mult 15 minute, la aceeași oră și în același loc, ca să reducă complexitatea. Formatul este la alegerea dezvoltatorilor; o variantă răspândită este ca fiecare să spună ce a făcut, ce urmează și ce îl blochează, dar scopul real este planul pentru ziua următoare, nu raportarea către șef. Discuțiile detaliate continuă după întâlnire, doar cu cei implicați. Regulile generale despre ședințe scurte și utile sunt în Ședințele eficiente: cum le pregătești, conduci și închei.
Analiza sprintului
Analiza nu este o simplă demonstrație, ci o sesiune de lucru cu părțile interesate: se arată ce s-a realizat, se discută ce s-a schimbat în context și se ajustează backlogul pentru perioada următoare.
Retrospectiva
Retrospectiva încheie sprintul. Echipa discută ce a mers bine, ce probleme au apărut și cum au fost rezolvate, apoi alege cele mai utile îmbunătățiri, care pot intra chiar în backlogul sprintului următor. Principiile unei retrospective bune, aplicate la scara întregului proiect, sunt descrise în Retrospectiva de proiect: cum tragi lecțiile la final.
Artefactele și angajamentele lor
Scrum are trei artefacte, fiecare legat de un angajament care dă un reper clar de progres. Artefactele fac munca transparentă; angajamentele spun față de ce măsori progresul.
| Artefact | Ce conține | Angajamentul asociat |
|---|---|---|
| Backlogul produsului (Product Backlog) | lista ordonată, în continuă schimbare, a tot ce ar putea fi nevoie pentru produs | obiectivul produsului (Product Goal), ținta pe termen lung |
| Backlogul sprintului (Sprint Backlog) | elementele alese pentru sprint plus planul de livrare | obiectivul sprintului (Sprint Goal), motivul pentru care sprintul contează |
| Incrementul (Increment) | rezultatul utilizabil, adăugat la incrementele anterioare | definiția lui „gata” (Definition of Done), standardul de calitate |
Definiția lui „gata” este descrierea formală a stării în care un element este considerat terminat: de exemplu, testat, revizuit de un coleg, documentat, publicat. Un element care nu respectă definiția nu se prezintă la analiză ca fiind livrat și se întoarce în backlog. Fără o definiție clară, „aproape gata” devine o sursă permanentă de surprize.
Rafinarea backlogului, adică descompunerea, clarificarea și estimarea elementelor, este o activitate continuă, făcută de dezvoltatori împreună cu Product Owner-ul. Multe echipe îi dedică un interval fix în fiecare săptămână.
Estimarea și urmărirea progresului
Ghidul Scrum nu impune o metodă de estimare, dar multe echipe folosesc puncte de efort (în engleză story points), o estimare relativă a mărimii și complexității unui element, comparat cu altele. Puncte de efort nu înseamnă ore: un element de 5 puncte este aproximativ de două ori mai mare decât unul de 2–3 puncte, indiferent cine îl face.
Practici complementare frecvente:
- Estimarea prin consens (în engleză planning poker): fiecare membru alege în paralel o valoare, apoi se discută diferențele mari.
- Viteza echipei (în engleză velocity): suma punctelor livrate într-un sprint, folosită ca reper de capacitate pentru sprintul următor, nu ca indicator de performanță între echipe.
- Graficul de ardere (în engleză burndown chart): munca rămasă în sprint, zi de zi, care arată devreme dacă obiectivul este în pericol.
Sfat: Nu compara viteza între echipe și nu o transforma în țintă. Punctele sunt relative la fiecare echipă; când devin o țintă, oamenii încep să umfle estimările, iar reperul își pierde valoarea.
Metodele de estimare, inclusiv cele în ore și zile, sunt comparate în Estimarea duratei și a costurilor unui proiect: metode uzuale.
Cum pornești Scrum într-o echipă
Pornirea Scrum reușește când începi cu regulile de bază aplicate disciplinat și îmbunătățești pe parcurs, nu cu toate practicile deodată. Pașii de mai jos se potrivesc unei echipe care nu a lucrat niciodată în sprinturi.
- Clarifici rolurile: cine este Product Owner, cine este Scrum Master, cine sunt dezvoltatorii. Evită ca managerul ierarhic al echipei să fie și Scrum Master.
- Scrii obiectivul produsului într-o frază și construiești o primă versiune a backlogului.
- Stabilești definiția lui „gata” împreună cu echipa.
- Alegi durata sprintului, de obicei două săptămâni, și fixezi calendarul evenimentelor.
- Faci primul sprint cu așteptări modeste; primele sprinturi servesc la calibrare.
- Folosești fiecare retrospectivă pentru o singură îmbunătățire concretă.
- Revizuiești după trei–patru sprinturi ce funcționează și ce trebuie adaptat la contextul firmei.
Echipa va trece probabil printr-o perioadă de frecări la început, ca orice echipă nouă; fazele obișnuite sunt descrise în Etapele dezvoltării unei echipe după modelul Tuckman.
Greșeli frecvente în aplicarea Scrum
Majoritatea problemelor nu vin din Scrum, ci din aplicarea lui parțială sau din păstrarea vechilor obiceiuri sub nume noi.
- Product Owner absent sau fără autoritate, care nu poate decide prioritățile.
- Întâlnirea zilnică transformată în raportare către manager, de 40 de minute.
- Sprinturi supraîncărcate, cu elemente rămase mereu nefinalizate.
- Schimbări impuse în mijlocul sprintului, de către oameni din afara echipei.
- Retrospective sărite când „nu e timp”, exact când ar fi mai necesare.
- Lipsa definiției lui „gata”, cu elemente „aproape terminate” care se adună.
- Viteza folosită pentru a compara oameni sau echipe.
Recapitulare: Scrum în câteva idei
Scrum este un cadru simplu de descris și greu de aplicat bine, pentru că cere transparență, disciplină și autonomie reală pentru echipă. Echipa mică livrează la fiecare sprint un rezultat utilizabil, îl arată părților interesate și își îmbunătățește constant modul de lucru. Pentru locul lui Scrum în tabloul general al proiectelor, vezi ghidul de management de proiect, iar pentru o alternativă cu flux continuu, Kanban.
De reținut:
- trei roluri: Product Owner, Scrum Master, dezvoltatori;
- sprinturi de cel mult o lună, de obicei două săptămâni;
- patru evenimente cu durate maxime: planificare, întâlnire zilnică, analiză, retrospectivă;
- trei artefacte, fiecare cu un angajament: obiectivul produsului, al sprintului și definiția lui „gata”;
- estimarea în puncte este opțională și relativă la fiecare echipă.
Întrebări frecvente
Cât durează un sprint în Scrum?
Cel mult o lună, iar durata rămâne constantă de la un sprint la altul. Cele mai multe echipe aleg sprinturi de două săptămâni.
Poate managerul echipei să fie Scrum Master?
Tehnic se poate, dar nu este recomandat. Scrum Master-ul trebuie să faciliteze și să protejeze echipa, iar relația ierarhică îi face pe oameni mai reticenți să semnaleze probleme deschis.
Câți oameni poate avea o echipă Scrum?
De regulă cel mult zece, incluzând Product Owner-ul și Scrum Master-ul. Când munca cere mai mulți oameni, se formează mai multe echipe care lucrează pe același produs, cu același backlog și același Product Owner.
Ce se întâmplă cu sarcinile neterminate la final de sprint?
Se întorc în backlogul produsului, unde Product Owner-ul le reordonează. Nu se prezintă ca livrate și nu se prelungește sprintul pentru ele.
Este obligatoriu să estimăm în puncte de efort?
Nu. Ghidul Scrum nu impune o metodă de estimare. Echipa poate folosi ore, mărimi relative sau poate număra elementele livrate, cu condiția ca metoda să o ajute să planifice realist.
