Questa versione HTML della Scrum Guide è una porta diretta della versione di novembre 2020 disponibile come PDFhere.

Scopo della Guida Scrum

Abbiamo sviluppato Scrum nei primi anni 1990. Abbiamo scritto la prima versione della Guida Scrum nel 2010 per aiutare le persone in tutto il mondo a capire Scrum. Abbiamo risolto la Guida da allora attraverso piccoli aggiornamenti funzionali.Insieme, siamo dietro di esso.

La Guida Scrum contiene la definizione di Scrum. Ogni elemento di theframework serve uno scopo specifico che è essenziale per il valore generale e risultati realizzati con Scrum. Cambiare il core design o ideasof Scrum, tralasciando elementi, o non seguendo le regole di Scrum, copre i problemi e limita i benefici di Scrum, potenzialmente evenrending inutile.

Seguiamo il crescente uso di Scrum all’interno di un mondo complesso in continua crescita.Siamo umiliati nel vedere Scrum essere adottato in molti domini che svolgono un lavoro estremamente complesso, al di là dello sviluppo di prodotti software whereScrum ha le sue radici. Mentre l’uso di Scrum si diffonde, sviluppatori,ricercatori, analisti, scienziati e altri specialisti fanno il lavoro. Usiamo la parola”sviluppatori” in Scrum non per escludere, ma per semplificare. Se ottieni valuefrom Scrum, considera te stesso incluso.

Man mano che viene utilizzato Scrum, è possibile trovare, applicare e definire modelli, processi e insight che si adattano al framework Scrum descritto in questo documento. La loro descrizione va oltre lo scopo della guida Scrumperché sono sensibili al contesto e differiscono ampiamente tra gli usi Scrum.Tali tattiche per l’utilizzo all’interno del framework Scrum variano ampiamente e sonodescritto altrove.

Definizione Scrum

Scrum è un framework leggero che aiuta le persone, i team e le organizzazioni a generare valore attraverso soluzioni adattive per problemi complessi.

In poche parole, Scrum richiede uno Scrum Master per promuovere un ambientedove:

1. Un Product Owner ordina il lavoro per un problema complesso in un ProductBacklog.

2. Il team Scrum trasforma una selezione del lavoro in un incremento di valore durante uno Sprint.

3. Il team Scrum e i suoi stakeholder ispezionano i risultati e si adeguano al prossimo Sprint.

4. Ripetere

Scrum è semplice. Provalo così com’è e determina se la sua filosofia, teoria e struttura aiutano a raggiungere gli obiettivi e creare valore. Lo Scrumframework è volutamente incompleto, definendo solo le parti necessarie per implementare la teoria dello Scrum. Scrum è costruito sul collettivointelligenza delle persone che lo usano. Piuttosto che fornire alle persone istruzioni dettagliate, le regole di Scrum guidano le loro relazioni e le loro interazioni.

Vari processi, tecniche e metodi possono essere impiegati all’interno del quadro. Scrum avvolge le pratiche esistenti o le rendenon necessario. Scrum rende visibile l’efficacia relativa della gestione corrente, dell’ambiente e delle tecniche di lavoro, in modo che i miglioramenti possano essere apportati.

Teoria Scrum

Scrum si basa sull’empirismo e sul pensiero snello. L’empirismo afferma che la conoscenza deriva dall’esperienza e prende decisioni basate su ciò che è osservato. Lean thinking riduce gli sprechi e si concentra sull’essenziale.

Scrum impiega un approccio iterativo e incrementale per ottimizzare la prevedibilità e controllare il rischio. Scrum coinvolge gruppi di persone che hanno collettivamente tutte le competenze e le competenze per svolgere il lavoro e condividere o acquisire tali competenze se necessario.

Scrum combina quattro eventi formali per l’ispezione e l’adattamento all’interno di un evento di mantenimento, lo Sprint. Questi eventi funzionano perché implementano i pilastri empirici di trasparenza, ispezione e adattamento.

Trasparenza

Il processo e il lavoro emergenti devono essere visibili sia a chi esegue il lavoro che a chi lo riceve. Con Scrum, importantdecisions si basano sullo stato percepito dei suoi tre artefatti formali. Artefatti che hanno una bassa trasparenza possono portare a decisioniche diminuiscono il valore e aumentano il rischio.

La trasparenza consente l’ispezione. Ispezione senza trasparenza ismisleading e dispendioso.

Ispezione

Gli artefatti di Scrum e il progresso verso gli obiettivi concordati devono essere osservati frequentemente e diligentemente per rilevare variazioni o problemi potenzialmente indesiderati. Per aiutare con l’ispezione, Scrum fornisce cadenzanella forma dei suoi cinque eventi.

L’ispezione consente l’adattamento. L’ispezione senza adattamento èconsiderato inutile. Gli eventi Scrum sono progettati per provocare cambiamenti.

Adattamento

Se alcuni aspetti di un processo si discostano al di fuori dei limiti accettabili o se il prodotto risultante è inaccettabile, il processo applicato o i materiali prodotti devono essere adeguati. La regolazione deve essere fattail più presto possibile per ridurre al minimo ulteriori deviazioni.

L’adattamento diventa più difficile quando le persone coinvolte non sono alimentate o autogestite. Ci si aspetta che un team Scrum adatti il momentoimpara qualcosa di nuovo attraverso l’ispezione.

Scrum Values

L’uso riuscito di Scrum dipende dal fatto che le persone diventano più abili nel vivere cinque valori:

Impegno, Concentrazione, Apertura, Rispetto e Coraggio

Il Team Scrum si impegna a raggiungere i propri obiettivi e a sostenersi a vicenda. Il loro obiettivo principale è il lavoro dello Sprint per fare il miglior progresso possibile verso questi obiettivi. Il team Scrum e itsstakeholders sono aperti circa il lavoro e le sfide. Scrum Teammembers rispettare l’altro per essere persone capaci, indipendenti, e arerespected come tale dalle persone con cui lavorano. Gli Scrum Teammembers hanno il coraggio di fare la cosa giusta, di lavorare su problemi difficili.

Questi valori danno indicazioni al Team Scrum per quanto riguarda il loro lavoro,le azioni e il comportamento. Le decisioni che vengono prese, le misure adottate e il modo in cui viene utilizzato Scrum dovrebbero rafforzare questi valori, non diminuirli o ridurli. I membri del team Scrum imparano ed esplorano i valori che lavorano con gli eventi e gli artefatti Scrum. Quando questi valori sono incorporati dal team Scrum e dalle persone con cui lavorano, i pilastri empirici di trasparenza, ispezione e adattamento arrivano alla fiducia di lifebuilding.

Scrum Team

L’unità fondamentale di Scrum è un piccolo team di persone, un Team Scrum.Il team Scrum è composto da uno Scrum Master, un Product Owner, andDevelopers. All’interno di una squadra Scrum, non ci sono sotto-squadre o hierarchies.It è un’unità coesa di professionisti focalizzata su un obiettivo alla volta, l’obiettivo del prodotto.

I team Scrum sono interfunzionali, il che significa che i membri hanno tutte le abilità necessarie per creare valore ogni Sprint. Essi sono alsoself-gestione, nel senso che internamente decidere chi fa cosa, quando, andhow.

Il team Scrum è abbastanza piccolo da rimanere agile e abbastanza grande da completare un lavoro significativo all’interno di uno Sprint, in genere 10 o meno people.In generale, abbiamo scoperto che i team più piccoli comunicano meglio e sono più produttivi. Se i team Scrum diventano troppo grandi, dovrebbero considerare l’organizzazione in più team Scrum coesi, ciascuno focalizzato sullo stesso prodotto. Pertanto, dovrebbero condividere lo stesso obiettivo del prodotto,il Product Backlog e il Product Owner.

Il team Scrum è responsabile di tutte le attività relative al prodotto di collaborazione, verifica, manutenzione, funzionamento,sperimentazione, ricerca e sviluppo e qualsiasi altra cosa che potrebbe essere richiesta. Sono strutturati e autorizzati dall’organizzazione a gestire il proprio lavoro. Lavorare in Sprint a un ritmo sostenibile migliora l’attenzione e la coerenza del team Scrum.

L’intero team Scrum è responsabile per la creazione di un prezioso, utileincrement ogni Sprint. Scrum definisce tre specifiche accountabilitieswithin il Team Scrum: gli sviluppatori, il proprietario del prodotto e lo ScrumMaster.

Sviluppatori

Gli sviluppatori sono le persone del team Scrum che si impegnano a creare qualsiasi aspetto di un incremento utilizzabile ogni Sprint.

Le competenze specifiche necessarie agli Sviluppatori sono spesso ampie e si sposteranno con il dominio del lavoro. Tuttavia, gli sviluppatori sono alwaysaccountable per:

• Creazione di un piano per lo Sprint, lo Sprint Backlog;

• Instillare qualità aderendo ad una definizione di fatto;

• Adattare il loro piano ogni giorno verso l’obiettivo Sprint; e,

• Tenendosi reciprocamente responsabili come professionisti.

Product Owner

Il Product Owner è responsabile della massimizzazione del valore del prodotto derivante dal lavoro del Team Scrum. Come questo viene fatto può varywidely tra le organizzazioni, Scrum Team, e gli individui.

Il Product Owner è anche responsabile di un’efficace gestione del Product Backlog, che include:

• Sviluppare e comunicare esplicitamente l’obiettivo del prodotto;

• Creare e comunicare chiaramente gli elementi del Product Backlog;

• Ordinare gli elementi del Product Backlog; e,

• Garantire che il Product Backlog sia trasparente, visibile e comprensibile.

Il Proprietario del prodotto può svolgere il lavoro di cui sopra o può delegare la responsabilità ad altri. Indipendentemente da ciò, il proprietario del prodotto rimaneaccountabile.

Affinché i proprietari di prodotti abbiano successo, l’intera organizzazione deve rispettarele loro decisioni. Queste decisioni sono visibili nel contenuto e nell’ordine del Product Backlog e attraverso l’incremento ispezionabile alla revisione della stampa.

Il proprietario del prodotto è una persona, non un comitato. Il proprietario del prodotto puòrappresentare le esigenze di molti stakeholder nel Product Backlog. Thosewanting per cambiare l’arretrato di prodotto può farlo provando a convincethe il proprietario di prodotto.

Scrum Master

Lo Scrum Master è responsabile della creazione di Scrum come definito nella Guida Scrum. Lo fanno aiutando tutti a capire Scrum theoryand pratica, sia all’interno del team Scrum e l’organizzazione.

Lo Scrum Master è responsabile dell’efficacia del Team Scrum. Lo fanno consentendo al team Scrum di migliorare le sue pratiche, all’interno del framework Scrum.

I Master Scrum sono veri leader che servono il Team Scrum e la largerorganization.

Il Scrum Master serve il mediano di Mischia della Squadra in diversi modi, tra cui:

• il Coaching, i membri della squadra in autogestione andcross-funzionalità;

• Aiutare i Scrum Team focus sulla creazione di valore elevato Incrementi thatmeet la Definizione di Fatto;

• Causando la rimozione degli ostacoli alla Mischia della Squadra di progresso;e,

• Garantire che tutti Mischia eventi hanno luogo e sono positivo,produttivo, e mantenuti entro il timebox.

Il Scrum Master serve il Proprietario del Prodotto in diversi modi, tra cui:

• Aiuta a trovare le tecniche per un’efficace Prodotto Obiettivo definizione andProduct la gestione del Backlog;

• Aiutare i Scrum Team comprendere l’esigenza di un chiaro e conciseProduct articoli Backlog;

• Aiutare a stabilire empirica pianificazione di prodotto per un complexenvironment; e,

• Facilitare la collaborazione degli stakeholder, come richiesto o necessario.

Lo Scrum Master serve l’organizzazione in diversi modi, tra cui:

• Guidare, formare e istruire l’organizzazione nella sua Opzione Scrum;

• Pianificare e consigliare le implementazioni Scrum all’interno dell’organizzazione;

• Aiutare i dipendenti e gli stakeholder a comprendere e attuare un approccio empirico per lavori complessi; e,

• Rimuovere le barriere tra stakeholder e team Scrum.

Eventi Scrum

Lo Sprint è un contenitore per tutti gli altri eventi. Ogni evento in Scrum è un’opportunità formale per ispezionare e adattare gli artefatti Scrum. Questi eventi sono specificamente progettati per consentire la trasparenza richiesta. Il mancato funzionamento di qualsiasi evento come prescritto comporta la perdita di opportunità di osservazione e adattamento. Gli eventi vengono utilizzati in Scrum per creare regolarità e ridurre al minimo la necessità di riunioni non definite in Scrum.

In modo ottimale, tutti gli eventi si svolgono allo stesso tempo e luogo per ridurrecomplessity.

Lo Sprint

Sprint è il battito cardiaco di Scrum, dove le idee vengono trasformate in valore.

Sono eventi di lunghezza fissa di un mese o meno per creare coerenza.Un nuovo Sprint inizia immediatamente dopo la conclusione del precedentestampa.

Tutto il lavoro necessario per raggiungere l’obiettivo del prodotto, tra cui SprintPlanning, Daily Scrums, Sprint Review e Sprint Retrospective, avviene in Sprint.

Durante lo Sprint:

• Non vengono apportate modifiche, che metterebbe in pericolo la Sprint Obiettivo;

• la Qualità non diminuisce;

• Il Product Backlog è raffinato come necessario; e,

• campo di applicazione possono essere chiarite e rinegoziato con il Proprietario del Prodotto asmore è imparato.

Gli sprint consentono la prevedibilità garantendo l’ispezione e l’adattamento dei progressi verso un obiettivo di prodotto almeno ogni mese di calendario. Quando l’orizzonte di aSprint è troppo lungo, l’obiettivo Sprint potrebbe non essere valido, la complessità potrebbe aumentare e il rischio potrebbe aumentare. Gli sprint più brevi possono essere impiegati per generare più cicli di apprendimento e limitare il rischio di costi e costi a un arco di tempo più ridotto. Ogni Sprint può essere considerato un breveprogetto.

Esistono varie pratiche per prevedere i progressi, come burn-down,burn-up o flussi cumulativi. Sebbene dimostrati utili, questi non sostituiscono ilimportanza dell’empirismo. In ambienti complessi, ciò che accadrà ènoto. Solo ciò che è già accaduto può essere utilizzato per il processo decisionale lungimirante.

Uno Sprint potrebbe essere annullato se l’obiettivo dello Sprint diventa obsoleto. Soloil proprietario del prodotto ha l’autorità di annullare lo Sprint.

Sprint Planning

Sprint Planning avvia lo Sprint disponendo il lavoro da eseguire per lo Sprint. Questo piano risultante è stato creato dallavoro collaborativo dell’intero team Scrum.

Il Product Owner assicura che i partecipanti siano pronti a discutere gli elementi del Product Backlog più importanti e il modo in cui si associano all’obiettivo del prodotto. Il team Scrum può anche invitare altre persone a partecipare SprintPlanning per fornire consigli.

Sprint Planning affronta i seguenti argomenti:

Argomento uno: perché questo Sprint è prezioso?

Il Product Owner propone come il prodotto potrebbe aumentare il suo valore e l’utilità nello Sprint corrente. L’intero team Scrum collabora quindi per definire un obiettivo Sprint che comunica perché lo Sprint è prezioso per gli stakeholder. L’obiettivo Sprint deve essere finalizzato prima della fine della pianificazione delle stampe.

Argomento due: Cosa si può fare questo Sprint?

Attraverso la discussione con il proprietario del prodotto, gli sviluppatori selezionano itemsfrom il Product Backlog da includere nello Sprint corrente. Il ScrumTeam può perfezionare questi elementi durante questo processo, che increasesunderstanding e la fiducia.

Selezionare quanto può essere completato all’interno di uno Sprint può essere difficile.Tuttavia, più gli sviluppatori conoscono le loro prestazioni passate, la loro capacità imminente e la loro definizione di Done, più saranno sicuri nelle loro previsioni di Sprint.

Argomento tre: Come verrà eseguito il lavoro scelto?

Per ogni elemento del Product Backlog selezionato, gli sviluppatori pianificano il worknecessary per creare un incremento che soddisfi la definizione di Done. Thisis fatto spesso scomponendo gli articoli del Backlog del prodotto in più piccoli workitems di un giorno o di meno. Come questo è fatto è a esclusiva discrezione digli sviluppatori. Nessun altro dice loro come trasformare gli elementi del Product Backlog in incrementi di valore.

L’obiettivo dello Sprint, gli elementi del Product Backlog selezionati per lo Sprint, plusil piano per la loro consegna sono insieme denominati SprintBacklog.

La pianificazione dello sprint è limitata a un massimo di otto ore per una stampa di un mese. Per sprint più brevi, l’evento è di solito più breve.

Daily Scrum

Lo scopo del Daily Scrum è quello di ispezionare i progressi verso lo SprintGoal e adattare lo Sprint Backlog, se necessario, regolando il lavoro pianificato.

Il Daily Scrum è un evento di 15 minuti per gli sviluppatori di ScrumTeam. Per ridurre la complessità, si svolge allo stesso tempo e luogo ognigiorno lavorativo dello Sprint. Se il proprietario del prodotto o Scrum Master stanno lavorando attivamente sugli elementi nel Backlog Sprint, partecipano asDevelopers.

Gli sviluppatori possono selezionare qualsiasi struttura e le tecniche che vogliono,a patto che la loro Mischia quotidiana si concentra sui progressi verso l’obiettivo Sprint e produce un piano attuabile per il giorno successivo di lavoro. Questo createsfocus e migliora l’autogestione.

Mischia quotidiana migliorare le comunicazioni, identificare gli impedimenti, promuovere quickdecision-making, e di conseguenza eliminare la necessità di altri incontri.

La Mischia giornaliera non è l’unica volta che gli sviluppatori sono autorizzati a regolare il loro piano. Spesso si incontrano durante il giorno per più dettagliatidiscussioni sull’adattamento o la riprogrammazione del resto del lavoro dello Sprint.

Sprint Review

Lo scopo della Sprint Review è quello di ispezionare il risultato dello Sprint e determinare gli adattamenti futuri. Il team Scrum presenta i risultati del proprio lavoro ai principali stakeholder e i progressi verso l’obiettivo del prodotto sono discussi.

Durante l’evento, il team Scrum e le parti interessate esaminano ciò che è stato completato nello Sprint e ciò che è cambiato nel loro ambiente.Sulla base di queste informazioni, i partecipanti collaborano su cosa fare dopo. L’arretrato del prodotto può anche essere adeguato per soddisfare nuove opportunità. TheSprint Review è una sessione di lavoro e il team Scrum dovrebbe evitare di limitarlo a una presentazione.

La Sprint Review è il penultimo evento dello Sprint ed è limitata a un massimo di quattro ore per uno Sprint di un mese. Per shorterSprints, l’evento è di solito più breve.

Sprint Retrospective

Lo scopo della Sprint Retrospective è quello di pianificare modi per aumentarequalità ed efficacia.

Il team Scrum ispeziona come è andato l’ultimo Sprint per quanto riguarda gli individui, le interazioni, i processi, gli strumenti e la loro definizione di Done. Gli elementi ispezionati spesso variano a seconda del dominio del lavoro. Le ipotesi che li hanno traviati sono identificate e le loro origini esplorate. Il team di Scrum discute cosa è andato bene durante lo Sprint, quali problemi ha incontrato e come questi problemi sono stati (o non sono stati) risolti.

Il team Scrum identifica le modifiche più utili per migliorare la sua efficacia. I miglioramenti più impattanti sono affrontati non appena possibile. Essi possono anche essere aggiunti al Backlog Sprint per il nextSprint.

La retrospettiva Sprint conclude lo Sprint. È timeboxed a amaximum di tre ore per uno sprint di un mese. Per sprint più brevi, l’evento è solitamente più breve.

Artefatti di Scrum

Gli artefatti di Scrum rappresentano lavoro o valore. Sono progettati per massimizzaretrasparenza delle informazioni chiave. Quindi, tutti quelli che li ispezionano hanno la stessa base per l’adattamento.

Ogni artefatto contiene un impegno a garantire che fornisca informazioniche migliora la trasparenza e la concentrazione rispetto alla quale il progresso può essere misurato:

• Per il Product Backlog è l’obiettivo del prodotto.

• Per il Backlog Sprint è l’obiettivo Sprint.

• Per l’Incremento è la Definizione di Fatto.

Questi impegni esistono per rafforzare l’empirismo e i valori Scrum per il Team Scrum e i loro stakeholder.

Product Backlog

Il Product Backlog è un elenco emergente e ordinato di ciò che è necessario per migliorare il prodotto. È l’unica fonte di lavoro intrapresa dal team di Scrum.

Gli elementi del Product Backlog che possono essere eseguiti dal team Scrum all’interno di oneSprint sono ritenuti pronti per la selezione in un evento di pianificazione Sprint. Di solito acquisiscono questo grado di trasparenza dopo le attività di raffinazione.La raffinatezza del product Backlog è l’atto di abbattere e furtherdefining Product Backlog items in più piccoli articoli più precisi. Questa è un’attività in corso per aggiungere dettagli, ad esempio una descrizione, un ordine e una dimensione. Gli attributi variano spesso con il dominio del lavoro.

Gli sviluppatori che eseguiranno il lavoro sono responsabili della dimensionamento. Il proprietario del prodotto può influenzare gli sviluppatori aiutandolicapire e selezionare i compromessi.

Impegno: Obiettivo del prodotto

L’obiettivo del prodotto descrive uno stato futuro del prodotto che può servire come obiettivo per il team Scrum da pianificare. L’obiettivo del prodotto è inthe Product Backlog. Il resto del Product Backlog emerge per definire “cosa” soddisferà l’obiettivo del prodotto.

Un prodotto è un veicolo per fornire valore. Ha un confine chiaro, stakeholder noti, utenti o clienti ben definiti. Un prodotto potrebbe essere un servizio, un prodotto fisico o qualcosa di più astratto.

L’obiettivo del prodotto è l’obiettivo a lungo termine per il team Scrum. Devono soddisfare (o abbandonare) un obiettivo prima di assumere il prossimo.

Sprint Backlog

Il Backlog Sprint è composto dall’obiettivo Sprint (perché), dall’insieme di elementi di Backlog del prodotto selezionati per lo Sprint (cosa) e da un piano attuabile per la consegna dell’incremento (come).

Lo Sprint Backlog è un piano di e per gli sviluppatori. È un’immagine altamente visibile e in tempo reale del lavoro che gli sviluppatori pianificano di completare durante lo Sprint per raggiungere l’obiettivo dello Sprint.Di conseguenza, il Backlog Sprint viene aggiornato durante lo Sprint asmore viene appreso. Dovrebbe avere abbastanza dettagli da poter ispezionarei loro progressi nella Mischia quotidiana.

Impegno: Obiettivo Sprint

L’obiettivo Sprint è il singolo obiettivo per lo Sprint. Sebbene l’obiettivo della stampa sia un impegno degli sviluppatori, fornisce flessibilità in termini di lavoro esatto necessario per raggiungerlo. L’obiettivo Sprint crea anche coerenza e concentrazione, incoraggiando il team Scrum a lavorare insieme piuttosto che su iniziative separate.

L’obiettivo Sprint viene creato durante l’evento di pianificazione Sprint e quindi aggiunto al Backlog Sprint. Mentre gli sviluppatori lavorano durante lo Sprint, tengono a mente l’obiettivo dello Sprint. Se il lavoro risulta essere differentthan loro aspettavano, loro collaborano con il Proprietario di Prodotto per negotiatethe la portata del Backlog di Sprint all’interno dello Sprint senza intaccare l’Obiettivo di theSprint.

Incremento

Un incremento è un trampolino di lancio concreto verso l’obiettivo del Prodotto. EachIncrement è additivo a tutti gli incrementi precedenti e accuratamente verificato, assicurando che tutti gli incrementi di lavorare insieme. Per fornire valore, l’Incremento deve essere utilizzabile.

È possibile creare più incrementi all’interno di uno Sprint. La somma degli aumenti è presentata alla Sprint Review sostenendo così l’empirismo.Tuttavia, un incremento può essere consegnato alle parti interessate prima della fine dello Sprint. La revisione Sprint non dovrebbe mai essere considerata un valore di gate toreleasing.

Il lavoro non può essere considerato parte di un incremento a meno che non soddisfi la definizione di Done.

Impegno: Definizione di Done

La definizione di Done è una descrizione formale dello stato dell’Incremento quando soddisfa le misure di qualità richieste per il prodotto.

Nel momento in cui un elemento del Product Backlog soddisfa la definizione di Done, nasce anIncrement.

La definizione di Done crea trasparenza fornendo a tutti una comprensione condivisa di quale lavoro è stato completato come parte dell’Incremento. Se un elemento del Product Backlog non soddisfa la definizione di Done, non può essere rilasciato o addirittura presentato alla Sprint Review.Invece, ritorna al Product Backlog per la considerazione futura.

Se la Definizione di Done per un incremento fa parte degli standard dell’organizzazione, tutti i Team Scrum devono seguirla come minimo. Se isnot uno standard organizzativo, il team Scrum deve creare un Definitionof fatto appropriato per il prodotto.

Gli sviluppatori sono tenuti a conformarsi alla Definizione di Done. Ifthere sono più team Scrum che lavorano insieme su un prodotto, essi mustmutually definire e rispettare la stessa definizione di fatto.

Nota finale

Scrum è gratuito e offerto in questa Guida. Il framework Scrum, come qui descritto, è immutabile. Mentre si implementano solo parti di Scrum ispossible, il risultato non è Scrum. Scrum esiste solo nella sua interezza e funziona bene come contenitore per altre tecniche, metodologie e pratiche.

Ringraziamenti

Persone

Delle migliaia di persone che hanno contribuito a Scrum, dovremmo distinguere quelli che sono stati strumentali all’inizio: Jeff Sutherland ha lavorato con Jeff McKenna e John Scumniotales, e Ken Schwaber ha lavorato con Mike Smith e Chris Martin, e tutti hanno lavorato insieme. Manyothers contribuito negli anni successivi e senza il loro aiuto Scrumwould non essere raffinato come è oggi.

Scrum Guide History

Ken Schwaber e Jeff Sutherland hanno co-presentato Scrum alla OOPSLAConference nel 1995. Ha essenzialmente documentato l’apprendimento che Ken andJeff ha acquisito negli anni precedenti e ha reso pubblica la prima definizione formale di Scrum.

La Guida Scrum documenta Scrum come sviluppato, evoluto e sostenuto per oltre 30 anni da Jeff Sutherland e Ken Schwaber. Altre fonti fornisconomodelli, processi e approfondimenti che completano il framework Scrum.Questi possono aumentare la produttività, valore, creatività, e satisfactionwith i risultati.

La cronologia completa di Scrum è descritta altrove. Per onorare i primiluoghi in cui è stato provato e provato, riconosciamo Individual Inc., Newspage, Fidelity Investments e IDX (ora GE Medical).

© 2020 Ken Schwaber e Jeff Sutherland Questa pubblicazione è offerto in licenza sotto la AttributionShare-Alike license Creative Commons, accessibile all’indirizzo https://creativecommons.org/licenses/by-sa/4.0/legalcode e alsodescribed, in forma sintetica, all’indirizzo https://creativecommons.org/licenses/by-sa/4.0/. Utilizzando questo ScrumGuide, l’utente riconosce e accetta di aver letto e accettato di essere vincolato dai termini della licenza Attribution Share-Alike di CreativeCommons.