Guidul

Scrum
Ghidul Absolut al Scrum: Regulile Jocului

Iulie 2013
Dezvoltat i susinut de ctre Ken Schwaber i Jeff Sutherland

Cuprins
Scopul Ghidului Scrum .................................................................................................................... 3 Prezentare Scrum ............................................................................................................................ 3 Teoria Scrum ................................................................................................................................... 3 Echipa Scrum ................................................................................................................................... 4 Product Owner-ul ........................................................................................................................ 5 Echipa de Dezvoltare ................................................................................................................... 5 Scrum Master .............................................................................................................................. 6 Evenimentele Scrum (Scrum Events) .............................................................................................. 7 Sprint-ul (The Sprint) ................................................................................................................... 7 Planificarea Sprint-ului (Sprint Planning) .................................................................................... 8 edina Scrum Zilnic (Daily Scrum) .......................................................................................... 10 Revizuirea Sprint-ului (Sprint Review) ....................................................................................... 11 Retrospectiva Sprint-ului (Sprint Retrospective) ....................................................................... 12 Artefacte Scrum ............................................................................................................................ 13 Product Backlog ........................................................................................................................ 13 Sprint Backlog ............................................................................................................................ 14 Incrementul ............................................................................................................................... 15 Transparena artefactului ............................................................................................................. 15 Definiia strii Finalizat (Definition of Done) ...................................................................... 16 End Note ....................................................................................................................................... 16 Mulumiri ...................................................................................................................................... 17 Oamenii ..................................................................................................................................... 17 Istoria ........................................................................................................................................ 17 Traducerea ................................................................................................................................ 17 Schimbri ale ghidului Scrum ntre 2011 i 2013 .......................................................................... 18

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Page | 2

Scopul Ghidului Scrum

Scrum-ul este un cadru pentru dezvoltarea i susinerea produselor complexe. Acest ghid conine definiia Scrum-ului. Aceast definiie const n rolurile, evenimentele, artefactele Scrum-ului precum i regulile care le leag pe acestea mpreun. Ken Schwaber i Jeff Sutherland au dezvoltat Scrum-ul; Ghidul Scrum este scris i furnizat de ei. mpreun, ei stau n spatele Ghidului Scrum.

Prezentare Scrum
Scrum (subst.): un cadru n care oamenii i pot adresa probleme complexe de adaptare, livrnd n acelai timp, n mod productiv i creativ, produse de cea mai mare valoare posibil. Scrum este: Uor Simplu de neles Dificil de stpnit Scrum este un cadru pentru procese care a fost folosit n managementul dezvoltrii de produse complexe nc de la nceputul anilor 1990. Scrum nu este un proces sau o tehnic de construire a produselor; mai degrab este un cadru n care poi folosi diferite procese i tehnici. Scrum clarific eficacitatea relativ a managementului produsului i practicile de dezvoltare astfel nct s se poat face mbuntiri. Cadrul Scrum const n Echipele Scrum i n rolurile, evenimentele, artefactele i regulile asociate acestora. Fiecare component din cadru servete unui anumit scop i este esenial n succesul i utilizarea Scrum-ului. Regulile Scrum leag mpreun evenimentele, rolurile i artefactele, guvernnd relaiile i interaciunea dintre ele. Regulile Scrum sunt descrise n interiorul acestui document. Strategiile specifice de utilizare a cadrului Scrum variaz i vor fi descrise n alt parte.

Teoria Scrum
Scrum este bazat pe o teorie empiric de control a proceselor, sau empirism. Empirismul afirm faptul c sursa cunotinelor este experiena i luarea deciziilor se bazeaz pe ceea ce este tiut. Scrum folosete o abordare iterativ, incremental cu scopul de a optimiza predictibilitatea i de a controla riscul. Trei piloni susin orice implementare a controlului procesului empiric: transparena, inspecia i adaptarea.

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Page | 3

Transparena
Aspecte semnificative ale procesului trebuie s fie vizibile celor responsabili de rezultate. Transparena necesit ca aceste aspecte s fie definite de un standard comun astfel nct observatorii s mprteasc puncte de vedere comune asupra a ceea ce vd. De exemplu: Un limbaj comun referitor la proces trebuie s fie mprtit de ctre toi participanii; i, O definiie comun a statusului Finalizat trebuie mprtit de ctre cei care efectueaz munca i cei care accept munca rezultat.

Inspecia
Utilizatorii Scrum trebuie s inspecteze n mod frecvent artefactele i progresul fcut, astfel nct s detecteze variaiile. Inspecia lor nu trebuie s fie att de frecvent nct s afecteze lucrul n general. Inspeciile sunt cele mai benefice atunci cnd sunt efectuate n mod srguincios la locul de munc.

Adaptarea
Dac un inspector stabilete c unul sau mai multe aspecte ale procesului deviaz n afara unor limite acceptabile, i c produsul rezultat va fi inacceptabil, procesul sau materialul procesat trebuie s fie ajustat. O ajustare trebuie fcut ct mai curnd posibil pentru a minimiza deviaiile ulterioare. Scrum recomand patru evenimente formale n cadrul unui Sprint, pentru inspecie i adaptare, aa cum este descris n seciunea Evenimentele Scrum ale acestui document: Planificarea Sprint-ului (Sprint Planning) edina Scrum Zilnic (Daily Scrum) Revizuirea Sprint-ului (Sprint Review) Retrospectiva Sprint-ului (Sprint Retrospective)

Echipa Scrum
Echipa Scrum este alctuit din Product Owner, Echipa de Dezvoltare i Scrum Master. Echipa Scrum se auto-organizeaz i este inter-funcional. Echipele auto-organizate mai degrab aleg ct de bine s-i fac munca dect s fie direcionai de alii din afara echipei. Echipele inter- funcionale au toate competenele necesare pentru a-i ndeplini munca fr a depinde de alii care nu fac parte din echip. Echipa model n Scrum este proiectat astfel nct s optimizeze flexibilitatea, creativitatea i productivitatea. Echipa Scrum livreaz produsele n mod iterativ i incremental, maximiznd oportunitile de feedback. Livrrile incrementale de produse cu statusul Finalizat asigur c o versiune potenial folositoare a produsului n lucru este mereu disponibil.

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Page | 4

Product Owner-ul
Product Owner-ul este responsabil de maximizarea valorii produsului i a muncii Echipei de Dezvoltare. Modul n care acest lucru este fcut poate varia pe scar larg n funcie de organizaie, Echipa Scrum sau indivizi. Product Owner-ul este singura persoan responsabil de Product Backlog. Managementul Product Backlog-ului include: Exprimarea clar a elementelor din Product Backlog; Ordonarea elementelor din Product Backlog pentru a realiza cel mai bine obiectivele i misiunile; Optimizarea valorii muncii produse de ctre Echipa de Dezvoltare; Garantarea faptului c Product Backlog-ul este vizibil, transparent i clar pentru toi, i c arat la ce va lucra Echipa Scrum n continuare; i, Garantarea faptului c Echipa de Dezvoltare nelege pn la nivelul necesar toate elementele din Product Backlog.

Product Owner-ul poate s fac activitile de mai sus sau poate delega Echipa de Dezvoltare s fac acest lucru. Totui, Product Owner-ul rmne responsabil. Product Owner-ul este o persoan, nu un comitet. Product Owner-ul poate reprezenta interesele unui comitet n Product Backlog, dar cei care vor s schimbe prioritatea elementelor din Backlog trebuie s l conving pe Product Owner. Pentru ca Product Owner-ul s reueasc, ntreaga organizaie trebuie s-i respecte deciziile. Deciziile Product Owner-ului sunt vizibile n coninutul i ordinea elementelor din Product Backlog. Nimnui nu i este permis s i spun Echipei de Dezvoltare s lucreze pe baza unui alt set de cerine, iar Echipei de Dezvoltare nu i este permis s acioneze la ceea ce spune oricine altcineva.

Echipa de Dezvoltare
Echipa de Dezvoltare const din profesioniti care fac din activitatea de livrare un potenial Increment, lansabil pe pia, al produsului Finalizat, la sfritul fiecrui Sprint. Numai membrii Echipei de Dezvoltare creeaz Incrementul. Echipa de Dezvoltare este structurat i mputernicit de ctre organizaie s-i organizeze i s- i gestioneze munca. Sinergia rezultat optimizeaz la nivel global eficiena i eficacitatea Echipei de Dezvoltare. Echipele de Dezvoltare au urmtoarele caracteristici:

Ele se auto-organizeaz. Nimeni (nici mcar Scrum Master-ul) nu spune Echipei de Dezvoltare cum s transforme elementele din Product Backlog n poteniale Incrementuri ale funcionalitii ce pot fi lansate pe pia;

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Page | 5

Echipele de Dezvoltare sunt inter-funcionale i au toate competenele necesare ca echip pentru a crea un Increment al produsului; Scrum nu recunoate nici un titlu pentru membrii Echipei de Dezvoltare altul dect Dezvoltator, indiferent de munca care a fost efectuat de persoana respectiv; nu exist excepii de la aceast regul; Scrum nu recunoate sub-echipe ale Echipei de Dezvoltare, indiferent de anumite domenii particulare cum ar fi testarea sau analiza afacerii; nu exist excepii de la aceast regul; i, Diferii membri ai Echipei de Dezvoltare pot avea competene specializate i zone de focalizare, dar responsabilitatea aparine Echipei de Dezvoltare ca un ntreg.

Dimensiunea Echipei de Dezvoltare

Dimensiunea optim a Echipei de Dezvoltare este suficient de mic nct echipa sa rmn agil i suficient de mare nct s poat termina o munca semnificativ n cadrul unui Sprint. Dac sunt mai puin de trei membri n Echipa de Dezvoltare, interaciunile sunt mai puine i rezult n creteri productive mai mici. Echipele de Dezvoltare mai mici pot ntlni limitri ale abilitilor n timpul Sprint-ului, cauznd inabilitatea livrrii unui potenial Increment gata de lansare. Dac Echipa de Dezvoltare are mai mult de nou membri, este nevoie de prea mult coordonare. Echipele de Dezvoltare mari genereaz prea mult complexitate ca s poate fi administrate de un proces empiric. Rolurile de Product Owner i Scrum Master nu sunt incluse n aceast numrtoare dect dac muncesc la elemente aflate n Backlog-ul Sprint-ului.

Scrum Master
Scrum Master-ul este responsabil ca Scrum s fie neles i adoptat. Scrum Master-ul face acest lucru prin asigurarea c Echipa Scrum ader la teoria, practicile i rolurile Scrum. Scrum Master-ul este un servitor-conductor pentru Echipa Scrum. Scrum Master-ul i ajut pe cei din afara Echipei Scrum s neleag care din interaciunile lor cu Echipa Scrum sunt folositoare i care nu. Scrum Master-ul ajut pe toat lumea s schimbe aceste interaciuni astfel nct s maximizeze valoarea creat de Echipa Scrum.

Serviciile Scrum Master-ului pentru Product Owner

Scrum Master-ul l ajut pe Product Owner n mai multe moduri, incluznd: Gsirea tehnicilor de gestionare eficace a Backlog-ului Produsului; Ajutarea Echipei Scrum s neleag necesitatea de a avea elemente clare i concise n Backlog-ul Produsului; nelegerea planificrii produsului ntr-un mediu de dezvoltare empiric; Asigurarea c Product Owner-ul tie cum s aranjeze Backlog-ul Produsului astfel nct s maximizeze valoarea; nelegerea i practicarea metodelor agile; i, Facilitarea evenimentelor Scrum dup cum este cerut sau necesar.

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Page | 6

Serviciile Scrum Master-ului pentru Echipa de Dezvoltare

Scrum Master-ul ajut Echipa de Dezvoltare n mai multe moduri, incluznd: Antrenarea Echipei de Dezvoltare s foloseasc auto-organizarea i inter-funcionalitatea; Ajutarea Echipei de Dezvoltare s creeze produse de valoare mare; Eliminarea impedimentelor din calea progresului Echipei de Dezvoltare; Facilitarea evenimentelor Scrum dup cum este cerut sau necesar; i, Instruirea Echipei de Dezvoltare n mediile organizaionale unde Scrum nu a fost pe deplin adoptat sau neles.

Serviciile Scrum Master-ului pentru Organizaie

Scrum Master-ul ajut organizaia n mai multe moduri, incluznd: Direcionarea i pregtirea organizaiei n procesul de adoptare Scrum; Planificarea implementrilor Scrum n cadrul organizaiei; Ajutarea angajailor i a celor implicai s neleag i s adopte Scrum precum i dezvoltarea empiric a produselor; Cauzarea schimbrilor ce duc la creterea productivitii Echipei Scrum; i, Colaborarea cu ali Scrum Master-i pentru a crete eficacitatea aplicrii Scrum-ului n cadrul organizaiei.

Evenimentele Scrum (Scrum Events)

Evenimentele prestabilite n mod regulat din Scrum sunt utilizate pentru a minimiza necesitatea unor reuniuni ocazionale. Toate evenimentele sunt limitate ca timp, n aa fel nct fiecare are o durat maxim. Odat ce Sprint-ul ncepe, durata lui este fix i nu poate fi micorat sau mrit. Celelalte evenimente se pot termina atunci cnd scopul evenimentului a fost atins, asigurndu-se ca se petrece suficient timp, fr a permite pierderi n procesul de planificare. n afara Sprint-ului propriu-zis, care este un container pentru toate celelalte evenimente, fiecare eveniment n Scrum reprezint o oportunitate formal de a inspecta i a adapta ceva. Aceste evenimente sunt concepute special pentru a permite o transparen decisiv i inspecie. Omiterea includerii oricruia dintre aceste evenimente duce la o transparen redus i de asemenea este o ocazie pierdut de a inspecta i a adapta.

Sprint-ul (The Sprint)

Inima Scrum-ului este un Sprint, cu o durat de maxim o lun, n timpul cruia este creat un Increment al produsului, cu statusul "Finalizat" ("Done"), utilizabil i potenial livrabil. Sprint- urile au durate consistente de-a lungul efortului de dezvoltare. Un Sprint nou ncepe imediat dup tragerea concluziilor Sprint-ului anterior. Sprint-urile conin i constau din edina de Planificare a Sprint-ului (Sprint Planning Meeting), edina Scrum Zilnic (Daily Scrums), activitatea de dezvoltare, Revizuire a Sprint-ului (Review Meeting) i Retrospectiva Sprint-ului (Sprint Retrospective).

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Page | 7

n timpul Sprint-ului: Nu se aduc modificri care ar putea afecta obiectivul Sprint-ului; Obiectivele de calitate nu scad; i, Scopul poate fi clarificat i re-negociate ntre Product Owner i Echipa de Dezvoltare pe msur ce mai multe informaii devin disponibile.

Fiecare Sprint poate fi considerat un proiect cu un orizont de timp nu mai mare de o lun. La fel ca i proiectele, Sprint-urile sunt folosite pentru a realiza ceva. Fiecare Sprint are o definiie a ceea ce urmeaz s fie construit, un design i un plan flexibil, care l vor ghida n procesul de realizare ct i n produsul rezultat. Sprint-urile se limiteaz la o lun calendaristic. Atunci cnd orizontul de timp al Sprint-ului este prea lung, definirea a ceea ce este n curs de a fi construit se poate modifica i pot crete att complexitatea ct i riscul. Sprint-urile aduc predictibilitate prin asigurarea inspeciei i adaptarea a ceea ce se realizeaz spre un scop cel puin n fiecare lun calendaristic. De asemenea Sprint-urile limiteaz riscurile de cost la cel mult o lun calendaristic.

Anularea unui Sprint

Un Sprint poate fi anulat nainte de expirarea duratei alocate n care se ncadreaz Sprint-ul respectiv. Numai Product Owner-ul are autoritatea de a anula Sprint-ul, dei el sau ea pot face acest lucru sub influena celor implicai, Echipei de Dezvoltare sau a Scrum Master-ului. Un Sprint ar putea fi anulat i n cazul n care inta Sprint-ului devine perimat. Acesta s-ar putea ntmpla n cazul n care compania i schimb direcia sau n cazul n care condiiile de pia sau de tehnologie se schimb. n general, un Sprint ar trebui s fie anulat n cazul n care nu mai are sens, date fiind circumstanele. Dar anularea acestora are foarte rar sens, din cauza duratei reduse a Sprint-urilor. Atunci cnd un Sprint este anulat, toate elementele din Backlog-ul Produsului completate i "Finalizate" ("Done") sunt verificate. Dac o parte a lucrrilor realizate sunt potenial livrabile, de obicei Product Owner-ul le va accepta. Toate prile incomplete din Backlog-ul Produsului sunt re-evaluate i readuse n Backlog-ul Produsului. Lucrrile efectuate asupra lor se depreciaz rapid i trebuie s fie frecvent re-evaluate. Anulrile Sprint-urilor consum resurse, deoarece toat lumea trebuie s se regrupeze ntr-o alt edin de Planificare a Sprint-ului (Sprint Planning Meeting) pentru a ncepe un alt Sprint. Anulrile Sprint-urilor sunt adesea traumatizante pentru Echipa Scrum, i sunt foarte rar ntlnite.

Planificarea Sprint-ului (Sprint Planning)

Activitatea care urmeaz s fie efectuat n Sprint este planificat la edina de Planificare a Sprint-ului. Acest plan este creat de munca coroborat a ntregii Echipe Scrum.

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Page | 8

edina de Planificare a Sprint-ului este o ntlnire limitat la un maxim de 8 ore pentru un Sprint de o lun. Pentru Sprint-uri mai scurte, evenimentul este de obicei mai scurt. Scrum Master-ul se asigur c evenimentul are loc i c participanii i neleg scopul. Tot Scrum Master-ul nva echipa s se menin n limita de timp stabilit. edina de Planificare a Sprint-ului rspunde la urmtoarele ntrebri: Care este obiectivul Sprint-ului? Ce va fi livrat n Incrementul care rezult din Sprint-ul viitor? Cum va fi efectuat munca necesar pentru ca acest Increment s poat fi realizat?

Subiectul unu: Ce se va realiza n acest Sprint?

Echipa de Dezvoltare lucreaz pentru prognozarea funcionalitii ce va fi dezvoltat pe parcursul Sprint-ului. Product Owner-ul discut despre Obiectivele ce trebuie atinse n cadrul Sprint-ului, i despre elementele din Backlog-ul Produsului, care, dac vor fi finalizate, ar ajuta la ndeplinirea Obiectivului. ntreaga Echip Scrum colaboreaz la nelegerea a ceea ce trebuie realizat n cadrul Sprint-ului. Datele de intrare la aceast ntlnire reprezint Backlog-ul Produsului, cel mai recent Increment al produsului, capacitatea proiectat a Echipei de Dezvoltare n timpul Sprint-ului i performanele anterioare ale Echipei de Dezvoltare. Numrul de activiti (items) selectate din Backlog-ul Produsului pentru Sprint este numai la latitudinea Echipei de Dezvoltare. Numai Echipa de Dezvoltare poate evalua ce poate realiza n Sprint-ul urmtor. Dup ce Echipa de Dezvoltare previzioneaz elementele din Backlog-ul Produsului pe care le va livra n Sprint, ntreaga Echip Scrum definete obiectivul Sprint-ului. Obiectivul Sprint-ului poate crea coeren n munca Echipei de Dezvoltare, coerena care n-ar fi prezent n iniiative separate fr un el comun.

Subiectul doi: Cum se vor realiza activitile alese?

Dup selectarea Obiectivului Sprint-ului i a elementelor pentru Sprint-ul curent din Backlog-ul Produsului, Echipa de Dezvoltare decide cum va implementa pe durata Sprint-ului aceast funcionalitate ntr-un Increment al produsului avnd statusul Finalizat (Done). Elementele din Backlog-ul Produsului selectate pentru acest Sprint, plus planul pentru livrarea lor se numesc Backlog-ul Sprint-ului. Echipa de Dezvoltare ncepe de obicei cu proiectarea sistemului i a activitilor necesare convertirii Backlog-ului Produsului ntr-un Increment funcional al produsului. Activitatea poate varia n funcie de dimensiuni sau efort estimat. Cu toate acestea, o activitate suficient este planificat n cursul Planificrii Sprint-ului pentru ca Echipa de Dezvoltare s previzioneze ceea ce este posibil de realizat n urmtorul Sprint. Activitile planificate pentru primele zile ale Sprint-ului de ctre Echipa de Dezvoltare sunt descompuse n uniti de o zi sau mai puin pn la sfritul acestei reuniuni. Echipa de Dezvoltare se auto-organizeaz pentru ndeplinirea

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Page | 9

activitilor preluate din Backlog-ul Sprint-ului, aa cum este necesar, att n timpul Planificrii Sprint-ului ct i pe parcursul Sprint-ului. Pe msur ce Echipa de Dezvoltare planific, are n vedere Obiectivul Sprint-ului. n timpul Sprint-ului se poate ntmpla ca munca necesar s fie diferit de cea planificat de Echipa de Dezvoltare. ntr-o astfel de situaie, membrii echipei vor colabora cu Product Owner-ul, pentru a determina cum s revizuiasc planul astfel nct s poat totui realiza Obiectivul Sprint-ului. Obiectivul Sprint-ului ofer flexibilitate n ceea ce privete modul n care funcionalitatea poate fi implementat pn la sfritul Sprint-ului. Product Owner-ul poate ajuta la clarificarea activitilor selectate din Backlog-ul Produsului i la realizarea compromisurilor. n cazul n care Echipa de Dezvoltare determin c e prea mult sau prea puin de lucru, se pot renegocia elementele din Sprint Backlog cu Product Owner-ul. De asemenea, Echipa de Dezvoltare poate invita alte persoane s participe, cu scopul de a oferi consultan tehnic sau de specialitate. Pn la sfritul Planificrii Sprint-ului, Echipa de Dezvoltare ar trebui s fie capabil s explice Product Owner-ului i Scrum Master-ului cum intenioneaz s lucreze ca o echip auto- organizat pentru a ndeplini obiectivul Sprint-ului i pentru a crea Incrementul anticipat.

Obiectivul Sprint-ului (Sprint Goal)

Obiectivul Sprint-ului este un el ce poate fi atins n cadrul Sprint-ului prin implementarea Backlog-ului Produsului. El ghideaz Echipa de Dezvoltare ctre motivul pentru care se construiete Incrementul. Este creat n timpul edinei de Planificare a Sprint-ului. Obiectivul Sprint-ului confer Echipei de Dezvoltare un anumit grad de flexibilitate n ceea ce privete funcionalitatea implementat n cadrul Sprint-ului. Elementele selectate din Backlog-ul Produsului livreaz o funcionalitate coerent, care poate s fie obiectivul Sprint-ului. Obiectivul Sprint-ului poate fi orice alt coeren care face ca Echipa de Dezvoltare s lucreze mpreun, mai degrab dect la iniiative separate. Pe msur ce Echipa de Dezvoltare lucreaz, ei au n vedere Obiectivul Sprint-ului. Pentru a satisface Obiectivul Sprint-ului, se implementeaz funcionalitatea i tehnologia. n cazul n care munca depus se dovedete a fi diferit de ceea ce Echipa de Dezvoltare a ateptat, echipa colaboreaz cu Product Owner-ul pentru a negocia Obiectivul Sprint Backlog-ului n cadrul Sprint-ului.

edina Scrum Zilnic (Daily Scrum)

edina Scrum Zilnic este un eveniment de 15 minute cu scopul ca Echipa de Dezvoltare s i sincronizeze activitile i s i creeze un plan pentru urmtoarele 24 de ore. Acest lucru se face prin inspectarea activitilor desfurate de la ultima ntlnire i prognozarea activitilor ce ar putea fi realizate pana la urmtoarea ntlnire. edina Scrum Zilnic se desfoar n aceeai locaie i la aceeai or n fiecare zi pentru a reduce complexitatea. n timpul ntlnirii, fiecare membru al Echipei de Dezvoltare, detaliaz:

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Page | 10

Ce am fcut ieri pentru a ajuta Echipa de Dezvoltare s ating Obiectivul Sprint-ului? Ce voi face azi pentru a ajuta Echipa de Dezvoltare s ating Obiectivul Sprint-ului? Vd vreun impediment care m-ar putea mpiedica pe mine sau pe Echipa de Dezvoltare s atingem Obiectivul Sprint-ului? Echipa de Dezvoltare utilizeaz ntlnirea zilnic pentru a evalua progresul realizat spre Obiectivul Sprint-ului i tendina progresului spre finalizarea lucrrilor din Sprint Backlog. ntlnirea optimizeaz probabilitatea ca Echipa de Dezvoltare s realizeze Obiectivul Sprint-ului. n fiecare zi, Echipa de Dezvoltare trebuie sa neleag modul n care intenioneaz s lucreze mpreun ca o echip auto-organizat pentru a realiza Obiectivul Sprint-ului i pentru a crea Incrementul anticipat nainte de finalul Sprint-ului. Adesea, Echipa de Dezvoltare, sau unii din membri ei, se ntlnesc dup aceast edin Scrum Zilnic pentru o discuie mai detaliat, sau pentru a adapta sau replanifica munca rmas din Sprint. Scrum Master-ul se asigur c Echipa de Dezvoltare se reunete, dar aceasta este responsabil pentru desfurarea edinei Scrum Zilnice. Scrum Master-ul instruiete Echipa de Dezvoltare s in edina Scrum Zilnic n cadrul duratei de 15 minute. Scrum Master-ul impune regula ca numai membrii Echipei de Dezvoltare s participe la edina Scrum Zilnic. edina Scrum Zilnic nu este o ntlnire de raportare ci este adresat persoanelor care transform elementele din Backlog-ul Produsului ntr-un Increment. edina Scrum Zilnic mbuntete comunicarea, elimin alte ntlniri, identific i ndeprteaz obstacolele, evideniaz i promoveaz luarea rapid a deciziilor i mbuntete nivelul de cunoatere a proiectului de ctre Echipa de Dezvoltare. Aceast ntlnire cheie este una de inspecie i de adaptare.

Revizuirea Sprint-ului (Sprint Review)

Aceast Revizuire a Sprint-ului (Sprint Review) este inut la sfritul Sprint-ului cu scopul de a se inspecta Incrementul i dac este necesar, se adapteaz Product Backlog-ul. n timpul edinei de Revizuire a Sprint-ului, Echipa Scrum i cei implicai colaboreaz cu privire la ceea ce s-a realizat n Sprint. Pornind de la aceast dezvoltare i de la orice alt modificare adus Product Backlog-ului n timpul Sprint-ului, participanii conlucreaz la aciunile urmtoare care ar putea fi realizate. Aceasta este o ntlnire informal, nu una de status, iar prezentarea Incrementului este destinat solicitrii de feedback i ncurajeaz colaborarea. Aceasta este o edin limitat la 4 ore pentru Sprint-urile de o lun. Pentru Sprint-urile mai scurte evenimentul este de obicei i el mai scurt. Scrum Master-ul se asigur c evenimentul are loc i c participanii i neleg scopul. Tot Scrum Master-ul i nva pe toi s menin timpul alocat evenimentului. edina de Revizuire a Sprint-ului cuprinde urmtoarele elemente:

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Page | 11

ntre participani sunt inclui Membrii echipei i acionarii principali invitai de Product Owner; Product Owner-ul explic care elemente din Product Backlog au fost "Finalizate" i care nu au fost "Finalizate"; Echipa de Dezvoltare discut despre ceea ce a mers bine n timpul Sprint-ului, problemele de care s-a lovit i modul n care acele probleme au fost soluionate; Echipa de Dezvoltare demonstreaz lucrrile care au fost "Finalizate" i rspunde la ntrebri cu privire la Increment; Product Owner-ul discut Product Backlog-ul aa cum se prezint la momentul respectiv. El sau ea preconizeaz datele posibile de finalizare bazate pe progresele nregistrate pn n prezent (dac este necesar); ntregul grup colaboreaz asupra a ceea ce urmeaz s fac n continuare, astfel nct aceast ntlnire asigur o contribuie valoroas pentru ulterioarele edine de Planificare ale Sprint-ului; Se revizuiete cum s-ar fi putut schimba piaa sau felul de folosire al produsului, care este cel mai valoros lucru ce poate fi fcut n continuare; i, Se revizuiete organizarea n timp, bugetul, potenialele capabiliti i piaa pentru urmtoarea versiune a produsului. Rezultatul Revizuirii Sprint-ului este un Product Backlog revizuit care definete elementele probabile din cadrul acestuia pentru urmtorul Sprint. De asemenea, Product Backlog-ul poate fi revizuit pe ansamblu pentru a satisface noi oportuniti.

Retrospectiva Sprint-ului (Sprint Retrospective)

Retrospectiva Sprint-ului reprezint o oportunitate pentru Echipa Scrum de a se auto-inspecta i de a crea un plan pentru mbuntiri care urmeaz s fie adoptate n cadrul Sprint-ului urmtor. Retrospectiva Sprint-ului are loc dup Revizuirea Sprint-ului (Sprint Review) i nainte de Planificarea Sprint-ului urmtor (Sprint Planning). Aceasta este o edin limitat la 3 ore pentru Sprint-urile de o lun. Pentru Sprint-uri mai scurte, evenimentul este i el mai scurt. Scrum Master-ul se asigur c evenimentul are loc i c participanii i neleg scopul. Tot Scrum Master-ul i nva pe toi s menin timpul alocat evenimentului. Scrum Master-ul particip ca membru egal din echip, din punctul de vedere al responsabilitii legate de procesul de Scrum. Scopul Retrospectivei Sprint-ului este: De a inspecta modul n care ultimul Sprint a funcionat cu privire la oameni, relaii, proces, i instrumente; De a identifica i ordona elementele majore care au mers bine i mbuntirile poteniale; i, De a crea un plan pentru punerea n aplicare a mbuntirilor n modul n care Echipa Scrum i desfoar activitatea.

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Page | 12

Scrum Master-ul ncurajeaz Echipa Scrum s-i mbunteasc, n cadrul contextului Scrum, procesul su de dezvoltare i practicile sale, pentru ca acestea s devin mai eficiente i mai plcute n Sprint-ul urmtor. n timpul fiecrei Retrospective a Sprint- ului, Echipa Scrum planific moduri de cretere a calitii produselor prin adaptarea Definiiei "Finalizat", dup caz. La sfritul Retrospectivei Sprint-ului, Echipa Scrum trebuie s fi identificat mbuntirile pe care le va implementa n urmtorul Sprint. Punerea n aplicare a acestor mbuntiri n urmtorul Sprint reprezint adaptarea la auto-inspecie a Echipei Scrum nsi. Dei mbuntirile pot fi puse n aplicare n orice moment, Retrospectiva Sprint-ului este un eveniment formal, axat pe inspecie i adaptare.

Artefacte Scrum
Artefactele Scrum reprezint munca sau valoarea sub diverse forme care sunt folosite n asigurarea transparenei i a oportunitilor pentru inspecie i adaptare. Artefactele definite de Scrum sunt special concepute pentru a maximiza transparena informaiei cheie n aa fel nct toi s aib aceeai nelegere legat de artefact.

Product Backlog
Product Backlog-ul este o list ordonat cuprinznd tot ce poate fi necesar n cadrul produsului i este singura surs de cerine coninnd toate schimbrile care trebuie fcute produsului. Product Owner-ul este responsabil de Backlog-ul Produsului, incluznd coninutul su, disponibilitatea sa i ordinea sarcinilor. Product Backlog-ul nu este niciodat complet. Cea mai timpurie dezvoltare a sa prezint cerinele iniiale, cunoscute i cel mai bine nelese. Product Backlog-ul evolueaz odat cu produsul i mediul n care acesta evolueaz. Product Backlog-ul este dinamic, se schimb constant pentru a identifica ceea ce are nevoie produsul pentru a fi adecvat, competitiv i folositor. Atta timp ct un produs exist, va exista i Product Backlog-ul acestuia. Product Backlog-ul listeaz toate caracteristicile, facilitile, funciile, cerinele, mbuntirile i remedierile ce constituie schimbrile necesare a fi fcute produsului n versiunile viitoare. Elementele din Product Backlog au atribute precum descrierea, ordinea i estimarea. Pe msur ce un produs este folosit i capt valoare, i rspunsul (feedback-ul) oferit de pia crete, Product Backlog-ul devine o list mai cuprinztoare i mai complet (exhaustiv). Sarcinile se modific n continuu astfel c Product Backlog-ul este un artefact viu. Schimbrile n cerinele de afaceri, condiiile de pia sau cele tehnologice pot cauza schimbri n Product Backlog.

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Page | 13

Adesea, mai multe Echipe Scrum lucreaz mpreun la acelai produs. Un singur Product Backlog este utilizat pentru a descrie munca ce urmeaz a fi fcut pe produs. Un atribut al Product Backlog-ului care grupeaz elementele poate fi utilizat n acest caz. Rafinarea Product Backlog-ului reprezint activitatea de adugare de detalii, estimri i ordonare a elementelor din Product Backlog. Acesta este un proces n continu desfurare n care Product Owner-ul i Echipa de Dezvoltare colaboreaz asupra stabilirii detaliilor din Product Backlog. n timpul rafinrii Product Backlog-ului, elementele sunt reexaminate i revizuite. Echipa Scrum decide cum i cnd este fcut rafinarea. Rafinarea nu consum de regul mai mult de 10% din capacitatea Echipei de Dezvoltare. Totui, elementele Product Backlog-ului pot fi actualizate n orice moment de timp de ctre Product Owner sau la discreia acestuia. Elementele din Product Backlog ordonate n susul listei sunt mai clare i mai detaliate dect cele ordonate n josul listei. Estimrile mai precise se bazeaz pe o claritate mrit i pe un nivel crescut al detaliilor; cu ct ordinea elementului este n josul listei, cu att acesta este mai puin detaliat. Elementele din Product Backlog care vor ocupa Echipele de Dezvoltare pentru urmtoarele cteva Sprint-uri sunt att de rafinate nct orice element s poat fi Finalizat (Done) n cadrul duratei unui Sprint. Elementele din Product Backlog care pot fi Finalizate de ctre Echipa de Dezvoltare n cadrul unui Sprint sunt considerate pregtite (ready) sau gata de aciune (actionable) pentru selectarea fcut la Planificarea Sprint-ului. Elementele din Product Backlog ajung n mod normal la acest grad de transparen datorit activitilor de rafinare descrise mai sus. Echipa de Dezvoltare este responsabil pentru toate estimrile. Product Owner-ul poate influena Echipa de Dezvoltare prin a o ajuta s neleag i s selecteze compromisurile, dar membrii echipei care vor lucra efectiv fac estimrile finale.

Monitorizarea Progresului ctre un Obiectiv

n orice moment de timp, volumul de munc rmas pentru a atinge obiectivul poate fi nsumat. Product Owner-ul urmrete acest volum de munc rmas cel puin la fiecare Revizuire a Sprintului (Sprint Review). Product Owner-ul compar acest volum de munc rmas cu volumul de munc rmas de la edinele de Revizuire Sprint anterioare (Sprint Reviews) cu scopul de a evalua progresul fcut spre finalizarea activitii planificate n funcie de timpul dorit pentru atingerea obiectivului. Aceast informaie este transparent pentru toate prile interesate. Diverse diagrame burn-down, burn-up i alte practici de proiecie au fost folosite pentru a se previziona progresul. Acestea s-au dovedit folositoare. Totui, acestea nu nlocuiesc importana empirismului. n mediile complexe, ceea ce se va ntmpla este necunoscut. Numai ceea ce s-a ntmplat deja poate fi utilizat n viitoarele luri de decizii.

Sprint Backlog
Sprint Backlog-ul reprezint un set de elemente ale Product Backlog-ului selectate pentru Sprint, plus un plan de livrare al Incrementului i de realizare a Obiectivului Sprint-ului. Sprint Backlog-ul

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Page | 14

reprezint o prognoz dat de Echipa de Dezvoltare cu privire la funcionalitatea cuprins n urmtorul Increment precum i de munca necesar pentru a livra aceast funcionalitate ntr-un Increment Finalizat. Sprint Backlog-ul asigur transparena muncii pe care Echipa de Dezvoltare o identific ca fiind necesar pentru a ndeplini Obiectivul Sprint-ului. Sprint Backlog-ul este un plan cu detalii suficiente astfel nct modificrile survenite pe parcurs pot fi nelese n edinele Zilnice de Scrum. Echipa modific Sprint Backlog-ul de-a lungul Sprint- ului i astfel se contureaz Sprint Backlog-ul. Aceast definire apare pe msur ce Echipa parcurge activitile din Sprint i i d seama de munca necesar pentru a atinge Obiectivul Sprint-ului. Echipa de Dezvoltare adaug la Sprint Backlog activitile noi ce apar de-a lungul unui Sprint. Pe msur ce activitile sunt efectuate sau finalizate i estimarea muncii rmase este actualizat. Elementele planului considerate inutile vor fi eliminate. Numai Echipa de Dezvoltare poate schimba Sprint Backlog-ul n timpul unei iteraii. Sprint Backlog-ul este vizibil, reprezint o imagine n timp real a muncii pe care Echipa de Dezvoltare intenioneaz s o realizeze n timpul Sprint-ului i aparine exclusiv Echipei de Dezvoltare.

Monitorizarea Progresului ntr-un Sprint

n orice moment din Sprint se poate nsuma munca total rmas a activitilor din Sprint Backlog. Echipa de Dezvoltare monitorizeaz aceast munc zilnic, cu ajutorul edinelor Zilnice de Scrum. Echipa monitorizeaz munca rmas zilnic cu scopul de a estima ct mai realist probabilitatea de realizare a Obiectivului din Sprint dar i pentru a-i gestiona progresul.

Incrementul
Incrementul reprezint suma tuturor elementelor din Product Backlog finalizate de-a lungul unui Sprint alturi de toate Sprint-urile anterioare. La sfritul unui Sprint, noul Increment trebuie s fie n stadiul de Finalizat, ceea ce nseamn c trebuie s fie utilizabil i n concordan cu ceea ce Echipa Scrum identific ca fiind definiia strii Finalizat. Incrementul trebuie s fie utilizabil indiferent de decizia Product Owner-ului de a-l livra sau nu.

Transparena artefactului
Scrum-ul se bazeaz pe transparen. Deciziile de a optimiza valoarea i de a controla riscul se iau pe baza strii percepute ale artefactelor. n msura n care transparena este complet, aceste decizii au o baz solid. n msura n care artefactele sunt incomplet transparente, aceste decizii pot fi eronate, valoarea se poate diminua i riscul poate crete. Scrum Master-ul trebuie s lucreze cu Product Owner-ul, Echipa de dezvoltare, precum i cu alte pri implicate pentru a nelege dac artefactele sunt complet transparente. Exist practici pentru a face fa transparenei incomplete; Scrum Master-ul trebuie s-i ajute pe toi s aplice

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Page | 15

practicile cele mai adecvate n lipsa de transparen total. Un Scrum Master poate detecta transparena incomplet inspectnd artefactele, sesiznd modelele, ascultnd cu atenie la ceea ce se spune, i detectnd diferenele dintre rezultatele ateptate i cele reale. Treaba Scrum Master-ului este de a lucra cu Echipa Scrum i cu organizaia pentru a crete transparena artefactelor. Acest lucru implic, de obicei, nvare, convingere, i schimbare. Transparena nu se ntmpl peste noapte, dar este o cale.

Definiia strii Finalizat (Definition of Done)

Cnd un element din Product Backlog sau un Increment este descris ca Finalizat, toi trebuie s neleag aceast stare. Dei definiia strii Finalizat difer de la o Echip Scrum la alta, membrii trebuie s aib o nelegere comun a ceea ce nseamn lucrul care urmeaz s fie terminat, pentru a asigura transparen. Aceasta este definiia strii Finalizat folosit de Echipa Scrum pentru a determina cnd munca este complet pentru Increment. Aceeai definiie ndrum Echipa de Dezvoltare n a ti cte activiti din Product Backlog poate selecta n cadrul edinei de Planificare a Sprint-ului. Scopul fiecrui Sprint este de a obine Incrementuri potenial livrabile, n starea Finalizat conform cu definiia Echipei Scrum. Echipa de Dezvoltare furnizeaz un Increment al Produsului n fiecare Sprint. Acest Increment este utilizabil, deci Product Owner-ul poate decide s l livreze imediat. Dac definiia "finalizat" (definition of "done") pentru un increment este parte din convenii, standarde sau ghiduri ale organizaiei de dezvoltare, toate Echipele Scrum trebuie minimum s o urmeze. Dac definiia "finalizat" pentru un increment nu este o convenie a organizaiei de dezvoltare, Echipa de Dezvoltare trebuie s conceap o definiie "finalizat" adecvat pentru produs. Dac exist mai multe Echipe Scrum care lucreaz mpreun la un sistem sau o versiune de produs, echipele de dezvoltare din toate Echipele Scrum trebuie s conceap reciproc definiia "Finalizat". Fiecare Increment se adaug la toate Incrementurile anterioare i este testat amnunit pentru a verifica dac toate Incrementurile din care este compus funcioneaz mpreun. Pe msur ce Echipa Scrum acumuleaz experien este de ateptat ca definiia strii Finalizat s se extind pentru a include criterii mai stricte, cu scopul de a asigura o calitate superioar a Incrementului. Orice proiect sau sistem ar trebui s aib o definiie a strii Finalizat ce este standard pentru orice munc efectuat.

End Note
Scrum-ul este gratuit i oferit n acest ghid. Rolul Scrum-ului, artefactele, evenimentele i regulile sale sunt imuabile. Dei punerea n aplicare a doar o parte din Scrum este posibil, rezultatul nu este Scrum. Scrum exist numai n toate elementele sale i funcioneaz precum un container pentru alte tehnici, metodologii i practici.

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Page | 16

Mulumiri
Oamenii
Din miile de persoane care au contribuit la Scrum, ar trebui s-i evideniem pe cei care au avut un rol n primii zece ani. La nceput a fost Jeff Sutherland, care a lucrat cu Jeff McKenna, i Ken Schwaber, care a lucrat cu Mike Smith i Chris Martin. Muli alii au contribuit n anii care au urmat i fr ajutorul lor Scrum nu ar fi fost att de perfecionat precum este n ziua de astzi.

Istoria
Ken Schwaber i Jeff Sutherland au fost primii care au co-prezentat Scrum la conferina OOPSLA n 1995. Aceast prezentare a documentat n mod esenial nvturile pe care Ken i Jeff le-au dobndit n cei civa ani anteriori de aplicare a Scrum-ului. Istoria Scrum este deja considerat lung. Pentru a onora primele locuri unde a fost ncercat i perfecionat, menionm Individual, Inc., Fidelity Investments, i IDX (astzi GE Medical). Ghidul Scrum documenteaz Scrum aa cum a fost dezvoltat i susinut de 20 de ani de Jeff Sutherland i Ken Schwaber. Alte surse v ofer modele, procese, i perspective care completeaz cadrul Scrum. Acestea optimizeaz productivitatea, valoarea, creativitatea, i mndria.

Traducerea
Acest ghid a fost tradus din versiunea Englez original, furnizat de Ken Schwaber i Jeff Sutherland. Printre cei care au contribuit la traducerea n limba Romna se numr: Monica Ipate, Ana Vintil, Petru Furescu, Marius Delc i Alexandra Suciu. La revizuire au participat Radu Orjanu i Maria Deaconu.

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Page | 17

Schimbri ale ghidului Scrum ntre 2011 i 2013

1. Artefactele trebuie s fie transparente pentru ca mecanismele Scrum de inspecie i adaptare s fie eficiente. 2. edina Scrum zilnic este un eveniment de planificare venit exact la momentul potrivit. Informaiile ce intr trebuie s se refere la modul cum echipa reuete s ndeplineasc Obiectivul Sprint-ului; Informaiile ce ies trebuie s se refere la un nou plan sau un plan revizuit ce optimizeaz eforturile echipei n a ndeplini Obiectivul Sprint-ului. Toate conversaiile sunt orientate spre noi, echipa dect spre eu, dezvoltatorul. 3. Planificarea Sprint-ului este acum un singur eveniment, nu divizat n dou evenimente ce/cum. Dezvoltarea Obiectivului Sprint-ului pornete evenimentul i apoi se compar ce este necesar pentru a ndeplini Obiectivului Sprint-ului cu ce va veni i cu capacitatea posibil, i n final se dezvolt un plan de ndeplinire a Obiectivului Sprint-ului n timpul Sprint-ului. 4. Backlog-ul Produsului este rafinat, mai degrab dect ntreinut (groomed). Elementele rafinate ale Backlog-ului Produsului sunt transparente, suficient de bine nelese i destul de granulare pentru a fi introduse n Planificarea Sprint-ului i pentru a fi selectate n Sprint. Elementele Backlog-ului Produsului avnd aceast transparen sunt aa numite Pregtite (Ready). 5. Toate evenimentele sunt limitate n timp. Durata de timp descris este durata maxim alocat. De cele mai multe ori Sprint-urile cu o durat mai mic de o lun nu ajung la durata maxim. 6. Rezultatul Revizuirii Sprint-ului (Sprint Review) este un Backlog al Produsului potenial reorganizat unde elementele cu cea mai mare valoare sunt cel mai probabil s fie selectate la viitoarea Planificare a Sprint-ului. 7. Planificarea Sprint-ului definete funcionalitatea n incrementul planificat, i planific cum Echipa de Dezvoltare va crea acest increment. Obiectivul Sprint-ului este conceput pentru a ncheia rezultatul acestei munci.

1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

Page | 18