Ghid Scrum | 16. Scaling Scrum

Publicat: 2022-05-16

Echipa Scrum ar trebui să fie formată din până la zece persoane. Dar ce să faci când un grup mai mare de specialiști trebuie să lucreze la un singur proiect? Sau dacă organizația decide să urmeze un mod agil de management? Pentru a rezolva această problemă, dezvoltatorii Scrum au propus [email protected] Este o arhitectură fără scalare pentru a organiza echipe întregi conform principiilor Scrum.

Scaling Scrum – cuprins:

  1. Introducere
  2. [email protected]
  3. Scrum of Scrums
  4. Probleme suplimentare de scalare și [protejat prin e-mail] .
  5. rezumat

Introducere

De îndată ce o organizație crește, apar noi tipuri de probleme. De exemplu, o scădere a eficienței angajaților cauzată de o structură internă complexă, de luare a deciziilor dificile sau de stabilirea direcției. Companiile care operează agil la nivel de echipă de proiect mici caută adesea să se extindă.

Multe întreprinderi se descurcă bine fără a scala Scrum. Chiar dacă mai multe echipe Scrum rulează simultan, nu au nevoie de coordonare, deoarece grupurile funcționează independent. Cu toate acestea, acest lucru nu înseamnă că este un Scrum cu mai multe echipe. Nevoia de scalare apare doar atunci când cea mai mare parte a organizației lucrează la un singur produs și își poate sincroniza mai multe echipe Scrum în mod eficient.

Majoritatea organizațiilor care adoptă metode agile de management la scară aleg modelul SAFE sau Scaled Agile Framework. Astăzi, totuși, nu ne vom concentra pe SAFE , ci vom discuta despre un alt model numit [email protected] , deoarece conform celui de-al 15-lea raport State of Agile din 2021, este a doua cea mai bună alegere dintre companiile care optează pentru agil.

[email protected]

În 1996, creatorii lui Scrum, Jeff Sutherland și Ken Schwaber, lucrau la un proiect amplu. În timp ce o făceau, au avut probleme în a menține echipele mai mici care lucrează în Scrum în sincronizare. Au venit cu o modalitate de a-l scala, pe care l-au numit în cele din urmă [email protected]

Analog cu Ghidul Scrum oficial a fost Ghidul [email protected] , care definește acest mod de scalare a muncii ca:

Un cadru în care funcționează rețelele de echipe Scrum urmând Ghidul Scrum pentru a rezolva probleme complexe de adaptare și a livra în mod creativ produse cu cât mai multă valoare posibil.

Premisa de bază a [email protected] este simplitatea și eficiența. Prin urmare, funcționarea sa se bazează pe o arhitectură fără scară. Cu alte cuvinte, folosește Scrum pentru a scala Scrum. În acest fel, o echipă Scrum formată din indivizi care acționează ca Product Owner, Scrum Master sau Dezvoltator devine Scrum of Scrums: o echipă formată din echipe.

Scrum of Scrums

Scrum of Scrums este o echipă Scrum cu oameni care ocupă roluri tradiționale Scrum. Cu toate acestea, deoarece sarcina Scrum of Scrums este de a integra rezultatele muncii mai multor echipe Scrum, are nevoie de postări suplimentare:

  • Echipa Product Owner – un grup de Product Owner care se întâlnesc pentru a conveni asupra priorităților și pentru a crea o viziune coerentă asupra produsului
  • Chief Product Owner – Product Owner al echipei Scrum sau o persoană care se ocupă exclusiv de Scrum of Scrums
  • Scrum of Scrums Master – persoana care supraveghează eficacitatea Scrum of Scrums.

Ei se întâlnesc la aceleași evenimente Scrum și folosesc artefacte similare.

Scaling Scrum

Probleme suplimentare de scalare și [protejat prin e-mail].

Arhitectura fără scalare a [email protected] înseamnă că permite scalarea de mai multe ori. Dacă o organizație trebuie să coordoneze echipe la o scară și mai mare, poate configura Scrum of Scrums.

Cu toate acestea, scalarea Scrum, ca orice altă metodologie de management are defectele sale, iar în acest caz, acestea sunt similare cu cele ale echipelor Scrum de bază, doar că sunt proporțional mai mari. De aceea, vă recomandăm să stabiliți detaliile colaborării în cadrul fiecărei echipe Scrum înainte de a începe Scrum la o scară mai mare. Vă sugerăm să extindeți Scrum pentru echipele cu experiență care au o bună cunoaștere și înțelegere a valorilor și funcționării Scrum.

scaling

Scaling Scrum – rezumat

Scaling Scrum nu este o joacă de copii. Este necesar ca echipele Scrum să aplice cu competență principiile Scrum și să își sincronizeze sarcinile cu alte echipe Scrum. Prin urmare, întrebarea de bază la care trebuie să răspundeți este: este necesară scalarea? Doar pentru că există multe echipe Scrum într-o organizație nu înseamnă automat că coordonarea acestora va aduce rezultate mai bune.

Dacă o organizație alege să mărească Scrum, aceasta dobândește o arhitectură fără scară care poate fi mărită cu succes în continuare. Cu toate acestea, fiecare creștere este însoțită de o creștere a nivelului de complexitate cu care trebuie să se confrunte Echipa Product Owner, Chief Product Owner și Scrum of Scrums Master.

Dacă vă place conținutul nostru, alăturați-vă comunității noastre de albine ocupate pe Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 16. Scaling Scrum caroline becker avatar 1background

Autor: Caroline Becker

În calitate de manager de proiect, Caroline este expertă în găsirea de noi metode de a proiecta cele mai bune fluxuri de lucru și de a optimiza procesele. Abilitățile ei de organizare și capacitatea de a lucra sub presiunea timpului o fac cea mai bună persoană pentru a transforma proiectele complicate în realitate.

Vizualizați toate postările

Ghid Scrum:

  1. Glosar de termeni de bază, roluri și noțiuni
  2. Ce este Scrum?
  3. Valorile Scrum
  4. Cum implementezi Scrum în compania ta?
  5. Echipa Scrum - ce este și cum funcționează?
  6. Cine este un proprietar de produs?
  7. Cele mai frecvente greșeli ale Product Ownerului
  8. Cine este Scrum Master?
  9. Caracteristicile unui bun Scrum Master
  10. Cele mai frecvente greșeli ale Scrum Master
  11. Ce statistici și valori ar trebui să urmărească Scrum Master?
  12. Cooperare între Product Owner și Scrum Master
  13. Echipa de dezvoltare în Scrum
  14. Cele mai frecvente greșeli ale dezvoltatorilor
  15. Artefacte Scrum
  16. Scaling Scrum
  17. Sprint Backlog
  18. Ce este Product Backlog?
  19. Ce sunt User Stories?
  20. Crearea celei mai bune povești de utilizator cu INVEST
  21. Cele mai frecvente greșeli ale User Story
  22. Criterii de acceptare a poveștii utilizatorului
  23. Estimare și Story Points în Scrum
  24. Planificarea Pokerului
  25. Joc de estimare a echipei
  26. Definirea creșterii
  27. Evenimente Scrum
  28. Ce este Sprint în Scrum?
  29. Angajamentele echipei Scrum - Obiectiv de produs, obiectiv de sprint și definiția finalizării
  30. Ce este un grafic Burndown?
  31. Cum se creează și se interpretează un grafic de ardere?
  32. Avantajele și dezavantajele diagramei de ardere
  33. Panouri Kanban în Scrum și Scrumban
  34. Viteza în Scrum - Viteza echipei de dezvoltare
  35. Scrum zilnic
  36. Planificarea sprintului
  37. Sprint Review
  38. Ce este o retrospectivă Sprint?
  39. Greșeli frecvente în timpul unei retrospective de sprint
  40. Creșterea backlog-ului de produse