Mă gândeam pentru cursul de Scrum Gratuit de la Brașov și cele care vor urma să pun la dispoziție ultima versiune a Ghidului Scrum în Română. Zis și făcut. 

Exercițiul a fost mai mult decât interesant. Este impresionant cât de preciși încearcă să fie autorii cu cuvintele lor în acest ghid. Astfel am încercat să punctez în traducere diferențele dintre versiunea veche și cea nouă, după cum urmează:

• text adăugat în noua versiune – deși arată mult mai bine subliniat precum în imaginea de mai sus, eu n-am reușit să evidențiez textul adăugat decât colorându-l cu culoarea albastră;
• text dispărut în noua versiune – tăiat precum în exemplul alăturat;
• text neschimbat;
• some words in English – pentru ca cititorului să nu-i sune complet străină terminologia din engleză am mai adăugat pe ici, pe colo câte-o paranteză cu expresiile originale; În alte locuri anumite cuvinte n-au putut fi traduse – sau nu m-am descurcat eu – și-am lăsat textul original, evidențiindu-l cu aceeași culoare maro.

Sper ca această traducere să fie utilă și prietenilor de la Agile Works și să vedem curând și versiunea adusă la zi în lista celorlalte traduceri. 

Care sunt diferențele față de versiunea din 2011?

Traducere după documentul cu schimbările dintre cele două versiuni, publicat în engleză de către Ken Schwaber și Jeff Sutherland pe site-ul Scrum.org.

1. O secțiune cu Transparența Artefactului a fost adăugată. Scrum-ul se bazează pe transparență. Deciziile de optimizare a valorii și controlul riscurilor sunt luate pe baza stării percepute a artefactelor. În măsura în care transparența este completă, aceste decizii au o bază solidă. În măsura în care transparența este incompletă, aceste decizii pot fi eronate, valoarea poate scădea și riscurile pot crește.
2. Planificarea Sprintului este acum un eveniment. Două subiecte sunt adresate în el: Ce poate fi livrat în acest sprint? Cum va fi efectuat lucrul? După ce Echipa de Dezvoltare prognozează elementele din Product Backlog pe care le va livra în decursul Sprintului, întreaga Echipă Scrum definește Obiectivul Sprintului. Obiectivul Sprintului creează coerență în lucrul Echipei de Dezvoltare, coerență care nu ar fi prezentă în inițiativele individuale fără un obiectiv comun. De notat includerea formală a Obiectivului Sprintului.
3. Product Backlog-ul este mai degrabă rafinat (refined) decât îngrjit (groomed). Elementele din Product Backlog-ul rafinat sunt transparente, înțelese suficient de bine și granulate suficient astfel încât să servească ca date de intrare pentru Planificarea Sprintului și pentru selecția în Sprint. Elementele din Product Backlog cu această transparență sunt denumite „Gata” (Ready). „Gata” și „Finalizat” (Done) sunt două stări care consolidează transparența.
4. Scrum recomandă evenimentele sale pentru a crea regularitate și pentru a minimiza nevoia de ședințe nedefinte în Scrum. Toate evenimentele sunt limitate în timp, astfel încât fiecare eveniment să aibă o durată maximă. Un Sprint, ca container, are o durată fixă, pe care n-o putem scurta sau prelungi. Restul de evenimente s-ar putea termina oricând scopul evenimentului este atins; asigurând consumul cantității de timp adecvate fără să permitem să risipim timpul în proces.
5. Importanța Scrum-ului Zilnic (Daily Scrum) ca eveniment de planificare este consolidată. Evenimentul este văzut prea des ca o ședință de informare/raportare. În fiecare zi, Echipa de Dezvoltare trebuie să înțeleagă cum intenționează să lucreze împreună ca o echipă auto-organizată cu scopul de a atinge Obiectivul Sprintului și de a crea Incrementul (The Increment) anticipat până la finalul Sprintului. Datele de intrare pentru această ședință ar trebui să fie situația echipei/cum se descurcă echipa cu scopul îndeplinirii Obiectivului Sprintului. Rezultatul trebuie să fie un nou plan revizuit care optimizează efortul echipei în îndeplinirea Obiectivului de Sprint. În acest scop, cele trei întrebări au fost reformulate pentru a accentua echipa față de individ:
   • Ce am făcut ieri și a ajutat Echipa de Dezvoltare la îndeplinirea Obiectivului de Sprint?
   • Ce voi face astăzi ca să ajut Echipa de Dezvoltare să îndeplinească Obiectivul Sprintului?
   • Văd vreun obstacol care să mă împiedice pe mine sau pe Echipa de Dezvoltare să îndeplinească Obiectivul Sprintului?
6. Conceptul de valoare a fost consolidat pentru a fi folosit în Revizuirea Sprintului (Sprint Review). Pe parcursul Revizuirii Sprintului, Echipa Scrum și persoanele implicate colaborează cu privire la ceea ce a fost finalizat în Sprint. Pornind de la aceasta și de la orice altă modificare adusă Product Backlog-ului în timpul Sprintului, participanții colaborează pe următoarele lucruri care pot fi făcute ca să optimizeze valoarea.

Ghidul Scrum

versiunea iulie 2013

Traducere după Ghidul Scrum publicat în engleză de către Ken Schwaber și Jeff Sutherland pe site-ul Scrum.org. Pe alocuri m-am inspirat din traducerea vechii versiuni a Ghidului Scrum 2011 publicată aici.

Scopul Ghidului Scrum

Scrum este un cadru pentru dezvoltarea și susținerea produselor complexe. Acest ghid conține definiția Scrum-ului. Definiția este alcătuită din rolurile, evenimentele și artefactele Scrum-ului precum și din 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.

Definiția Prezentarea Scrum-ului

Scrum (subst.): un set de reguli prin care oamenii pot adresa probleme complexe de adaptare, furnizând într-un mod productiv și creativ produse de cea mai înaltă valoare posibilă. Scrum este:

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

Scrum este un cadru de proces utilizat pentru a gestiona dezvoltarea de produse complexe încă de la începutul anilor 1990. Scrum nu este un proces sau o tehnică de construire a produselor; mai degrabă este o bază de reguli prin care se pot încadra diferite procese și tehnici. Scrum clarifică eficacitatea relativă a managementului de produs și practicile de dezvoltare astfel încât să-l puteți îmbunătăți.

Cadrul Scrum

Cadrul Scrum este alcătuit din echipe Scrum și din rolurile, evenimentele, artefactele și regulile asociate lor. Orice constituent din acest cadru servește unui anumit scop și este esențial în reușita și utilizarea Scrum-ului. Regulile din Scrum leagă împreună evenimentele, rolurile și artefactele, guvernând asupra relațiilor și interacțiunea dintre ele. Regulile din Scrum sunt descrise în interiorul acestui document. Tactici specifice de utilizare a Scrum-ului diferă și sunt descrise în altă parte.

Teoria Scrum

Scrum este fondat pe teoria empirică de control al procesului, sau empirismul.  Empirismul declară că din experiență vin cunoștințele și luarea deciziilor se bazează pe ceea ce cunoaștem. Scrum angrenează o abordare iterativă, incrementală cu scopul de a optimiza predictibilitatea și controlarea riscurilor. Trei piloni susțin orice implementare a controlului procesului empiric: transparența, inspecția, și adaptarea.

Transparența

Aspecte semnificative ale procesului trebuie să fie vizibile celor responsabili cu rezultatele. Transparența cere ca aceste aspecte să fie definite de un standard comun astfel încât observatorii să interpreteze în același fel ceea ce văd. De exemplu:

• Un limbaj comun referitor la proces,care trebuie cunoscut de toți participanții; și,
• Cei care efectuează munca și cei care acceptă produsul rezultat trebuie să înțeleagă la fel definiția stării de „Finalizat” (Done).

Inspecția

Utilizatorii Scrum trebuie să inspecteze în mod frecvent artefactele și progresul făcut în îndeplinirea obiectivului Sprintului astfel încât să detecteze schimbările nedorite. Inspecția lor nu trebuie să fie atât de frecventă încât să împiedice munca. Inspecția este benefică mai ales atunci când este efectuată în mod sârguincios de către inspectori abili la locul de muncă.

Adaptarea

Dacă un inspector determină că unul sau mai multe aspecte ale procesului deviază de la limitele acceptabile și că produsul rezultat va fi inacceptabil, procesul sau materialul care este prelucrat trebuie să fie ajustat. Scrum prestabilește patru momente formalizate de inspecție și adaptare, precum sunt descrise în secțiunea Evenimentele Scrum a acestui document:

• Planificarea Sprintului (Sprint Planning)
• Scrum-ul zilnic (Daily Scrum)
• Revizuirea Sprintului (Sprint Review)
• Retrospectiva Sprintului (Sprint Retrospective)

Scrum

Scrum este un cadru structurat în așa fel încât să suporte dezvoltarea produselor complexe. Scrum este alcătuit din Echipele Scrum și rolurile, evenimentele, artefactele și regulile asociate acestora. Fiecare componentă servește unui anumit scop și este esențială utilizării și reușitei Scrum-ului.

Echipa Scrum

Echipa Scrum este alcătuită din Product Owner („Deținătorul Produsului”) , „Echipa de Dezvoltare” (Development Team), și un Scrum Master („Maestrul Scrum”). Echipele Scrum se auto-organizează și sunt transversal-funcționale. Echipele auto-organizate își aleg mai degrabă cum să-și îndeplinească munca cel mai bine, decât să fie ghidați de alții din afara echipei. Echipele transversal-funcționale au toate abilitățile necesare să-și îndeplinească munca fără să depindă de alte persoane din afara echipei. Echipa model Scrum este concepută să optimizeze flexibilitatea, creativitatea și productivitatea. Echipele Scrum livrează produsele în mod iterativ și incremental, maximizând oportunitățile de obținere a feedbackului. Livrările incrementale ale produsului „finalizat” (Done), asigură că avem mereu o versiune potențial folositoare a produsului în lucru care este mereu disponibilă.

Product Owner-ul (Deținătorul Produsului)

Product Onwer-ul este responsabil cu maximizarea valorii produsului și a muncii Echipei de Dezvoltare. Modul în care maximizarea este implementată poate varia foarte mult în funcție de organizații, Echipele Scrum sau de indivizi. Product Onwer-ul este singura persoană responsabilă cu gestiunea Product Backlog-ului. Managementul Product Backlog-ului include:

• exprimarea precisă a elementelor din Product Backlog;
• Ordonarea elementelor din Product Backlog pentru a realiza cel mai bine obiectivele și misiunile;
• Optimizarea valorii muncii realizate de Echipa de Dezvoltare;
• Garantarea faptului că Product Backlog-ul este vizibil, transparent, și clar pentru toți, și arată pe ce anume va lucra echipa în continuare; și,
• Garantarea faptului că echipa înțelege elementele din Product Backlog până la nivelul necesar.

Product Owner-ul poate să facă activitățile de mai sus, sau să ceară Echipei de Dezvoltare să o facă. Totuși, Product Owner-ul rămâne responsabil. Product Owner-ul este o persoană, nu un comitet. Product Owner-ul poate să reprezinte dorințele unui comitet în Product Backlog, dar cei care doresc să modifice prioritatea unui element din Product Backlog trebuie să se adreseze Product Owner-ului. Pentru ca Product Owner-ul să reușească, întreaga organizație trebuie să-i respecte deciziile. Deciziile Product Owner-ului sunt vizibile în conținutul și ordonarea Product Backlog-ului. Nimeni nu are voie să ceară Echipei de Dezvoltare să lucreze dintr-un alt set de cerințe, și Echipa de Dezvoltare nu are voie să acționeze la ceea ce spune altcineva.

Echipa de Dezvoltare (Development Team)

Echipa de Dezvoltare este alcătuită din profesioniști care îndeplinesc sarcinile de livrare a incrementului (Increment) de produs potențial livrabil cu elemente „finalizate” (done) la finalul fiecărui Sprint. Doar membrii Echipei de Dezvoltare creează incrementatul (the Increment). Echipele de Dezvoltare sunt structurate și împuternicite de organizație să-și organizeze și să-și gestioneze munca. Sinergia rezultată optimizează eficacitatea și eficiența în ansamblul Echipei de Dezvoltare. Echipele de Dezvoltare au următoarele caracteristici:

• Se auto-organizează. Nimeni (nici măcar Scrum Master-ul) nu spune Echipei de Dezvoltare cum să transforme Product Backlog-ul în incremente (Increments) ale funcționalității potențial livrabile;
• Echipele de Dezvoltare sunt transversal-funcționale, cu toate abilitățile necesare ca echipă să creeze un increment al produsului;
• Scrum nu recunoaște niciun titlu pentru membrii Echipei de Dezvoltare în afară de Dezvoltator, indiferent de munca realizată de respectiva persoană; nu există excepții de la această regulă;
• Scrum nu recunoaște sub-echipe în Echipa de Dezvoltare, indiferent de domeniile particulare care trebuiesc adresate precum testarea sau analiza de business; nu există excepții de la această regulă; și,
• Membrii individuali ai Echipei de Dezvoltare ar putea avea abilități specializate sau zone de interes, dar răspunderea aparține Echipei de Dezvoltare ca un întreg.

Dimensiunea Echipei de Dezvoltare

Mărimea Echipei de Dezvoltare optime este suficient de mică ca să rămână sprintenă și destul de mare încât să termine o muncă semnificativă în timpul Sprintului. Mai puțin de trei membri ai Echipei de Dezvoltare va scădea interacțiunea rezultând în câștiguri mai mici de productivitate. Echipe de Dezvoltare mai mici ar putea întâmpina constrângeri legate de competențe în timpul Sprintului, făcând Echipa de Dezvoltare incapabilă să livreze un increment potențial livrabil. Necesitatea de coordonare este prea mare când sunt mai mult de nouă membri. Echipele de Dezvoltare mari generează prea multă complexitate pentru a fi gestionate de un proces empiric. Rolurile de Product Owner și Scrum Master nu sunt luate în calcul atâta timp cât ei nu execută munca din Sprint Backlog.

Scrum Master-ul (Maestrul Scrum)

Scrum Master-ul este responsabil cu garantarea înțelegerii și adoptării Scrum-ului. Scrum Master-ii fac asta asigurându-se că Echipa Scrum aderă la teoria, practicile și regulile Scrum. Scrum Master-ul este un servitor-lider pentru Echipa Scrum. Scrum Master-ul îi ajută pe cei din afara Echipei Scrum să înțeleagă care din interacțiunile lor cu Echipa Scrum sunt utile și care nu. Scrum Master-ul ajută pe toată lumea să schimbe aceste interacțiuni ca să maximizeze valoarea creată de Echipa Scrum.

Serviciile Scrum Master-ului pentru Product Owner

Scrum Master-ul își servește Product Owner-ul în câteva moduri, printre care:

• Găsind tehnici de gestionare eficace a Product Backlog-ului;
• Comunicând clar și concis viziunea, obiectivele, și elementele Product Backlog-ului către Echipa de Dezvoltare;
• Instruind Ajutând Echipa Scrum să creeze să înțeleagă nevoia de elemente clare și concise în Product Backlog;
• Înțelegând planificarea produsului pe termen lung într-un mediu empiric;
• Asigurându-se că Product Owner-ul cunoaște cum să aranjeze Product Backlog-ul ca să maximizeze valoarea;
• Înțelegând și practicând agilitatea; și,
• Facilitând evenimentele Scrum așa cum sunt cerute sau necesare

Serviciile Scrum Master-ului pentru Echipa de Dezvoltare

Scrum Master-ul își servește Echipa de Dezvoltare-ul în câteva moduri, printre care:

• Antrenând Echipa de Dezvoltare în auto-organizare și transveral-funcționare;
• Instruind și îndrumând Ajutând Echipa de Dezvoltare să creeze produse cu valoare ridicată;
• Eliminând obstacolele (impediments) din calea Echipei de Dezvoltare;
• Facilitând evenimentele Scrum așa cum sunt cerute sau necesare; și,
• Antrenând Echipa de Dezvoltare în mediile organizaționale în care Scrum-ul nu este încă adoptat sau înțeles.

Serviciul Scrum Master-ului pentru Organizație

Scrum Master-ul își servește Organizația în mai multe moduri, printre care:

• Îndrumând și antrenând Organizația în adoptarea Scrum;
• Planificând implementarea Scrum-ului în cadrul organizației;
• Ajutând angajații și persoanele implicate să înțeleagă și să adopte Scrum și să înțeleagă dezvoltarea empirică de produse;
• Cauzând schimbarea care crește productivitatea echipe de Scrum; și
• Lucrând cu alți Scrum Master-i să crească eficiența aplicării Scrum-ului în organizație.

Evenimentele Scrum

Evenimentele prestabilite sunt folosite în Scrum să creeze regularitate și să minimizeze nevoia de ședințe nedefinite în Scrum. Toate evenimentele sunt limitate în timp, astfel încât fiecare eveniment să aibă o durată maximă.  Odată ce un Sprint pornește, durata lui este fixă și nu poate fi micșorat sau mărit. Evenimentele rămase se pot termina oricând atunci când scopul lor este atins, asigurându-ne că timpul corespunzător este consumat planificând fără să permitem irosirea lui în proces. În afara Sprintului propriuzis, care este containerul pentru toate celelalte evenimente, fiecare eveniment din Scrum este o oportunitate formalizată de a inspecta și adapta ceva. Aceste evenimente sunt concepute special să permită transparența esențială și inspecția. Eșecul de a include oricare dintre aceste evenimente conduce la o transparență redusă și este o oportunitate pierdută să inspectăm și să adaptăm.

Sprintul

Inima Scrum-ului este un Sprint, limitat la o lună sau mai puțin, în timpul căruia se creează incrementul produsului „finalizat” (done), utilizabil și potențial livrabil. Sprinturile cele mai bune au o durată consistentă de-a lungul efortului de dezvoltare. Un nou Sprint începe imediat după concluzia Sprintului anterior. Sprinturile conțin și sunt alcătuite din Planificarea Sprintului (Sprint Planning), Scrum-ul zilnic (Daily Scrum), muncă de dezvoltare, Revizuirea Sprintului (sprint Review) și Retrospectiva Sprintului (Sprint Retrospective).

În timpul sprintului:

• Nicio schimbare care să pună în pericol Obiectivul Sprintului (Sprint Goal) nu este făcută;
• Obiectivele legate de calitate nu scad; și,
• Scopul Sprintului poate fi clarificat și renegociat între Product Owner și Echipa de Dezvoltare pe măsură ce învățăm.

Fiecare Sprint poate fi considerat un proiect cu un orizont de timp nu mai mare de o lună. Ca proiectele, scopul Sprinturilor este să îndeplinească ceva. Fiecare Sprint are o definiție despre ceea ce urmează să fie construit, un concept și un plan flexibil care va ghida echipa în construcția lui, munca și produsul de realizat. Sprinturile sunt limitate la o lună calendaristică. Când orizontul unui sprint este prea lung definiția a ceea ce construim se poate schimba, iar complexitatea și riscurile pot crește. Sprinturile permit predictibilitate asigurând inspecția și adaptarea progresului către un obiectiv Obiectivul Sprintului măcar la fiecare lună calendaristică. De asemenea Sprinturile limitează riscurile privind costurile la o lună calendaristică.

Anularea Sprintului

Un Sprint poate fi anulat înainte de data prevăzută inițial. Doar Product Owner-ul are autoritatea de a Anula Sprintul, deși acesta poate acționa sub influența persoanelor implicate, Echipei de Dezvoltare sau a Scrum Master-ului. Un Sprint poate fi anulat și în cazul în care ținta Sprint-ului devine perimată. Asta s-ar putea întâmpla dacă compania schimbă direcția sau dacă condițiile pieței sau cele tehnologice se schimbă. În general, Un Sprint ar trebui să fie anulat dacă nu mai are sens în circumstanțele date. Dar, din cauza duratei scurte a Sprinturilor, anularea are rar sens. Când un Sprint este anulat, toate elementele „Finalizate” (Done) ale Product Backlog-ului sunt revizuite. Dacă o parte din lucrurile realizate sunt potențial livrabile, de obicei Product Owner-ul le va accepta. Toate elementele incomplete ale Product Backlog-ului sunt reestimate și repuse în Product Backlog. Munca făcută pe aceste elemente se depreciază rapid și trebuie să le reestimăm în mod frecvent. Anularea Sprintului consumă resurse, deoarece toată lumea trebuie să se regrupeze într-o altă ședință de Planificare a Sprintului (Sprint Planning) pentru a începe un alt Sprint. Anulările Sprinturilor sunt adesea traumatizante pentru Echipa de Scrum și sunt foarte rar întâlnite.

Planificarea Sprintului (Sprint Planning Meeting)

Muncă ce urmează a fi realizată în cadrul Sprintului este planificată în ședința de Planificare a Sprintului. Acest plan este creat prin munca colaborativă a întregii Echipe de Scrum. Planificarea Sprintului este limitată în timp la un maxim de 8 ore pentru un Sprint de o lună calendaristică. Pentru Sprinturi mai scurte, evenimentul este de obicei proporțional mai scurt.  De exemplu, un Sprint de 2 săptămâni va avea o ședință de Planificare a Sprintului de 4 ore. Scrum Master-ul se asigură că evenimentul are loc și că participanții îi înțeleg scopul. Scrum Master-ul își învață Echipa Scrum să păstreze evenimentul limitat în timp. Planificarea Sprintului este formată din două părți, fiecare fiind jumătate din durata întregii întâlniri. Cele două părți trebuie să răspundă la următoarele întrebări, respectiv: Planificarea Sprintului răspunde la următoarele:

• Ce poate fi livrat în Incrementul care rezultă din Sprintul următor?
• Cum va fi efectuată munca pentru ca acest Increment să fie livrat?

Partea întâi Primul subiect: Ce poate fi făcut în acest Sprint?

Echipa de Dezvoltare lucrează să anticipeze funcționalitatea pe care o vor dezvolta în decursul Sprintului. Product Owner-ul prezintă elementele ordonate din Product Backlog Echipei de Dezvoltare, și întreaga Echipă Scrum colaborează la înțelegerea a ceea ce trebuie realizat în cadrul Sprintului.  Product Owner-ul discută obiectivele pe care Sprintul trebuie să le întâlnească și elementele din Product Backlog care, dacă sunt completate în Sprint, ar atinge Obiectivul Sprintului.  Datele de intrare la această întrunire sunt Product Backlog-ul, ultimul Increment al produsului, capacitatea estimată a Echipei de Dezvoltare pe parcursul Sprintului și performanțele anterioare ale Echipei de Dezvoltare. Numărul de elemente selectate din Product Backlog pentru Sprint este decis exclusiv de către Echipa de Dezvoltare. Numai Echipa de Dezvoltare poate evalua ce poate să realizeze pe parcursul Sprintului următor. După ce Echipa de Dezvoltare prognozează elementele din Product Backlog pe care le va livra în decursul Sprintului, întreaga Echipă Scrum definește Obiectivul Sprintului. Obiectivul Sprintului este o țintă care va fi atinsă în Sprint prin implementarea Product Backlogului, și oferă îndrumări Echipei de Dezvoltare despre motivul construirii Incrementului.

Partea a doua  Al doilea subiect: Cum se vor realiza activitățile selecționate?

Având ceea ce este de făcut în cadrul Sprintului Obiectivul Sprintului stabilit și elementele din Product Backlog selecționate, Echipa de Dezvoltare decide cum va construi această funcționalitate într-un Increment de produs „finalizat” (Done) pe parcursul Sprintului. Elementele selecționate pentru acest Sprint plus planul cu livrarea lor este numit Backlog-ul de Sprint (Sprint Backlog). Echipa începe de obicei cu conceperea sistemului și a lucrului necesar conversiei Product Backlog-ului în Incrementul de Produs funcțional. Lucrul poate fi de diferite dimensiuni sau efort estimat. Cu toate acestea, în ședința de Planificare a Sprintului planificăm suficientă muncă, astfel încât Echipa de Dezvoltare să poată previziona ceea ce crede că poate realiza pe parcursul Sprintului următor. Lucrul planificat pentru primele zile este descompus până la finalul întrunirii, de obicei în unități de o zi sau mai puțin, Echipa de Dezvoltare se auto-organizează pentru îndeplinirea lucrului din Backlog-ul de Sprint, atât în timpul Planificării Sprintului cât și atunci când este nevoie pe parcursul Sprintului. Product Owner-ul poate ajuta ar putea fi prezent la clarificarea elementelor selecționate din Product Backlog și să facă compromisuri. Dacă Echipa de Dezvoltare determină că are prea mult de muncă sau prea puțin, ar putea renegocia elementele selectate din Product Backlog cu Product Owner-ul. Echipa de Dezvoltare ar putea de asemenea să invite alți oameni să participe cu scopul de a furniza sfaturi tehnice sau legate de domeniul de business. Până la finalul Planificării Sprintului, Echipa de Dezvoltare ar trebui să fie capabilă să explice Product Owner-ului și Scrum Master-ului cum intenționează să lucreze ca echipă auto-organizată în vederea realizării Obiectivului de Sprint și să creeze Incrementul anticipat.

Obiectivul Sprintului (Sprint Goal)

Obiectivul Sprintului este o țintă setată pentru Sprint, care poate fi atinsă prin implementarea Product Backlog-ului. Aduce îndrumări Echipei de Dezvoltare referitor la motivele implementării Incrementului. Este creat pe parcursul ședinței de Planificare a Sprintului. Obiectivul Sprintului oferă Echipei de dezvoltare un anumit grad de flexibilitate în ceea ce privește funcționalitatea implementată în decursul Sprintului. Elementele selectate din Product Backlog livrează o funcție coerentă, care poate fi Obiectivul Sprintului. Obiectivul Sprintului poate fi orice coerență care determină Echipa de Dezvoltare să lucreze mai degrabă împreună decât pe inițiative separate. Pe măsură ce Echipa de Dezvoltare lucrează, păstrează Obiectivul Sprintului în minte. Pentru a realiza Obiectivul Sprintului, aceasta implementează funcționalitatea și tehnologia. Dacă munca se dovedește a fi diferită de ceea ce Echipa de Dezvoltare s-a așteptat, ei colaborează cu Product Owner-ul în vederea negocierii scopului Sprint Backlog-ului pe parcursul Sprintului. Obiectivul Sprint-ului poate fi un jalon în cadrul scopului mai mare al planului de produs.

Scrumul Zilnic (Daily Scrum)

Scrum-ul Zilnic este un eveniment cu durata limitată la 15 minute cu scopul sincronizării activităților Echipei de Dezvoltare și creării unui plan pentru următoarele 24 de ore. Toate astea pot fi reușite prin inspectarea lucrului realizat de la Scrum-ul Zilnic anterior și prognozând lucrul pe care pot să-l realizeze până la următorul. Scrum-ul Zilnic se desfășoară la aceeași oră și în același loc în fiecare zi pentru a reduce complexitatea. În timpul ședinței, membrii Echipei de Dezvoltare explică:

• Ce s-a realizat de la ultima întâlnire?
• Ce va fi făcut până la următoarea întâlnire?
• Ce obstacole sau piedici au apărut pe parcurs?

• Ce am făcut ieri și a ajutat Echipa de Dezvoltare la îndeplinirea Obiectivului de Sprint?
• Ce voi face astăzi ca să ajut Echipa de Dezvoltare să îndeplinească Obiectivul Sprintului?
• Văd vreun obstacol care să mă împiedice pe mine sau pe Echipa de Dezvoltare să îndeplinească Obiectivul Sprintului?

Echipa de Dezvoltare folosește Scrum-ul Zilnic ca să evalueze inspecteze progresul spre îndeplinirea Obiectivului de Sprint și totodată să evalueze inspecteze tendința progresului în finalizarea lucrului din Backlog-ul de Sprint. Scrum-ul zilnic optimizează probabilitatea ca Echipa de Dezvoltare să-și atingă Obiectivul Sprintului. În fiecare zi, Echipa de Dezvoltare ar trebui să poată explica Product Owner-ului și Scrum Master-ului înțeleagă cum intenționează să lucreze împreună, ca o echipă care se auto-organizează să îndeplinească Obiectivul Sprintului și să creeze Incrementul anticipat până la finalul Sprintului. Echipa de Dezvoltare sau membrii echipei se întâlnesc deseori pentru discuții detaliate, ori să adapteze sau să replănuiască restul lucrului de realizat în Sprint. Scrum Master-ul se asigură că Echipa de Dezvoltare are o ședință, dar Echipa de Dezvoltare este responsabilă pentru dirijarea Scrum-ului Zilnic. Scrum Master-ul instruiește Echipa de Dezvoltare să păstreze Scrum-ul Zilnic în limita celor 15 minute. Scrum Master-ul împuternicește regula ca doar Echipa de Dezvoltare să participe la Scrum-ul Zilnic. Scrum-ul Zilnic nu este o întâlnire de raportare și este dedicat celor care transformă elementele din Product Backlog într-un Increment. Scrum-urile Zilnice îmbunătățesc comunicarea, elimină alte ședințe, identifică obstacolele pentru a fi scoase din calea dezvoltării, evidențiază și promovează luarea rapidă a deciziilor și îmbunătățește nivelul de cunoștințe al Echipei de Dezvoltare. Această întâlnire este un factor cheie de inspecție și adaptare.

Revizuirea Sprintului (Sprint Review)

Ședința de Revizuirea a Sprintului este ținută la finalul Sprintului pentru a inspecta Incrementul și a adapta Product Backlog-ul dacă este necesar. Pe parcursul Revizuirii Sprintului, Echipa Scrum și persoanele implicate colaborează cu privire la ceea ce a fost finalizat în Sprint. Pornind de la aceasta și de la orice altă modificare adusă Product Backlog-ului în timpul Sprintului, participanții colaborează legat de următoarele lucruri pe care le pot îndeplini ca să optimizeze valoarea. Este o ședință informală, nu de raportare, și prezentarea Incrementului este intenționată să smulgă feedbackul și să promoveze colaborarea. Durata Revizuirii Sprintului este limitată la 4 ore pentru Sprinturile de o lună. Pentru Sprinturi mai mici, evenimentul durează de obicei proporțional mai puțin. De exemplu, un sprint de 2 săptămâni are Revizuirea Sprintului limitată la 2 ore.  Scrum Master-ul se asigură că evenimentul are loc și că participanții îi înțeleg scopul. Scrum Master-ul își învață echipa să nu depășească limita de timp definită. Revizuirea Sprintului include următoarele elemente:

• În lista participanților este inclusă Echipa Scrum și persoanele implicate cheie invitate de Product Owner;
• Product Owner-ul explică care elemente din Product Backlog au fost finalizate și ce nu a fost finalizat;
• Echipa de Dezvoltare, discută ce a funcționat bine în timpul Sprintului, care au fost problemele de care s-au lovit, și cum au fost rezolvate aceste probleme;
• Echipa de Dezvoltare, demonstrează lucrul „finalizat” (Done) și răspunde întrebărilor legate de Increment;
• Product Owner-ul discută Product Backlog-ul așa cum se prezintă în momentul respectiv. El sau ea preconizează datele posibile de finalizare bazate pe progresul înregistrat până în prezent (dacă este necesar);
• Întregul grup colaborează legat de ceea ce urmează să implementeze ulterior, astfel încât Revizuirea Sprintului să furnizeze date de intrare de valoare pentru următoarele sesiuni următoarea sesiune de Planificare a Sprintului;
• Se revizuiește cum piața de desfacere sau utilizarea potențială a produsului ar fi schimbat cel mai valoros lucru cu care să continuăm; și,
• Revizuirea cronologiei proiectului, bugetului, capabilităților potențiale și a pieței de desfacere pentru următoarea livrare anticipată.

Rezultatul Revizuirii Sprintului este un Product Backlog revizuit care definește elementele probabile din Product Backlog pentru următorul Sprint. Product Backlog-ul poate fi ajustat în ansamblul lui pentru a răspunde unor oportunități noi.

Retrospectiva Sprintului (Sprint Retrospective)

Retrospectiva Sprintului reprezintă o oportunitate pentru Echipa Scrum să se inspecteze pe ea însăși și să creeze un plan cu ameliorări pe care să le adopte în Sprintul următor. Retrospectiva Sprintului are loc după Revizuirea Sprintului și înaintea următoarei sesiuni de Planificarea Sprintului.  Această ședință are durata constrânsă la 3 ore pentru Sprinturile de o lună. Pentru Sprinturile mai mici, acest eveniment durează de obicei proporțional mai puțin. Scrum Master-ul se asigură că evenimentul are loc și că participanții îi înțeleg scopul. Scrum Master-ul își învață echipa să nu depășească limita de timp definită. Scrum Master-ul participă la ședință ca un membru egal al echipei datorită responsabilității sale asupra procesului Scrum. Scopul Retrospectivei Sprintului este:

• De a inspecta modul în care ultimul Sprint a funcționat cu privire la oameni, relații, proces, și instrumente;
• De a identifica și ordona elementele majore care au mers bine și îmbunătățirile potențiale; și
• De a crea un plan pentru punerea în aplicare a îmbunătățirilor în modul în care Echipa Scrum își desfășoară activitatea.

Scrum Master-ul își încurajează Echipa de Scrum să îmbunătățească, în cadrul contextului Scrum, procesul de dezvoltare și practicile pentru ca dezvoltarea să devină mai eficace și plăcută pentru Sprintul următor. Pe parcursul fiecărei Retrospective de Sprint, Echipa Scrum planifică moduri de creștere a calității prin adaptarea definiției „Finalizat” (Done) atunci când este nevoie. Până la finalul Retrospectivei Sprintului, Echipa Scrum ar trebui să fi identificat ameliorări pe care să le implementeze în Sprintul următor. Implementarea acestora în Sprintul următor este adaptarea la inspecția Echipei Scrum. Deși îmbunătățirile pot fi implementate în orice moment, Retrospectiva Sprintului este o oportunitate formală de a se concentra pe inspecție și adaptare.

Artefactele Scrum

Artefactele Scrum reprezintă munca și valoarea sub diverse forme care sunt folosite în asigurarea cu scopul furnizării transparenței și a oportunităților pentru inspecție și adaptare. Artefactele definite de Scrum sunt concepute special pentru a maximiza transparența informațiilor cheie necesare să asigure Echipelor Scrum reușita în livrarea unui Increment considerat „Finalizat”, astfel încât fiecare să aibă același nivel de înțelegere asupra artefactelor.

Product Backlog (Backlog-ul de produs)

Product Backlog-ul este o listă ordonată cu tot ce poate fi necesar în produs și este singura sursă de cerințe conținând toate schimbările care trebuie făcute produsului. Product Owner-ul este responsabil de Product Backlog, incluzând conținutul său, disponibilitatea și ordinea sarcinilor. Product Backlog-ul nu este niciodată complet. Cea mai timpurie dezvoltare a sa prezintă cerințele cunoscute inițial și cel mai bine înțelese. Product Backlog-ul evoluează odată cu produsul și evoluția mediului în care acesta va fi folosit. Product Backlog-ul este dinamic, se schimbă constant pentru a identifica de ce are nevoie produsul pentru a fi adecvat, competitiv și folositor. Atâta timp cât un produs există, va exista și Product Backlog-ul acestuia. Product Backlog-ul listează toate caracteristicile, facilitățile, funcțiile, cerințele, îmbunătățirile și corecțiile care constituie schimbările necesare a fi făcute produsului în livrările viitoare. Elementele din Product Backlog au atributele: descriere, rang/ordinea în listă, estimare și valoare. Product Backlog-ul este adesea ordonat după valoare, risc, prioritate și necesitate. Elementele cu cea mai mare prioritate vor fi dezvoltate imediat. Cu cât mai mare este prioritatea, cu atât mai mult elementul din Product Backlog a fost analizat, și există mai mult consens în privința sa și a valorii sale. Pe măsură ce un produs este folosit și câștigă în valoare, și piața furnizează feedback, Product Backlog-ul devine o listă mai mare și mai cuprinzătoare. Cerințele nu încetează niciodată să se schimbe, astfel încât Product Backlog-ul este un artefact viu. Schimbările în cerințe de business, în condițiile pieței, sau în domeniul tehnologiei pot cauza schimbări în Product Backlog. Echipe Scrum multiple lucrează deseori împreună la același produs. Un Product Backlog este folosit să descrie șantierul următor despre produs. Un atribut care să regrupeze elementele din Product Backlog poate fi adăugat. Rafinarea Îngrijirea (Refinement Grooming)  Product Backlog-ului este actul de adăugare a detaliilor, estimărilor, și ordonarea elementelor din Product Backlog. Acesta este un proces continuu prin care Product Owner-ul și Echipa de Dezvoltare colaborează pe detaliile elementelor din Product Backlog. Pe parcursul rafinării Product Backlog-ului, elementele sunt revizuite și corectate. Echipa Scrum decide cum și când are loc revizuirea. De obicei rafinarea nu consumă mai mult de 10% din capacitatea Echipei de Dezvoltare. Totuși, elementele Product Backlog-ului pot fi aduse la zi în orice moment de către Product Owner sau de cineva la discreția Product Owner-ului. Îngrijirea Product Backlog-ului este o activitate cu jumătate de normă pe parcursul Sprintului îmârțită între Product Owner și Echipa de Dezvoltare. Destul de des, Echipa de Dezvoltare are suficient de multe cunoștințe ale domeniului de activitate încât pot realiza această activitate și singuri. Elementele ordonate mai sus (cu rangul mai mare) în Product Backlog sunt de obicei mai clare și mai detaliate decât cele ordonate mai jos. Estimările mai precise sunt bazate pe claritate mai bună și detalii bogate; Cu cât rangul este mai mic cu atât nivelul de detalii este mai mic. Elementele din Product Backlog de care se va ocupa Echipa de Dezvoltare în Sprintul care urmează sunt rafinate fiind descompuse astfel încât oricare element să poată fi „finalizat” în mod rezonabil și în durata fixă alocată Sprintului. Elementele din Product Backlog pe care Echipa de Dezvoltare le poate realiza într-un Sprint sunt considerate „Pregătite” (Ready) sau „gata de atac” pentru selectare lor în Planificarea Sprintului. Elementele Product Backlog-ului, dobândesc de obicei acest grad de transparență prin intermediul activităților de rafinare descrise mai sus. Echipa de Dezvoltare este responsabilă pentru toate estimările. Product Owner-ul poate influența Echipa de Dezvoltare ajutând-o să înțeleagă și să facă compromisuri, dar doar oamenii care vor realiza lucrul fac estimarea finală.

Monitorizarea progresului către un obiectiv

În orice moment, lucrul total rămas de realizat pentru a atinge obiectivul poate fi însumat. Product Owner-ul trasează acest volum total de lucru cel puțin la fiecare Revizuire de Sprint. Product Owner-ul compară această valoare cu munca rămasă de la celelalte Revizuiri de Sprint pentru a evalua progresul față de finalizarea estimată în funcție de data dorită pentru atingerea obiectivului. Diverse practici de proiecție/vizualizare a tendinței au fost folosite pentru a prognoza progresul, precum graficele de tip burn-down, burn-up, sau flux cumulativ (cumulative flow). Acestea s-au dovedit utile. Totuși, acestea nu înlocuiesc importanța empirismului. În mediile complexe, ceea ce se va întâmpla ne este necunoscut. Doar ceea ce s-a întâmplat poate fi folosit în luarea deciziilor viitoare. Sprint Backlog (Backlog-ul de Sprint) Sprint Backlog-ul este setul de elemente din Product Backlog pe care le-am selectat pentru Sprint plus planul cu livrarea Incrementului produsului și cu realizarea Obiectivului Sprintului. Sprint Backlog-ul este prognoza Echipei de Dezvoltare cu privire la funcționalitatea cuprinsă în Incrementul următor precum și prognoza muncii necesare livrării acesteia într-un Increment „finalizat”. Sprint Backlog-ul definește lucrul pe care Echipa de Dezvoltare îl va realiza pentru a transforma elementele din Product Backlog în incrementul „finalizat”. Sprint Backlog-ul face vizibilă toată munca pe care Echipa de Dezvoltare o identifică ca necesară pentru a atinge Obiectivul Sprintului. Sprint Backlog-ul este un plan cu destule detalii astfel încât modificările care survin pe parcurs să fie înțelese în Scrum-ul Zilnic. Echipa de Dezvoltare modifică Sprint Backlog-ul de-a lungul Sprintului, și Sprint Backlog-ul emerge pe parcursul Sprintului. Această emergență are loc pe măsură ce Echipa de Dezvoltare lucrează respectând planul și învață mai multe despre munca necesară atingerii Obiectivului de Sprint. Echipa de Dezvoltare adaugă noul lucru identificat în Sprint Backlog. Pe măsură ce lucrul este realizat sau completat, timpul estimat rămas de lucru este adus la zi. Când elemente ale planului sunt apreciate ca fiind inutile, ele sunt scoase. Doar Echipa de Dezvoltare poate schimba Sprint Backlog-ul. Sprint Backlog-ul este foarte vizibil, reprezintă o imagine în timp real asupra lucrului pe care Echipa de Dezvoltare intenționează să-l realizeze pe parcursul Sprint-ului și aparține exclusiv Echipei de Dezvoltare.

Monitorizarea Progresului într-un Sprint

La orice moment din Sprint, lucrul total rămas de realizat în Sprint Backlog poate fi însumat. Echipa de Dezvoltare urmărește lucrul rămas de realizat cel puțin o dată la fiecare Scrum Zilnic pentru a estima probabilitatea atingerii Obiectivului de Sprint. Urmărind lucrul rămas de realizat de-a lungul Sprintului, Echipa de Dezvoltare poate gestiona procesul său. Scrum nu ia în considerare timpul petrecut lucrând pe elementele Product Backlog-ului. Lucrul rămas de realizat și data sunt singurele variabile care ne interesează.

Incrementul (Increment)

Incrementul este suma tuturor elementelor din Product Backlog completate de-a lungul unui Sprint și valoarea Incrementelor din Sprinturile anterioare. La finalul unui Sprint, noul Increment trebuie să fie „Finalizat” (Done), ceea ce înseamnă că trebuie să fie în condiții utilizabile și să îndeplinească definiția  de „Finalizat” stabilită de Echipa de Dezvoltare. Trebuie să fie în condiții utilizabile indiferent dacă Product Owner-ul cere să livreze sau nu.

Transparența Artefactelor

Scrum-ul se bazează pe transparență. Deciziile de optimizare a valorii și controlul riscurilor sunt luate pe baza stării percepute a artefactelor. În măsura în care transparența este completă, aceste decizii au o bază solidă. În măsura în care transparența este incompletă, aceste decizii pot fi eronate, valoarea poate scădea și riscurile pot crește. Scrum Master-ul trebuie să lucreze cu Product Owner-ul, Echipa de Dezvoltare, și alte părți implicate să înțeleagă dacă artefactele sunt complet transparente. Există practici de copiere cu transparență incompletă; Scrum Master-ul trebuie să ajute pe toată lumea în aplicarea practicilor cele mai adecvate în absența transparenței complete. Un Scrum Master poate detecta transparența incompletă inspectând artefactele, detectând șabloane, ascultând atent la ceea ce se spune și detectând diferențele dintre ceea ce este așteptat și rezultatele reale. Este de datoria Scrum Master-ului să lucreze cu Echipa Scrum și organizația pentru a crește transparența artefactelor. Această muncă implică de obicei învățarea, convingerea și schimbarea. Transparența nu are loc peste noapte, dar este o cale.

Definiția lui „Finalizat” (Definition of ”Done”)

Când un element al Product Backlog-ului este descris ca fiind „Finalizat” (Done), toată lumea trebuie să înțeleagă ce înseamnă „Finalizat”. Deși diferă semnificativ de la o Echipa Scrum la alta, membrii echipei trebuie să aibă o înțelegere comună legată de semnificația finalizării lucrului, pentru a asigura transparența. Aceasta este definiția lui „Finalizat” pentru o Echipa Scrum și este folosită pentru a evalua dacă lucrul este terminat pentru Incrementul produsului. Aceeași definiție ghidează Echipa de Dezvoltare în a ști câte elemente să selecteze din Product Backlog pe parcursul Planificării Sprintului. Scopul fiecărui sprint este să livreze Incrementul funcționalității potențial livrabile care aderă la Definiția curentă a lui „Finalizat” Echipele de Dezvoltare livrează Incrementul funcționalității produsului în fiecare Sprint. Acest Increment, este utilizabil, deci Product Owner-ul poate decide să îl livreze imediat. Dacă definiția lui „Finalizat” pentru un Increment este parte a convențiilor, standardelor sau indicațiilor de dezvoltare ale organizației, toate echipele Scrum trebuie să le urmeze cu strictețe. Dacă „Finalizat” pentru un Increment nu este o convenție în cadrul organizației, Echipa de Dezvoltare din Echipa Scrum trebuie să-și creeze definiția lui „Finalizat” care să se plieze pe produsul în cauză. Dacă există mai multe Echipe Scrum care lucrează pe același sistem sau versiune de produs, Echipele de Dezvoltare din toate Echipele Scrum trebuie să agreeze mutual definiția lui „Finalizat”.  Fiecare Increment se adaugă la toate Incrementele anterioare și este testat amănunțit, verificând că toate Incrementele din care este compus funcționează împreună. Pe măsura ce Echipele Scrum se maturizează, este de așteptat ca definiția lui „Finalizat” să se extindă cu scopul includerii altor criterii stringente pentru o calitate superioară. Oricare produs sau sistem individual trebuie să aibă o definiție a lui „Finalizat” care să fie standardul pentru orice lucru realizat pe el.

Notă de încheiere

Scrum este gratuit și oferit în acest ghid. Rolurile, artefactele, evenimentele, și regulile Scrum sunt imuabile și deși implementarea doar a unor părți din Scrum este posibilă, rezultatul nu este Scrum. Scrum există numai în întregul său și funcționează bine ca un container pentru alte tehnici, metodologii și practici.

Mulțumiri

Oamenii

Acest articol a fost citit de 15355 ori