cadrul Nexus pentru scalarea Scrum în dezvoltarea de Software

Scrum, fiind cel mai comun mod agil, că echipele de dezvoltare de software de lucru, duce la întrebarea, ‘cum putem scala Scrum dincolo de o singură echipă? Dacă aveți probleme cu dependențele între echipe, riscuri care afectează mai multe echipe, programarea livrărilor, este posibil să aveți nevoie de un cadru de scalare.

puteți organiza mai multe Echipe Scrum în mai multe moduri diferite. În acest articol, vom merge în profunzime a cadrului Nexus pentru scalarea Agile și Scrum, pe baza experienței DevCom. Există și alte cadre pentru scalarea Agile, cum ar fi mai puțin, sigur, tată (disciplinat agile Delivery) și, dar acestea nu sunt acoperite în acest articol.

ce este Nexus Framework?

Nexus framework a fost fondat de co-creatorul Scrum Ken Schwaber și Scrum.org echipa în 2015 ca un ghid pentru scalarea Scrum în proiecte agile ample.
deoarece Scrum a devenit o parte integrantă a multor organizații, proiectele lor trebuie să depășească sesiunile tipice zilnice, de planificare, revizuire și întâlnire Retro utilizate în Scrum pentru a fi eficiente. Scrum singur nu este suficient atunci când mai multe echipe lucrează la un produs. Productivitatea se erodează din cauza dependențelor dintre echipe.
Nexus framework folosește Scrum ca element de construcție și îl extinde pentru o mai bună gestionare a mai multor echipe Scrum care lucrează la un singur produs. Nexus este aplicat la 3-9 grupuri scrum și să le ghideze cu privire la modul în care acestea trebuie să coopereze, și cota de lucru pentru a livra software-ul în fiecare Sprint cu dependențe minime.

Cum Nexus Framework Scale Scrum?

Scrum este un cadru din care evoluează procesul. Acesta este axat pe modul în care o singură echipă Scrum funcționează pe un singur produs și să livreze software-ul în trepte mici. Principala diferență între Nexus framework și Scrum este adăugarea unei echipe de integrare care se concentrează pe facilitarea dependențelor dintre echipe.

Cadru Scrum

(Sursa)

Nexus pentru scalarea agile

(Sursa)

fluxul de proces Nexus:

  1. rafinați Backlogul produsului.
  2. Planificarea Nexus Sprint.
  3. lucrări de dezvoltare.
  4. Nexus Daily Scrum.
  5. Nexus Sprint Opinie.
  6. Nexus Sprint Retrospectivă.

în momentul în care implementați Nexus, nu există modificări semnificative în fundamentele Scrum în sine. Nexus este la fel ca adăugarea de noi practici la Scrum, roluri suplimentare, evenimente și artefacte numai acolo unde este necesar pentru a permite inițiative de dezvoltare software de succes. Nexus mărește Scrum pentru a permite Scrum la scară în mod eficient. Acest lucru se realizează prin creșterea simplității și transparenței prin lucrul dintr-un singur produs. Lucrul care contează este că se acordă mai multă atenție dependențelor dintre echipele Scrum, care sunt responsabile pentru livrarea incrementelor “făcute” la fiecare Sprint.

o definiție a “terminat” este criterii riguroase care pot fi aplicate incrementului integrat dezvoltat la fiecare Sprint și care este urmat de toate echipele Scrum ale unui Nexus.

DevCom cum Nexus extinde Scrum

Nexus Framework implementare

Nexus framework presupune experiență Scrum. Organizațiile care lucrează deja cu Scrum vor putea implementa Nexus cu ușurință. Pentru a începe un Nexus, organizațiile ar trebui să identifice mai întâi echipele din Nexus, o echipă inițială de integrare Nexus, un singur produs restante, o definiție a “făcut”, o cadență Sprint.

strategia de implementare Nexus

definiți echipele Scrum (păstrați accentul pe caracteristici, mai degrabă decât pe componente). 1.1. Organizați o întâlnire și definiți modul de formare a echipelor;
1.2. Alocați membrii echipei (în mod ideal Echipe auto-făcute);
1.3. Definiți jucătorul(jucătorii) cheie/reprezentantul(reprezentanții) din fiecare echipă.
definiți mediile și repo-urile pentru dezvoltare (pe baza numărului de clienți(chiriași) și a nivelului de acces). 2.1. Faceți o listă a repo-urilor curente;
2.2. Reorganizarea repo-uri și medii de revizuire pentru a scurta timpul de plumb DE SARCINI;
2.3. Faceți o bază de cod comună (dacă este posibil);
definiți echipa de integrare Nexus (membrii echipelor Scrum. Poate varia în funcție de informații care urmează să fie diseminate și rezolvate ca urmare a Nexus Daily Scrum). 3.1. Definiți persoanele responsabile pentru integrări în principal și rezolvarea dependențelor;
3.2. Atribuiți rolul unui Scrum master în cadrul fiecărei echipe.
învățați și explicați Scrum & Nexus framework. 4.1. Organizați o întâlnire pentru toate echipele Scrum și examinați elementele de bază;
4.2. Facilitează întâlnirile atunci când este necesar.
definiți instrumente pentru a lucra cu și în interior. 5.1. Definiți productivitatea și instrumente de management de proiect pentru a lucra cu și în cadrul și integra (înființat).
definiți “definiția de făcut”. 6.1. Sunt de acord cu NIT pe termen;
6.2. Creați un document formal.
definiți Product backlog / rafinați Product backlog cu Product Owner (PO) sau/și repetari. 7.1. Înregistrați cerințele funcționale utilizând unul dintre instrumentele de mai sus;
7.2. Creați un șablon cu câmpurile obligatorii care trebuie completate (de exemplu, Nume, Descriere, criterii de acceptare, constrângeri).
obțineți aprobarea proprietarului produsului & lăsați-o să acorde prioritate restanțelor. 8.1. Implică PO să mire și rafina restante;
8.2. Colaborare continuă cu PO pentru a lucra pe Product backlog (scrie povești, sarcini folosind un șablon 7.2).
organizați NIT pentru a estima restanțele folosind puncte relative. 9.1. Țineți prima parte a întâlnirii pentru a dobândi o tehnică de estimare.
9.2. Organizați o a doua parte a întâlnirii pentru a face estimări brute pentru articolele din Product backlog (PBI).
Implementați Planificarea Nexus Sprint. 10.1. Definiți cadența Sprintului;
10.2. Definiți dependențele, problemele de integrare care pot apărea;
10.3. Domeniul de aplicare care trebuie definit: aproximativ cel puțin 2 sprinturi înainte și curent;
10.4. Organizați o întâlnire pentru a ajuta membrii NIT cu planificarea sprintului în Echipe.
implementați planificarea sprintului în cadrul fiecărei echipe Scrum. 11.1. Utilizați estimări absolute pentru sarcini și subactivități în timpul planificării Sprintului;
11.2. Facilitarea planificării Sprintului pentru fiecare echipă;
11.3. Creați un șablon de document.
implementați Nexus Daily Scrum și Daily Scrum pentru fiecare echipă. 12.1. Definiți ora, facilitați întâlnirile zilnice Nexus Scrum (încercați să le păstrați timeboxed);
12.2. Definiți ora, facilitați întâlnirile zilnice Scrum (păstrați-le timeboxed).
punerea în aplicare Nexus Sprint Review (max 4h). 13.1. Țineți o revizuire Nexus Sprint (inclusiv înregistrarea demo, dacă este necesar) cu membrii echipei Scrum, PO, alte părți interesate.
punerea în aplicare Nexus Sprint întâlnire retrospectivă și retrospectivă pentru fiecare echipă Scrum (a crea un document de template-uri) (max 1h și 3h). 14.1. Organizarea unei ședințe retrospective pentru NIT;
14.2. Crearea unui document șablon;
14.3. Facilitați întâlnirile retrospective în echipele Scrum.
14.4. Creați un document șablon.
punerea în aplicare Nexus rafinament eveniment în mod regulat a restante de produse. 15.1. Definiți frecvența (ori de câte ori este necesar; de exemplu, 2t/săptămână).
implementați estimarea în puncte de poveste (în funcție de inițiativa PO și dorința de a prognoza). 16.1. Începeți urmărirea vitezei echipelor Scrum (după 3 sprinturi);
16.2. Urmăriți progresul folosind graficul Sprint burndown.
implementați dependențele vizuale și prognoza acestora între sarcini. 17.1. Vizualizați dependențele între poveștile utilizatorilor ,sarcini (de exemplu, pavilion și link);
17.2. Definiți dependențele pentru sprintul curent și două sprinturi înainte.
începeți activitățile de management de proiect pentru a sprijini proiectul. 18.1. Creați documente care ar putea fi utile (de exemplu, Carta proiectului, matricea de gestionare a riscurilor, managementul părților interesate, managementul echipei (incl. Informații despre membrii echipei, test de DISC, test de motivație, verificare de sănătate a echipei));
18.2. Definiți KPI-urile proiectului și creați un șablon pentru a le urmări. De obicei, acestea includ viteza, Sprint burndown, CSAT. Altele pot include calcule bugetare;
18.3. Definirea rapoartelor pentru controalele de sănătate ale proiectului cu OP și părțile interesate cheie;
18.4. Examinați strategia de testare în cadrul activităților și fluxului (manual, teste unitare, automatizare) dacă acestea nu fac parte din fluxul implicit.
strategia de a oferi mai multă valoare și de a maximiza rezultatele după implementarea pașilor de mai sus (TBD). 19.1. Să organizeze o întâlnire cu părțile interesate cheie (PO, CEO alții);
19.2. Colectați și discutați cerințele care se aliniază strategiei de afaceri.

Nexus Teams

un Nexus este format din aproximativ 3 până la 9 Echipe Scrum și o echipă de integrare Nexus formată din 1-2 membri din fiecare echipă scrum care sunt responsabili pentru planificarea viziunii produsului general și coordonarea echipelor.

se recomandă formarea echipelor pe baza fezabilității. Echipele de caracteristici au cel mai mult sens, deoarece pot lucra la orice articol din lista de produse.

cu toate acestea, fluxul de lucru curent se înclină spre echipele componente, ceea ce poate duce la dependențe mai mari între ele. Pentru a reduce riscul este un punct valabil pentru a delega echipelor acele sarcini care aparțin altor decât componenta lor. Procesul de schimb de cunoștințe va fi esențial în acest caz și va reduce lipsa de informații la integrare.

echipa de integrare Nexus (nit) este formată din membri din:

  • ⇒ Product Owner-responsabil pentru maximizarea valorii produsului și pentru asigurarea faptului că munca combinată finalizată de un Nexus este produsă cel puțin o dată la fiecare Sprint.
  • scrum master – responsabil pentru echipele Scrum face Scrum și Nexus corect și maximizarea valorii livrate de echipa de dezvoltare. Responsabil pentru livrarea incrementelor “terminate” ale produselor potențial eliberabile.
  • echipa de dezvoltare a proiectului – responsabila pentru crearea de incremente integrate care sunt realizate. Nit asigurați-vă că echipele Scrum din cadrul Nexus înțeleg și implementează practicile necesare pentru detectarea dependențelor și integrează frecvent toate artefactele la definiția “terminat.”

rolul echipei de integrare Nexus:

  • ⇒ echipa de integrare Nexus este responsabilă pentru asigurarea definiției “terminat”.
  • increment integrat (lucrarea combinată finalizată de un Nexus) este produsă cel puțin o dată la fiecare Sprint.
  • XV echipele Scrum sunt responsabile pentru livrarea “Done”.
  • XV nit oferă un punct focal de integrare pentru Nexus. Integrarea include rezolvarea oricăror constrângeri tehnice și non-tehnice între echipe care pot împiedica capacitatea unui Nexus de a oferi o creștere integrată constant.
  • calitatea de membru poate varia în timp, în funcție de impedimentele pe care le experimentează Nexus.

membrii echipei trebuie să producă rezultatul maxim pentru fiecare Sprint. Este recomandat un control de sănătate regulat pentru echipe, precum și pentru software. O dată pe lună se poate organiza un chestionar rapid pentru a monitoriza productivitatea echipelor în cadrul fiecărei echipe Scrum.

întrebări pentru membrii echipei:

  • ⇒ aduc valoare?
  • XV este produsul ușor de eliberat?
  • XV membrii echipei se distrează?
  • este produsul sănătos?
  • este durabil și suportabil?
  • XV sunt membrii echipei de învățare?
  • XV înțeleg obiectivele produsului?
  • XV se simt ca niște pioni sau jucători?
  • XV se simt proprietari?
  • este viteza lor adecvată?
  • OLX consideră că au un proces adecvat?
  • XV se simt sprijiniți?
  • OLX funcționează bine ca o echipă?
  • OLX contribuie compania la dezvoltarea angajaților?

DevCom Nexus Echipa Sănătate Verifica

Nexus Evenimente

1.Rafinament

rafinament are ca rezultat un Backlog produs care este suficient de granular pentru echipele Scrum pentru a trage de lucru fără a crea dependențe imposibil de gestionat. În timpul rafinării, echipele Scrum ar trebui să se concentreze asupra acestor întrebări:

  • ⇒ ce muncă va face fiecare echipă?
  • in ce ordine trebuie facuta aceasta munca pentru a oferi cea mai mare valoare afacerii cat mai devreme, minimizand in acelasi timp riscul si complexitatea?

Nexus Sprint planificare

Nexus Sprint planificare constă din:

  • ⇒ validarea Product Backlog. Echipele Scrum revizuiesc PBI-urile și fac toate ajustările necesare pentru lucrul de la evenimentul de rafinare. Toate echipele Scrum ar trebui să participe și să contribuie la minimizarea problemelor de comunicare; cu toate acestea, trebuie să participe doar reprezentanții corespunzători (cei care consideră că pot contribui la rafinarea PBI-urilor) de la fiecare dintre echipele Scrum.
  • XlX formularea obiectivului Nexus. Obiectivul Nexus este un obiectiv Sprint care este îndeplinit prin implementarea PBI-urilor de către mai multe echipe.
  • planificarea sprintului echipei Scrum. Odată ce obiectivul Nexus pentru Sprint este înțeles, fiecare echipă Scrum își va desfășura evenimentele individuale de planificare Sprint în care membrii își creează propriile restanțe Sprint. Pe măsură ce identifică dependențele cu alte echipe, lucrează cu acele Echipe pentru a minimiza sau elimina dependențele. Majoritatea planificării Sprintului ar trebui să dureze 8 ore.

în unele cazuri, acest lucru va însemna că secvența de lucru între Echipe poate fi ajustată pentru a permite unei echipe să-și termine munca înainte ca alta să înceapă.

Nexus Daily Scrum

Nexus Daily Scrum meeting cuprinde principalele întrebări:

  • ⇒ munca din ziua precedentă a fost integrată cu succes și, dacă nu, de ce?
  • au fost identificate noi dependențe?
  • XV ce informații trebuie partajate între echipele din Nexus?

de obicei este ținut în același timp și loc.

Nexus Sprint Review

Sprint Review Include următoarele elemente:

  • ⇒ printre participanți se numără echipele Scrum și principalele părți interesate invitate de Product Owner;
  • olfactiv Product Owner explică ce produse au fost “realizate” și ce nu au fost “realizate”;
  • XV echipele de dezvoltare discută despre ce a mers bine în timpul sprintului, ce probleme s-au confruntat și cum au fost rezolvate aceste probleme;
  • XV echipele de dezvoltare demonstrează munca pe care a “făcut-o” și răspunde la întrebări despre Increment;
  • XV Product Owner discută despre restanțele de produse în forma lor actuală. El sau ea proiectează date țintă și de livrare probabile pe baza progreselor înregistrate până în prezent (dacă este necesar);
  • intreg grupul colaborează cu privire la ceea ce trebuie făcut în continuare, astfel încât revizuirea Sprint să ofere o contribuție valoroasă la planificarea Sprint ulterioară;
  • revizuire a modului în care piața sau utilizarea potențială a produsului ar fi putut schimba ceea ce este cel mai valoros lucru de făcut în continuare;
  • revizuire a calendarului, bugetului, capacităților potențiale și pieței pentru următoarele versiuni anticipate ale funcționalității sau capacității produsului.

rezultatul revizuirii Sprint este un Backlog de produs revizuit care definește elementele probabile de Backlog de produs pentru următorul Sprint. Restanțele de produse pot fi, de asemenea, ajustate în general pentru a satisface noi oportunități.

această activitate nu trebuie să dureze mai mult de 3 ore.

Întâlnire Retrospectivă Nexus

5.1. Retrospectiva NIT

deoarece există disfuncții comune de scalare, fiecare retrospectivă ar trebui să abordeze următoarele întrebări.

  • ⇒ au îndeplinit obiectivul Nexus? Dacă nu, de ce nu?
  • a rămas vreo lucrare nefăcută? Nexus a generat datorii tehnice?
  • au fost toate artefactele, în special codul, frecvent (în mod ideal, continuu) și integrate cu succes?
  • a fost software-ul construit, testat și implementat cu succes suficient de des pentru a preveni acumularea copleșitoare de dependențe nerezolvate?

când problemele sunt descoperite, reprezentanții trebuie să ceară:

  • ⇒ de ce s-a întâmplat asta?
  • XV cum poate fi rezolvată problema?
  • XV cum poate fi prevenită recurența?

după întâlnirea retrospectivă Nexus, este important să definiți elementele de acțiune la care să lucrați în cadrul tuturor echipelor Scrum. NIT trebuie să țină evidența acestor elemente și poate utiliza un tabel de mai jos.

DevCom Nexus Action Items

5.2. Scrum Teams Retrospective

fiecare echipă Scrum poate folosi un panou pentru a vizualiza elementele la care trebuie lucrat. În plus, se recomandă să urmăriți în mod oficial astfel de înregistrări într-un mod structurat. Cel mult, este nevoie de 4 ore pentru a discuta cu echipa cum a decurs un Sprint.

Scrum teams Retrospective

Product Owner

Product Owner este responsabil pentru maximizarea valorii produsului.

Product Owner este singura persoană responsabilă pentru gestionarea restanțelor de produse. Managementul Product Backlog include:

  • de produse;
  • de produse;
  • de produse;
  • de produse;
  • de produse;
  • de produse;
  • de produse;
  • de produse;

  • de produse;
  • de produse;
  • de produse;
  • XV asigurarea faptului că echipele Scrum înțeleg elementele din restanțele de produse la nivelul necesar;
  • XV definesc obiectivul Nexus pentru fiecare Sprint (similar cu milestone).

proprietarul produsului poate face munca de mai sus sau poate pune echipa Nexus să o facă. Cu toate acestea, proprietarul produsului rămâne responsabil.

Takeaways cheie

  1. scalate lucrări Agile, și folosind un cadru de scalare a vă ajuta să obțineți un start rapid.
  2. scalarea Scrum este doar Scrum. Nu schimbați modul în care lucrați ca echipă Scrum și nici nu schimbați munca livrată.
  3. prin adăugarea cadrului Nexus deasupra Scrum, acesta oferă echipelor o modalitate de a face față dependențelor între echipe și de a se asigura că toate lucrează împreună pentru un obiectiv comun și o creștere a produsului.
  4. dacă știți Scrum foarte bine, Nexus framework este cadrul “no-brainer” pentru scalarea echipelor de dezvoltare software și este posibil să nu aveți nevoie de nimic altceva.
  5. Nexus este un cadru de discuții util pentru cei care au deja mai multe Echipe Scrum în loc, care funcționează împreună.
  6. alternativ, dacă doriți să descrieți procesul dvs., Nexus framework este un bun punct de plecare, astfel încât să nu pierdeți nicio perspectivă.
  7. ca întotdeauna, când vine vorba de scalarea agilă, amintiți-vă aceste trei lucruri importante:
  • ⇒ adaptați metoda pentru a se potrivi organizației dvs.
  • XlX reflectă în mod constant asupra situației.
  • Olt îmbunătăți modul în care lucrați împreună.

aveți mai multe sugestii pentru tehnicile “dincolo de echipă”? Vrei ajutor pentru implementarea acestor idei?

din 2000, DevCom a adaptat Metodologii Agile standard în industrie concepute pentru a crea soluții în timp util, eficiente și eficiente pentru a atinge obiectivele clientului nostru. Aceste metodologii reprezintă un model de dezvoltare iterativă în care efortul general este împărțit în mai multe versiuni pentru a atinge obiectivele prezentate pentru o anumită fază. Punem mult accent pe trei elemente ale ciclului de viață al dezvoltării: evaluarea și planificarea inițială a Proiectului, Managementul Proiectului calității, Asigurarea Calității.

abordarea noastră de dezvoltare reduce riscurile proiectului și lucrează pentru a controla timpul de lansare pe piață și bugetul. Împărtășim această experiență și cunoștințe cu noii noștri clienți, astfel încât toată lumea să poată reuși la scalare.

obțineți rezultate mai bune prin munca în echipă: contactați-ne la DevCom astăzi!

Lasă un răspuns

Adresa ta de email nu va fi publicată.