Il framework Nexus per il ridimensionamento di Scrum nello sviluppo software

Scrum, essendo il modo agile più comune, che i team di sviluppo software lavorano, porta alla domanda di, ‘ Come scalare Scrum oltre un singolo team?’In caso di problemi con dipendenze tra team, rischi che interessano più team, pianificazione delle consegne, potrebbe essere necessario un framework di ridimensionamento.

È possibile organizzare più team Scrum in molti modi diversi. In questo articolo, andremo in profondità del framework Nexus per il ridimensionamento Agile e Scrum, sulla base dell’esperienza di DevCom. Esistono altri framework per il ridimensionamento Agile come LeSS, SAFe, DAD (Disciplined Agile Delivery) e, ma non sono coperti in questo articolo.

Che cos’è Nexus Framework?

Nexus framework è stato fondato da Scrum co-creatore Ken Schwaber e il Scrum.org team nel 2015 come guida per il ridimensionamento Scrum in progetti agili ad ampio raggio.
Poiché Scrum è diventato parte integrante di molte organizzazioni, i loro progetti devono andare oltre le tipiche sessioni quotidiane, di pianificazione, revisione e riunione retrò utilizzate in Scrum per essere efficaci. Scrum da solo non è sufficiente quando più team lavorano su un prodotto. La produttività si erode a causa delle dipendenze tra i team.
Nexus framework utilizza Scrum come elemento costitutivo e lo estende per una migliore gestione di più team Scrum che lavorano su un singolo prodotto. Nexus viene applicato a 3-9 gruppi scrum e guidarli su come devono cooperare, e condividere il lavoro per fornire software in ogni Sprint con dipendenze minime.

Come Nexus Framework scale Scrum?

Scrum è un framework da cui evolve il processo. Si concentra su come un singolo team Scrum lavora su un singolo prodotto e fornisce software in piccoli incrementi. La principale differenza tra il framework Nexus e Scrum è l’aggiunta di un team di integrazione che si concentra sulla facilitazione delle dipendenze tra i team.

Struttura Scrum

(Fonte)

Nexus per scalare agile

(Fonte)

Flusso di processo Nexus:

  1. Perfeziona il backlog del prodotto.
  2. Nexus Sprint Pianificazione.
  3. Lavori di sviluppo.
  4. Nexus Mischia quotidiana.
  5. Nexus Sprint Recensione.
  6. Nexus Sprint Retrospettiva.

Nel momento in cui si implementa il Nexus, non ci sono cambiamenti significativi nei fondamenti di Scrum stesso. Nexus è molto simile all’aggiunta di nuove pratiche a Scrum, ruoli aggiuntivi, eventi e artefatti solo se necessario per consentire iniziative di sviluppo software di successo. Nexus aumenta Scrum per consentire Scrum per scalare in modo efficace. Ciò si ottiene aumentando la semplicità e la trasparenza lavorando da un singolo backlog di prodotto. La cosa che conta è che viene prestata maggiore attenzione alle dipendenze tra i team Scrum, che sono responsabili della distribuzione di incrementi “fatti” ad ogni Sprint.

Una definizione di “Fatto” è criteri rigorosi che possono essere applicati all’incremento integrato sviluppato ogni Sprint, e che è seguito da tutti i team Scrum di un Nexus.

DevCom Come Nexus estende Scrum

Implementazione del framework Nexus

Il framework Nexus presuppone l’esperienza di Scrum. Le organizzazioni che già lavorano con Scrum saranno in grado di implementare Nexus facilmente. Per avviare un Nexus, le organizzazioni devono prima identificare i team nel loro Nexus, un team di integrazione Nexus iniziale, un singolo Product Backlog, una definizione di “Fatto”, una cadenza Sprint.

Strategia di implementazione Nexus

Definire i team Scrum (mantenere l’attenzione sulle caratteristiche, piuttosto che sui componenti). 1.1. Tenere una riunione e definire come formare squadre;
1.2. Assegnare i membri del team (idealmente squadre fatte da sé);
1.3. Definire il giocatore chiave(s)/rappresentante(s) da ogni squadra.
Definire gli ambienti e i repository per lo sviluppo (in base al numero di client (tenant) e al livello di accesso). 2.1. Crea un elenco di repository correnti;
2.2. Riorganizzare i repository e gli ambienti di revisione per ridurre i tempi di esecuzione delle attività;
2.3. Crea una base di codice comune (se possibile);
Definire il team di integrazione Nexus (membri dei team Scrum. Può variare a seconda delle informazioni da diffondere e risolvere a seguito di Nexus Daily Scrum). 3.1. Definire le persone responsabili principalmente delle integrazioni e della risoluzione delle dipendenze;
3.2. Assegna il ruolo di Scrum master all’interno di ogni squadra.
Insegnare e spiegare Scrum & Nexus quadro. 4.1. Tenere una riunione per tutti i team Scrum e rivedere le basi;
4.2. Facilitare le riunioni quando necessario.
Definire gli strumenti con cui lavorare e all’interno. 5.1. Definire la produttività e gli strumenti di gestione del progetto per lavorare con e all’interno e integrare (set up).
Definire la “Definizione di fatto”. 6.1. D’accordo con il NIT sul termine;
6.2. Creare un documento formale.
Definire il Product backlog / perfezionare il product backlog con Product Owner (PO) o / e reps. 7.1. Registrare i requisiti funzionali utilizzando uno degli strumenti di cui sopra;
7.2. Creare un modello con i campi obbligatori da compilare (ad esempio nome, descrizione, criteri di accettazione, vincoli).
Ottieni l’approvazione del proprietario del prodotto & lascia che dia la priorità al backlog. 8.1. Coinvolgere PO per governare e perfezionare il backlog;
8.2. Collaborazione continua con PO per lavorare sul Product backlog (scrivere storie, attività utilizzando un modello 7.2).
Organizzare NIT per stimare il backlog utilizzando i punti relativi. 9.1. Tenere la prima parte della riunione per acquisire una tecnica di stima.
9.2. Tenere una seconda parte della riunione per effettuare stime approssimative per gli elementi del Product backlog (PBI).
Implementare la pianificazione Nexus Sprint. 10.1. Definire la cadenza Sprint;
10.2. Definire dipendenze, problemi di integrazione che possono apparire;
10.3. Ambito da definire: approssimativamente almeno 2 sprint avanti e corrente;
10.4. Tenere una riunione per aiutare i membri NIT con la pianificazione Sprint in team.
Implementare la pianificazione Sprint all’interno di ogni squadra Scrum. 11.1. Utilizzare stime assolute per attività e attività secondarie durante la pianificazione dello Sprint;
11.2. Facilitare la pianificazione Sprint per ogni squadra;
11.3. Creare un modello di documento.
Implementa Nexus Daily Scrum e Daily Scrum per ogni squadra. 12.1. Definire il tempo, facilitare Nexus Daily Scrum meetings (cercare di tenerli timeboxed);
12.2. Definire il tempo, facilitare le riunioni quotidiane Scrum (tenerli timeboxed).
Implementare Nexus Sprint Recensione (max 4h). 13.1. Tenere una revisione Nexus Sprint (compresa la registrazione demo, se necessario) con i membri del team Scrum, PO, altre parti interessate.
Implementare Nexus Sprint Riunione retrospettiva e retrospettiva per ogni team Scrum (creare un documento di modelli) (max 1h e 3h). 14.1. Tenere una riunione retrospettiva per NIT;
14.2. Creare un documento modello;
14.3. Facilitare le riunioni retrospettive nei team Scrum.
14.4. Creare un documento modello.
Implementare evento Raffinatezza Nexus sulla base regolare del Product Backlog. 15.1. Definire la frequenza (tutte le volte che è necessario, ad esempio 2t / settimana).
Implementare la stima in punti storia (a seconda dell’iniziativa PO e della volontà di prevedere). 16.1. Inizia a monitorare la velocità dei team Scrum (dopo 3 sprint);
16.2. Monitorare i progressi utilizzando il grafico Sprint burndown.
Implementa le dipendenze visive e le loro previsioni tra le attività. 17.1. Visualizzare le dipendenze tra storie utente, attività (ad esempio flag e link);
17.2. Definire le dipendenze per lo Sprint corrente e due Sprint avanti.
Avviare attività di project management a supporto del progetto. 18.1. Creare documenti che potrebbero essere utili (ad esempio Carta del progetto, matrice di gestione del rischio, gestione degli stakeholder, gestione del team (incl. Informazioni sul membro del team, test del DISCO, test di motivazione, controllo dello stato di salute del team));
18.2. Definire KPI di progetto e creare un modello per tenerne traccia. Di solito includono velocity, Sprint burndown, CSAT. Altri possono includere calcoli di bilancio;
18.3. Definire rapporti per i controlli dello stato del progetto con PO e le principali parti interessate;
18.4. Esaminare la strategia di test all’interno delle attività e del flusso (manuale, test unitari, automazione) se non fanno parte del flusso predefinito.
Strategia per fornire più valore e massimizzare i risultati dopo l’implementazione dei passaggi precedenti (TBD). 19.1. Tenere un incontro con le principali parti interessate (PO, CEO altri);
19.2. Raccogliere e discutere i requisiti che si allineano con la strategia di business.

Team Nexus

Un Nexus è composto da circa 3-9 team Scrum e un team di integrazione Nexus costituito da 1-2 membri di ciascun team scrum che sono responsabili della pianificazione della visione del prodotto complessivo e del coordinamento dei team.

Si consiglia di formare squadre in base alla fattibilità. I team di funzionalità hanno più senso in quanto potrebbero lavorare su qualsiasi elemento del product backlog.

Tuttavia, il flusso di lavoro corrente si appoggia ai team di componenti, il che potrebbe portare a dipendenze più grandi tra loro. Per ridurre il rischio è un punto valido per delegare ai team quelle attività che appartengono a diversi dal loro componente. Il processo di condivisione delle conoscenze sarà essenziale in questo caso e ridurrà la mancanza di informazioni durante l’integrazione.

Nexus Integration Team (NIT) è composto da membri provenienti da:

  • ⇒ Product Owner-responsabile per massimizzare il valore del prodotto e per garantire che il lavoro combinato completato da un Nexus è prodotto almeno una volta ogni Sprint.
  • ⇒ Scrum Master-responsabile per i team Scrum che eseguono correttamente Scrum e Nexus e massimizzano il valore fornito dal team di sviluppo. Responsabile della fornitura di incrementi “fatti” di prodotti potenzialmente rilasciabili.
  • ⇒ Team di sviluppo-responsabile per la creazione di incrementi integrati che sono ‘fatto’. NIT assicura che i team Scrum all’interno del Nexus comprendano e implementino le pratiche necessarie per rilevare le dipendenze e spesso integrino tutti gli artefatti nella definizione di “Done.”

Ruolo del team di integrazione Nexus:

  • ⇒ Il team di integrazione Nexus è responsabile per garantire la definizione di”Fatto”.
  • ⇒ Incremento integrato (il lavoro combinato completato da un Nexus) viene prodotto almeno una volta ogni Sprint.
  • ⇒ I team Scrum sono responsabili della consegna “Fatto”.
  • ⇒ Il NIT fornisce un punto focale di integrazione per il Nexus. L’integrazione include la risoluzione di eventuali vincoli tecnici e non tecnici tra team che potrebbero ostacolare la capacità di un Nexus di fornire un incremento costantemente integrato.
  • ⇒ Appartenenza può variare nel tempo a seconda degli impedimenti le esperienze Nexus.

I membri del team devono produrre il risultato massimo per ogni Sprint. Si consiglia un controllo regolare dello stato di salute per i team e per il software. Una volta al mese si può tenere un questionario rapido per monitorare la produttività dei team all’interno di ogni team Scrum.

Domande per i membri del team:

  • ⇒ Stanno offrendo valore?
  • ⇒ È il prodotto facile da rilasciare?
  • ⇒ I membri del team si divertono?
  • ⇒ Il prodotto è sano?
  • ⇒ È sostenibile e sostenibile?
  • ⇒ I membri del team stanno imparando?
  • ⇒ Capiscono gli obiettivi del prodotto?
  • ⇒ Si sentono pedine o giocatori?
  • ⇒ Si sentono proprietari?
  • ⇒ La loro velocità è adeguata?
  • ⇒ Ritengono di avere un processo adatto?
  • ⇒ Si sentono supportati?
  • ⇒ Stanno lavorando bene come una squadra?
  • ⇒ L’azienda contribuisce allo sviluppo dei dipendenti?

Controllo dello stato del team DevCom Nexus

Eventi Nexus

1.Refinement

Refinement si traduce in un Product Backlog abbastanza granulare per consentire ai team Scrum di eseguire il lavoro senza creare dipendenze ingestibili. Durante il perfezionamento, i team Scrum dovrebbero concentrarsi su queste domande:

  • ⇒ Che lavoro farà ogni squadra?
  • ⇒ In quale ordine deve essere svolto questo lavoro per fornire il massimo valore aziendale prima, riducendo al minimo il rischio e la complessità?

Nexus Sprint Planning

Nexus Sprint Planning è costituito da:

  • ⇒ Convalida del product Backlog. I team Scrum esaminano i PBI e apportano le modifiche necessarie per il lavoro dall’evento di perfezionamento. Tutti i team Scrum dovrebbero partecipare e contribuire a ridurre al minimo i problemi di comunicazione; tuttavia, solo i rappresentanti appropriati (coloro che ritengono di poter dare un contributo al perfezionamento dei PBI) di ciascuno dei team Scrum devono partecipare.
  • ⇒ Formulare l’obiettivo Nexus. L’obiettivo Nexus è un obiettivo Sprint che viene raggiunto attraverso l’implementazione di PBI da più team.
  • ⇒ Scrum squadra Sprint Pianificazione. Una volta compreso l’obiettivo Nexus per lo Sprint, ogni team Scrum condurrà i propri eventi di pianificazione Sprint individuali in cui i membri creano i propri Backlog Sprint. Quando identificano le dipendenze con altri team, lavorano con tali team per ridurre al minimo o eliminare le dipendenze. La maggior parte della pianificazione Sprint dovrebbe prendere 8 ore.

In alcuni casi, ciò significa che la sequenza di lavoro tra i team potrebbe dover essere regolata per consentire a un team di terminare il proprio lavoro prima che un altro inizi.

Nexus Daily Scrum

Nexus Daily Scrum meeting comprende le domande principali:

  • ⇒ Il lavoro del giorno precedente è stato integrato con successo, e se no, perché?
  • ⇒ Sono state identificate nuove dipendenze?
  • ⇒ Quali informazioni devono essere condivise tra i team del Nexus?

In genere si svolge allo stesso tempo e luogo.

Nexus Sprint Review

La Sprint Review include i seguenti elementi:

  • ⇒ I partecipanti includono i team Scrum e le principali parti interessate invitate dal Product Owner;
  • ⇒ Il Product Owner spiega quali elementi del Product Backlog sono stati” Fatti “e cosa non è stato”Fatto”;
  • ⇒ I team di sviluppo discutono cosa è andato bene durante lo Sprint, quali problemi ha incontrato e come questi problemi sono stati risolti;
  • ⇒ I team di sviluppo dimostrano il lavoro che ha “fatto” e rispondono alle domande sull’incremento;
  • ⇒ Il Product Owner discute il Product Backlog così com’è. Lui o lei progetti probabile target e date di consegna in base ai progressi fino ad oggi (se necessario);
  • ⇒ L’intero gruppo collabora su cosa fare dopo in modo che la revisione Sprint fornisce prezioso input per la successiva pianificazione Sprint;
  • ⇒ Revisione di come potrebbe essere cambiato il marketplace o il potenziale utilizzo del prodotto qual è la cosa più preziosa da fare dopo;
  • ⇒ Revisione della timeline, budget, potenziali funzionalità e marketplace per le prossime versioni previste di funzionalità o capacità del prodotto.

Il risultato della revisione Sprint è un Product Backlog rivisto che definisce gli elementi probabili del Product Backlog per lo Sprint successivo. Il Product Backlog può anche essere adeguato in generale per soddisfare nuove opportunità.

Questa attività non deve richiedere più di 3 ore per essere completata.

Riunione retrospettiva Nexus

5.1. NIT Retrospective

Poiché ci sono disfunzioni di ridimensionamento comuni, ogni retrospettiva dovrebbe rispondere alle seguenti domande.

  • ⇒ Hanno raggiunto l’obiettivo Nexus? Se no, perché no?
  • ⇒ Qualche lavoro è stato lasciato annullato? Il Nexus ha generato debito tecnico?
  • ⇒ Erano tutti gli artefatti, in particolare il codice, frequentemente (idealmente, continuamente) e integrati con successo?
  • ⇒ Il software è stato costruito, testato e distribuito con successo abbastanza spesso da prevenire l’accumulo travolgente di dipendenze irrisolte?

Quando vengono rilevati problemi, i rappresentanti devono chiedere:

  • ⇒ Perché è successo?
  • ⇒ Come può essere risolto il problema?
  • ⇒ Come si può prevenire la ricorrenza?

Dopo la riunione retrospettiva Nexus, è importante definire gli elementi di azione su cui lavorare all’interno di tutti i team Scrum. Il NIT deve tenere traccia di tali elementi e può utilizzare una tabella qui sotto.

Elementi di azione DevCom Nexus

5.2. Scrum Team Retrospettiva

Ogni Scrum team può utilizzare una scheda per visualizzare gli elementi su cui è necessario lavorare. Oltre a ciò, si raccomanda di tenere formalmente traccia di tali record in modo strutturato. Al massimo, ci vogliono 4 ore per discutere con il team come è andato uno Sprint.

Scrum teams Retrospective

Product Owner

Il Product Owner è responsabile della massimizzazione del valore del prodotto.

Il Product Owner è l’unico responsabile della gestione del Product Backlog. Product Backlog di gestione include:

  • ⇒ Chiaramente esprimere Product Backlog elementi;
  • ⇒ Ordinare gli elementi del Product Backlog raggiungere al meglio gli obiettivi e missioni;
  • ⇒ Ottimizzare il valore del lavoro che i Nexus Team esegue;
  • ⇒ Garantire che il Product Backlog è visibile, trasparente e chiaro a tutti, e mostra ciò che Mischia le squadre di lavoro su avanti;
  • ⇒ Garantire che i team Scrum comprendano gli elementi del Product Backlog al livello necessario;
  • ⇒ Definire l’obiettivo Nexus per ogni Sprint (simile a milestone).

Il proprietario del prodotto può eseguire il lavoro di cui sopra o farlo eseguire dal team Nexus. Tuttavia, il proprietario del prodotto rimane responsabile.

Key Takeaways

  1. Scaled Agile funziona e l’utilizzo di un framework di scaling ti aiuta a iniziare rapidamente.
  2. Scaling Scrum è solo Scrum. Non cambi il modo in cui lavori come Scrum team né cambi il lavoro che viene consegnato.
  3. Aggiungendo il framework Nexus a Scrum, fornisce ai team un modo per gestire le dipendenze tra team e garantire che lavorino tutti insieme verso un obiettivo comune e un incremento del prodotto.
  4. Se conosci Scrum davvero bene, il framework Nexus è il framework “non-brainer” per ridimensionare i team di sviluppo software e potresti non aver mai bisogno di nient’altro.
  5. Nexus è un utile framework di discussione per coloro che hanno già diversi team Scrum in atto che funzionano insieme.
  6. In alternativa, se vuoi descrivere il tuo processo, il framework Nexus è un buon punto di partenza in modo da non perdere alcuna prospettiva.
  7. Come sempre, quando si tratta di scalare agile, ricorda queste tre cose importanti:
  • ⇒ Adatta il metodo per adattarlo alla tua organizzazione.
  • ⇒ Riflettere costantemente sulla situazione.
  • ⇒ Migliorare il modo di lavorare insieme.

Hai altri suggerimenti per le tecniche “oltre la squadra”? Vuoi aiutare a implementare queste idee?

Dal 2000, DevCom ha adattato metodologie Agili standard di settore progettate per creare soluzioni tempestive, efficaci ed efficienti per raggiungere gli obiettivi dei nostri clienti. Queste metodologie rappresentano un modello di sviluppo iterativo in cui lo sforzo complessivo è suddiviso in più versioni al fine di raggiungere gli obiettivi delineati per una particolare fase. Abbiamo messo molta enfasi su tre elementi del ciclo di vita dello sviluppo: valutazione iniziale del progetto e pianificazione, gestione del progetto di qualità, garanzia della qualità.

Il nostro approccio di sviluppo riduce i rischi del progetto e lavora per controllare il time-to-market e il budget. Condividiamo questa esperienza e conoscenza con i nostri nuovi clienti in modo che tutti possano avere successo durante il ridimensionamento.

Ottenere risultati migliori attraverso il lavoro di squadra: Contattaci a DevCom oggi!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.