Proiectul de management al proiectului Partea 2: O comparație cuprinzătoare între Waterfall, DAD, SAFe, LeSS și Scrum@Scale

Prezentare generală

În partea 1 a Planului de management al proiectelor, am acoperit metodologiile de dezvoltare software Lean, Agile, Scrum și Kanban și modul în care toate își au rădăcinile până la Lean Manufacturing. Aceste metodologii sunt de obicei implementate la un singur nivel de echipă. Cu toate acestea, complexitatea crește pe măsură ce proiectele și echipele de proiect devin mai mari și sunt necesare noi abordări pentru a fi agile la scară.

În partea a 2-a, vom aborda mai întâi modul în care managerii de proiect utilizează metodologia cascadă, care este cel mai comun cadru pentru dezvoltarea de software la companiile tradiționale. Juxtapus cu asta, vom acoperi cele mai populare cadre care încearcă să încorporeze principii agile la scară – Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) și Scrum@Scale.

Cascadă

Metodologia cascadă (cunoscută și sub numele de modelul ciclului de viață al dezvoltării software (SDLC)) este o metodologie mai tradițională în care dezvoltarea software-ului se desfășoară de la o fază la alta ca o cascadă. Fazele nu se suprapun și au criterii specifice de intrare și ieșire pentru trecerea de la o fază la alta.

Cele șase etape ale ciclului de viață ale modelului original de cascadă sunt:

1. Cerințe: În această fază, așteptările și obiectivele proiectului sunt definite, iar cerințele sunt analizate și documentate pe larg, de obicei de către un analist de afaceri. Cerințele sunt revizuite și aprobate înainte de a ieși din această fază.
2. Proiectare: După ce cerințele sunt aprobate, începe lucrările de arhitectură și proiectare a produsului pentru a îndeplini cerințele aprobate. Arhitectura fizică, arhitectura componentelor, proiectarea bazei de date, componenta detaliată, proiectarea modulelor și alte aspecte ale designului sunt documentate de un arhitect sau designer de software. Acesta este apoi revizuit și aprobat înainte de a începe implementarea.
3. Implementare: După aprobarea designului, implementarea sau codificarea software-ului conform cerințelor și proiectarea este realizată de dezvoltatorii de software.
4. Verificare: După finalizarea implementării, software-ul este testat de echipa de testare sau QA pentru a se asigura că cerințele și designul sunt îndeplinite și că nivelul dorit de calitate este atins. Defectele sunt găsite, înregistrate, triizate și, în multe cazuri, remediate.
5. Lansare și întreținere: După ce testarea și depanarea sunt finalizate, produsul este eliberat clientului și instalat. Adesea, are loc o rundă de teste pentru a se asigura că instalarea a avut succes. După livrarea produsului, au loc întreținere și asistență continuă pentru a se asigura că produsul continuă să funcționeze așa cum a fost proiectat.

Avantajele cascadei

Cascada are câteva avantaje și este potrivită pentru anumite tipuri de proiecte, dar există și unele dezavantaje serioase. Cascada este cea mai potrivită pentru proiecte mai scurte în care cerințele, tehnologia sunt bine înțelese și nu este probabil să se schimbe în vreun fel semnificativ.

Dacă se aplică tipului potrivit de proiect, câteva dintre avantajele modelului cascadă:

• Simplitate: Cascada este ușor de implementat datorită identificării în față a domeniului de aplicare și datorită fazelor rigide și a unei tranziții clare de la o fază la alta.
• Vizibilitate: Progresul este mai ușor de măsurat și văzut de părțile interesate, deoarece întreaga sferă a activității este cunoscută dinainte și pe măsură ce proiectul trece de la o etapă la alta.
• Documentație: Domeniul de aplicare, cerințele și planurile pot fi bine gândite și bine documentate, ceea ce face mai ușor pentru echipele mai puțin experimentate să lucreze la proiect.
• Lucru în etape: Datorită rolurilor rigide și tranziției dintre faze, este posibil ca resursele proiectului să lucreze la alte proiecte atunci când faza lor principală nu este în desfășurare.

Dezavantajele cascadei

Cascada nu este potrivită pentru proiecte mai lungi în care cerințele nu sunt bine înțelese și/sau susceptibile de a se modifica și/sau unde există un risc tehnic semnificativ. În epoca actuală, în care condițiile de piață se schimbă constant și timpul de lansare pe piață este critic, acest lucru se aplică majorității proiectelor software.

Dezavantajele modelului cascadă, care se concentrează în principal pe incapacitatea sa de a se adapta la schimbare, includ:

• Domeniul de aplicare monolitic: recompensează părțile interesate să se gândească la TOT atunci când definesc domeniul de aplicare al proiectului, ceea ce duce la un domeniu de aplicare monolitic.
• Feedback întârziat al clienților: este greu pentru părțile interesate și în special pentru clienți să-și imagineze întregul domeniu detaliat al unui proiect. Deoarece cascada expune clienții la rezultatele proiectului mai ales în ultimele etape ale proiectului, atunci, inevitabil, devine greu să încorporați feedback-ul clienților în proiect
• Cerințele se modifică: în proiectele mai lungi, condițiile de piață și, prin urmare, obiectivele și cerințele proiectului, prezintă un risc foarte mare de a se schimba în timpul proiectului.
• Valoarea creată la sfârșit: Cascada necesită multă muncă în avans, ceea ce înseamnă că valoarea nu este produsă decât târziu în proiect.
• Interdependența fazelor: Încorporarea modificărilor are ca rezultat adesea cerințe și/sau reluări de proiectare care pot avea impact asupra altor zone ale proiectului. Dependența etapelor ulterioare de etapele anterioare poate face schimbări mici în proiect disproporționat de provocatoare.

Livrare agilă disciplinată (DAD)

Disciplined agile delivery (DAD) a fost oficializat de Scott Ambler la IBM și Mark Lines și extinde cadrele agile și scrum, recunoscând că părțile non-agile ale unei organizații sunt de obicei implicate într-o anumită capacitate în livrarea unui proiect software. Acest cadru include în mod explicit activități de la operațiunile IT, arhitectura întreprinderii, managementul portofoliului, finanțe și achiziții până la ciclul complet de livrare. DAD își propune să crească agilitatea globală a afacerii într-un mod pragmatic.

Principii și componente principale

Roluri

DAD are mult mai multe roluri decât scrum și este împărțit în două categorii de roluri de echipă. Rolurile principale sunt ocupate de oameni care lucrează cu proiectul în mod constant. Rolurile secundare sunt introduse în mod obișnuit temporar pentru a ajuta echipa cu extinderea sau alte probleme. DAD are aceste roluri suplimentare, deoarece se adresează întregului ciclu de viață de livrare a soluției și pentru că recunoaște diferitele tipuri de roluri temporare și suport necesare găsite în lumea reală.

Roluri primare:

1. Părți interesate: cineva care depinde de echipa ta care finalizează proiectul: client, utilizator final sau coleg intern.
2. Membru al echipei: oameni din cadrul echipei care realizează munca planificată: dezvoltatori, designeri, testeri etc.
3. Conducător de echipă : La fel ca Scrum Master, șeful echipei lucrează ca un servitor-lider pentru echipă, înlăturând impedimentele, facilitând coeziunea echipei și răspândind valori agile.
4. Proprietar de produs: uneori denumit „vocea clientului”. Proprietarul produsului reprezintă părțile interesate și menține lista prioritizată a lucrărilor care trebuie făcute.
5. Proprietar de arhitectură: responsabil pentru atenuarea riscului de arhitectură la scară. Acest rol este de obicei ocupat de un dezvoltator senior în cadrul echipei, deoarece necesită un fundal tehnic profund și cunoștințe solide în domeniul afacerilor.

Roluri secundare:

1. Specialist: Persoane care se alătură echipei temporar pentru a ajuta într-un rol specializat. De exemplu, un analist de date se poate alătura pentru a oferi capabilități de cercetare în etapele incipiente ale unui proiect.
2. Expert în domeniu: consultanți fiscali, consilieri juridici și alte persoane care au experiență în domeniu și ajută echipa la provocările conexe.
3. Expert tehnic: administrator de baze de date, expert în securitate build master etc. Acești oameni ajută membrii echipei mai generalizate în punctele cheie ale ciclului de viață.
4. Tester independent: În timp ce testerii fac de obicei parte din echipa principală, în unele cazuri cerințele de reglementare a vieții sau sistemele foarte complexe, testerii independenți lucrează în paralel pentru a valida munca de livrare.
5. Integrator: La scară, diferite echipe lucrează la diferite părți ale întregului sistem. Un integrator ajută echipa să-și integreze partea cu întregul sistem și gestionează dependențele.

Suport pentru ciclul de viață

DAD promovează un ciclu de viață complet al livrării, nu doar partea de programare și lansare acoperită de agile/scrum, ci și faza de inițiere în care viziunea proiectului este definită și aprobată și fazele de suport și retragere după lansare. În prezent, DAD acceptă 6 cicluri de viață diferite:

• Ciclul de viață agil: un ciclu de viață al proiectului bazat pe Scrum
• Ciclul de viață Lean: Un ciclu de viață al proiectului bazat pe Kanban
• Livrarea continuă: ciclul de viață agil
• Livrarea continuă: ciclu de viață slab
• Ciclul de viață explorator (Lean Startup).
• Ciclul de viață al programului pentru o echipă de echipe

Aceste cicluri de viață reprezintă diferite stiluri de lucru, niveluri de agilitate a companiei și alte situații în care s-ar putea găsi echipele. Principalul aspect este că aceste cicluri de viață acționează ca sugestii. DAD promovează pragmatismul în detrimentul purismului, deoarece fiecare situație este unică și practicanții agile disciplinați ar trebui să adopte procesul agil la nevoile lor.

Obiectivele procesului

DAD folosește o abordare bazată pe obiective pentru a crea și adapta procese agile. Autorii acestei metodologii subliniază 21 de procese cele mai importante și comune cu care se vor confrunta majoritatea echipelor pe parcursul ciclului de viață.

Toate aceste procese au puncte de decizie documentate care vor cere echipei să decidă cum va structura acel proces. Fiecare punct de decizie oferă tehnici sau practici sugerate care pot fi utilizate pentru implementarea deciziei. Puteți vedea un exemplu în acest sens în imaginea de mai jos. Un proces „Dezvoltarea viziunii comune” are 6 decizii care ar trebui luate. Fiecare dintre aceste decizii are 2 până la 5 practici sugerate. Săgețile indică faptul că autorii DAD au ordonat lista, elementul de sus fiind cea mai bună practică, iar elementul de jos fiind cea mai proastă practică din această listă. Textul _ cursiv îngroșat_ semnifică puncte de plecare bune pentru echipele noi, care abia încep cu DAD.

Scalarea lui DAD

Disciplined Agile Delivery abordează scalarea din două unghiuri diferite:

• Agilitate tactică la scară

• Agilitate strategică la scară

Agilitatea tactică încearcă să abordeze factorii individuali de scalare a echipei, cum ar fi dimensiunea, distribuția geografică, complexitatea proiectului etc., prin aplicarea situațională a obiectivelor procesului și a practicilor sugerate de acestea.

Agilitatea strategică încearcă să abordeze scalarea prin aplicarea strategiilor agile și lean în general în întreaga organizație, extinzând cadrul pentru a aborda diferite zone ale organizației:

• DevOps disciplinat: acoperă utilizarea DevOps pentru a oferi rezultate mai eficiente unei organizații.

• Disciplined Agile IT (DAIT): acoperă modul de aplicare a strategiilor agile și lean la toate aspectele IT.

• Întreprindere Agile disciplinată:. acoperă modul de aplicare lean și agile în cadrul unei întreprinderi.

Sigur

Scaled Agile Framework (SAFe) este cel mai popular, precum și cel mai complex și cuprinzător cadru Agile scalat chiar acum. 29% dintre respondenții din Raportul anual privind starea Agile susțin că folosesc acest cadru în organizațiile lor. La rândul lor, pe piață există mulți manageri de proiect SAFe.

Începutul SAFe a fost cartea lui Dean Leffingwell „Scaling Software Agility: Best Practices for Large Enterprises”, publicată în 2007. Leffingwell este acum metodologul șef al SAFe, dar mulți alți oameni contribuie și ei la acest cadru. În prezent, în versiunea 4.6, acest cadru seamănă cu un produs software cu versiuni, compatibilitate cu versiunea inversă și diverse componente.

Principii și componente principale

Scopul principal al SAFe este de a facilita crearea și creșterea unei întreprinderi Lean, deoarece recunoaște că multe tipuri diferite de companii sunt, în parte, companii de software care trebuie să livreze în mod continuu valoare în cea mai scurtă perioadă de timp durabilă.

SAFe for Lean Enterprises încearcă să creeze o întreprindere Lean furnizând o bază de cunoștințe de principii, competențe și bune practici dovedite.

SAFe 4.6 definește cinci competențe de bază ale întreprinderii slabe. Fiecare competență este un set de cunoștințe, abilități și comportamente conexe, care împreună permit organizațiilor să exceleze:

1. Leadership Lean-Agile : Descrie modul în care liderii conduc și susțin schimbarea organizațională prin învățare, predare și implementare a mentalității Lean-Agile a SAFe.

2. Agilitate în echipă și tehnică : Descrie abilitățile, principiile și practicile necesare pentru a crea echipe Agile de înaltă performanță.

3. DevOps și lansare la cerere : Descrie modul în care implementarea DevOps și a unei conducte de livrare continuă oferă organizațiilor capacitatea de a lansa creșteri de produse în orice moment necesare pentru a satisface cererea.

4. Soluții de afaceri și ingineria sistemelor lean : Descrie modul de aplicare a principiilor și practicilor lean-agile la specificarea, dezvoltarea, implementarea și evoluția aplicațiilor software mari și complexe.

5. Gestionarea portofoliului Lean : Aliniază strategia și execuția prin aplicarea abordărilor lean și a gândirii sistemice la finanțarea strategiei și a investițiilor, a operațiunilor de portofoliu agile și a guvernării.

Fiecare dintre competențele de bază se mapează direct la nivelul lor respectiv în diagrama procesului SAFe, cu excepția Leadership-ului Lean-Agile, care cuprinde întregul proces.

Competență de leadership Lean-Agile

Scopul principal al Lean-Agile Leadership Competency este de a ajuta la transformarea organizației într-o întreprindere lean-agile. Acest lucru se realizează prin învățarea, exersarea și predarea mentalității, valorilor, principiilor și practicilor Lean-Agile ale SAFe.

Valorile de bază ale SAFe ghidează transformarea către întreprinderea lean. La fiecare ocazie, comportamentul unui lider joacă un rol critic în promovarea lor. Valorile de bază sunt:

1. Aliniere : comunicați misiunea, strategia de portofoliu și viziunea soluției. Efectuați briefing-uri relevante și participați la planificarea creșterii programului (PI) și la întreținerea restanțelor.

2. Transparență : vizualizați toate lucrările relevante.

3. Calitate încorporată: implicați- vă în practici pentru a oferi calitate pe tot parcursul ciclului de viață. Refuzați să acceptați munca de calitate scăzută. Sprijiniți investițiile în întreținere și reducerea datoriilor tehnice.

4. Execuția programului : Participați în calitate de proprietari de afaceri la execuția PI și stabiliți valoarea afacerii. Asigurați-vă că domeniul de aplicare este aliniat cu cererea și capacitatea. Îndepărtați în mod agresiv impedimentele și demotivatorii.

Valorile de bază SAFe sunt susținute de îmbrățișarea mentalității Lean-Agile și aplicarea principiilor SAFe:

1. Luați o viziune economică

2. Aplicați gândirea sistemică

3. Să presupunem variabilitatea; păstrează opțiunile

4. Construiți progresiv cu cicluri de învățare rapide și integrate

5. Bazați reperele pe o evaluare obiectivă a sistemelor de lucru

6. Vizualizați și limitați WIP, reduceți dimensiunile loturilor și gestionați lungimile cozilor

7. Aplicați cadența, sincronizați cu planificarea pe mai multe domenii

   

8. Deblocați motivația intrinsecă a lucrătorilor în cunoaștere

9. Descentralizați luarea deciziilor

Aceste principii sunt similare cu principiile Lean și Agile. În cele din urmă, transformarea organizației se realizează urmând Foaia de parcurs de implementare SAFe.

Echipă și agilitate tehnică Competență/Nivel echipă

Competența de agilitate echipă și tehnică descrie abilitățile, principiile și practicile necesare pentru a crea echipe agile de înaltă performanță, care creează soluții de înaltă calitate. Două caracteristici cheie sunt critice:

• Agilitatea echipei : echipele adoptă practici și principii Agile, care le permit să lucreze, să învețe și să se adapteze la o cadență de încredere

• Agilitate tehnică : echipele aplică practici tehnice Agile care asigură codul și calitatea componentelor și mentenabilitatea codului pe care îl produc\ Calitatea este un accent mare în echipă și competența de agilitate tehnică. Pentru a realiza acest lucru, tehnici de inginerie agile, cum ar fi Behavior Driven Development (BDD) și Test-driven development (TDD) sunt aplicate pentru a crește calitatea și fluxul. Fluxul rapid depinde de calitatea clădirii în întregul sistem, deoarece erorile pot afecta grav fluxul și pot întârzia lansările.

Nivelul de echipă al diagramei SAFe descrie modul în care funcționează echipele Agile individuale. Toate echipele fac parte din Agile Release Train care lucrează pentru a oferi o creștere a produsului. Se aplică majoritatea fluxului tradițional agil/scrum, în care echipele lucrează în iterații pentru a furniza sisteme de lucru. Rolurile de scrum master, proprietar de produs și membru al echipei sunt folosite în SAFe, la fel ca majoritatea activităților și artefactelor scrum. Echipele sunt, de asemenea, susținute de roluri la nivel de program, cum ar fi Managementul produsului, Arhitectul de sistem și alte servicii partajate. Kanban este folosit pentru a ajuta la vizualizarea fluxului de funcții prin ciclul de viață al livrării și interacțiunile și transferurile dintre echipe.

DevOps și Release on Demand Nivel de competență/program

Competența DevOps și Release on Demand descriu modul în care „implementarea DevOps și a unei conducte de livrare continuă oferă întreprinderii capacitatea de a elibera valoare, în întregime sau parțial, în orice moment necesar pentru a satisface cererea pieței și a clienților”.

DevOps lucrează pentru a alinia dezvoltarea, operațiunile, afacerile și alte domenii pentru a lucra împreună pentru a oferi rezultate de afaceri. Deși nu fiecare organizație trebuie să lanseze la fel de des ca unii dintre liderii din industrie ai mișcării DevOps (Amazon lansează la fiecare câteva secunde), toate organizațiile trebuie să poată lansa la cerere.

• DevOps oferă abordarea culturii, automatizării, fluxului slab, măsurare și recuperare (CALMR) care permite livrarea continuă și lansarea la cerere

• Trenurile de eliberare agile (ART) sunt echipe de echipe agile care sunt organizate pentru a oferi valoare la cerere printr-o conductă de livrare continuă

Nivelul de program al diagramei descrie rolurile și activitățile necesare pentru a livra în mod continuu printr-un Agile Release Train (ART) . Acest nivel funcționează într-un mod iterativ similar cu nivelul de echipă, dar integrează mai multe echipe agile și include mai multe cicluri. ART este o echipă agilă de echipe formată din 5 până la 12 echipe (50 până la 125 de persoane), inclusiv rolurile tradiționale agile, precum și roluri critice ale programului, cum ar fi Release Train Engineer (RTE) și Product Management. ART oferă în 8-12 săptămâni Creșteri de program (PI) care sunt planificate prin PI Planning și conduse de un manager de produs .

Progresul caracteristicilor PI, epopeei etc. este urmărit și gestionat prin intermediul unui panou Program Kanban. RTE acționează ca Scrum Master pe ART. Întâlnirile zilnice de sincronizare includ echipe Daily Standups, Scrum-of-Scrums (RTE și Scrum Masters), PO Sync (Managementul produselor și proprietarilor de produse) și ART Sync (Scrum-of-Scrums și PO Sync împreună). Fiecare PI are o demonstrație de sistem și o retrospectivă.

Soluții de afaceri și Lean Systems Engineering Competență/Large Solution Level

Soluțiile de afaceri și competența de inginerie a sistemelor Lean descrie „cum se aplică principiile și practicile Lean-Agile la specificarea, dezvoltarea, implementarea și evoluția aplicațiilor software mari și complexe și a sistemelor ciber-fizice”.

Pe lângă principiile SAFe, aplicarea următoarelor 8 principii atunci când lucrați la soluții mari este cheia acestei competențe:

Nivelul de soluție mare conține rolurile, artefactele și procesele necesare pentru a construi soluții mari și complexe. Mai multe ART-uri lucrează împreună la soluții pentru a oferi soluții . Obiectivele principale sunt:

• Gestionați integrarea frecventă

• Abordați continuu problemele de conformitate

• Arhitect pentru scară, modularitate, eliberare și funcționalitate

Managementul soluției controlează conținutul unei soluții, iar Inginerul de tren de soluții (STE) ghidează munca. Solution Architect este responsabil pentru menținerea unei arhitecturi bune pentru toate ART-urile din Soluție. Planificarea pre și post PI este utilizată pentru a planifica soluții livrate prin mai multe creșteri de program. Un Backlog de soluții conține capacități și epopee de soluție și este urmărit printr-un panou de soluții Kanban

Nivel de portofoliu/Competență de gestionare a portofoliului Lean

Competența de gestionare a portofoliului Lean „aliniază strategia și execuția prin aplicarea abordărilor Lean și a gândirii sistemice la finanțarea strategiei și a investițiilor, a operațiunilor de portofoliu agile și a guvernării”.

Lean Portfolio Management se concentrează pe următoarele domenii:

1. Strategie și finanțare de investiții: conectează portofoliul la strategia întreprinderii, finanțează fluxurile de valoare și stabilește fluxul de portofoliu

2. Operațiuni de portofoliu agile: coordonează fluxurile de valoare, sprijină execuția programului și excelența operațională

3. Guvernare Lean: prognozează bugetele, măsoară performanța portofoliului și impune conformitatea

Nivelul portofoliului conține principiile, practicile și rolurile necesare pentru a iniția și guverna un set de fluxuri de valoare de dezvoltare. Un portfolio Backlog conține Business Epics și Enabler Epics și este urmărit prin intermediul unui panou Portfolio Kanban*. **Lean Portfolio Management (LPM) decide ce fluxuri de valoare sunt într-un portofoliu și include cei mai înalți factori de decizie dintr-o întreprindere. Un arhitect Enterprise ghidează munca și coordonează fluxurile de valoare.

Mai puțin

Cadrul Scrum la scară largă (LeSS) a fost creat de Craig Larman și Bas Vodde, care l-au bazat pe experiența lor în industria financiară și a telecomunicațiilor. După cum sugerează și numele, LeSS promovează existența a cât mai puține procese și proceduri posibil pentru ca multe echipe Scrum să lucreze împreună. Scalare este dificilă, deoarece oamenii o fac complexă, așa că scopul aici este să fie cât mai simplu posibil.

Principii și componente principale

„LeSS este Scrum, aplicat mai multor echipe, lucrând împreună, pe un singur produs”. LeSS se bazează pe zece principii care vor părea familiare oricui este familiarizat cu principiile Lean-Agile:

1. Scrum la scară largă este Scrum

2. Controlul empiric al procesului

3. Transparenţă

4. Mai mult cu mai puțin

5. Concentrare pe întregul produs

6. Centrat pe client

7. Îmbunătățirea continuă spre perfecțiune

8. Gândirea sistemică

9. Gândire slabă

10. Teoria cozilor

LeSS are doar două roluri principale, ambele fiind împrumutate de la Scrum:

1. Proprietar produs: Lucrează cu 2-8 echipe.
2. Scrum master: Lucrează cu 1-3 echipe.

Toate echipele lucrează cu același backlog de produse în sprinturi de 1-4 săptămâni. Echipele lucrează în paralel, adică încep și termină sprinturile în același timp. La sfârșitul sprintului, echipele oferă în mod colectiv un increment de produs . Ar putea părea aproape imposibil ca un proprietar de produs să lucreze cu 8 echipe. LeSS promovează mutarea responsabilității pentru clarificarea articolelor din backlog de produse către echipe. La rândul lor, echipele trebuie să fie interfuncționale și să conțină nu numai competențe de codificare, proiectare și testare, ci și cunoștințe în domeniul afacerii. Mai important, echipele trebuie să fie împuternicite pentru a putea ajunge la clienți.

Planificarea sprintului

Planificarea este împărțită în două părți:

1. Planificarea sprintului 1: În cazul în care reprezentanții echipelor se întâlnesc cu proprietarul produsului și decid asupra elementelor restante pe care le vor prelua și discută orice posibilă cooperare care ar putea fi necesară între echipe în timpul sprintului.
2. Planificarea sprintului 2: La fel ca și în scrumul tradițional, fiecare echipă se adună separat pentru a crea un plan pentru modul în care vor fi făcute elementele din backlog.

Rafinarea registrului de produse

Rafinarea registrului de produse (PBR) se face în timpul sprintului pentru a pregăti elementele registrului de produse pentru planificarea sprintului. LeSS nu oferă reguli cum să facă PBR și lasă la latitudinea companiilor să-și dea seama de cel mai eficient proces. PBR implică trei activități cheie:

1. Împărțirea obiectelor mari.
2. Detalierea articolelor până la gata.
3. Estimarea.

Sfârșitul sprintului

La sfârșitul fiecărui sprint se întâmplă trei lucruri:

1. Sprint Review: o demonstrație Sprint comună, în care echipele și clienții explorează ceea ce s-a făcut în timpul Sprintului și ce ar trebui făcut în continuare.
2. Retrospectivă: Fiecare echipă are propria retrospectivă pentru a-și îmbunătăți procesul.
3. Retrospectivă generală: echipele, proprietarii de produse și scrum masters se reunesc pentru a inspecta și a adapta practicile organizaționale pentru a fi mai eficiente.

Scrum@Scale

Scrum at Scale și Scrum@Scale sunt folosite interschimbabil. Această metodologie a fost introdusă de Jeff Sutherland în 2014, care a creat metodologia Scrum și a fost unul dintre semnatarii Agile Manifesto.

Scrum@Scale ia Scrum ca punct de plecare și oferă un cadru simplu și ușor pentru a scala Scrum cu o „birocratie viabilă minimă”. Este mai puțin prescriptivă decât celelalte metodologii agile scalate și poate fi considerată ca un meta-cadru. Evidențiază problemele și domeniile de scalare și oferă un cadru mental pentru modul în care acestea ar putea fi abordate.

Principii și componente principale

Scrum@Scale este un cadru care simplifică radical scalarea utilizând Scrum pentru a scala Scrum. În Scrum, „ce” (proprietarul produsului) este clar separat de „cum” (scrum master). Aceeași strategie este utilizată în Scrum@Scale, astfel încât jurisdicția și responsabilitatea să fie bine înțelese, eliminând risipa și conflictul.

Scrum@Scale conține două cicluri pentru a separa clar jurisdicțiile: ciclul Scrum Master și ciclul Product Owner cu două puncte de contact: Procesul la nivel de echipă și Feedback pentru lansarea produsului.

Ciclul Scrum Master

Ciclul Scrum Master este responsabil pentru modul în care vor fi construite lucrurile identificate de ciclul proprietarului produsului. În Scrum@Scale, echipele individuale Scrum au aceleași roluri, artefacte, activități și ceremonii ca și Scrum tradițional.

Echipele Scrum sunt grupate într-un Scrum of Scrums (SoS) , care este responsabil în comun de producerea unei creșteri comune a produsului. Ei participă la îngrijirea și stabilirea priorităților comune, țin retrospective, mențin întârzierile de impedimente și dețin un Scaled Daily Scrum (SDS) (similar ca format cu scrum-ul zilnic) pentru a coordona echipele și a elimina blocajele. La SDS participă cel puțin un reprezentant (de obicei, Scrum Master al echipei) al fiecăreia dintre echipele participante și este condus de Scrum of Scrums Master (SoSM) , care este responsabil de coordonarea cu echipele Scrums și cu proprietarii de produse.

Dacă este nevoie de o scalare suplimentară, există un scrum of scrum of scrums (SoSoS) creat din mai multe SoS care s-ar întâlni, de asemenea, zilnic și așa mai departe. Liderul general este Executive Action Team (EAT) care este responsabilă de promovarea Agile în organizație, de coordonarea echipelor Scrum după cum este necesar și de a fi punctul final pentru eliminarea impedimentelor.

Ciclul Product Owner

Ciclul Product Owner este responsabil pentru ce produs sau serviciu va fi creat și pentru toate activitățile necesare pentru a sprijini acest lucru. Proprietarii de produse sunt repartizați în echipele Scrum și desfășoară toate activitățile rolului lor, așa cum este definit în Scrum. Proprietarii de produse sunt grupați în echipe de proprietari de produse care se mapează cu echipele SoS. Echipele Product Owner se întâlnesc zilnic la un Meta Scrum pentru a discuta despre o strategie la nivel înalt pentru echipe și se coordonează, după caz, cu SoSM corespunzător și cu alți proprietari de produse și părți interesate. Meta Scrums sunt conduse de un Chief Product Owner (CPO) .

Proprietarii de produse cresc într-un mod similar cu ciclul Scrum Master, în funcție de dimensiunea organizației și culminează cu un Executive Meta Scrum (EMT) , care este responsabil pentru stabilirea priorităților la nivel de companie.

Implementarea Scrum@Scale

Implementarea Scrum@Scale începe cu crearea unui model de referință scalabil, adică un set mic de echipe care utilizează scrum la scară mică. Acest lucru se face pentru a rezolva orice politici organizaționale și practici de dezvoltare care împiedică agilitatea. Scrum@Scale sugerează rezolvarea acestora din timp, deoarece toate echipele sunt susceptibile de a se confrunta cu aceste probleme la nivel de organizație, iar frustrările ulterioare ar putea împiedica adoptarea agile. Modelul de referință este apoi folosit ca model pentru scalarea scrum-ului la alte echipe și departamente.

Echipa de acțiune executivă (EAT) trebuie creată inițial pentru a implementa modelul de referință. EAT este compus din persoane care sunt împuternicite din punct de vedere politic și financiar în cadrul organizației, deoarece vor putea implementa modificările politicii organizaționale.

Concluzie

În această a doua parte a planului de management al proiectelor, am acoperit unele dintre cele mai populare cadre utilizate în proiecte sau programe mai mari. Cascada este încă utilizată pe scară largă în multe organizații și, deși are multe dezavantaje din cauza proceselor sale inflexibile, uneori are sens să folosiți acest cadru atunci când proiectele sunt mici și domeniul de aplicare este bine definit și este puțin probabil să se schimbe.

Pe măsură ce companiile se confruntă cu proiecte mai mari și mai complexe, cu cerințe sau obiective în continuă schimbare, ele caută abordări mai Agile. Deoarece Agile a fost inițial conceput pentru echipe mici de 5-9 persoane, diverși practicieni Agile au venit cu mai multe modalități de a scala agil de la echipe individuale, la mai multe echipe, la întreaga întreprindere. În acest articol, am acoperit Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) și Scrum@Scale.

În partea finală a planului de management de proiect, vom acoperi câteva cadre specifice managementului de proiect, cum ar fi PMP (PMBOK) și PRINCE2. Vom analiza, de asemenea, unele procese și cadre de inovare, cum ar fi „lucrări de făcut” (JTBD) și „gândirea în proiectare”.