Guida a Nexus La guida definitiva a Scrum su larga scala con Nexus: Le regole del gioco - AWS

Pagina creata da Alice Bucci

Computer e tecnologie

Italiano

Piace
Condividi
Incorpora
Schermo intero
Diapositive
Scarica HTML
Scarica PDF
Abuso

←

CONTINUA A LEGGERE

→

Trascrizione del contenuto della pagina

Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù

Guida a Nexus La guida definitiva a Scrum su larga scala con Nexus: Le regole del gioco - AWS

Guida a Nexus™
La guida definitiva a Scrum su larga scala con Nexus:
                 Le regole del gioco

                        Gennaio 2018

                Sviluppata e mantenuta da Ken Schwaber e Scrum.org

                        Italiano / Italian

0

Sommario
Italiano / Italian....................................................................................................................................... 0
Introduzione a Nexus ...................................................................................................................................... 2
Scopo della Guida a Nexus........................................................................................................................... 2
Definizione di Nexus .................................................................................................................................... 2
Motivazioni di Nexus ................................................................................................................................... 2
Il framework Nexus ..................................................................................................................................... 3
Il processo di Nexus ..................................................................................................................................... 4
Nexus .............................................................................................................................................................. 5
I ruoli di Nexus ............................................................................................................................................ 5
Nexus Integration Team .......................................................................................................................... 5
Il Product Owner nel Nexus Integration Team ......................................................................................... 6
Lo Scrum Master nel Nexus Integration Team ......................................................................................... 6
I membri del Nexus Integration Team...................................................................................................... 6
Gli eventi di Nexus....................................................................................................................................... 7
Raffinamento (Refinement) ..................................................................................................................... 7
Nexus Sprint Planning ............................................................................................................................. 7
Nexus Sprint Goal.................................................................................................................................... 8
Nexus Daily Scrum................................................................................................................................... 8
Nexus Sprint Review................................................................................................................................ 8
Nexus Sprint Retrospective ..................................................................................................................... 9
Gli artefatti di Nexus.................................................................................................................................. 10
Product Backlog .................................................................................................................................... 10
Nexus Sprint Backlog ............................................................................................................................. 10
Incremento Integrato ............................................................................................................................ 10
Trasparenza degli artefatti......................................................................................................................... 10
Definizione di “Fatto” ............................................................................................................................ 11
Conclusioni ................................................................................................................................................ 11
Ringraziamenti .......................................................................................................................................... 11
Ringraziamenti per la traduzione ............................................................................................................... 11
Modifiche tra le versioni del 2015 e del 2018 della guida a Nexus .............................................................. 12

2018 Scrum.org. Offered for license under the Offered for license under the Attribution Share Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at
http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Nexus Guide, you acknowledge and agree that you have read
and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Page 1

Introduzione a Nexus

Scopo della Guida a Nexus
Nexus è un framework per lo sviluppo e il mantenimento di prodotti software in scala. Nexus usa Scrum
come base. Questa guida contiene la definizione di Nexus. Questa definizione comprende i ruoli di
Nexus, gli eventi, gli artefatti e le regole che li fanno funzionare. Ken Schwaber e Scrum.org hanno
sviluppato Nexus. La guida a Nexus è stata scritta e resa disponibile da loro.

Definizione di Nexus
Nexus (s. m.): una relazione o connessione tra persone o cose

Nexus è un framework che include ruoli, eventi, artefatti e tecniche che consentono a molteplici Scrum
Team (da tre a nove) di lavorare insieme. Diversi Scrum Team lavorano con un singolo Product Backlog
per sviluppare un Incremento Integrato che soddisfi un obiettivo prefissato.

Motivazioni di Nexus
Lo sviluppo software è un lavoro complesso. La sua integrazione in software funzionante necessita di
una attenta organizzazione di tutti gli artefatti e le attività necessarie per ottenere un risultato che può
essere considerato “Fatto”. Le dipendenze devono essere risolte e i risultati devono essere preparati per
l’installazione su ambienti di staging. Inoltre i prodotti software pongono difficoltà aggiuntive perché
non sono presenti fisicamente.

Molti sviluppatori software usano il framework Scrum per lavorare collettivamente allo sviluppo di un
Incremento di software funzionante. Tuttavia, diverse difficoltà possono presentarsi quando più di uno
Scrum Team lavora con lo stesso Product Backlog e con lo stesso codice sorgente di un prodotto. Se gli
sviluppatori non fanno parte dello stesso team, come comunicano possibili dipendenze emerse dal loro
lavoro? Se lavorano in team diversi, come integrano e testano il corretto funzionamento dell’Incremento
Integrato? Queste difficoltà si presentano quando il lavoro di due team deve essere integrato e
aumentano significativamente con tre o più team.

Molte sono le dipendenze presenti tra il lavoro di più team che collaborano per creare almeno un
incremento completo e “Fatto” per ogni Sprint. Queste dipendenze sono correlate ai seguenti punti:

1. Requisiti: La portata dei requisiti potrebbe sovrapporsi e la loro implementazione
potrebbe generare conflitti. Questo deve essere considerato quando i requisiti
contenuti nel Product Backlog vengono prioritizzati e selezionati per lo sviluppo.

Page 2

2. Conoscenza di dominio: I membri dei team hanno conoscenze di diversi sistemi
informatici e di business. Queste conoscenze devono essere mappate negli Scrum Team
per assicurare la loro adeguatezza e anche per minimizzare interruzioni tra i team
durante uno Sprint.

3. Artefatti software e di test: I requisiti sono o verranno implementati in codice software
e suite di test.

Le dipendenze tra i diversi team sono ridotte nella misura in cui i requisiti, le conoscenze dei membri del
team e gli artefatti di codice e test vengono mappati negli stessi Scrum Team.

Quando lo sviluppo software fatto con Scrum viene scalato, le dipendenze dei requisiti, le conoscenze di
dominio e gli artefatti di software e test dovrebbero guidare l’organizzazione dei team. Nella misura in
cui lo faranno, la produttività verrà ottimizzata.

Il framework Nexus
Nexus struttura il lavoro di molteplici Scrum Team uniti per creare un Incremento Integrato. Nexus è
coerente con Scrum e le parti che lo compongono risulteranno familiari per coloro che hanno già
lavorato a progetti con Scrum. La differenza è che viene data più attenzione alle dipendenze e
all’interoperabilità tra gli Scrum Team che sviluppano almeno un Incremento Integrato considerato
“Fatto” per ogni Sprint.

ll framework Nexus™, l’esoscheletro di Scrum in scala

Come illustrato nel seguente grafico, Nexus consiste di:

• Ruoli: Un nuovo ruolo, il Nexus Integration Team, esiste per coordinare, istruire e
supervisionare l’applicazione di Nexus e l’operatività di Scrum così da ottenere i migliori
2018 Scrum.org. Offered for license under the Offered for license under the Attribution Share Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at
http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Nexus Guide, you acknowledge and agree that you have read
and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Page 3

risultati. Il Nexus Integration Team include un Product Owner, uno Scrum Master e i membri
del Nexus Integration Team.

• Artefatti: Tutti gli Scrum Team usano un unico Product Backlog. Non appena gli elementi del
Product Backlog sono pronti per lo sviluppo, viene visualizzato, attraverso degli indicatori,
quale team eseguirà il lavoro durante uno Sprint. Un nuovo artefatto, il Nexus Sprint
Backlog, esiste per supportare la trasparenza durante lo Sprint. Tutti gli Scrum Team
mantengono i loro Sprint Backlog individuali.

• Eventi: Gli eventi avvengono dopo, contengono o sostituiscono (nel caso dell’incontro di
Sprint Review) gli eventi di Scrum. Così modificati, questi eventi servono sia lo sforzo
comune di tutti gli Scrum Team di un Nexus sia quello individuale di ogni team.

Il processo di Nexus
Un Nexus è formato da diversi Scrum Team cross-funzionali che lavorano insieme per lo sviluppo e la
potenziale release di almeno un Incremento Integrato per ogni Sprint. A seconda delle dipendenze, i
team possono auto-organizzarsi e selezionare i membri più appropriati per eseguire del lavoro specifico.

• Perfezionare il Product Backlog: Il Product Backlog deve essere decomposto così da
identificare, rimuovere o minimizzare le dipendenze. Gli elementi del Product Backlog
vengono suddivisi in piccole parti e il team più adatto a eseguire la loro implementazione
dovrebbe essere identificato il prima possibile.

• Nexus Sprint Planning: I rappresentanti più appropriati di ogni Scrum Team si incontrano
per discutere e revisionare il Product Backlog e per selezionare elementi del Product Backlog
per i diversi team. Ogni Scrum Team può poi pianificare il suo Sprint interagendo con gli altri
team quando necessario. Il risultato è un insieme di Sprint Goal allineati con il Nexus Goal
globale, con lo Sprint Backlog di ogni Scrum Team e con un unico Nexus Sprint Backlog
comune. Il Nexus Sprint Backlog rende trasparenti gli elementi del Product Backlog
selezionati da uno Scrum Team e le loro possibili dipendenze.

• Lavoro di sviluppo: Tutti i team sviluppano software e integrano il loro lavoro
frequentemente in un ambiente comune dove questo può essere testato per assicurare che
l’integrazione funzioni correttamente.

• Nexus Daily Scrum: I rappresentanti più appropriati di ogni Scrum Development Team si
incontrano giornalmente per controllare se esistono dei problemi di integrazione. Quando
identificati vengono riportati durante il Daily Scrum di ogni Scrum Team. Gli Scrum Team
possono quindi usare il Daily Scrum per creare un piano giornaliero, assicurandosi di
affrontare i problemi di integrazione riscontrati durante il Nexus Daily Scrum.

Page 4

• Nexus Sprint Review: Questo incontro si tiene alla fine dello Sprint per fornire del feedback
sull’Incremento Integrato che un Nexus ha sviluppato durante lo Sprint. Tutti i singoli Scrum
Team si incontrano con gli stakeholder per revisionare l’Incremento Integrato. Il Product
Backlog può essere adattato se necessario.

• Nexus Sprint Retrospective: I rappresentanti più appropriati di ogni Scrum Team si
incontrano per individuare problemi comuni. Dopodiché ogni Scrum Team tiene il proprio
incontro di Sprint Retrospective. I rappresentati più appropriati di ogni team si incontrano di
nuovo per discutere qualsiasi azione necessaria per affrontare problemi comuni e fornire
informazioni bottom-up.

Nexus
I ruoli di Nexus, i suoi eventi e i suoi artefatti ereditano lo scopo e gli intenti dei rispettivi ruoli, eventi e
artefatti di Scrum, così come documentato nella “Guida a Scrum” (www.scrumguides.org).

I ruoli di Nexus
Un Nexus consiste in un Nexus Integration Team e approssimativamente da tre a nove Scrum Team.

Nexus Integration Team

Il Nexus Integration Team è responsabile di assicurare che almeno un Incremento Integrato (il lavoro
combinato completato da un Nexus) venga prodotto per ogni Sprint. Gli Scrum Team sono responsabili
per lo sviluppo e la potenziale release di Incrementi di software , come prescritto da Scrum. Tutti i ruoli
per membri degli Scrum Team sono prescritti nella Guida a Scrum.

Il Nexus Integration Team è formato da:

• Il Product Owner

• Uno Scrum Master

• Uno o più membri del Nexus Integration Team

Membri del Nexus Integration Team possono anche lavorare negli Scrum Team in un Nexus. Se questo
avviene, la priorità viene comunque data sempre al lavoro fatto per il Nexus Integration Team.
L’appartenenza ad un Nexus Integration Team prende precedenza sull’appartenenza ai singoli Scrum
Team. Questa preferenza aiuta ad assicurare che il lavoro di risoluzione di problemi che colpiscono
diversi team abbia la priorità.

Page 5

La composizione del Nexus Integration Team può cambiare col tempo per rispecchiare le necessità
correnti di un Nexus. Le attività comuni eseguite dal Nexus Integration Team possono includere il
coaching, la consulenza, l’identificazione di dipendenze e di problemi cross-team. Il Nexus Integration
Team può anche eseguire del lavoro contenuto nel Product Backlog.

Gli Scrum Team risolvono problemi di integrazione all’interno di un Nexus. Il Nexus Integration Team
rappresenta un punto focale per l’integrazione di un Nexus. L’integrazione include la risoluzione di
qualsiasi costrizione cross-team tecnica e non-tecnica che possa ostacolare l’abilità di un Nexus di
produrre costantemente un Incremento Integrato. Questi possono usare le informazioni bottom-up del
Nexus per raggiungere una soluzione.

Il Product Owner nel Nexus Integration Team

Un Nexus lavora usando un unico Product Backlog e, come descritto nel framework Scrum, un Product
Backlog ha un unico Product Owner che ha l’ultima parola sui suoi contenuti. Il Product Owner è
responsabile per la massimizzazione del valore del prodotto e del lavoro eseguito e integrato dagli
Scrum Team. Il Product Owner fa parte del Nexus Integration Team.

Il Product Owner è responsabile per l’ordine e il raffinamento del Product Backlog, così da raggiungere il
massimo valore possibile da un Incremento Integrato realizzato da un Nexus. Il modo in cui questo viene
fatto può variare di molto a seconda dell’organizzazione, del Nexus, dello Scrum Team o delle singole
persone.

Lo Scrum Master nel Nexus Integration Team

Lo Scrum Master nel Nexus Integration Team ha la responsabilità complessiva di assicurare che il Nexus
framework venga capito ed eseguito correttamente. Lo Scrum Master del Nexus può anche essere lo
Scrum Master di uno o più Scrum Team facenti parte del Nexus stesso.

I membri del Nexus Integration Team

Il lavoro di sviluppo in scala necessità di strumenti e pratiche che i singoli Scrum Team di solito non
utilizzano frequentemente. Il Nexus Integration Team comprende professionisti del software che
posseggono abilità per l’utilizzo di queste pratiche, strumenti, e nel campo generale dell’ingegneria dei
sistemi. I membri del Nexus Integration Team devono assicurarsi che le pratiche e gli strumenti vengano
implementati, capiti e usati per individuare dipendenze e integrare frequentemente tutti gli artefatti in
una definizione di “Fatto.”

I membri del Nexus Integration Team sono responsabili della guida degli Scrum Team in un Nexus
durante l’acquisizione, l’implementazione e l’apprendimento di queste pratiche e strumenti. Forniscono
inoltre attività di coaching agli Scrum Team su necessari standard di sviluppo, infrastruttura o
architettura del software richiesti dall’organizzazione al fine di assicurare lo sviluppo di Incrementi
Integrati di qualità.

Page 6

Se la loro responsabilità primaria viene portata a termine, i membri del Nexus Integration Team possono
anche lavorare come membri del team di sviluppo di uno o più Scrum Team.

Gli eventi di Nexus
La durata degli eventi di Nexus si basa sulla durata dei corrispettivi eventi nella “Guida a Scrum”. La loro
durata viene sommata a quella dei corrispettivi eventi di Scrum.

Raffinamento (Refinement)

Il Raffinamento su larga scala del Product Backlog ha un doppio scopo. Aiuta gli Scrum Team a prevedere
quale team produrrà quali elementi del Product Backlog e a identificare le dipendenze tra i team stessi.
Questa trasparenza permette a i team di monitorare e minimizzare le dipendenze.

Il Raffinamento degli elementi del Product Backlog da parte del Nexus continua fino a che gli elementi
sono adeguatamente indipendenti in modo che un singolo Scrum Team possa eseguirne il lavoro senza
eccessivi conflitti.

Il numero, la frequenza, la durata e la partecipazione al Raffinamento si basa sulle dipendenze ed
incertezze inerenti nel Product Backlog. Gli elementi del Product Backlog passano attraverso diversi
livelli di decomposizione, da molto grandi e richieste vaghe, a lavoro eseguibile da un singolo Scrum
Team all’interno di uno Sprint.

Il Raffinamento può avvenire in maniera continua durante lo Sprint come necessario e appropriato. Il
raffinamento del Product Backlog continuerà all’interno di ogni Scrum Team in modo tale che gli
elementi del Product Backlog siano pronti per essere selezionati durante l’incontro di Nexus Sprint
Planning.

Nexus Sprint Planning

Lo scopo dell’incontro di Nexus Sprint Planning è quello di coordinare le attività di tutti gli Scrum Team
in un Nexus per un unico Sprint. Il Product Owner fornisce conoscenza di dominio e guida le decisioni di
selezione e prioritizzazione.

Durante l’incontro di Nexus Sprint Planning, i rappresentanti più appropriati di ogni Scrum Team
convalidano e ordinano il lavoro così come definito durante gli eventi di Raffinamento (Refinement).
Tutti i membri degli Scrum Team dovrebbero partecipare per minimizzare problemi di comunicazione.

Il Product Owner discute il Nexus Sprint Goal durante l’incontro di Nexus Sprint Planning. Il Nexus Sprint
Goal descrive cosa sarà raggiunto dagli Scrum Team durante lo Sprint. Dopo che il lavoro complessivo
del Nexus è stato compreso da tutti i presenti, ogni Scrum Team prende parte al proprio incontro di
Sprint Planning. Gli Scrum Team devono continuare a condividere nuove dipendenze emerse durante i

Page 7

loro incontri separati. L’incontro di Nexus Sprint Planning si conclude quando ogni Scrum Team ha
concluso i propri eventi di Sprint Planning individuali.

Se nuove dipendenze emergono durante l’incontro di Nexus Sprint Planning devono essere visualizzate e
ridotte. La sequenza del lavoro tra i team può anche essere adattata. Un Product Backlog che è
adeguatamente raffinato minimizzerà l’emergenza di nuove dipendenze durante l’incontro di Nexus
Sprint Planning. Tutti gli elementi del Product Backlog selezionati per lo Sprint e le loro dipendenze
dovrebbero essere visualizzate nel Nexus Sprint Backlog.

Nexus Sprint Goal

Il Nexus Sprint Goal è un obbiettivo per lo Sprint. É la somma di tutto il lavoro e degli Sprint Goal degli
Scrum Team all’interno del Nexus. Il Nexus dovrebbe dimostrare, durante la Nexus Sprint Review, la
funzionalità che ha sviluppato secondo la definizione di “Fatto” per raggiungere il Nexus Sprint Goal, così
da poter ricevere feedback dagli stakeholder.

Nexus Daily Scrum

Il Nexus Daily Scrum è un evento per i rappresentanti più appropriati di ogni singolo team di sviluppo
finalizzato a ispezionare lo stato attuale dell’Incremento Integrato e a identificare problemi di
integrazione o nuove dipendenze cross-team o impatti cross-team.

Durante l’incontro di Nexus Daily Scrum, i partecipanti dovrebbero concentrarsi sull’impatto di ciascun
team all’Incremento Integrato e discutere i seguenti punti:

• Il lavoro del giorno precedente è stato integrato con successo? Se no, perché?

• Quali nuove dipendenze o impatti sono stati identificate?

• Che tipo di informazione deve essere condivisa tra i team in un Nexus?

I team di sviluppo usano il Nexus Daily Scrum per ispezionare il progresso verso il Nexus Sprint Goal.
Almeno durante ogni Nexus Daily Scrum, il Nexus Sprint Backlog dovrebbe essere adattato per
rispecchiare l’attuale conoscenza dello stato del lavoro degli Scrum Team all’interno del Nexus.

Ogni Scrum Team riporta i problemi e lavoro identificati durante il Nexus Daily Scrum all’interno dei
propri team per la pianificazione durante i loro eventi di Daily Scrum.

Nexus Sprint Review

L’incontro di Nexus Sprint Review si tiene alla fine dello Sprint per fornire feedback sull’Incremento
Integrato che un Nexus ha sviluppato durante lo Sprint.

Un incontro di Nexus Sprint Review sostituisce le riunioni individuali di Sprint Review di ogni Scrum
Team, perché l’intero Incremento Integrato è il focus dell’acquisizione di feedback da parte degli

Page 8

stakeholder. Potrebbe non essere possibile mostrare tutto il lavoro completato nel dettaglio. Tecniche
specifiche potrebbero risultare necessarie per massimizzare il feedback da parte degli stakeholder. Il
risultato del Nexus Sprint Review è un Product Backlog adattato.

Nexus Sprint Retrospective

L’incontro di Nexus Sprint Retrospective è un’opportunità formale per l’ispezione, l’adattamento e per
creare un piano di miglioramenti da eseguire durante il prossimo Sprint per assicurare il miglioramento
continuo (continuous improvement). La Nexus Sprint Retrospective si tiene dopo la Nexus Sprint Review
e prima del successivo Nexus Sprint Planning.

Consiste di tre parti:

1. La prima parte è un’opportunità per i rappresentanti più appropriati di ogni team di un
Nexus di incontrarsi e identificare i problemi che hanno influito su più di un team. Lo
scopo è quello di rendere i problemi condivisi trasparenti a tutti gli Scrum Team.

2. La seconda parte consiste nell’incontro di Sprint Retrospective individuale di ogni Scrum
Team, così come descritto nel framework Scrum. Si possono usare problemi riscontrati
durante la prima parte dell’incontro di Nexus Retrospective come input per le
discussioni dei team. Ogni Scrum Team dovrebbe proporre soluzioni a questi problemi
durante l’incontro di Sprint Retrospective individuale del loro Scrum Team.

3. La terza e ultima parte è un’opportunità per i rappresentanti più appropriati di ogni
Scrum Team di incontrarsi di nuovo e mettersi d’accordo su come visualizzare e
monitorare le azioni identificate. Questo permette l’adattamento complessivo del
Nexus.

I seguenti punti dovrebbero essere affrontati durante ogni incontro di Retrospective, perché
rappresentano problemi comuni allo sviluppo in scala:

• È rimasto del lavoro non fatto? È stato generato del debito tecnico dal Nexus?

• Gli artefatti, e in particolare il codice sorgente, sono stati frequentemente integrati (almeno
una volta al giorno) con successo?

• Il software è stato sviluppato, testato e installato con successo così da prevenire un numero
insostenibile di dipendenze irrisolte?

Per le domande appena citate, affrontare se necessario:

• Perché questo è successo?

Page 9

• Come possiamo rimuovere il debito tecnico?

• Come possiamo evitare che questo accada di nuovo?

Gli artefatti di Nexus
Gli artefatti rappresentano lavoro o valore per fornire trasparenza e opportunità di ispezione e
adattamento, così come descritto nella Guida a Scrum.

Product Backlog

C’è un solo Product Backlog per l’intero Nexus e tutti i suoi Scrum Team. Il Product Owner è responsabile
per il Product Backlog, compresa la sua disponibilità, i suoi contenuti e il loro ordinamento.

Su larga scala, il Product Backlog deve essere capito a un livello dove le dipendenze possono essere
individuate e minimizzate. Per supportare la risoluzione, gli elementi del Product Backlog sono risolti a
un livello di granularità della funzionalità definito “diviso finemente” (thinly sliced). Gli elementi del
Product Backlog sono considerati “Pronti” per l’incontro di Nexus Sprint Planning quando possono
essere selezionati per lo sviluppo dagli Scrum Team con nessuna o minime dipendenze con gli altri
Scrum Team.

Nexus Sprint Backlog

Un Nexus Sprint Backlog è composto da tutti gli elementi del Product Backlog presi dagli Sprint Backlog
di ogni Scrum Team. Questo viene usato per evidenziare le dipendenze e il flusso di lavoro durante lo
Sprint e viene aggiornato almeno una volta al giorno, spesso come parte del Nexus Daily Scrum.

Incremento Integrato

L’Incremento Integrato rappresenta la somma attuale di tutto il lavoro integrato completato da un
Nexus. L’Incremento Integrato deve essere usabile e potenzialmente pronto per una release, ovvero
deve soddisfare la definizione di “Fatto”. L’Incremento Integrato viene ispezionato durante l’incontro di
Nexus Sprint Review.

Trasparenza degli artefatti
Proprio come il framework su cui è fondato, Scrum, Nexus si basa sulla trasparenza. Il Nexus Integration
Team lavora con gli Scrum Team all’interno di un Nexus e dell’organizzazione per assicurare che la
trasparenza sia presente tra tutti gli artefatti e che lo stato integrato dell’Incremento sia ampiamente
compreso.

Page 10

L’efficacia delle decisioni prese in base allo stato degli artefatti del Nexus dipende dal livello di
trasparenza degli stessi artefatti. Informazioni incomplete o parziali porteranno a decisioni sbagliate o
imperfette. L’impatto di queste decisioni può essere amplificato su larga scala nel Nexus. Il software
deve essere sviluppato in modo tale che le dipendenze possano essere identificate e risolte prima che il
debito tecnico (technical debt) diventi inaccettabile per il Nexus. La mancanza di completa trasparenza
renderà impossibile la guida efficiente di un Nexus per minimizzare i rischi e massimizzare il valore.

Definizione di “Fatto”

Il Nexus Integration Team è responsabile per una definizione di “Fatto” che può essere applicata
all’Incremento Integrato sviluppato per ogni Sprint. Tutti gli Scrum Team di un Nexus aderiscono a
questa definizione di “Fatto”. L’Incremento viene considerato “Fatto” solo quando è integrato, usabile e
potenzialmente pronto per una release approvata dal Product Owner.

Ogni Scrum Team può scegliere di applicare una definizione di “Fatto” più stringente all’interno del
proprio team, ma non si possono applicare criteri meno rigorosi di quelli concordati per l’Incremento.

Conclusioni
Nexus è gratis e offerto in questa Guida. Così come nel framework Scrum, i ruoli, gli artefatti, gli eventi e
le regole di Nexus sono immutabili. Sebbene sia possibile implementare solo alcune parti di Nexus, il
risultato non sarà Nexus.

Ringraziamenti
Nexus e Scaled Professional Scrum sono stati sviluppati in collaborazione da Ken Schwaber, David Dame,
Richard Hundhausen, Patricia Kong, Rob Maher, Steve Porter, Christina Schwaber e Gunther Verheyen.

Ringraziamenti per la traduzione
Traduttori: Francesco Macri, Amin Al Hazwani

Contatto email principale: francesco.macri1986@gmail.com

Page 11

Modifiche tra le versioni del 2015 e del 2018 della guida a Nexus
1. Aggiornata la descrizione della Guida a Nexus da “L’esoscheletro dello sviluppo in scala con Scrum” a
“La guida definitiva a Scrum su larga scala con Nexus: Le regole del gioco”.
2. Nexus definito come “una relazione o connessione tra persone o cose.”
3. Nella sezione “Il processo di Nexus”, il testo è stato cambiato per accentuare il focus sui team
piuttosto che su i membri individuali, “Un Nexus è formato da diversi Scrum Team cross-funzionali
che lavorano insieme per lo sviluppo e la potenziale release di almeno un Incremento Integrato per
ogni Sprint.”. Anche aggiunto che A seconda delle dipendenze, i team possono auto-organizzarsi e
selezionare i membri più appropriati per eseguire del lavoro specifico.
4. Fatto più chiarezza sul ruolo del Nexus Integration Team
a. Il Nexus Integration Team spesso è composto da membri degli Scrum Team del Nexus.
Questa composizione supporta la necessità di informazioni bottom-up dagli Scrum Team
individuali all’interno del Nexus.
b. Il Nexus Integration Team non si occupa dell’integrazione personalmente. I singoli Scrum
Team eseguono il lavoro necessario per l’integrazione.
c. Rimossa la definizione che un Nexus Integration Team è uno Scrum Team, perché lasciava
intendere erroneamente che il Nexus Integration Team fosse permanentemente uno Scrum
Team separato all’interno del Nexus.
5. Nella sezione “Gli eventi di Nexus”, la descrizione del Raffinamento (Refinement) è stata spostata
prima della descrizione del Nexus Sprint Planning.
a. Il Raffinamento non è più prescritto come diviso in due parti. Il linguaggio si concentra sulla
trasparenza piuttosto che sulla visualizzazione.
b. Rimosso la descrizione di Raffinamento come “meeting” e descritto solo come
“Raffinamento”.
c. Insistenza sul fatto che il Raffinamento possa essere continuo durante lo Sprint come
necessario ed appropriato.
6. Il Nexus Goal non è specificato come input o output del Nexus Sprint Planning perché questo può
variare, ma piuttosto è descritto come un obbiettivo che il Product Owner discute durante l’incontro
di Nexus Sprint Planning. Rimosso la parte di testo sulla necessità che questo incontro sia tenuto in
un spazio condiviso da tutti gli Scrum Team del Nexus.
a. Il Nexus Goal viene ora chiamato Nexus Sprint Goal e non è più descritto come un nuovo
artefatto, in modo da essere consistenti con lo Scrum Framework.
b. Rimosso dall’sommario
7. Il Nexus Daily Scrum è un opportunità per i team di controllare, a parte le dipendenze cross-team,
anche gli impatti cross-team.
a. Il Nexus Daily Scrum non è la sola occasione dove il Nexus Sprint Backlog dovrebbe essere
adattato. Ma questo è il momento minimo necessario per adattare il Nexus Sprint Backlog in
modo da rispecchiare l’attuale conoscenza dello stato del lavoro e delle dipendenze tra i
team.
b. Il Nexus Daily Scrum è quando i team di sviluppo in un Nexus ispezionano il prograsso verso
il Nexus Sprint Goal.
8. La Nexus Sprint Review non è un incontro di “mostra e racconta”, così come non lo è in Scrum –
aggiunto del testo che spiega come questo sia anche un opportunità per adattare il Product Backlog
se necessario. Inoltre del testo, che spiega la necessità di fornire del feedback durante la Nexus
Sprint Review, è stato aggiunto alla sezione “Il processo di Nexus” nella parte dedicata alla stessa.

Page 12

9. Aggiunto che la Nexus Sprint Retrospective è un opportunità formale per il Nexus di ispezionare e
adattare se stesso e per creare un piano di miglioramenti da eseguire nello Sprint successivo.
a. Così come nell’aggiornamento della Guida a Scrum, la Nexus Sprint Retrosepctive esiste per
assicurare il miglioramento continuo del Nexus.
10. L’Incremento Integrato rappresenta lo stato attuale del lavoro integrato.
11. La Definizione di “Fatto” specifica che l’Incremento Integrato deve essere integrato.
12. Nella sezione “Trasparenza degli artefatti”, rimossa la frase “Quando si procede all’integrazione e lo
stato delle dipendenze risolte rimane non chiaro, questo è un segnale che è stato introdotto del
debito tecnico inaccettabile”. Sostituita con “Il software deve essere sviluppato in modo tale che le
dipendenze possano essere identificate e risolte prima che il debito tecnico (technical debt) diventi
inaccettabile per il Nexus.”
13. Rimosso il paragrafo sulle Pratiche Software. Nonostante questo fosse importante e rilevante,
l’argomento dovrebbe essere elaborato maggiormente per aggiungere un qualsiasi tipo di valore al
testo.
14. Aggiunto il testo Creative Commons a piè di pagina.

Page 13

Puoi anche leggere