Ghidul metodei de lucru Scrum

Scopul Ghidului Scrum

Scrum este un cadru de lucru (framework) pentru dezvoltarea, livrarea și întreținerea de produse complexe. Acest Ghid conține definiția Scrum. Această definiție este compusă din rolurile, evenimentele, artefactele care compun Scrum precum și regulile care le unesc.

Scrum a fost creat de către Ken Schwaber și Jeff Sutherland; Ei au scris și distribuit Ghidul Scrum. Ei stau, împreună, în spatele Ghidul Scrum. Acest document este traducerea în limba română a Ghidului Scrum.

Definiția Scrum

Scrum (n): un cadru de lucru în care se pot rezolva probleme de adaptare complexe, în același timp dezvoltând într-o manieră productivă și creativă produse cu cea mai mare valoare posibilă,

Scrum este:

Ușor
Simplu de înțeles
Greu de stăpânit

Scrum este un proces cadru, care a fost utilizat pentru gestionarea dezvoltării de produse complexe încă de la începutul anilor 90. Scrum nu este un proces, tehnică sau metodă strict definită. Mai degrabă, este un cadru de lucru în se pot utiliza diverse procese și tehnici. Scrum scoate în evidență eficacitatea relativă a tehnicilor de management de produs și a tehnicilor de lucru, astfel încât produsul, echipa și mediul de lucru să poată fi continuu îmbunătățite.

Cadrul de lucru Scrum consistă în Scrum Teamuri și rolurile asociate acestora, evenimente, artefacte și reguli. Fiecare componentă a cadrului de lucru servește unui anumit scop și este esențială pentru succesul și utilizarea Scrum.

Regulile Scrum combină rolurile, evenimentele și artefactele, reglementând relațiile și interacțiunea dintre ele. Regulile Scrum sunt descrise pe parcursul acestui document.

Tacticile specifice utilizării cadrului de lucru Scrum variază și sunt descrise în altă parte.

Utilizările Scrum

Scrum a fost inițial conceput pentru gestionarea și dezvoltarea de produse. Încă de la începutul anilor 90, Scrum a fost utilizat pe scară largă, la nivel mondial, pentru:

Cercetarea și identificarea de piețe viabile, tehnologii și capabilități ale produselor;
Dezvoltarea și îmbunătățirea produselor;
Lansarea de produse noi sau îmbunătățiri ale produselor existente, câteodată cu o frecvență de mai multe ori pe zi;
Dezvoltarea și sprijinirea tehnologiei Cloud (on-line, în siguranță, la cerere) precum și a altor medii operaționale pentru utilizarea produselor;
Întreținerea și împrospătarea produselor.

Scrum a fost utilizat pentru dezvoltarea de software, hardware, software încorporat, rețele de funcții interdependente, vehicule autonome, (în) școli, guvern, studii de piață, gestionarea activității organizațiilor și aproape în tot ceea ce folosim în viața de zi cu zi, ca indivizi și ca societate.

Odată cu creșterea rapidă a complexității tehnologiei, pieței și mediului, precum și a interacțiunilor între ele, utilitatea Scrum în gestionarea complexității este confirmată zilnic.

Scrum s-a dovedit a fi deosebit de eficace în transferarea repetitivă și graduală al cunoștințelor. Scrum este acum utilizat pe scară largă pentru dezvoltarea de produse și servicii precum și administrarea forului tutelar.

Esența cadrului de lucru Scrum este o echipă mică. Fiecare echipă este extrem de agilă și adaptabilă. Aceste forțe acționează la nivelul unei singure echipe, a câtorva sau multor echipe, precum și în rețele de echipe care creează, lansează, operează și susțin munca și produsele muncii a mii de oameni. Aceștia colaborează și interacționează folosind concepte de creație și medii de lansare sofisticate.

În Ghidul Scrum cuvintele „dezvoltă“ și „dezvoltare“ se referă la procese de producție complexe, cum ar fi tipurile menționate mai sus.

Teoria Scrum

Scrum se bazează pe teoria empirică (experimentală) de control al proceselor, sau empirism. Empirismul afirmă că experiența duce la acumularea de cunoștințe iar deciziile se iau pe baza cunoștințelor acumulate. Scrum folosește o abordare repetitivă, graduală pentru a îmbunătăți predictibilitatea și a controla riscul.

Orice punere în aplicare a controlului empiric al proceselor se bazează pe trei piloni: onestitate, inspecție și reglare.

Onestitate (Transparency)

Aspectele semnificative ale procesului trebuie să fie vizibile celor răspunzători pentru rezultat. Onestitatea cere ca aceste aspecte să fie definite folosind un standard comun, astfel încât observatorii să înțeleagă la fel ceea ce văd.

De exemplu

Un limbaj comun, care trebuie să fie cunoscut de către toți participanții; și
Cei care efectuează munca și precum si cei care controlează Incrementul funcțional rezultat trebuie să aibă o definiție comună a ceea ce înseamnă „Făcut“.

Inspecție (Inspection)

Utilizatorii Scrum trebuie să inspecteze frecvent artefactele Scrum și progresul făcut spre îndeplinirea obiectivului Sprintului pentru a identifica abateri nedorite. pentru a nu împiedica munca inspecțiile nu trebuie să fie prea frecvente. Inspecțiile sunt benefice atunci când sunt efectuate in mod profesional chiar la locul de muncă de către inspectori calificați.

Reglarea sau adaptare (Adaptation)

Dacă un inspector stabilește că unul sau mai multe aspecte ale procesului au deviat în afara limitelor acceptabile, și ca urmare produsul rezultat nu va fi acceptat, procesul sau materialul care este prelucrat trebuie să fie reglat. Reglarea trebuie făcută cât mai curând posibil, pentru a reduce creșterea în continuare a abaterii.

Scrum impune patru întâlniri formale pentru inspecție și reglare, așa cum este descris în secțiunea Evenimente Scrum a acestui document:

Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective

Valorile Scrum

Atunci când valori precum angajament, curaj, concentrare, deschidere și respect se regăsesc în Scrum Team, pilonii Scrum: onestitate, inspecție și reglare înfloresc insuflând încredere între membrii echipei. Membrii Scrum Teamului învață și exploră aceste valori în timp ce aplică rolurile, evenimentele și artefactele Scrum. Succesul utilizării Scrum depinde de creșterea continuă a competenței echipei în aceste cinci valori. Membrii se angajează personal să atingă obiectivelor Scrum Teamului.

Membrii Scrum Teamului trebuie sa aibă curajul să facă ceea ce trebuie și să abordeze problemele dificile. Toată lumea se concentrează pe activitățile din Sprint si obiectivele Scrum Teamului. Scrum Teamul și celelalte părți interesate se înțeleg să abordeze deschis toate sarcinile și provocările pe durata muncii. Membrii Scrum Teamului se respectă între ei considerându-se reciproc capabili și independenți.

Scrum Team (Echipa de Scrum)

Echipa de scrum constă din Product Owner (Proprietarul Produsului), Development Team (Echipa de Lucru ) și Scrum Master (Maistrul Scrumului). Echipele de scrum se auto-organizează și sunt policalificate. Echipele auto-organizate își aleg singure cea mai bună abordare pentru a-și atinge obiectivul, în loc să fie dirijate de către persoane din afara echipei. Echipele policalificate au toate competențele necesare pentru a-și atinge obiectivul fără a depinde de persoane care nu fac parte din echipa.

Modelul Scrum Teamului este conceput pentru a optimiza flexibilitatea, creativitatea și productivitatea. Scrum Teamurile s-au dovedit a fi eficiente în toate utilizările (Scrum) menționate anterior și în general în orice activitate complexă.

Scrum Teamurile livrează produse într-un mod repetitiv si gradual, maximizând ocaziile de reglare pe baza răspunsului la performanței anterioare (feedback). Livrarea incrementală a produsului „Făcut“ asigură ca în orice moment este disponibilă o versiune a produsului potențial utilizabilă din punct de vedere funcțional.

Product Owner (Proprietarul Produsului)

Product Ownerul este răspunzător pentru maximizarea valorii produsului rezultat din activitățile Scrum Teamului. În practică acest rol poate varia foarte mult între organizații, Scrum Teamuri și persoane fizice.

Product Ownerul este singura persoana răspunzătoare pentru gestionarea Product Backlogului. Gestionarea Product Backlogului cuprinde:

Descrierea exactă a articolelor din Product Backlog;
Aranjarea articolele din Product Backlog pentru a realiza cât mai bine obiectivele și sarcinile;
Optimizarea valorii muncii Scrum Teamului;
Asigurarea că, Product Backlogul este vizibil, corect și clar tuturor, indicând cu exactitate ceea ce Scrum Teamul va lucra în viitor; și,
Asigurarea că Development Teamul înțelege articolele din Product Backlog la nivelul necesar.

Product Ownerul poate să efectueze el însuși activitățile de mai sus, sau le poate repartiza Development Teamului. Indiferent cine efectuează activitățile, Product Ownerul rămâne singurul răspunzător.

Product Ownerul este o singură persoană, nu un grup. Product Ownerul poate reprezenta dorințele unui grup folosind Product Backlogul, dar cei care doresc să schimbe prioritatea unui articol trebuie să se adreseze Product Ownerului.

Pentru ca Product Ownerul să aibă succes, întreaga organizație trebuie să respecte deciziile sale. Deciziile Product Ownerului sunt vizibile în conținutul și aranjamentul articolelor în Product Backlog. Nimeni nu poate obliga Development Teamul să lucreze cu un alt set de cerințe.

Development Team (Echipa de Lucru)

Development Team este formată din profesioniști care asigură livrarea unui adaos funcțional „Făcut“, în principiu este un produs utilizabil, la sfârșitul fiecărui Sprint. Incrementul funcțional „Făcut“ este obligatoriu pentru Sprint Review. Doar membrii Development Teamului pot participa la realizarea Incrementului funcțional.

Development Teamurile sunt structurate și împuternicite de către organizație să-și organizeze și să-și gestioneze propria lor muncă. Sinergia rezultată optimizează eficiența și eficacitatea globală a Development Teamului.

Development Teamurile au următoarele caracteristici:

Se auto-organizează. Nimeni (nici măcar Scrum Masterul) nu poate impune Development Teamului cum să transforme Product Backlogul în Incremente funcționale potențial livrabile;
Development Teamurile sunt policalificate, la nivel de echipă având toate cunoștințele si abilitățile necesare pentru a crea un adaos funcțional al produsului;
Scrum nu recunoaște titluri pentru membrii Development Teamului, indiferent de tipul de activități efectuată de către o anumită persoana;
Scrum nu recunoaște nici sub-echipe ale Development Teamului, indiferent de domeniile de activitate care trebuie abordate cum ar fi testarea, proiectarea, operarea, sau analiza; și,
Ca indivizi membrii Development Teamului pot fi specializați pe anumite competențe și domenii de interes, dar responsabilitatea livrării aparține Development Teamului în ansamblu.

Mărimea Development Teamului

Development Teamul optim trebuie să fie suficient de mic pentru a rămâne flexibil și suficient de mare pentru a putea finaliza un volum de muncă considerabil într-un Sprint. Într-o echipă cu mai puțin de trei membri interacțiunea este mică și ca urmare creșterile de productivității vor fi mici. În timpul Sprintului, Development Teamurile mici pot avea probleme din cauza lipsei calificărilor necesare, iar ca urmare Development Teamul nu va fi capabil să livreze Incrementul funcțional potențial livrabil.

Având mai mult de nouă membri necesită prea multă coordonare. Development Teamurile mari introduc prea multă complexitate pentru ca un proces empiric să poată fi util. Rolurile de Product Owner si Scrum Master nu sunt incluse în numărul de membri ai Scrum Teamului, cu excepția cazului în care aceștia execută activități din Sprint Backlog.

Scrum Master (Maistrul Scrumului)

Scrum MasteruI este răspunzător pentru promovarea și susținerea Scrum așa cum este definit în Ghidul Scrum. Scrum Masterul face acest lucru ajutându-i pe toți să înțeleagă teoria, practicile, regulile și valorile Scrum.

Scrum Masterul este un conducător participativ al Scrum Teamului. Scrum Masterul îi ajută pe cei din afara Scrum Teamului să înțeleagă care dintre interacțiunile lor cu Scrum Teamul sunt utile și care nu sunt. Scrum Masterul îi ajută pe toți să modifice aceste interacțiuni, pentru a maximiza valoarea creată de către Scrum Team.

Serviciile Scrum Masterului în sprijinul Product Ownerului

Scrum Masterul sprijină Product Ownerul în mai multe moduri, cum ar fi: • Asigurându-se că obiectivele, scopul și domeniul de aplicare al produsului sunt înțelese cât mai bine posibil de către toți membrii Scrum Teamului;

Găsind tehnici pentru gestionarea eficientă a Product Backogului;
Ajutând Scrum Teamul să înțeleagă necesitatea ca articolele din Product Backlogl să fie clare și concise;
Explicând planificarea produsului într-un mediu empiric;
Asigurându-se ca Product Ownerul știe cum să aranjeze Product Backlogul pentru a maximiza valoarea;
Explicând și practicând agilitatea; și,
Facilitând evenimentele Scrum atunci când este solicitat sau atunci când este necesar

Serviciile Maistrului Scrumului în sprijinul Echipei de Lucru

Scrum Masterul sprijină Development Teamul în mai multe moduri, cum ar fi:

Instruind Development Teamul în auto-organizare și policalificare;
Ajutând Development Teamul să creeze produse de mare valoare;
Înlăturând obstacolele din calea progresului Development Teamului;
Facilitând Evenimentele Scrum la cerere sau atunci când este necesar; și,
Instruind Development Teamul din mediile organizaționale în care Scrum nu este încă pe deplin înțeles și adoptat.

Serviciile Scrum Masterului în sprijinul Organizației

Scrum Masterul sprijină Organizația în mai multe moduri, cum ar fi:

Îndrumând si instruind organizația în adoptarea Scrum;
Planificând implementarea Scrum în cadrul organizației;
Sprijinind angajații și părțile interesate să înțeleagă și să adopte Scrum și dezvoltarea experimentală a produselor;
Provocând schimbări care cresc productivitatea Scrum Teamului; și,
Lucrând cu alți Scrum Masteri pentru a crește eficiența utilizării Scrum în organizație.

Evenimentele Scrum (Scrum Events)

În Scrum anumite evenimente sunt impuse pentru a crea ritmicitatea și pentru a reduce nevoia de întâlniri care nu sunt definite în Scrum. Toate evenimentele au durată delimitată, ca urmare fiecare eveniment are o durată maximă. Odată ce un Sprint a început, durata sa este fixă și nu poate fi scurtată sau prelungită. Celelalte evenimente se pot termina atunci când este atins scopul evenimentului, dacă o durata de timp adecvată a fost alocată pentru evitarea de pierderi în proces.

În afară de Sprintul în sine, care este un cadru pentru toate celelalte evenimente, fiecare eveniment în Scrum este o ocazie formală de a inspecta și adapta ceva. Aceste evenimente sunt în mod special concepute pentru a permite critică deschisă și inspecție. Eșecul de a include oricare dintre aceste evenimente are ca rezultat transparența redusă și este o ocazie pierdută de a inspecta și regla.

Sprint

Chintesența Scrum este Sprintul, o perioada de timp delimitată de o lună sau mai puțin, în timpul căreia se creează un Increment funcțional al produsului „Făcut“, utilizabil și potențial livrabil. Sprinturile au o durată constantă pe tot parcursul unui ciclu de producție. Un nou Sprint începe imediat după încheierea Sprintului precedent.

Sprinturile conțin și constau din Sprint Planning, Daily Scrum, activități de lucru, Sprint Review, și Sprint Retrospective.

Pe durata Sprintului:

Nu se aduc modificări care ar putea pune în pericol obiectivul Sprintului;
Cerințele de calitate sunt menținute; și,
Scopul poate fi clarificat și re-negociat între Product Owner și Development Team pe măsură ce este mai bine înțeles.

Fiecare Sprint poate fi considerat un proiect cu o durată de maximum o lună. Ca și proiectele, Sprinturile sunt folosite pentru a realiza ceva. Fiecare Sprint are un obiectiv a ceea ce este de făcut, un concept și un plan flexibil, care va dirija construcția acestuia, activitățile și Incrementul funcțional rezultat.

Sprinturile sunt limitate la o lună calendaristică. Atunci când lungimea unui Sprint este prea lungă definiția a ceea ce este de făcut se poate schimba, complexitatea și riscul pot crește. Sprinturile permit predictibilitatea prin garantarea inspecției și adaptarea progresului către obiectivul Sprintului, cel puțin la fiecare lună calendaristică. În același timp Sprinturile limitează riscul financiar la costul unei luni calendaristice.

Finalizarea unui Sprint

Un Sprint poate fi terminat înainte de durata stabilita. Numai Product Ownerul are autoritatea de a termina un Sprint, deși el sau ea poate face acest lucru sub influența părților interesate, Development Teamului, sau a Scrum Masterului.

Un Sprint poate fi terminat în cazul în care Obiectivul Sprintului a devenit inutil. De exemplu în cazul în care organizația își schimbă obiectivul sau în cazul în care se schimba cerințele pieței sau tehnologia. În general, un Sprint trebuie terminat în cazul în care, luând în considerație circumstanțele, nu mai are sens. Deși posibilă, terminarea are sens foarte rar deoarece durata Sprintului este scurtă.

Atunci când un Sprint este terminat, toate articolele din Product Backlog care sunt realizate si „Făcute” sunt reevaluate. Dacă o parte a muncii este potențial livrabila Product Ownerul de regulă o acceptă. Toate articolele incomplete din Product Backlog sunt reevaluate și puse la loc în Product Backlog. Munca depusă la aceste articole se degradează rapid și trebuie să fie în mod frecvent reevaluată.

Terminarea Sprintului consumă resurse, deoarece membrii Sprint Teamului trebuie să se întâlnească din nou într-un Sprint Planning pentru a putea începe un alt Sprint. În general terminarea Sprintului este traumatică pentru Scrum Team și este extrem de rară..

Sprint Planning (Planificarea Sprintului)

Lucrările care urmează să fie efectuate în Sprint sunt stabilite în Sprint Planning. Acest plan este conceput în colaborare de către întreagul Scrum Team.

Sprint Planning este limitat la maximum opt ore pentru un Sprint cu o durată prestabilită de o lună calendaristica. În cazul Sprinturilor mai scurte, acest eveniment de regula durează mai puțin. Scrum Masterul trebuie să se asigure că întâlnirea are loc și că participanții înțeleg scopul ei. Scrum Masterul educă Scrum Teamul să nu depășească durata stabilita.

Sprint Planningul răspunde următoarelor întrebări:

Ce poate fi realizat în Sprintul următor ca adaos funcțional livrabil?
Cum se vor efectua activitățile necesare pentru livrarea Incrementului funcțional?

Subiectul întâi: Ce se poate livra în Sprintul următor?

Development Teamul lucrează pentru a pronostica funcționalitatea care va fi realizată în timpul Sprintului. Product Ownerul prezintă obiectivul pe care Sprintul trebuie să îl atingă și articolele din Product Backlog prin care, dacă vor fi realizate în Sprint, obiectivul Sprintului va fi atins. Întregul Scrum Team colaborează pentru înțelegerea activităților din Sprint.

Elementul absolut necesar pentru această întâlnire este Product Backlog, cel mai recent Increment funcțional al produsului, capacitatea prognozată a Development Teamului pe durata Sprintului și performanțele anterioare ale Development Teamului. Este datoria Development Teamului să stabilească numărul de articole din Product Backlog care vor fi selectate pentru Sprintul curent. Numai Development Teamul are dreptul să evalueze ce se poate realiza in viitorul Sprint.

Totodată, in timpul Sprint Planning Scrum Teamul stabilește Obiectivul Sprintului. Obiectivul Sprintului reprezintă obiectivul care va fi îndeplinit în cadrul Sprintului prin realizarea articolelor din Product Backlog, indicând Development Teamului motivul pentru care Incrementul funcțional trebuie realizat.

Subiectul al doilea: Cum se vor efectua lucrările stabilite?

După ce a stabilit Obiectivul Sprintului și a selectat articolele din Product Backlog pentru Sprint, Development Teamul decide modul în care va realiza această funcționalitate ca un Increment funcțional „Făcut“ produs în timpul Sprintului. Articolele din Product Backlog selectate pentru Sprintul următor, împreună cu planul pentru livrarea lor reprezintă Sprint Backlogul.

De regula Development Teamul începe prin stabilirea normelor și a activităților necesare pentru a transforma Product Backlogul într-un Increment funcțional al produsului. Munca poate avea diverse durate sau estimări ale efortului necesar. Cu toate acestea, Sprint Planning trebuie să selecteze suficiente activități pentru ca Development Teamul să poată estima ce crede că se poate face în viitorul Sprint. Activitățile planificate de către de către Development Team pentru primele zile ale Sprintului trebuie divizate până la sfârșitul acestei întâlniri, de regula în durate de o zi sau mai puțin.

Development Teamul se auto-organizează pentru a efectua lucrările din Sprint Backlog, atât în timpul Sprint Planningului precum și, dacă este necesar, pe tot parcursul Sprintului.

Product Ownerul poate ajuta la clarificarea articolelor din Product Backlog selectate pentru Sprint și de asemenea poate să facă compromisuri. În cazul în care Development Teamul consideră că are prea mult de lucru sau prea puțin, aceasta poate renegocia cu Product Ownerul articolele din Product Backlog selectate pentru Sprint. Development Teamul poate invita și alte persoane să participe pentru a oferi consultanță tehnică sau în domeniu.

Până la sfârșitul Sprint Planningului, Development Teamul trebuie să fie în măsură să demonstreze Product Ownerului si Scrum Masterului modul în care intenționează să lucreze ca o echipă auto-organizata pentru a realiza Obiectivul Sprintului și pentru a crea Incrementul funcțional prevăzut.

Obiectivul Sprintului (Sprint Goal)

Obiectivul Sprintului reprezintă scopul stabilit pentru Sprint, care poate fi atins prin realizarea articolelor din Product Backlog. Obiectivul Sprintului ajută Development Teamul să înțeleagă motivul pentru care este produs Incrementul funcțional. Acesta este stabilit în timpul întâlnirii de Sprint Planning. Obiectivul Sprintului oferă Development Teamului o anumită flexibilitate în ceea ce privește funcționalitatea produsă în cadrul Sprintului. Articolele din Product Backlog selectate pentru Sprint trebuie să livreze o funcționalitate coerentă, care poate fi chiar obiectivul Sprintului. Obiectivul Sprintului poate include orice altă activitate comună care poate influența

Development Teamul să muncească împreună, nu în procese separate.

Pe măsura ce Development Teamul muncește, membri ei păstrează în memorie Obiectivul Sprintului. Pentru a îndeplini Obiectivul Sprintului ei produc funcționalitatea și tehnologia necesara . În cazul în care rezultatul se dovedește a fi diferit decât ceea ce Development Teamul intenționa, în timpul Sprintului echipa va colabora cu Product Ownerul pentru a revizui obiectivul Sprint Backlogului.

Daily Scrum (Scrumul Zilnic)

Daily Scrum este o întâlnire a Development Teamului cu o durata delimitata de 15 minute. Daily Scrum are loc în fiecare zi a Sprintului. În timpul acestuia, Development Teamul planifică activitățile pentru următoarele 24 de ore. Această abordare optimizează colaborarea în echipă și performanța echipei prin inspectarea lucrărilor efectuate după Scrumul din ziua precedenta și prognoza de lucru pentru următorul Sprint. Pentru reducerea complexității Daily Scrum are loc în fiecare zi la aceiași ora și in același loc. Development Teamul folosește

Daily Scrum pentru a inspecta progresul către Obiectivul Sprintului și de a verifica progresul în direcția finalizării activităților incluse în Sprint Backlog. Daily Scrum optimizează probabilitatea ca Development Teamul să îndeplinească obiectivul Sprintului. În fiecare zi, Development Teamul trebuie să înțeleagă modul în care intenționează să lucreze împreună ca o echipă auto-organizată pentru a realiza Obiectivul Sprintului și de a crea Incrementul funcțional anticipat la sfârșitul Sprintului.

Agenda întâlnirii este stabilită de către Development Team și poate fi abordată în diferite moduri atât timp cât pune accentul pe progresul în realizarea Obiectivului Sprintului. Unele Development Teamuri folosesc întrebări standard, altele se bazează pe discuții libere.

În continuare este prezentat un exemplu a ceea ce ar putea fi folosit:

Ce-am făcut, ieri, pentru a ajuta Development Teamul să îndeplinească Obiectivul Sprintului?
Ce voi face astăzi pentru a ajuta Development Teamul să îndeplinească Obiectivul Sprintului?
Ce obstacol consider că mă poate împiedica pe mine sau Development Teamul să atingem Obiectivul Sprintului?

De multe ori întreaga Development Team sau membrii ai echipei se întâlnesc imediat după Daily Scrum pentru discuții detaliate, sau pentru a adapta sau schimba planul restului de activități din Sprint. Scrum Masterul se asigură că Development Teamul participă la întâlnire, dar responsabilitatea ținerii Daily Scrum aparține Development Teamului. Scrum Masterul educă Development Teamull să limiteze durata Daily Scrum la 15 minute.

Daily Scrum este o întâlnire internă a Development Teamului. În cazul în care alte persoane sunt prezente, Scrum Masterul asigură că acestea nu perturbă întâlnirea. Daily Scrum îmbunătățește comunicarea, elimină necesitatea altor întâlniri, identifică obstacolele din calea realizării care trebuie îndepărtate, evidențiază și promovează luarea rapidă a deciziilor și ajuta la îmbunătățirea nivelului de cunoștințe al Development Teamului. Aceasta este o întâlnire cheie pentru inspecție și reglare.

Sprint Review (Verificarea Sprintului)

Sprint Review are loc la sfârșitul Sprintului în scopul validării Incrementului funcțional și dacă este necesar, revizuirea Product Backlogului. În timpul întâlnirii de Sprint Review, Scrum Teamul și părțile interesate colaborează pentru a valida ceea ce a fost făcut în Sprint. Pe baza acest lucru și a modificărilor în Product Backlog din timpul Sprintului, participanții stabilesc împreună următoarele lucruri care pot fi făcute pentru a optimiza valoarea. Aceasta este o întâlnire informală, nu o ședință de raportare, iar scopul prezentării Incrementului funcțional este de a obține răspunsuri la performanțele anterioare și pentru a favoriza colaborarea.

Aceasta întâlnire este de cel mult patru ore pentru un Sprint cu durata de o lună. Pentru Sprinturi cu durată mai scurtă, întâlnirea este de obicei mai scurtă. Scrum Masterul trebuie să se asigure că întâlnirea are loc și că participanții înțeleg scopul acesteia. Scrum Masterul îi educă pe toți participanții să nu depășească durata stabilită.

Sprint Reviewul are următoarele elemente:

Participanții includ Scrum Teamul și părțile interesate principale care sunt invitate de către Product Owner;
Product Ownerul arată articolele din Product Backlog care au fost „Făcute“ și cele care nu au fost „Făcute“;
Development Teamul discută despre ceea ce a mers bine în timpul Sprintului, ce probleme au apărut și modul în care au fost rezolvate aceste probleme;
Development Teamul prezintă munca „Făcută“ și răspunde la întrebări despre Incrementul funcțional;
Product Ownerul dezbate starea în care se află Product Backlogul. El sau ea prezintă obiectivul dorit și datele de livrare pe baza de progresului înregistrate până în prezent (dacă este necesar);
Întregul grup colaborează în stabilirea a ce se va face în continuare, astfel încât Sprint Reviewul este o contribuție importantă la următorul Sprint Planning;
Analiza pieței și potențialele utilizări ale produsului care ar putea schimba prioritățile ulterioare; și,
Revizuirea timpului, bugetului, performanței potențiale și cerințele pieței pentru următoarele livrări de funcționalitate sau performanță planificate.

Rezultatul Sprint Reviewului este o revizuire a Product Backlogului, care indică articolele din Product Backlog care se intenționează a fi incluse în următorul Sprint. Product Backlogul poate fi, de asemenea, revizuit în totalitate pentru a răspunde noilor oportunități.

Sprint Retrospective (Retrospectiva Sprintului)

Sprint Retrospective este o ocazie pentru Scrum Team de a se inspecta și de a crea un plan pentru îmbunătățiri care urmează să fie adoptate în timpul următorului Sprint.

Sprint Retrospective are loc după Sprint Review și înaintea următorului Sprint Planning. Acesta este de regulă o întâlnire de trei ore pentru un Sprint cu durata de o lună. Pentru Sprinturi mai scurte, întâlnirea este de regulă mai scurta. Scrum Masterul asigură că întâlnirea are loc și că participanții îi înțeleg scopul.

Scrum Masterul asigură ca întâlnirea să fie pozitivă și productivă. Scrum Masterul îi educă pe toți participanții să nu depășească durata stabilită. Scrum Masterul participă în calitate de membru egal al echipei la din punct de vedere al responsabilității asupra procesului Scrum.

Scopul Sprint Retrospective este de a:

Verifica modul în care ultimul Sprint a mers din punctul de vedere al oamenilor, relațiilor, proceselor și instrumentelor;
Identifica și aranja elementele majore care au mers bine și potențiale îmbunătățiri; și,
Crearea unui plan de implementare a îmbunătățirilor a modului în care Scrum Team își desfășoară activitatea.

Scrum Masterul încurajează Scrum Teamul să-și îmbunătățească, în cadrul de proces Scrum, pregătirea și practicile pentru a-l face mai eficient și mai plăcut în următorul Sprint. In timpul fiecărei Sprint Retrospective, Scrum Teamul planifică modalități de creștere a calității produselor prin îmbunătățirea proceselor de lucru sau prin adaptarea definiției de „Făcut“, dacă este cazul, și nu intră în conflict cu normele de produs sau ale organizației.

Până la sfârșitul Sprint Retrospective, Scrum Teamul trebuie să identifice îmbunătățirile pe care le va pune în aplicare în următorul Sprint. Punerea în aplicare a acestor îmbunătățiri în următorul Sprint este adaptarea la inspecția Scrum Teamului în sine. Deși îmbunătățirile pot fi puse în aplicare în orice moment, Sprint Retrospective oferă o ocazie formală de a se concentra pe inspecție și adaptare.

Artefactele Scrum

Artefacte Scrum reprezintă munca sau valoarea produsă pentru a oferi transparență și oportunități pentru inspecție și adaptare. Artefactele definite de Scrum sunt concepute special pentru a maximiza onestitatea informațiilor cheie, astfel încât toată lumea să aibă aceeași înțelegere a artefactului.

Product Backlog (Catalogul Produsului)

Product Backlogul este o listă ordonată a tot ceea ce este cunoscut a fi necesare în produs. Este singura sursă de cerințe pentru orice modificări care trebuie aduse produsului. Product Ownerul este răspunzător pentru Product Backlog, inclusiv pentru conținutul, disponibilitatea și aranjarea articolelor.

Product Backlogul nu este niciodată complet. Versiune anterioara a acestuia conține cerințele cunoscute inițial și cel mai bine înțelese. Product Backlogul evoluează odată cu evoluția produsului și a mediului în care va fi utilizat. Product Backlogul este dinamic; el se modifică în permanență pentru a identifica ceea ce produsul necesită pentru a fi adecvat, competitiv și util. Pentru orice produs existent, există de asemenea un Product Backlog.

Product Backlogul listează toate caracteristicile, funcționalitatea, cerințele, îmbunătățirile și remedierile care împreună constituie modificările care trebuie aduse produsului în versiunile ulterioare. Articolele din Product Backlog sunt definite prin descriere, ordine, estimare și valoare. Articolele din Product Backlog includ adesea indicații de testare care se vor valida că sunt complete atunci când sunt „Făcute“.

Pe măsură ce produsul este utilizat și acumulează valoare, iar piață oferă informații despre performanțele anterioare, Product Backlogul devine o listă mai lungă și mai exhaustivă. Cerințele nu se opresc niciodată din schimbare, în consecință Product Backlogul este un artefact viu. Modificări în cerințele pieței, condițiile de piață sau tehnologice pot provoca schimbări în Product Backlog.

În mod frecvent mai multe Scrum Teamuri lucrează împreună la același produs. Product Backlogul este folosit pentru a descrie activitatea viitoare la produs. O caracteristică a Product Backlogului este că articolele pot fi grupate înainte de a fi utilizate..

Rafinarea Product Backlogului reprezintă activitățile de adăugare de detalii, estimări pentru articolele din Product Backlog. Aceasta este un proces continuu în care Product Ownerul și Development Teamul colaborează în ceea ce privește detaliile articolelor din Product Backlog. În timpul rafinării Product Backlogului, articolele sunt analizate și revizuite. Scrum Teamul decide cum și când are loc rafinamentul; de obicei rafinarea Product Backlogului nu consumă mult de 10% din capacitatea Development Teamului. În definitiv, articolele din Product Backlog pot fi revizuite în orice moment de către Product Owner, revizuirea fiind la latitudinea Product Ownerului.

De obicei, articolele aflate mai în fața în Product Backlog sunt, mai clare și mai detaliate decât cele aflate la coada Product Backlogului. Precizia estimării depinde de claritatea descrierii si numărul de detalii disponibile; cu cât articolul este mai la coada Product Backlogului, cu atât mai puțin detalii va avea. Articolele din Product Backlog selectate de către Development Team pentru următorul Sprint sunt revizuite, astfel încât orice articol să poate fi în mod rezonabil „Făcut“, la sfârșitul duratei stabilite pentru Sprint. Articolele din Product Backlog care poate fi „Făcute“ de către Development Team într-un Sprint sunt considerate „Pregătite“ pentru selecția pentru Sprint Planning. Articole din Product Backlog dobândesc, de obicei, acest grad de pregătire prin activitățile de rafinare descrise mai sus.

Development Teamul este răspunzătoare pentru toate estimările. Product Ownerul poate influența Development Teamul, ajutând-ul să înțeleagă și să decidă compromisuri, dar cei care vor efectua munca fac estimarea finală.

Urmărirea Progresului în îndeplinirea Obiectivelor

În orice moment, activitatea totală rămasă pentru a atinge un obiectiv poate fi însumată. Product Ownerul controlează volumul de muncă rămas cel puțin la fiecare Sprint Review. Product Ownerul compară acest volum cu volumul de munca rămas la Sprint Reviewului anterior pentru a evalua progresul spre finalizarea lucrărilor la data planificate pentru atingerea obiectivului. Aceste informații trebuie să fie vizibile tuturor părților interesate. Diverse practici de vizualizare a progresului pot fi utilizate pentru a estima progresul, cum ar fi de exemplu graficele Burn-down, Burn-up, sau fluxurile cumulative. Deși acestea s-au dovedit utile ele nu diminuează importanța experimentării. În medii complexe, nu se știe ce se va întâmpla. Numai ceea ce sa întâmplat deja poate fi utilizat pentru luarea deciziilor care vor determina ce se întâmpla în viitor.

Sprint Backlog (Catalogul Sprintului)

Sprint Backlogul este un ansamblu de articole din Product Backlog selectate pentru Sprint, plus planul pentru livrarea Incrementului funcțional al produsului și de atingere a Obiectivului Sprintului. Sprint Backlogul este o prognoză făcută de Development Team despre ce capabilitate va fi adăugată de următorul Increment funcțional și a muncii necesare pentru a realiza această capabilitate într-un adaos funcțional „Făcut“.

Sprint Backlogul permite vizualizarea tuturor lucrărilor pe care Development Teamul le-a identificat ca fiind necesare pentru a îndeplini Obiectivul Sprintului. Pentru a asigura perfecționarea o continuă a procesului, acesta trebuie să includă cel puțin o îmbunătățire a procesului de prioritate ridicată identificata în întâlnirea Sprint Retrospective precedentă. Sprint Backlogul este un plan suficient de detaliat pentru ca schimbările efectuate pe parcursul Sprintului să poate fi percepute și înțelese în Daily Scrum. Development Teamul modifică Sprint Backlogul pe tot parcursul Sprintului, Sprint Backlogul formându-se de-a lungul Sprintului.

Această constituire apare în timp ce Development Teamul lucrează la realizarea planului și învață mai multe despre munca necesară pentru atingerea Obiectivului Sprintului. Cerințele noi apărute pe parcursul Sprintului sunt adăugate de către Development Team în Sprint Backlog. Pe măsură ce lucrările se desfășoară sau sunt finalizate, estimarea muncii rămase este actualizată.

Atunci când elemente ale planului sunt considerate inutile, acestea sunt eliminate. In timpul Sprintului numai Development Teamul poate efectua schimbări în Sprint Backlog. Sprint Backlogul este o reprezentare vizibilă în timp real a muncii pe care Development Teamul intenționează să o realizeze în timpul Sprintului și aparține exclusiv Development Teamului.

Urmărirea progresului Sprintului

În timpul Sprintului, volumul total de munca rămas în Sprint Backlog poate fi însumat in orice moment,. Development Teamul controlează volumul total de munca rămas, cel puțin la fiecare Daily Scrum pentru a estima probabilitatea de a atinge Obiectivul Sprintului. Prin urmărirea volumului de muncă rămas pe tot parcursul Sprintului, Development Teamul își poate administra progresul său.

Increment (Adaos funcțional)

Incrementul funcțional este suma tuturor articolelor din Product Backlog realizate în timpul unui Sprint și a valorii adaosurilor funcționale din toate Sprinturile anterioare. La sfârșitul unui Sprint, noul adaos funcțional trebuie să fie „Făcut“, ceea ce înseamnă că trebuie să fie în stare utilizabilă și să îndeplinească definiția de „Făcut“ stabilită de Scrum Team. Un Increment funcțional este un volum de muncă complet care poate fi verificat a sfârșitul Sprintului, sprijinind caracterul experimental al acestei abordări. Incrementul funcțional este un pas spre o viziune sau un obiectiv. Incrementul funcțional trebuie să fie în stare utilizabilă, indiferent dacă Product Ownerul decide să-l livreze.

Onestitatea Artefactelor

Scrum se bazează pe onestitate. Deciziile pentru optimizarea valorii și controlul riscului se iau pe baza stării percepute a artefactelor. În măsura în care onestitatea este desăvârșită, aceste decizii au o bază solidă. Dacă artefactele nu sunt oneste, aceste decizii pot fi eronate, valoarea se poate diminua și riscul poate crește.

Scrum Masterul trebuie să colaboreze cu Product Ownerul, Development Teamul precum și cu celelalte părți implicate pentru a înțelege onestitatea artefactelor. Există practici pentru a face față lipsei de onestitate; Scrum Masterul trebuie să-i ajute pe toți să aplice practicile cele mai adecvate în cazul în care onestitatea nu e desăvârșită. Scrum Masterul poate identifica lipsa onestității, prin inspectarea artefactelor, identificarea șabloanelor, ascultând cu atenție la ceea ce se spune și detectarea diferențelor dintre rezultatele așteptate și cele reale.

Datoria Scrum Masterului este de a lucra cu Scrum Teamul și organizația pentru a îmbunătăți onestitatea artefactelor. Acest lucru implică, de obicei, muncă de învățare, convingere și schimbare. Onestitatea nu are loc peste noapte, ci este o evoluție.

Ce înseamnă ”Făcut”

Atunci când un articol din Product Backlog sau un Increment funcțional este prezentat ca fiind „Făcut“, toată lumea trebuie să înțeleagă ce înseamnă „Făcut“. Deși acest lucru poate varia în mod semnificativ între Scrum Teamuri, pentru munca să fie completă și a asigura onestitatea membrii echipei trebuie să aibă o înțelegere comună a ceea ce înseamnă acest termen. Aceasta definiție a lucrului „Făcut“ este utilizată de către Scrum Team pentru a verifica dacă munca la Incrementul funcțional este realizată în întregime.

Aceeași definiție ghidează Development Teamul în a ști cât de multe articole din Product Backlog poate selecta în timpul Sprint Planning. Scopul fiecărui Sprint este de a livra Incremente de funcționalitate potențial livrabile care satisfac definiția de „Făcut“ dată de Scrum Team. În fiecare Sprint Development Teamurile livrează un Increment funcțional al produsului. Acest Increment funcțional trebuie să fie utilizabil, astfel încât Product Ownerul să poate alege să-l livreze imediat. Dacă definiția „Făcut“ pentru un Increment funcțional este inclus în normele, standardele sau liniile directoare ale organizației, toate Scrum Teamurile trebuie să o satisfacă ca un minimum.

Dacă „Făcut“ pentru un Increment funcțional nu este o definit în normele organizației, Development Teamul din cadrull Scrum Teamului trebuie să stabilească o definiție pentru „Făcut“ adecvată produsului la care lucrează. Dacă multe Scrum Teamuri lucrează pentru livrarea aceluiași sistem sau produs, Development Teamurile din toate Scrum Teamurile trebuie să stabilească reciproc definiția de „Făcut“.

Fiecare Increment funcțional este o adăugare la Incrementele funcționale anterioare și trebuie testat bine, pentru a se încredința că toate Incrementele lucrează împreună.

Pe măsură ce Scrum Teamurile se maturizează, este de așteptat ca definiția lor de „Făcut“ se va extinde pentru a include criterii mai stricte pentru a asigura o calitate superioară. Definiții noi, așa cum sunt utilizate, pot descoperi că o parte din munca făcută anterior nu este încă „Făcută“. Orice produs sau sistem trebuie să aibă o definiție a „Făcut“ etalon pentru orice muncă efectuată la el.