Scrum

Versiunea actuală a paginii nu a fost încă examinată de colaboratori experimentați și poate diferi semnificativ de versiunea revizuită la 2 septembrie 2022; verificările necesită 27 de modificări .

Scrum
Site-ul oficial	scrum.org
Fișiere media la Wikimedia Commons

Scrum ( /skrʌm/ [1] ; scrum „  scrum”) este un cadru ușor care ajută oamenii, echipele și organizațiile să creeze valoare prin soluții adaptative la probleme complexe [2] .

Scrum poate fi folosit nu numai în domeniul dezvoltării software, ci și în alte industrii de producție [3] .

Pe lângă gestionarea proiectelor de dezvoltare software, Scrum poate fi folosit și de echipele de asistență software ca o abordare a managementului și întreținerii dezvoltării software.

Ar trebui făcută o distincție între Scrum [4] și Agile [5] .

Istorie

Sursele primare ale metodologiei Scrum au fost: sistemul de producție Toyota și ciclul OODA (bucla OODA, sau bucla OODA, sau bucla Boyd) al conceptului de utilizare a aviației militare, care include patru componente: observați („observați”) , orientați („orientați”), decideți („hotărâți”), acționați („acționați”). [6]

Abordarea în sine a fost descrisă pentru prima dată de Hirotaka Takeuchi și Ikujiro Nonaka în The New Product Development Game (Harvard Business Review, ianuarie-februarie 1986). Ei au observat că proiectele conduse de echipe multidisciplinare mici tind să producă în mod sistematic rezultate mai bune și au explicat acest lucru ca fiind „abordarea rugby”.

În 1991, DeGrace și Stahl, în cartea lor Unholy Problems, Righteous Solutions, [7] s-au referit la această abordare ca scrum , un termen sportiv inventat într-un articol de Takeuchi și Nonaka. Ken Schwaber a folosit abordarea care a adus Scrum în compania sa începutul anilor 1990 . Metodologia Scrum a fost prezentată pentru prima dată publicului larg documentată, clar definită și descrisă în comun de Schwaber și Jeff Sutherland [6] la OOPSLA'95 [8] din Austin . K. Schwaber și D. Sutherland au lucrat împreună în următorii ani pentru a procesa și descrie toată experiența și cele mai bune practici pentru industrie într-un singur întreg, în metodologia cunoscută astăzi ca Scrum.

Schwaber și-a unit forțele cu Mike Beadle în 2001 pentru a descrie metoda în detaliu în Agile Software Development with Scrum [9] .

În 2002, Schwaber a fondat Scrum Alliance [10] împreună cu alții și a creat o serie de acreditări Scrum certificate. Schwaber a părăsit Alianța Scrum la sfârșitul anului 2009 și a fondat Scrum.org Arhivat pe 10 decembrie 2019 la Wayback Machine , care organizează seria de acreditare concomitentă Professional Scrum [11] .

Din 2009, un document public numit Ghidul Scrum [12] a definit oficial Scrum. A fost revizuit de peste 5 ori. În 2018, Schwaber și comunitatea Scrum.org, împreună cu liderii comunității Kanban, au publicat Ghidul Kanban pentru echipele Scrum [13] .

Definiții

Scrum

Scrum (ing. „scrum” - un termen din rugby, denotă starea de start a echipelor înainte de aruncarea mingii) - setul minim necesar de evenimente, artefacte, roluri pe care se construiește procesul de dezvoltare a Scrum, permițând perioade scurte fixe. de timp, numite sprinturi ( sprints ), pentru a oferi utilizatorului final un produs funcțional cu noi oportunități de afaceri pentru care este determinată cea mai mare prioritate. Metodologia se bazează pe ideile exprimate în articolul de Taekuchi și Nonaka „ The New New Product development Game ”, precum și pe munca în echipă, similar modului în care în rugby o echipă lucrează împreună pentru a atinge un obiectiv comun. Oportunitățile de implementare în următorul sprint sunt determinate de echipă la începutul sprintului la întâlnirea de planificare a sprintului . Pentru a estima cantitatea de muncă viitoare în sprint, sunt folosite cel mai des estimări relative și practica de planificare a pokerului (Planning Poker).

La sfârșitul sprintului, echipa Scrum se întâlnește la o întâlnire de revizuire a sprintului (Sprint Review - vechiul nume al Demonstrației) cu clientul și îi prezintă un increment de produs de afaceri (o versiune de produs cu un set complet de funcționalități care poate să fie deja dat clientului și utilizatorului pentru utilizare), ceea ce a reușit să facă într-un sprint. Scopul Sprint Review este de a obține feedback de la client pentru a înțelege ce trebuie subliniat în viitor și care ar trebui să fie următoarea creștere a produsului de afaceri.

O durată scurtă de sprint strict fixată (de la 1 la 4 săptămâni) reduce riscurile și face posibilă obținerea rapidă a feedback-ului de la client pentru a ajusta viziunea produsului.

Sprint

Sprint [14]  este o perioadă de timp suficientă pentru a finaliza un set planificat de operațiuni Scrum, al căror scop este de a crea o creștere a unui produs de afaceri. Fixat rigid în timp. Durata unui sprint este de la 1 la 4 săptămâni. Cu cât sprintul este mai scurt, cu atât procesul de dezvoltare este mai flexibil, lansările apar mai des, feedback-ul de la client sosește mai repede, se petrece mai puțin timp lucrând în direcția greșită, dar se petrece mult timp pe întâlniri de planificare a sprintului, retrospective . Pe de altă parte, cu sprinturi mai lungi, echipa Scrum reduce costurile întâlnirilor, demonstrațiilor de produse etc. Diferite echipe aleg durata sprintului în funcție de specificul muncii lor, echipele interfuncționale și cerințele, adesea prin încercare și eroare. Pentru a estima cantitatea de muncă într-un sprint, puteți utiliza o estimare preliminară, măsurată în puncte de poveste. O estimare preliminară a duratei sprintului este înregistrată în backlog -ul proiectului ( backlog de produse ; vezi mai jos).

Artefacte din Scrum

Diagrama Burndown

O diagramă care arată cantitatea de muncă efectuată și cantitatea de muncă rămasă în raport cu timpul de dezvoltare a unui proiect se numește diagramă de ardere.

Aceste diagrame trebuie actualizate zilnic pentru a arăta în timp real progresul și costurile în munca de pe sprint și proiect, disponibile pentru toți membrii echipei Scrum: Scrum Master și Product Owner.

Graficul burndown de sprint arată câte sarcini au fost finalizate și cât mai rămâne de făcut în sprintul curent.

Întârziere de proiect

Jurnalul de dorințe de proiect (project backlog) conține o listă de cerințe de funcționalitate, ordonate după importanță și, în consecință, ordinea implementării. Elementele din acest jurnal se numesc user stories ( user stories ) sau articole backlog ( backlog items ). Restul proiectului este deschis pentru editare de către toți participanții la procesul Scrum. Persoana responsabilă cu menținerea backlog-ului proiectului este proprietarul produsului Scrum.

Sprint restante

Sprint Wishlist (Sprint Backlog) - conține funcționalitatea selectată de proprietarul produsului din backlog-ul proiectului. Toate funcțiile sunt împărțite în sarcini, fiecare dintre acestea fiind evaluată de echipa Scrum. La Sprint Planning Meeting , metoda de planificare a pokerului este folosită de echipă pentru a estima cantitatea de muncă care trebuie făcută pentru a finaliza sprintul [15] .

Scrum board

Scrum Board este un instrument pentru a prezenta în mod deschis starea activității în desfășurare a echipei Scrum. Scrum board constă din trei coloane: „de făcut” ( to-do ), „în curs” ( în curs ), „terminat” ( terminat ).

Scrum Board conține întregul domeniu al Sprint Backlog-ului pe care echipa l-a selectat în Sprint Planning pentru implementare în sprintul curent. De obicei, cărțile de activitate de vizită sunt plasate pe tablă de sus în jos în ordinea descrescătoare a priorității (sus - cel mai important, de jos - cel mai puțin important). Este o bună practică de a descompune sarcinile de afaceri în activități specifice (tehnice, organizaționale și altele) pe care echipa trebuie să le îndeplinească pentru a implementa sarcina de afaceri.

Sarcinile de afaceri și cărțile de lucru specifice se deplasează de la o coloană la alta în conformitate cu modul în care echipa le ia pentru execuție (În curs) și le finalizează (Terminat). Pentru a oferi vizibilitate asupra progresului muncii echipei, „scăderea muncii” pe zi este afișată pe graficul Burndown.

Cel mai adesea, la începutul lucrului, echipele folosesc tablă cu flipchart desenate pe foi, în timp ce numele lucrării sunt scrise pe autocolante și lipite de tablă. Pe măsură ce întâlnirea progresează, echipa mută fizic note lipicioase de la coloană la coloană.

Sunt adesea folosite și plăci electronice, cu mecanisme similare implementate în ele. De exemplu, Atlassian Jira , Trello sau kaiten [16] .

Sprint Goal

Este o scurtă descriere a obiectivului de afaceri al sprintului. Ca artefact, obiectivul sprintului ajută echipa să ia decizii informate de afaceri. Acest artefact este necesar pentru ca echipa de proiect să ia o decizie independentă atunci când găsește modalități alternative de a rezolva o problemă de afaceri.

Creștere produs

Un increment de produs este o piesă gata de utilizare a unui produs care trebuie implementată până la sfârșitul unui sprint. Echipa Sprint Review (Demonstrație) demonstrează creșterea produsului Scrum Master-ului, Product Owner-ului, clienților și altor părți interesate [4] pentru a primi feedback de la aceștia și a decide direcția ulterioară a dezvoltării produsului [17] .

Povestea utilizatorului

Funcționalitatea de afaceri necesară care este adăugată în stocul de proiect este adesea denumită povestea utilizatorului. Adesea, structura povestirii este: „Ca utilizator <tip de utilizator>, vreau să fac <acțiune> pentru a obține <rezultat>”. Această structură este convenabilă, deoarece este clară atât pentru dezvoltatori, cât și pentru clienți.

Estimarea efortului necesar pentru a finaliza o poveste de utilizator (sarcini de sprint)

În cartea [6] , Sutherland a descris următoarea metodă eficientă, folosită de el și confirmată de experiență, de evaluare a intensității forței de muncă a îndeplinirii sarcinilor de sprint în unele unități de intensitate a muncii – ore-om și altele asemenea.

Evaluarea sarcinilor este realizată de dezvoltatorii de proiect împreună cu Scrum Master și Product Owner. Metoda corectă pentru estimarea sarcinilor este planificarea pokerului . Se arată că o astfel de evaluare a forței de muncă este mult mai precisă decât evaluările efectuate de alte persoane.

Fiecare dezvoltator trebuie să dea propria sa evaluare a complexității sarcinii, independent de ceilalți, folosind numere din seria Fibonacci (1, 2, 3, 5, 8, 13, 20, 40, 100). În locul numerelor 21, 34, 55 se folosesc numerele 20, 40, 100. Estimările pot fi înregistrate pe bucăți de hârtie sau pot fi folosite carduri speciale pentru aceasta (vezi planificarea pokerului ) și trebuie deschise în același timp . Această organizare a evaluării evită efectul de ancorare .

Dacă toate valorile alese de dezvoltatori se încadrează într-un interval de cel mult trei numere Fibonacci consecutive, atunci estimarea medie a tuturor dezvoltatorilor grupului este utilizată ca evaluare finală a sarcinii de către grup. Dacă scorurile alese se încadrează în afara acestui interval, atunci dezvoltatorii cu cele mai mari și cele mai mici valori trebuie să explice motivele alegerii lor, după care rundele de evaluare se repetă până când setul de estimări se încadrează în intervalul de trei numere Fibonacci consecutive. După cum arată practica, dacă varianta cu mediarea estimărilor situate în intervalul mai mare de trei numere Fibonacci consecutive este utilizată pentru a forma estimarea finală a complexității sarcinii, atunci rezultatul se dovedește a fi mult mai puțin precis.

Deși inițial sarcinile și, în consecință, poveștile și proiectul în ansamblu, sunt estimate într-o anumită unitate de forță de muncă, aceste estimări sunt ulterior utilizate ca input relativ de muncă ca puncte (puncte) pentru a determina viteza (productivitatea) echipa Scrum (Velocity). ).

Evident, metodologia de mai sus pentru evaluarea intensității muncii a sarcinilor individuale și a proiectului în ansamblu poate fi utilizată nu numai în Scrum, ci și în alte metode de implementare a proiectului.

Definiția gata (DoD)

Criterii care determină gradul de pregătire a unui articol din restanța utilizatorului.

Viteza echipei Scrum (Velocity)

Numărul total de puncte marcate de echipa Scrum în sprintul anterior. Această măsurătoare ajută echipa să înțeleagă câte povești poate finaliza într-un singur sprint.

Roluri în procesul Scrum

Conform metodologiei Scrum în procesul de producție, se pot defini roluri, împărțite în două grupe: „porci” și „găini”. Din 2011, metaforele „porcilor” și „găinilor” au lipsit din manualul Scrum, întrucât nu există ritualuri speciale pentru găini [18] . Ghidul Scrum este totul despre porci. Acești termeni au fost împrumuți dintr-o anecdotă: [6]

Porcul merge pe drum. Puiul se uită la ea și spune: „Hai să deschidem un restaurant!” Porcul se uită la pui și îi răspunde: „Bună idee, cum vrei să-i spui?” Puiul se gândește și spune: „De ce să nu-i zici Slănină și Ouă?” „Nu va fi,” răspunde porcul, „pentru că atunci va trebui să mă dedic complet proiectului, iar tu vei fi doar parțial implicat.”

Porcii creează produsul, în timp ce puii sunt interesați, dar nu la fel de interesați - pentru că nu le pasă dacă proiectul are succes sau nu, nu îi va afecta prea mult. Sunt luate în considerare cerințele, dorințele, ideile și influența găinilor , dar nu li se permite să fie implicați direct în derularea proiectului Scrum.

Roluri de bază în metodologia Scrum („Porci”)

Porcii sunt incluși pe deplin în proiect și în procesul Scrum. Scrum Master - conduce întâlniri (întâlniri Scrum), monitorizează respectarea tuturor principiilor Scrum, rezolvă conflictele și protejează echipa de distrageri, facilitează întâlnirile, este responsabil pentru înregistrarea, stocarea și emiterea inventarului Scrum. Acest rol nu implică altceva decât desfășurarea corectă a procesului Scrum. Astfel, Scrum Master este liderul servitorului .

Instrumentul principal al Scrum Master este valiza facilitatorului , care include cutii de cărți, cărți pătrate și rotunde, cărți lipicioase, ace, markere, un cuțit de papetărie, bandă adezivă , cărți de Planning Poker, magneți, foarfece, puncte de vot.

Scrum Product Owner - Reprezintă interesele utilizatorilor finali și ale altor părți interesate în produs .

Echipa de dezvoltare (Scrum Development Team) este o echipă interfuncțională de dezvoltatori de proiecte, formată din specialiști de diferite profiluri: testeri , arhitecți , analiști , programatori etc. Mărimea echipei este de la 5 la 9 persoane. Echipa este singurul participant pe deplin implicat în dezvoltare și este responsabilă de rezultat în ansamblu. Nimeni, în afară de echipa de dezvoltare, Scrum Master și proprietarul produsului, nu poate interfera cu procesul de dezvoltare în timpul sprintului. Funcționalitatea încrucișată a echipei vă permite să planificați costurile implementării cerințelor de afaceri cât mai eficient posibil și să furnizați aplicații de afaceri reale, în deplină conformitate cu cerințele în schimbare ale clienților, într-un timp scurt.

Echipa Scrum este, de fapt, o imagine colectivă a unei echipe formată dintr-o echipă de dezvoltare, un Scrum Master și un proprietar de produs. Echipa este complet autosuficientă și nu depinde de specialiști sau clienți externi.

Roluri suplimentare (roluri auxiliare) în metodologia Scrum („Pui”)

• Utilizatori (Utilizatori)
• Părțile interesate sunt persoanele care inițiază proiectul (clienții business) și pentru care proiectul Scrum va beneficia. Ei sunt implicați în luptă doar în timpul întâlnirii Sprint Review.

Povești utilizator

Câmpuri obligatorii

• ID  - un identificator unic, un număr de serie folosit pentru a identifica poveștile în cazul în care acestea sunt redenumite.
• Nume (Nume)  - o scurtă descriere a poveștii. Ar trebui să fie clar, astfel încât atât dezvoltatorii, Scrum Master cât și Product Ownerul să poată înțelege despre ce este vorba și să distingă o poveste de utilizator de alta.
• Importanță  – gradul de importanță al acestei povești, în opinia proprietarului produsului, obținut în urma negocierilor cu clientul. De obicei este un număr întreg, uneori numerele Fibonacci sunt folosite în acest scop . Cu cât valoarea este mai mare, cu atât prioritatea este mai mare.

• Procesul de afaceri  - o scurtă descriere a procesului de afaceri.
• Estimare inițială  - o estimare a cantității de muncă depusă înainte de începerea sprintului necesară pentru implementarea poveștii. Măsurat în puncte de poveste. Aproximativ corespunde numărului de „ ore de om ideal ”.
• Cum se face demo  - o scurtă descriere a modului în care se poate demonstra sarcina finalizată clientului, Scrum Master și Product Owner la sfârșitul sprintului. Acest câmp poate conține numele (identificatorul) sau codul testului automatizat pentru testul de acceptare.
• Criteriile de acceptare  sunt detalii semnificative ale implementării poveștii, clarificând cerințele proprietarului produsului, colectate de toți membrii echipei Scrum la planificarea sprintului [19] .

Câmpuri suplimentare

Uneori, sunt folosite și câmpuri suplimentare din backlog-ul proiectului, în principal pentru a ajuta proprietarul produsului să prioritizeze produsul.

• Categorie ( pistă ). De exemplu, „panou de control” sau „optimizare”. Cu acest câmp, proprietarul produsului poate selecta cu ușurință toate articolele din categoria „optimizare” și le poate seta la prioritate scăzută.
• Componente ( componente ) - indică ce componente (de exemplu, bază de date, server, client) vor fi afectate atunci când povestea utilizatorului este implementată.
• Inițiatorul cererii ( solicitant ). Un proprietar de produs poate dori să stocheze informații despre toți clienții care sunt interesați de o anumită problemă de afaceri. Acest lucru este pentru a-i ține la curent cu progresul lucrării în timpul sprintului.
• ID în sistemul de urmărire a defectelor ( ID de urmărire a erorilor ) - dacă în timpul dezvoltării este utilizat un sistem separat de urmărire a erorilor , în acest caz este util să stocați link-uri către toate erorile care se referă la acesta în descrierea istoricului.

Întâlniri majore Scrum

Următoarele întâlniri sunt folosite în Scrum pentru a obține regularitate, control al dezvoltării și, în același timp, pentru a minimiza numărul de întâlniri care nu sunt predefinite în Scrum [20] .

Întâlnire de planificare Sprint

Se desfășoară la începutul fiecărui sprint.

Întreaga cantitate de muncă care trebuie finalizată în timpul sprintului este planificată la această întâlnire. Planul ar trebui să fie rezultatul muncii tuturor membrilor echipei Scrum.

Durata întâlnirii este determinată de durata sprintului, de experiența echipei și de alți factori, dar nu trebuie să depășească 8 ore. Aceste cronologie sunt monitorizate de ScrumMaster.

Sprint Planning Meeting răspunde la întrebări precum:

• Care este scopul acestui sprint sau ce se poate face în acest sprint?
• Cum exact va fi atins obiectivul de sprint pentru a obține creșterea produsului?

Prima întrebare se decide în comun. Proprietarul de produs discută obiectivele care trebuie îndeplinite pentru sprint, luând în considerare stocul de produse, creșterea anterioară a produsului etc., adaugă noi Povești de utilizator în stocul de produse și le elimină pe cele finalizate. Echipa de dezvoltare încearcă să prezică funcționalitatea care va fi dezvoltată în timpul sprintului. De asemenea, toți membrii echipei Scrum ar trebui să înțeleagă și să evalueze împreună toată munca din sprintul viitor.

Pentru a planifica corect un sprint, luați în considerare următoarele:

• Întârziere de proiect;
• Creșterea proiectului anterior;
• Potențialul proiectat al echipei de dezvoltare în timpul sprintului;
• Rezultatele anterioare ale echipei de dezvoltare.

Doar echipa de dezvoltare lucrează cu a doua întrebare. Deoarece obiectivul de sprint a fost deja definit, echipa de dezvoltare trebuie să înțeleagă exact cum poate fi atins. Ei decid cum vor implementa funcționalitatea planificată pentru a obține o creștere a produsului finit nou pe sprint.

Echipa de dezvoltare începe în mod obișnuit cu proiectarea sistemului și munca necesară pentru a converti stocul de sprint într-o creștere a produsului. Munca planificată pentru primele zile ale sprintului este mai detaliată, adesea împărțită în bucăți de o zi sau mai puțin spre sfârșitul acelei întâlniri. Echipa de dezvoltare organizează în mod independent munca în backlog-ul de sprint, atât în ​​timpul planificării sprintului, cât și după cum este necesar în timpul sprintului.

Ținând cont de opinia echipei de dezvoltare, Product Owner-ul poate clarifica sarcinile-obiectivele selectate din backlog sau poate forma o soluție de compromis cu acestea. Dacă dezvoltatorii decid că există prea multă sau prea puțină muncă, atunci ei și proprietarul produsului pot reconsidera sarcinile-obiectivele selectate. De asemenea, echipa de dezvoltare poate invita alți experți să ofere consiliere tehnică sau în materie.

La sfârșitul întâlnirii, echipa de dezvoltare explică proprietarului de produs și Scrum Master cum vor lucra independent pentru a atinge obiectivele de sprint.

Întâlnire zilnică Scrum

Astfel de întâlniri sunt ținute de echipa de dezvoltare, cu posibila participare a proprietarului produsului și a Scrummaster-ului, în fiecare zi în același loc și la aceeași oră, cu o durată de cel mult 15 minute. La aceste întâlniri, echipa de dezvoltare planifică munca pentru ziua lucrătoare de astăzi. Aceste întâlniri eficientizează munca în echipă și măresc productivitatea prin revizuirea muncii care a fost făcută de la precedentul Daily Scrum și prin planificarea lucrărilor care urmează.

Aceste întâlniri zilnice ajută să vedem cum progresează munca spre atingerea obiectivului de sprint. Acestea cresc probabilitatea ca echipa de dezvoltare să atingă obiectivele stabilite. În timpul întâlnirilor, echipa de dezvoltare ar trebui să înțeleagă cum ar trebui să se organizeze împreună pentru a atinge obiectivele sprintului și a implementa incrementul planificat.

Structura unor astfel de întâlniri este determinată de echipa de dezvoltare, dacă este necesar și atunci când este cazul, structura întâlnirilor poate fi schimbată, în timp ce accentul principal ar trebui să fie pe atingerea obiectivului de sprint, cu toate acestea, există reguli obligatorii:

• Daily Scrum nu trebuie să depășească 15 minute;

• Daily Scrum se desfășoară în fiecare zi lucrătoare, permisul Daily Scrum nu este permis;

• Exemple de întrebări care pot fi luate în considerare la Daily Scrum:

• • Ce am făcut ieri care a ajutat echipa de dezvoltare să atingă obiectivul de sprint?

• • Ce voi face astăzi pentru a ajuta echipa de dezvoltare să atingă obiectivul de sprint?

• • Văd obstacole care mă împiedică pe mine sau pe echipa de dezvoltare să atingem obiectivul de sprint?

Echipa de dezvoltare sau membrii echipei se întâlnesc adesea imediat după Daily Scrum pentru discuții mai aprofundate sau pentru a adapta sau re-planifica restul muncii.

Scrum Master garantează aceste întâlniri, dar echipa de dezvoltare este responsabilă de rularea Daily Scrum. De asemenea, Scrum Master antrenează echipa de dezvoltare pentru a păstra Daily Scrum în 15 minute și trebuie să se asigure că întâlnirea nu este întreruptă.

Scopul acestor întâlniri este de a îmbunătăți comunicarea echipei, de a reduce numărul de întâlniri suplimentare, de a identifica riscurile și dificultățile viitoare și de a facilita luarea rapidă a deciziilor.

Acesta este principalul mijloc de verificare a activității echipei de dezvoltare.

Sprint review

Efectuat la sfârșitul sprintului pentru a verifica creșterea produsului și pentru a ajusta stocul în așteptare, dacă este necesar. În timpul revizuirii rezultatelor sprintului, echipa Scrum și toate părțile interesate participă. Această întâlnire informală și prezentarea creșterii sunt menite să primească feedback și să dezvolte cooperarea.

Rezumatul Sprintului include următoarele elemente:

• Proprietarul produsului arată ce articole în restanță au fost finalizate și care nu.
• Echipa de dezvoltare discută ce a mers bine, ce a fost dificil și cum au fost rezolvate.
• Echipa de dezvoltare prezintă munca pe care a realizat-o în sprint și ce increment de produs au primit.
• Proprietarul produsului discută starea actuală a restanțelor. De asemenea, prezice obiectivele și termenele limită probabile pe baza rezultatului obținut.
• Există o discuție despre ceea ce este mai valoros de făcut în continuare pe baza unei analize a pieței și/sau a potențialului public.
• Revizuirea calendarului, a bugetului, a oportunităților și a pieței pentru a completa restul.

Rezultatul este un backlog actualizat care definește obiectivele pentru următoarele sprinturi. Restul poate fi ajustat în ansamblu pentru a întâlni noi oportunități.

Întâlnire retrospectivă (Sprint Retrospective)

Scopul întâlnirii retrospective este de a elabora propuneri de îmbunătățire a procesului (proceduri, tehnici, operațiuni) de implementare a proiectului. În cursul unei analize retrospective a sprintului trecut, se formează un plan de îmbunătățire a procesului de implementare a proiectului pentru următorul sprint. Întâlnirea are loc după revizuirea rezultatelor sprintului înainte de a planifica următorul sprint și nu trebuie să dureze mai mult de 3 ore. Supraveghează progresul întâlnirii Scrum Master.

Principalele obiective ale întâlnirii sunt:

• O analiză a ultimului sprint finalizat în ceea ce privește oamenii, procesele și instrumentele implicate.
• Identificarea principalelor decizii eficiente de îmbunătățire a procesului de implementare a proiectului luate pentru ultimul sprint și căutarea modalităților de îmbunătățire în continuare a acestora.
• Formarea unui plan de implementare, îmbunătățirea procesului de implementare a proiectului de către echipa Scrum.

Scrum Master încurajează echipa să ofere sugestii pentru a îmbunătăți eficiența procesului de dezvoltare. În timpul fiecărei retrospective de sprint, echipa ar trebui să caute și să sugereze modalități și mijloace de îmbunătățire a proceselor de lucru.

Până la sfârșitul analizei sprintului, echipa ar trebui să identifice propuneri de îmbunătățire pentru implementare în următorul sprint. În timp ce astfel de propuneri pot fi implementate în orice moment, retrospectiva sprintului oferă o oportunitate de a se concentra pe analiza interacțiunilor echipei și adaptarea acesteia la condițiile actuale.

Anularea unui sprint

Un sprint poate fi anulat dacă obiectivul de sprint este depășit. Numai Proprietarul Produsului are dreptul de a anula un sprint [21] .

Întâlniri Scrum suplimentare

Este posibil ca aceste întâlniri să nu facă parte din fluxul general de lucru Scrum, dar cu siguranță au loc în unele situații. Sunt folosite atunci când există mai mult de 7-11 dezvoltatori, adică mai mult decât dimensiunea recomandată a echipei Scrum.

Scrum of Scrums

Dacă echipa este mai mare de 11 persoane, atunci echipa este mai mare decât dimensiunea Scrum recomandată. Scrum of Scrums [22] a fost propus pentru a extinde Scrum .

Apoi echipa este împărțită în mai multe echipe Scrum. Fiecare are propriul său Scrum Master și Product Owner.

Echipele conduc Daily Scrum.

După întâlnirea zilnică Scrum, are loc un miting Scrum of Scrums (SoS [23] ). Aceasta înseamnă următoarele. Din fiecare echipă este selectat un reprezentant. Reprezentanții sunt împărțiți în 5-9 persoane. Fiecărei echipe i se atribuie un Chief Scrum Master [24] și un Chief Scrum Product Owner [25] dintre Scrum Masters și Product Owners implicați în proiect. O echipă de reprezentanți din diferite echipe Scrum se numește Scrum of Scrums Team [26] . În această compoziție, are loc un miting de 15 minute de Scrum of Scrums (SoS) sau Meta Scrum sau Scaled Daily Scrum (SDS) [27] .

Ken Schwaber recomandă să faceți Scrum of Scrums în fiecare zi [28] .

Totuși, unele echipe Scrum of Scrums nu fac în fiecare zi, ci de 2-3 ori pe săptămână [28] . Acest lucru încalcă principiile de bază ale Scrum și este un exemplu clasic de ScrumBut [29] [30] . Acest lucru nu vă permite să profitați din plin de Scrum [31] .

Scrum of Scrums permite mai multor echipe Scrum să discute despre lucru, concentrându-se pe zone comune și pe integrarea reciprocă. Chief Scrum Master le adresează tuturor membrilor echipei Scrum of Scrum patru întrebări [28] , primele trei întrebări repetă întrebările Daily Scrum:

• Ce a făcut fiecare echipă de la întâlnirea anterioară a Scrum of Scrums pentru a atinge Scopul Sprintului?
• Ce va face fiecare echipă până la următoarea întâlnire zilnică Scrum of Scrums pentru a atinge obiectivul de sprint?
• Există probleme care împiedică echipa să atingă obiectivul de sprint?
• Cealaltă echipă trebuie să facă ceva din sarcinile echipei tale pentru a-i ajuta să atingă obiectivul de sprint?

Cu metodologia Scrum of Scrums, puteți continua să creșteți numărul de dezvoltatori. Dacă Scrum of Scrums nu acoperă întreaga echipă, o întâlnire Scrum of Scrum of Scrums (Scrum-3, SoSoS) [32] , Scrum of Scrum of Scrum of Scrums (Scrum-4, SoSoS [33] ) [34] poate să fie ținută și așa mai departe [35] . Cel mai recent MetaScrum se numește Executive Meta Scrum (EMS) [36] sau Executive Action Team (EAT) [37] . Această abordare permite organizarea muncii a 4096 de persoane în doar o oră [34] .

Ordinea Scrum of Scrums este aceeași cu Daily Scrum [26] :

• în același timp, în același loc,
• toată lumea poate privi, dar doar „porcii” vorbesc,
• Chief Scrum Master, Chief Scrum Product Owner și Scrum of Scrums Team participă la miting,
• dureaza exact 15 minute
• toți participanții la Scrum of Scrums stau (Rally Standup zilnic).

Backlog comenzi (Grooming)

Backlog-ul este organizat astfel încât echipa de dezvoltare și proprietarul produsului să poată [38] :

• Adăugați, eliminați, îmbinați sau împărțiți elementele de backlog de produse (PBI), descompuneți elementele de backlog în elemente de activitate la nivel de programare.
• Clarificați sau oferiți noi estimări ale complexității sarcinilor etc.
• Schimbați ordinea articolelor din backlog de produse.
• Discutați și clarificați cerințele de afaceri.

Alte tehnici de scalare Scrum

Pe lângă metodologia clasică Scrum of Scrums (SoS), LeSS [39] [40] [41] [42] (de la 2 la 8 echipe), Nexus [43] , RAGE [44] , DAD [45] , APM [46 ] ] [47] , SAFe [48] . Pentru proiecte foarte mari, se folosește LeSS Huge [40] (8+ comenzi) în loc de LeSS . Doar metodele SoS [49] și Nexus [50] au fost dezvoltate de Sutherland și Schwaber [40] și sunt predate în cursurile de certificare CSM și PSM.

Scrum Training and Certification

În Scrum, un Scrum Master calificat, Scrum Product Owner și Scrum Team joacă un rol crucial. Fondatorii Scrum și Certified Trainers (CST®) oferă cursuri de formare pentru a certifica profesioniștii Scrum. O bază obligatorie pentru toți sunt abilitățile Scrum Master. Urmează specializarea în Scrum Master, Scrum Product Owner și Scrum Developer (membru al echipei Scrum). Cei care promovează cu succes examenul li se eliberează certificate: Certified ScrumMaster (CSM®), Certified Scrum Product Owner (CSPO®), Certified Scrum Developer (CSD®), Professional Scrum Master (PSM™), Professional Scrum Product Owner (PSPO™) , Professional Scrum Developer (PSD™). Cei care doresc să-și îmbunătățească în continuare cunoștințele și abilitățile Scrum pot, după cursurile de bază CSM, CSPO de la Scrum ALLIANCE și promovarea examenului asupra acestora, care au o experiență de minim 1 an în rolul lor Scrum, să urmeze Advanced Certified Scrum Master (A -CSM), Advanced Certified Scrum Product Owner, Advanced Certified Scrum Developer [51] . Pentru dezvoltatori, există un set separat de cursuri legate de TDD , DevOps , etc. [52] . Cei care au absolvit cursuri CSM, CSPO, CSD, A-CSM, A-CSPO, A-CSD și și-au promovat examenele și au cel puțin 3 ani de experiență în rolul relevant Scrum li se permite să urmeze CSP®-SM, CSP® -cursuri PO, CSP-D® [53] . Ca parte a certificării scrum.org, cursurile au și mai multe niveluri: PSM-I, PSM-II, PSM-III, PSPO-I, PSPO-II, PSPO-III [54] .

Formarea ulterioară este posibilă cu eliberarea unui certificat de trainer Scrum - Certified Scrum Trainer (CST®) sau Professional Scrum Trainer (PST™).

Certificarea CST este deschisă persoanelor cu o certificare CSP-SM sau CSP-PO sau CSP-D și cel puțin 5 ani de experiență într-un rol relevant Scrum [55] .

Certificarea PST îi recunoaște pe Scrum Master Trainers (PSSMT), Product Owner Trainers (PSPOT) și Development Team Trainers (PSDT) [56] [57] [58] . Admiterea și certificarea Train-the-Trainer (TTT) necesită:

• pe certificat PSSMT - PSM III;
• pe certificatele PSPOT - PSM I și PSPO I;
• pe certificatele PSDT - PSM I si PSD I.

Certificarea Scrum este valabilă doi ani. Pe parcursul acestor doi ani, pentru a reînnoi certificatul pentru următorii doi ani, trebuie recrutat un anumit număr de Scrum Education Units (SEU®) [59] . Unitățile de educație Scrum sunt premiate pentru finalizarea cursurilor Scrum, participarea la Global Scrum Gathering℠ [60] și Regional Scrum Gathering℠ [61] , predarea Scrum și alte activități care vizează îmbunătățirea abilităților dvs. Scrum [59] . Un astfel de sistem arată că cunoștințele tale Scrum sunt la zi și că ești mereu gata să le aplici și să le transmită altora. Acest lucru crește foarte mult valoarea unui certificat Scrum. Unitățile de educație Scrum sunt acordate după cum urmează: 1 oră de formare Scrum (participare la adunare, predare, participare la un webinar etc.) este egală cu 1 SEU®. Reînnoirea unui certificat necesită:

• CSM®, CSPO®, CSD® - 20 SEU®;
• A-CSM®, A-CSPO®, A-CSD® - 30 SEU®;
• CSP®-SM, CSP®-PO, CSP-D®, CAL II-40 SEU®.

Dacă există mai multe certificate, numărul de SEU® necesar pentru reînnoire se calculează folosind un calculator special: [62] .

Nu tocmai Scrum

Scrumbut

ScrumBut este utilizarea doar a unei părți din principiile Scrum, menținând în același timp convingerea de a lucra pe Scrum [29] [30] . Acest lucru nu numai că vă împiedică să profitați din plin de Scrum [29] , dar și degradează performanța în comparație cu absența completă a unei metodologii.

Studiile au arătat că ScrumBut reduce profiturile anuale de la 400% la 0-35% [31] . În același timp, productivitatea muncii conform „cascadei” a fost luată ca 100%, iar conform Scrum ca 400%. Un studiu amplu al cauzelor și consecințelor ScrumBut este realizat în lucrarea „ScrumBut in Professional Software Development” [63] .

Exemple clasice de ScrumBut [29] :

• Conducerea Daily Scrum sau Scrum of Scrums nu este în fiecare zi;
• Lipsa retrospectivelor;
• Sprinturi mai lungi de 4 săptămâni;
• Lipsa definiției de făcut.

Un număr mare de exemple ScrumBut sunt furnizate pe site-ul Scrum Alliance, Scrum ALLIANCE® [64] .

Scrum Și

Pe lângă Scrum, dar luați în considerare ScrumAnd [65] . Se consideră că ScrumAnd utilizează Scrum și alte bune practici. Cu toate acestea, poate fi dificil să distingem ScrumBut de ScrumAnd [66] . De exemplu, ei pun întrebarea: avem un sprint de 6 luni, este ScrumBut sau ScrumAnd? Autorii lui [66] atribuie fără echivoc acest lucru lui ScrumBut și oferă o metodă pentru a distinge între ScrumBut și ScrumAnd. De reținut că metodologia Scrum este autosuficientă, iar atât ScrumBut, cât și ScrumAnd duc la o scădere a eficienței procesului de dezvoltare a aplicațiilor de afaceri. [67] .

Note

1. ↑ „scrum” traducere engleză-rusă . lingvo.abbyyonline.com. Preluat: 4 mai 2016. (nedefinit)
2. ↑ Schwaber Ken, Sutherland Jeff. Ghid Scrum (noiembrie 2020). (Rusă)
3. ↑ Copie arhivată . Consultat la 19 octombrie 2018. Arhivat din original la 20 octombrie 2018. (nedefinit)
4. ↑ 1 2 5 instrumente cheie ale metodei SCRUM (27 aprilie 2017). Preluat la 21 octombrie 2018. Arhivat din original la 2 octombrie 2019. (nedefinit)
5. ↑ Agile - o abordare agilă a managementului de proiect (4 noiembrie 2016). Preluat la 21 octombrie 2018. Arhivat din original la 3 octombrie 2019. (nedefinit)
6. ↑ 1 2 3 4 Jeff Sutherland. SCRUM. Metoda revoluționară de management de proiect = SCRUM. Arta de a face de două ori munca în jumătate de timp. - Mann, Ivanov și Ferber, 2016. - 288 p. - ISBN 978-5-00057-722-6 .
7. ↑ Leslie Hulet Stahl: Wicked Problems, Righteous Solutions: A Catalog of Modern Engineering Paradigms Yourdon Press Computing Series, 1990 (prima ediție), ISBN 0-13-590126-X
8. ↑ OOPSLA 2006 . Data accesului: 26 ianuarie 2010. Arhivat din original la 25 iunie 2010. (nedefinit)
9. ↑ Schwaber, Ken; Beedle, Mike. Dezvoltare agilă de software cu Scrum  (neopr.) . - Prentice Hall , 2002. - ISBN 0-13-067634-9 .
10. ↑ Maximini, Dominic. Cultura Scrum: introducerea metodelor agile în organizații. Management pentru profesioniști  // Cham: Springer. - 8 ianuarie 2015. Recuperat la 25 august 2016 .. - P. 26 . — ISSN 9783319118277 .
11. ↑ Partogi, Iosua. Scrum Master certificat vs Professional Scrum Master // Institutul Lean Agile. — 7 iulie 2013. Consultat la 10 mai 2017.
12. ↑ Ken Schwaber; Jeff Sutherland. Ghidul Scrum. — Scrum.org, preluat la 27 octombrie 2017..
13. ↑ Scrum.org Introduces Scrum with Kanban Course, Enabling Greater Transparency Among Development Teams (Preluat la 2 martie 2018). Preluat la 22 mai 2019. Arhivat din original la 18 noiembrie 2018. (nedefinit)
14. ↑ Sprint - smucitură; arunca; cursa scurta.
15. ↑ Ken Schwaber. Management agil de proiect cu Scrum . - Microsoft Press, 2004. - 163 p. — ISBN 073561993X .
16. ↑ Proiect vizual și managementul echipei @ Kaiten . Preluat la 15 martie 2021. Arhivat din original la 22 ianuarie 2021. (nedefinit)
17. ↑ Ce este Scrum-Agile pentru începători . Preluat la 20 octombrie 2018. Arhivat din original la 21 octombrie 2018. (nedefinit)
18. ↑ Găini și porci . Consultat la 23 iulie 2019. Arhivat din original la 23 ianuarie 2017. (nedefinit)
19. ↑ Criterii de acceptare pentru cerințe în Agile . Devprom ALM. Consultat la 3 aprilie 2016. Arhivat din original la 1 aprilie 2016. (nedefinit)
20. ↑ Scrum Guide | Ghiduri Scrum . scrumguides.org. Preluat la 3 iunie 2020. Arhivat din original la 16 iunie 2020. (nedefinit)
21. ↑ Copie arhivată . Preluat la 15 martie 2021. Arhivat din original la 14 ianuarie 2021. (nedefinit)
22. ↑ (PDF) Soluție Scrum of Scrums pentru echipe de dimensiuni mari folosind metodologia Scrum . Preluat la 21 octombrie 2018. Arhivat din original la 21 octombrie 2018. (nedefinit)
23. ↑ Definiția Scrum of Scrums (SoS) | inovatie . Preluat la 21 octombrie 2018. Arhivat din original la 21 octombrie 2018. (nedefinit)
24. ↑ Rolul unui șef Scrum Master | Blog SCRUMstudy . Preluat la 21 octombrie 2018. Arhivat din original la 25 octombrie 2018. (nedefinit)
25. ↑ Endava . Preluat la 21 octombrie 2018. Arhivat din original la 21 octombrie 2018. (nedefinit)
26. ↑ 1 2 Întâlnirea Scrum of Scrums - Manifest . Preluat la 21 octombrie 2018. Arhivat din original la 21 octombrie 2018. (nedefinit)
27. ↑ Jeff Sutherland lansează Ghidul Scrum@Scale | Blogul lui Henny Portman . Preluat la 21 octombrie 2018. Arhivat din original la 21 octombrie 2018. (nedefinit)
28. ↑ 1 2 3 Articole informative trimise de membri Scrum Alliance (link nu este disponibil) . Preluat la 21 octombrie 2018. Arhivat din original la 21 octombrie 2018. (nedefinit) 
29. ↑ 1 2 3 4 Ce este ScrumBut? | Scrum.org . Preluat la 21 octombrie 2018. Arhivat din original la 21 octombrie 2018. (nedefinit)
30. ↑ 1 2 ITKaiZenClub „Scrum, dar....” sau probleme tipice la implementarea Scrum, 8 februarie | DOU
31. ↑ 1 2 (PDF) Scrum+:: Este „ScrumBut” sau „ScrumAnd” . Preluat la 21 octombrie 2018. Arhivat din original la 21 octombrie 2018. (nedefinit)
32. ↑ Echipa Scrum și Scrum of Scrums . Preluat la 21 octombrie 2018. Arhivat din original la 21 octombrie 2018. (nedefinit)
33. ↑ Agile Organization with Scrum@Scale, Vimar Spa un exemplu real
34. ↑ 1 2 Agil în hardware militar. Cum SAAB Gripen a devenit cel mai rentabil avion militar din lume Arhivat 20 octombrie 2018 la Wayback Machine / Sutherland și Joe Justice , 2017 
35. ↑ Seria Scaling Agile Partea 2: O privire la două dintre cele patru cadre populare de scalare Agile: SoS și LeSS - Gorilla Logic . Preluat la 21 octombrie 2018. Arhivat din original la 21 octombrie 2018. (nedefinit)
36. ↑ MetaScrum executiv | AgileGenesis . Preluat la 15 martie 2021. Arhivat din original la 18 aprilie 2021. (nedefinit)
37. ↑ Executive Action Team - Scrum Inc. Preluat la 15 martie 2021. Arhivat din original la 28 februarie 2021. (nedefinit)
38. ↑ „Looking for a Backlog Comb Blog of Proactive Business (link indisponibil) . Data accesării: 8 decembrie 2018. Arhivat la 27 decembrie 2018. (nedefinit) 
39. ↑ Large-Scale Scrum (LeSS) - Alexey Krivitsky - Agile Coach and Scrum Trainer . Preluat la 2 noiembrie 2018. Arhivat din original la 4 noiembrie 2018. (nedefinit)
40. ↑ 1 2 3 Cum să scalați Agile? | sisteme deschise. SGBD | Editura „Sisteme deschise” . Preluat la 2 noiembrie 2018. Arhivat din original la 4 noiembrie 2018. (nedefinit)
41. ↑ Introducere în LeSS - Large Scale Scrum (LeSS) . Consultat la 4 noiembrie 2018. Arhivat din original pe 5 noiembrie 2018. (nedefinit)
42. ↑ Mai puțin - Scrum la scară - ScrumTrek Blog . Consultat la 4 noiembrie 2018. Arhivat din original pe 5 noiembrie 2018. (nedefinit)
43. ↑ Ghidul Nexus | Scrum.org . Consultat la 4 noiembrie 2018. Arhivat din original pe 5 noiembrie 2018. (nedefinit)
44. ↑ FURIE | Transformări agile la scară | proces | cPrime . Consultat la 4 noiembrie 2018. Arhivat din original pe 4 noiembrie 2018. (nedefinit)
45. ↑ Copie arhivată (link nu este disponibil) . Consultat la 4 noiembrie 2018. Arhivat din original pe 5 noiembrie 2018. (nedefinit) 
46. ↑ Management agil de proiect - ce și de ce | APM . Consultat la 4 noiembrie 2018. Arhivat din original pe 5 noiembrie 2018. (nedefinit)
47. ↑ Management agil de proiect cu Scrum . Consultat la 4 noiembrie 2018. Arhivat din original pe 5 noiembrie 2018. (nedefinit)
48. ↑ Copie arhivată (link nu este disponibil) . Consultat la 4 noiembrie 2018. Arhivat din original pe 5 noiembrie 2018. (nedefinit) 
49. ↑ Scrum of Scrums | Scrum.org . Preluat la 2 noiembrie 2018. Arhivat din original la 4 noiembrie 2018. (nedefinit)
50. ↑ Ghidul Nexus | Scrum.org . Preluat la 2 noiembrie 2018. Arhivat din original la 5 noiembrie 2018. (nedefinit)
51. ↑ Certificare Advanced Certified ScrumMaster (A-CSM℠) . Preluat la 15 martie 2021. Arhivat din original la 17 martie 2021. (nedefinit)
52. ↑ Căutare curs - Alianța Scrum
53. ↑ Curs de certificare Scrum Professional ScrumMaster® (CSP-SM) certificat . Preluat la 15 martie 2021. Arhivat din original la 17 martie 2021. (nedefinit)
54. ↑ Certificarea Scrum Master de la Acasă Scrum . Preluat la 15 martie 2021. Arhivat din original la 3 martie 2021. (nedefinit)
55. ↑ Procesul de aplicare a certificării Certified Scrum Trainer (CST) . Consultat la 19 octombrie 2018. Arhivat din original la 20 octombrie 2018. (nedefinit)
56. ↑ Procesul și aplicația de selecție a formatorilor PSD | Scrum.org . Consultat la 19 octombrie 2018. Arhivat din original la 20 octombrie 2018. (nedefinit)
57. ↑ Procesul și aplicația de selecție a formatorilor PSPO | Scrum.org . Consultat la 19 octombrie 2018. Arhivat din original la 20 octombrie 2018. (nedefinit)
58. ↑ Procesul și aplicația de selecție a formatorilor PSM | Scrum.org . Consultat la 19 octombrie 2018. Arhivat din original la 20 octombrie 2018. (nedefinit)
59. ↑ 1 2 Scrum Education Units® (SEU®) Credite pentru formare . Preluat la 15 martie 2021. Arhivat din original la 20 aprilie 2021. (nedefinit)
60. ↑ Global Scrum Gathering Event Information & Sponsorship . Preluat la 15 martie 2021. Arhivat din original la 4 martie 2021. (nedefinit)
61. ↑ Scrum Alliance Regional Scrum Gatherings . Preluat la 15 martie 2021. Arhivat din original la 28 ianuarie 2021. (nedefinit)
62. ↑ Agile și Scrum Training & Certification | Alianța Scrum . Preluat la 15 martie 2021. Arhivat din original la 21 aprilie 2021. (nedefinit)
63. ↑ Copie arhivată . Preluat la 21 octombrie 2018. Arhivat din original la 21 octombrie 2018. (nedefinit)
64. ↑ Articole informative trimise de membrii Scrum Alliance (link nu este disponibil) . Preluat la 21 octombrie 2018. Arhivat din original la 21 octombrie 2018. (nedefinit) 
65. ↑ Poziția „ScrumAnd” (necesită gândire și disciplină) | Scrum.org . Preluat la 15 martie 2021. Arhivat din original la 14 aprilie 2021. (nedefinit)
66. ↑ 1 2 (PDF) Scrum+:: Este „ScrumBut” sau „ScrumAnd” . Preluat la 21 octombrie 2018. Arhivat din original la 21 octombrie 2018. (nedefinit)
67. ↑ https://www.researchgate.net/publication/254048455_Scrum_Is_it_ScrumBut_or_ScrumAnd

Vezi și

• Implementare software

Link -uri

• Manualul oficial de reguli Scrum Arhivat pe 9 septembrie 2012 la Wayback Machine
• Prezentare generală a metodologiei Scrum Arhivat 14 martie 2016 la Wayback Machine

Literatură

• Henrik Kniberg. Scrum și XP: note din primele linii = Scrum și XP din tranșee. - C4Media, 2007. - P. 140. - ISBN 978-1-4303-2264-1 .
• Mike Cohn. Scrum: Agile Software Development = Succeed with Agile: Software Development Utilizând Scrum. - M. : „Williams” , 2011. - S. 576. - ISBN 978-5-8459-1731-7 .
• Jeff Sutherland. SCRUM. Metoda revoluționară de management de proiect = SCRUM. Arta de a face de două ori munca în jumătate de timp. - Mann, Ivanov și Ferber, 2016. - 288 p. - ISBN 978-5-00057-722-6 .
• Kenneth Rubin. Essential Scrum: Un ghid practic pentru cel mai popular proces agil. - M . : „Williams” , 20161. - S. 544. - ISBN 978-5-8459-2052-2 .

În cataloagele bibliografice	J9U : 987007534934605171 LCCN : sh2001003039

Dezvoltare de software
Proces	Etape de dezvoltare Analiza cerințelor Proiecta Programare Testare Documentație
Concepte de nivel înalt	Arhitectura software Paradigmă Metodologie Proces de dezvoltare Calitate
Directii	Programare ( Orientată pe aspect Orientat pe obiecte orientat spre probleme )
Metodologii de dezvoltare	Agil cameră curată CAZ SUS. RUP Deschide RAD Scrum Sigur Model Spotify MSF XP DSDM
Modele	Iterativ în cascadă Spirală Modelul V Model Dual Vee CMM CMMI Date model funcțional IDEF Informațional Metamodel model de obiect vezi modelul UML
Cifre notabile	Kent Beck Gradi Butch Fred Brooks Ward Cunningham Ole-Johan Dahl Tom Demarco Edsger Dijkstra Donald Knuth Alan Kay Martin Fowler Anthony Hoare Ivar Jacobson Bertrand Meyer Niklaus Wirth Edward Jordan Steve McConnell James Rambo Barry Boehm Humphrey Michael A. Jackson Craig Larman Robert Martin James David Parnas Winston Royce