La Guida a Nexus. La guida definitiva a Nexus: L esoscheletro dello sviluppo in scala con Scrum. Sviluppata e mantenuta da Ken Schwaber e Scrum.

Transcript

1 La Guida a Nexus La guida definitiva a Nexus: L esoscheletro dello sviluppo in scala con Scrum Sviluppata e mantenuta da Ken Schwaber e Scrum.org Agosto 2015

2 Sommario 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 Pratiche software... 5 Nexus...5 I ruoli di Nexus... 5 Nexus Integration Team... 5 Gli eventi di Nexus... 7 Nexus Sprint Planning... 7 Nexus Daily Scrum... 7 Nexus Sprint Review... 8 Nexus Sprint Retrospective... 8 Raffinamento (Refinement)... 9 Gli artefatti di Nexus... 9 Product Backlog Nexus Goal Nexus Sprint Backlog Incremento Integrato Trasparenza degli artefatti Definizione di Fatto Conclusioni Ringraziamenti Traduzione Translated By: Francesco Macri & Amin Al Hazwani Copyright Scrum.org, 2015 Tutti i diritti riservati Pagina 1 (Versione 1.1)

3 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.): Unità di sviluppo (in Scaled Professional Scrum) 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. 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. Copyright Scrum.org, 2015 Tutti i diritti riservati Pagina 2 (Versione 1.1)

4 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. 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 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. Copyright Scrum.org, 2015 Tutti i diritti riservati Pagina 3 (Versione 1.1)

5 Il framework Nexus, l esoscheletro di Scrum in scala Il processo di Nexus Tutto il lavoro in un Nexus può essere eseguito da tutti i membri degli Scrum Team come membri cross-funzionali del Nexus. A seconda delle dipendenze, i team possono 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 Copyright Scrum.org, 2015 Tutti i diritti riservati Pagina 4 (Versione 1.1)

6 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. Nexus Sprint Review: tutti i team incontrano il Product Owner 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. Pratiche software Molte pratiche di sviluppo software sono necessarie per unire il lavoro degli Scrum Team che collaborano al fine di ottenere un Incremento Integrato. Molte di queste pratiche richiedono automazione. L automazione aiuta a gestire il volume e la complessità del lavoro e degli artefatti, specialmente in ambienti in scala. 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. 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 di Incrementi di software potenzialmente rilasciabile, come prescritto da Scrum. Tutti i ruoli per membri degli Scrum Team sono prescritti nella Guida a Scrum. Il Nexus Integration Team è uno Scrum 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, come appropriato e necessario. Se questo avviene, la priorità viene comunque data sempre al lavoro fatto per il Nexus Integration Team. L appartenenza ad un Nexus Integration Team Copyright Scrum.org, 2015 Tutti i diritti riservati Pagina 5 (Versione 1.1)

7 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à. 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. Il Nexus Integration Team si assume la responsabilità di qualsiasi problema di integrazione ed è responsabile per il successo dell integrazione del lavoro eseguito da tutti gli Scrum Team in un Nexus. L integrazione include la risoluzione di qualsiasi costrizione cross-team tecnica e nontecnica che possa ostacolare l abilità di un Nexus di produrre costantemente un Incremento Integrato. Il Nexus Integration Team può 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à. Copyright Scrum.org, 2015 Tutti i diritti riservati Pagina 6 (Versione 1.1)

8 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. 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. Per iniziare 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 Nexus Sprint Goal viene definito durante l incontro di Nexus Sprint Planning. Esso 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. Se l incontro ha luogo in uno spazio comune, i team possono continuare a condividere nuove dipendenze emerse durante i loro incontri separati. L incontro di Nexus Sprint Planning 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. Il Product Backlog dovrebbe essere adeguatamente raffinato con le dipendenze identificate, rimosse o minimizzate prima dell incontro di Nexus Sprint Planning. Nexus Daily Scrum Il Nexus Daily Scrum è un evento per i rappresentanti più appropriati di ogni singolo Scrum Development Team finalizzato a ispezionare lo stato attuale dell Incremento Integrato e a identificare problemi di integrazione o nuove dipendenze cross-team. Durante l incontro di Nexus Daily Scrum, i partecipanti dovrebbero concentrarsi sul contributo di ciascun team all Incremento Integrato e discutere i seguenti punti: Copyright Scrum.org, 2015 Tutti i diritti riservati Pagina 7 (Versione 1.1)

9 Il lavoro del giorno precedente è stato integrato con successo? Se no, perché? Quali nuove dipendenze sono state identificate? Che tipo di informazione deve essere condivisa tra i team in un Nexus? Durante l incontro del Nexus Daily Scrum, il Nexus Sprint Backlog dovrebbe essere usato per visualizzare e gestire le dipendenze attuali. Il lavoro che viene identificato durante l incontro del Nexus Daily Scrum viene riportato a ogni Scrum Team per la pianificazione all interno dei 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 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. Nexus Sprint Retrospective L incontro di Nexus Sprint Retrospective è un opportunità formale per concentrarsi sull ispezione e l adattamento. 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? Copyright Scrum.org, 2015 Tutti i diritti riservati Pagina 8 (Versione 1.1)

10 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? Come possiamo rimuovere il debito tecnico? Come possiamo evitare che questo accada di nuovo? Raffinamento (Refinement) Al livello del Nexus ci sono molti livelli di raffinamento. Solo quando gli elementi del Product Backlog sono adeguatamente indipendenti possono essere selezionati e lavorati senza conflitti eccessivi tra gli Scrum Team in un Nexus. Il numero, la frequenza, la durata e la partecipazione agli incontri di Raffinamento si basa sulle dipendenze inerenti nel Product Backlog. Maggiori sono le complessità e le dipendenze e più gli elementi del Product Backlog devono essere raffinati per rimuoverle. Gli elementi del Product Backlog passano attraverso diversi livelli di decomposizione, da molto estesi e richieste vaghe a lavoro eseguibile da un singolo Scrum Team durante uno Sprint. Il raffinamento del Product Backlog in scala ha un doppio scopo. Prevedere quale team svilupperà quale elemento del Product Backlog e identificare le dipendenze tra questi team. La visualizzazione permette ai team di monitorare e minimizzare le dipendenze. La prima parte dell incontro cross-team di Raffinamento dovrebbe essere utilizzata per decomporre gli elementi del Product Backlog in sufficiente dettaglio da capire quali team possono svilupparli e in che sequenza durante i prossimi Sprint. La seconda parte dell incontro di Raffinamento dovrebbe essere utilizzata per concentrarsi sulle dipendenze. Le dipendenze dovrebbero essere identificate e visualizzate tra i vari team e i diversi Sprint. I team avranno bisogno di queste informazioni per riordinare la sequenza e l assegnazione del loro lavoro in modo tale da minimizzare il numero di dipendenze cross-team. Se gli elementi del Product Backlog sono pronti e selezionabili con dipendenze minime durante l incontro di Sprint Planning significa che sufficienti incontri di Raffinamento sono avvenuti durante uno Sprint. 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. Copyright Scrum.org, 2015 Tutti i diritti riservati Pagina 9 (Versione 1.1)

11 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. In 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 Goal Durante l incontro di Nexus Sprint Planning viene formulato un obiettivo per l intero Sprint. Questo viene chiamato Nexus Goal. È la somma di tutto il lavoro e gli Sprint Goal di ogni Scrum Team dentro al Nexus. Il Nexus dovrebbe dimostrare la funzionalità che questi team hanno sviluppato per raggiungere il Nexus Goal all incontro di Nexus Sprint Review. 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 di tutto il lavoro integrato completato da un Nexus. L Incremento Integrato deve essere usabile e potenzialmente rilasciabile, 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. Un 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. Le decisioni prese in base allo stato degli artefatti del Nexus sono tanto effettive quanto il livello di trasparenza degli stessi artefatti. Informazioni incomplete o parziali porteranno a decisioni sbagliate o imperfette. L impatto di queste decisioni può essere amplificato in scala di Nexus. La Copyright Scrum.org, 2015 Tutti i diritti riservati Pagina 10 (Versione 1.1)

12 mancanza di completa trasparenza renderà impossibile la guida efficiente di un Nexus per minimizzare i rischi e massimizzare il valore. Il software deve essere sviluppato in modo tale che le dipendenze siano individuate e risolte prima che il debito tecnico diventi inaccettabile. Quando si procede all integrazione e lo stato delle dipendenze risolte rimane non chiaro, questo è un segnale che è stato introdotto del debito tecnico inaccettabile. In questi casi, le dipendenze irrisolte rimangono nascoste nel codice sorgente e nei test, abbassando di conseguenza il valore complessivo del software. 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 è usabile e potenzialmente rilasciabile dal Product Owner. Un elemento del Product Backlog può essere considerato Fatto quando la funzionalità che rappresenta è stata aggiunta con successo al prodotto e integrata nell Incremento. Tutti gli Scrum Team sono responsabili per lo sviluppo e l integrazione del loro lavoro in un Incremento che soddisfi questi attributi. 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. Traduzione Questa guida è stata tradotta dalla versione originale inglese fornita dalle persone menzionate nei ringraziamenti. Le persone che hanno contribuito a questa traduzione sono Francesco Macrì e Amin Al Hazwani. Copyright Scrum.org, 2015 Tutti i diritti riservati Pagina 11 (Versione 1.1)