Scrum (informatica)

Questa voce o sezione sull'argomento linguaggi di programmazione non cita le fonti necessarie o quelle presenti sono insufficienti.

---

Puoi migliorare questa voce aggiungendo citazioni da fonti attendibili secondo le linee guida sull'uso delle fonti.

Scrum è un framework agile per la gestione del ciclo di sviluppo del software, iterativo ed incrementale, concepito per gestire progetti e prodotti software o applicazioni di sviluppo, creato e sviluppato da Ken Schwaber e Jeff Sutherland.

Scrum enfatizza tutti gli aspetti di gestione di progetto legati a contesti in cui è difficile pianificare in anticipo. Vengono utilizzati meccanismi propri di un "processo di controllo empirico", in cui cicli di feedback che ne costituiscono le tecniche di management fondamentali risultano in opposizione alla gestione basata sul concetto tradizionale di command-and-control. Il suo approccio alla pianificazione e gestione di progetti è quello di portare l'autorità decisionale al livello di proprietà e certezze operative.^[2]

Il termine Scrum, in quanto applicato allo sviluppo di prodotti, è stato per la prima volta utilizzato in "New New Product Development Game"^[3] (Harvard Business Review 86116:137-146, 1986) e successivamente elaborato in "The Knowledge Creating Company"^[4] entrambi testi di Ikujiro Nonaka e Hirotaka Takeuchi (Oxford University Press, 1995).

Nel 1986, Hirotaka Takeuchi e Ikujiro Nonaka descrissero un nuovo approccio allo sviluppo di prodotti commerciali che avrebbe aumentato la velocità e la flessibilità, basato su casi di studio presi dall'industria automobilistica e quella relativa alla realizzazione di fotocopiatrici e stampanti.^[5] Essi lo chiamarono approccio olistico o rugby, in quanto l'intero processo viene eseguito da un team interfunzionale su più fasi che si sovrappongono, dove la squadra "cerca di raggiungere l'obiettivo come unità, passando la palla avanti e indietro".^[5]

Il termine Scrum è mutuato dal termine del rugby che indica il pacchetto di mischia ed è evidentemente una metafora del team di sviluppo che deve lavorare insieme in modo che tutti gli attori del progetto spingano nella stessa direzione, agendo come un'unica entità coordinata.

Ken Schwaber e Jeff Sutherland hanno presentato per la prima volta Scrum alla conferenza OOPSLA del 1995. Questa presentazione ha essenzialmente documentato ciò che Ken e Jeff avevano appreso negli anni precedenti applicando Scrum. Nel 2001 Schwaber ha collaborato con Mike Beedle per descrivere il metodo in un libro chiamato Agile Software Development with Scrum.^[6]. Inoltre, nel 2004, Ken Schwaber ha pubblicato il libro Agile Project Management with Scrum^[7] pubblicato da Microsoft Press.

Scrum si basa sulla teoria dei controlli empirici di analisi strumentale e funzionale di processo o empirismo. L'empirismo afferma che la conoscenza deriva dall'esperienza e che le decisioni si basano su ciò che si conosce. Scrum utilizza un metodo interattivo e un approccio incrementale per ottimizzare la prevedibilità e il controllo del rischio.^[1]

Sono tre i pilastri che sostengono ogni implementazione del controllo empirico di processo.

Gli aspetti significativi del processo devono essere visibili ai responsabili del lavoro. La trasparenza richiede che quegli aspetti siano definiti da uno standard comune in modo tale che gli osservatori condividano una comune comprensione di ciò che viene visto. Ad esempio:

• Un linguaggio comune di riferimento al processo deve essere condiviso da tutti i partecipanti;
• Una definizione comune della parola "fatto" (in inglese "done") deve essere condivisa da chi esegue il lavoro e da chi deve accettarlo.

Chi utilizza Scrum deve ispezionare frequentemente gli artefatti prodotti e i progressi realizzati verso il conseguimento degli obiettivi prestabiliti, individuando in tal modo precocemente eventuali difformità rispetto a quanto si intende realizzare. La frequenza delle ispezioni non deve essere tale da determinare un'interruzione del lavoro in corso. Le ispezioni devono essere eseguite diligentemente e da ispettori qualificati.

Se chi ispeziona verifica che uno o più aspetti del processo di produzione sono al di fuori dei limiti accettabili e che il prodotto finale non potrà essere accettato, deve intervenire sul processo stesso o sul materiale prodotto dalla lavorazione. L'intervento deve essere portato a termine il più rapidamente possibile per ridurre al minimo l'ulteriore scarto rispetto agli obiettivi prestabiliti. Scrum prescrive quattro occasioni formali per l'ispezione e l'adattamento:

• Sprint Planning Meeting
• Daily Scrum
• Sprint Review
• Sprint Retrospective

In maniera molto sintetica Scrum è un framework di processo che prevede di dividere il progetto in blocchi rapidi di lavoro (Sprint) alla fine di ciascuno dei quali creare un incremento del software. Esso indica come definire i dettagli del lavoro da fare nell'immediato futuro e prevede vari meeting (eventi) con caratteristiche precise per creare occasioni di ispezione del lavoro svolto.

Il framework Scrum è un sistema formato basato su valori, responsabilità, eventi, artefatti e regole ad essi associati allo scopo di creare un ambiente trasparente che permetta l'ispezione ed adattamento. Ogni parte del framework serve a uno specifico scopo ed è essenziale per il successo e l'utilizzo di Scrum. Le regole di Scrum legano insieme eventi, responsabilità, artefatti e commitments, governando le relazioni e interazioni tra essi anche se le strategie specifiche per l'utilizzo del framework Scrum variano e vengono descritte in molti testi specifici.

Fino a qualche tempo fa le persone all'interno di un'organizzazione dove si fosse utilizzato Scrum venivano divise in due gruppi distinti: i maiali e i polli (in base alla storiella The Chicken and the Pig, una metafora che distingue ironicamente fra chi è "strettamente coinvolto" in un progetto e chi lo è invece solo parzialmente). Si è scelto nel 2011 di non utilizzare più questa analogia, perché da molti è stata ritenuta inappropriata ed offensiva.

Le persone che ricoprono i ruoli principali nel processo Scrum costituiscono il Team Scrum e sono quelle impegnate nel progetto e che realizzano il prodotto (obiettivo del progetto).

Il Team Scrum è formato dal Product Owner, sviluppatori (fino al 2017 development team, ora rinominato per ribadire il concetto che non esistono sotto-team) e da uno Scrum Master. I Team Scrum sono auto-organizzati e cross-funzionali: scelgono come meglio compiere il lavoro organizzandosi e coordinandosi al proprio interno e hanno tutte le competenze necessarie per realizzare il lavoro senza dover dipendere da nessuno al di fuori del team. Il modello di team in Scrum è progettato per ottimizzare la flessibilità, la creatività e la produttività. I Team Scrum rilasciano i prodotti in modo iterativo e incrementale, massimizzando le opportunità di feedback. I rilasci incrementali di prodotto "fatto" garantiscono che una versione potenzialmente utile del prodotto funzionante sia sempre disponibile.

Secondo l'ultima versione della scrum guide questo è tipicamente composto da 10 o meno persone

Product Owner

Il Product Owner rappresenta gli stakeholders ed è la voce del cliente. È responsabile di massimizzare il valore del prodotto risultante dal lavoro svolto dallo scrum team. Il Product Owner definisce gli item (requisiti di prodotto) centrati sui bisogni dei clienti (tipicamente, ma non necessariamente user stories), assegna loro la priorità, e li aggiunge al Product Backlog. I team Scrum devono avere un Product Owner e si raccomanda che questo ruolo non sia combinato con quello dello Scrum Master.^[8] Il ruolo di Product Owner non va inoltre confuso con quello di Product Manager.^[9]

Team di sviluppo

Il team di sviluppo è responsabile della consegna del prodotto, con incrementi di caratteristiche, che sia potenzialmente rilasciabile alla fine di ogni Sprint. Un team di sviluppo è composto da persone, con competenze cross-funzionali, che stimano e realizzano il lavoro effettivo (analisi, progettazione, sviluppo, test, comunicazione tecnica, documentazione...). Il team di sviluppo in Scrum si auto-organizza e gli incrementi sviluppati sono tenuti a rispettare la definition of done, sebbene possa esserci un'interfaccia verso il PMO (Project Management Office).

Scrum Master

Lo Scrum Master è responsabile della rimozione degli ostacoli che limitano la capacità del team di raggiungere l'obiettivo dello Sprint e i deliverable previsti e di massimizzare l'efficacia del team. Sebbene sia un ruolo manageriale, lo Scrum Master non è il team leader, piuttosto colui che facilita una corretta esecuzione del processo. Lo Scrum Master detiene l'autorità relativa all'applicazione delle norme. Una parte fondamentale del ruolo di Scrum Master è quello di proteggere il team di sviluppo e tenerlo concentrato sui compiti fungendo da cuscinetto verso qualsiasi influenza di distrazione. Fino al 2020, il ruolo viene anche descritto come servant-leader, anche se nell'ultima versione è più un true leader who serves the team. Lo scrum master, oltre ad essere un leader, deve anche essere un buon coach e un insegnante che sappia insegnare scrum agli altri membri del gruppo, sia capace di aiutare il product owner nella comunicazione degli obiettivi di progetto e nel trovare tecniche per massimizzare l'efficacia del product backlog e istruire il team nella direzione dell'auto organizzazione

Stakeholder

Lo stakeholder non fa parte dei ruoli del gruppo scrum, ma è il portatore di interessi che interfacciandosi con il po o con il team in generale da feedback e chiede modifiche (lasciando però l'ultima parola sempre al gruppo)

Gli eventi previsti sono utilizzati in Scrum per creare regolarità e ridurre al minimo la necessità di riunioni non definite da Scrum stesso. Scrum utilizza eventi time-box, in modo che ogni evento abbia una durata massima. Questo assicura che una quantità appropriata di tempo sia trascorsa pianificando, senza permettere l'introduzione di sprechi nel processo di pianificazione.^[10] Oltre allo stesso Sprint, che è un contenitore di tutti gli altri eventi, ogni evento in Scrum è un'occasione formale per ispezionare e adattare qualcosa. Questi eventi sono specificamente progettati per consentire trasparenza critica e ispezione. La mancata inclusione di uno qualsiasi dei risultati di questi eventi riduce la trasparenza ed è un'occasione persa per ispezionare e adattarsi.

Lo Sprint contiene e consiste dello Sprint Planning meeting, del Daily Scrum, del lavoro di sviluppo, dello Sprint Review e della Sprint Retrospective. Oltre questi eventi principali, possono aggiungersi altri due meeting: il Backlog Grooming e lo Scrum of Scrums.

Lo sprint è l'evento base in scrum, ha una durata fissa decisa dal team, che può andare da una a quattro settimane e dà ritmo e permette di attuare al suo interno i tre pilastri dell'empiricismo scrum.

Ogni sprint contiene al suo interno gli altri eventi scrum e all'interno di esso si trasformano gli items in valore aggiunto per il prodotto.

A inizio sprint viene fatta una pianificazione, chiamata sprint planning, in cui si pianifica il lavoro di tutta la durata dello sprint, alla fine si ispeziona il risultato in un evento, chiamato sprint review, e il processo nella sprint retrospective.

Ogni giorno gli sviluppatori si incontrano in un meeting chiamato daily scrum, dove in quindici minuti si allineano sull'andamento del lavoro.

Il lavoro nello sprint è regolato dallo sprint backlog, un artefatto di valore contenente gli oggetti che gli sviluppatori hanno previsto di portare entro lo sprint, in senso di storie e task, insieme allo sprint goal, il commitment dello sprint backlog ovvero l'obiettivo finale di quello sprint che non può essere cambiato né rinegoziato, a differenza delle storie e i task.

Lo Sprint Backlog è di esclusiva proprietà del team di sviluppo, quindi durante uno Sprint la modifica dello Sprint Backlog non è consentita a nessun altro, a eccezione degli sviluppatori. Lo sprint è di durata fissa, in modo tale che lo Sprint termini alla data prefissata, ma se uno o piu sprint goal perdono di valore il product owner potrebbe decidere di cancellarlo, anche se è fortemente sconsigliato farlo; se i requisiti non sono stati completati per una qualsiasi ragione, vengono esclusi dalla review e reinseriti nel Product Backlog, a discrezione del Product Owner, e, se durante gli sviluppi ci si rende conto che l'ambito dello sprint non è raggiungibile, product owner e sviluppatori devono rinegoziare le storie, in modo tale da riuscire comunque a raggiungere gli sprint goal.

All'inizio di ogni ciclo di Sprint, viene tenuto uno “Sprint Planning meeting”^[11].

Il lavoro da svolgere nello Sprint è pianificato durante lo Sprint Planning meeting. Questo piano è creato dal lavoro collaborativo dell'intero Team Scrum.

Lo Sprint Planning meeting è un incontro della durata di otto ore per uno Sprint di un mese. Per Sprint più brevi, l'evento è proporzionalmente più rapido. Ad esempio, uno Sprint di due settimane ha uno Sprint Planning meeting di quattro ore.

Lo Sprint Planning include i seguenti elementi:

• Selezionare il lavoro da fare
• Preparare lo Sprint Backlog che dettagli il tempo necessario per fare quel lavoro, con tutta la squadra
• Identificare e comunicare la maggior parte del lavoro che è probabile sarà effettuato durante l'attuale Sprint
• Ha un limite di otto ore (nel caso di uno Sprint lungo trenta giorni)
  • (Prima parte) l'intero Scrum team:^[12] definisce insieme al Product Owner l'obiettivo dello Sprint e l'insieme di storie su cui impegnarsi.
  • (Seconda parte) il team di sviluppo:^[13] definisce un piano per lo Sprint, risultante nello Sprint Backlog.

Questo incontro è frequentato dal Product Owner, dallo Scrum Master e dall'intero team di sviluppo. Possono partecipare anche tutti i manager del caso interessati o i rappresentanti della clientela.

Ogni giorno durante lo Sprint, viene tenuta una riunione di comunicazione del team di progetto. Questo meeting viene chiamato "Daily Scrum", o "Daily Standup", e ha un insieme di regole specifiche:

• Tutti i membri del team di sviluppo vengono preparati con gli aggiornamenti per la riunione
• L'incontro inizia puntualmente, anche se qualche membro del team è assente
• Il meeting dovrebbe avvenire ogni giorno nello stesso luogo e allo stesso tempo, per ridurre la complessità
• La durata del meeting è fissata (timeboxed) al tempo massimo di quindici minuti
• Si partecipa rimanendo in piedi, per non dare modo ai partecipanti di distrarsi e isolarsi, come accade nelle riunioni "tradizionali"
• Tutti sono benvenuti, ma normalmente solo i ruoli principali possono parlare

Durante l'incontro quotidiano, ogni membro del team risponde a tre domande:^[14]

• Che cosa è stato fatto dopo l'ultima riunione?
• Che cosa si farà prima della prossima riunione?
• Quali sono gli impedimenti / ostacoli incontrati?

Gli eventuali impedimenti / ostacoli identificati durante questo meeting vengono documentati dallo Scrum Master, per essere poi lavorati allo scopo di essere risolti al di fuori di questo incontro. Durante il Daily Scrum non dovranno essere affrontate discussioni approfondite.

Lo Scrum Master impone la regola che soltanto i membri del team di sviluppo possono partecipare al Daily Scrum. Questo incontro non è uno status meeting ed è rivolto alle persone che trasformano le voci del Product Backlog in un incremento.

Il Daily Scrum migliora le comunicazioni, elimina altri incontri, identifica e rimuove gli ostacoli allo sviluppo, evidenzia e promuove il rapido processo decisionale e migliora il livello di conoscenza del progetto da parte del team di sviluppo. Rappresenta un incontro chiave di ispezione e adattamento.

Per attività di sviluppo maggiori che sono suddivise tra vari team Scrum, durante l'esecuzione dello Sprint vengono generalmente tenuti altri due incontri di coordinamento: il "Backlog Grooming" e lo "Scrum of Scrums".

Il team dovrebbe impiegare del tempo durante uno Sprint per effettuare il Product Backlog Refinement. Questo è il processo di stima del backlog esistente (può essere fatto utilizzando story-point, o t-shirt sizing) raffinando i criteri di accettazione per le storie e dividendo storie più grandi in storie di minore grandezza e complessità.

• Gli incontri dovrebbero essere di durata inferiore al 10% del tempo totale
• Le sessioni di refinement non includono la suddivisione di storie in attività (task)
• Il team può decidere quanti incontri sono necessari a settimana.

Il metodo più comune di stima utilizzato è quello del planning poker, un "gioco di carte" per discutere, giustificare e valutare diverse stime realizzative effettuate da tutti i membri del team per arrivare ad una stima condivisa, ma questa pratica può essere sostituita da altre che fossero ritenute più opportune.

Durante lo Sprint con cadenza quotidiana o leggermente inferiore, viene tenuto, normalmente dopo il Daily Scrum, un incontro chiamato Scrum of Scrums.

• Questi incontri consentono a gruppi di team di discutere assieme il loro lavoro, con particolare attenzione sulle aree di sovrapposizione e integrazione
• Partecipa una persona designata per ciascun team.

L'agenda è la stessa dei Daily Scrum, più le seguenti quattro domande:

• Che cosa ha fatto la tua squadra dal nostro ultimo incontro?
• Cosa conterà di realizzare il tuo team prima che ci incontriamo nuovamente?
• C'è qualcosa che vi rallenta o vi impedisce di ottenere l'obiettivo?
• Siete in procinto di fare qualcosa che possa essere utilizzato da un altro team?

Al termine di un ciclo di Sprint, vengono tenute due riunioni: la “Sprint Review” e la “Sprint Retrospective”.

Alla fine dello Sprint si tiene l'incontro di Sprint Review^[15] per ispezionare l'incremento e adattare, se necessario, il Product Backlog. Durante la riunione di Sprint Review il team di sviluppo e gli stakeholder collaborano su ciò che è stato fatto durante lo Sprint. In conformità a questo e dei cambiamenti al Product Backlog fatti durante lo Sprint, i partecipanti collaborano sulle prossime cose che potrebbero esser fatte. Si tratta di un incontro informale e la presentazione dell'incremento ha lo scopo di suscitare commenti e promuovere la collaborazione.

Si tratta di un incontro della durata di quattro ore per uno Sprint di un mese. La durata è proporzionalmente inferiore per Sprint più brevi. Ad esempio, se uno Sprint dura due settimane, l'incontro di Sprint Review dura due ore.

La Sprint Review include i seguenti elementi:

• Il Product Owner identifica ciò che è stato “Fatto” e ciò che non è stato “Fatto”;
• Il team di sviluppo discute su cosa è andato bene durante lo Sprint, quali problemi si sono incontrati e come questi problemi sono stati risolti;
• Il team di sviluppo mostra il lavoro che ha “Fatto” e risponde alle domande sull'incremento;
• Il Product Owner discute il Product Backlog così com'è. Questi progetta la possibile data di completamento in base alla misura del progresso fino a oggi;
• L'intero gruppo collabora su cosa fare dopo, così la Sprint Review fornisce un prezioso contributo alle successive riunioni di Sprint Planning.

La Sprint Retrospective^[16] è l'occasione per il Team Scrum per ispezionare sé stesso e creare un piano di miglioramento, da attuare durante il prossimo Sprint.

Dopo la Sprint Review e prima del prossimo incontro Sprint Planning, il Team Scrum si riunisce per la Sprint Retrospective. Si tratta di una riunione di tre ore, per Sprint della durata mensile; in modo proporzionale è allocato meno tempo per Sprint più brevi.

Lo scopo della Sprint Retrospective è di:

• Esaminare come l'ultimo Sprint sia andato, per quanto riguarda le persone, le relazioni, i processi e gli strumenti;
• Identificare e ordinare i maggiori elementi che sono andati bene e il potenziale di miglioramento;
• Creare un piano per attuare i miglioramenti al modo di lavorare del Team Scrum.

Lo Scrum Master incoraggia il Team Scrum a migliorare, all'interno del framework di processo Scrum, il proprio processo di sviluppo e le pratiche per rendere più efficace e divertente il prossimo Sprint. Durante ogni Sprint Retrospective, il Team Scrum pianifica i modi per aumentare la qualità del prodotto adattando la definizione di “Fatto” secondo i casi.

Entro la fine della Sprint Retrospective, il Team Scrum dovrebbe aver individuato i miglioramenti che saranno implementati nel prossimo Sprint. Attuare tali miglioramenti durante il prossimo Sprint è l'adattamento all'ispezione del Team Scrum stesso. Anche se i miglioramenti possono essere implementati in ogni momento, la Sprint Retrospective fornisce un'opportunità formale per focalizzarsi sull'ispezione e l'adattamento.

Gli artefatti di Scrum rappresentano il lavoro o il valore in diversi modi tale da essere utili a fornire trasparenza e opportunità di ispezione e adattamento. Gli artefatti definiti da Scrum sono specificatamente progettati per massimizzare la trasparenza delle informazioni chiavi necessarie ad assicurare ai Team Scrum il successo nella realizzazione di un incremento “Fatto”.

Il Product Backlog è una lista ordinata dei "requisiti" relativi ad un prodotto. Contiene i Product Backlog Item (PBI) a cui viene assegnata dal Product Owner una priorità in base a considerazioni quali il rischio, il valore di business, le date in cui devono essere realizzati. Le funzionalità aggiunte al backlog sono comunemente scritte utilizzando il formato delle "storie".

Il Product Backlog rappresenta “cosa” deve essere fatto, organizzato in base all'ordine relativo in cui dovrà essere realizzato. È aperto e modificabile da tutti, ma il Product Owner è il responsabile ultimo della sua gestione e delle priorità da dare alle storie nel backlog per il team di sviluppo.

Il Product Backlog contiene delle stime approssimative sia del valore di business che dello sforzo necessario a svilupparle; questi ultimi valori sono spesso espressi mediante story point utilizzando una successione Fibonacci arrotondata. Queste stime aiutano il Product Owner a calcolare la timeline e possono influenzare l'ordine dei backlog item. Ad esempio se le funzionalità "aggiungi il controllo ortografico" e "aggiungi un supporto alle tabelle" avessero lo stesso valore di business, quella che richiede il minore sforzo di sviluppo avrà probabilmente una priorità più alta, in quanto il ROI (Return on Investment) sarebbe maggiore.

Il Product Backlog e il valore di business associato a ciascun item è responsabilità del Product Owner. Invece, lo sforzo stimato per completare ciascun backlog item è determinato dal team di sviluppo. Il team contribuisce nello stimare gli item e le User-Story, mediante story-point o mediante diverse misurazioni, quali quelle temporali (per es. ore o giorni).

Lo Sprint Backlog è la lista del lavoro che il team di sviluppo deve effettuare nel corso dello Sprint successivo. Questa lista viene generata selezionando una quantità di storie/funzionalità a partire dalla cima del Product Backlog determinata da quanto il team di sviluppo ritiene possa realizzare durante lo Sprint: ovvero avere una quantità di lavoro tale da riempire lo Sprint.

Questo viene fatto dal team di sviluppo chiedendosi "Possiamo fare anche questa?" e aggiungendo storie/funzionalità allo Sprint Backlog. Il team di sviluppo dovrebbe tener conto della "velocità" media ottenuta durante gli Sprint precedenti (il totale degli story point accumulati per ciascuna delle storie completate durante gli Sprint precedenti) nel momento in cui seleziona le storie/funzionalità per il nuovo Sprint, e utilizzare tale numero come guida di quanto lavoro potranno realizzare. Un altro parametro che si può anche tenere in considerazione è la capacità, per molti aspetti correlata alla velocità.

Le storie/funzionalità sono suddivise dal team di sviluppo in attività (task) che taluni considerano buona pratica di durata tra le quattro e le sedici ore di lavoro. Grazie a questo livello di dettaglio il team di sviluppo comprende meglio cosa fare, e potenzialmente, ognuno può prendere in carico un'attività dalla lista. I task non vengono mai assegnati, piuttosto, le attività vengono prese in carico dai membri del team durante il Daily Scrum, in base alle priorità predefinite e alle competenze dei membri del team. Questo promuove l'auto-organizzazione e la responsabilizzazione (buy-in) degli sviluppatori.

Lo Sprint Backlog è di proprietà del team di sviluppo, e tutte le stime incluse sono effettuate dal team stesso. Spesso viene utilizzata una task board per visualizzare i cambiamenti di stato dei task nello Sprint corrente, come ad esempio “to do”, “in progress” e “done”.

L'incremento è la somma di tutti gli elementi del Product Backlog completati durante uno Sprint e tutti gli Sprint precedenti.

Al termine dello Sprint, l'incremento dovrà essere realizzato in base a quanto concordato dal team di sviluppo nella "definition of done". L'incremento deve fornire un prodotto utilizzabile indipendentemente dal fatto che il Product Owner decida effettivamente di rilasciarlo.

Lo stesso argomento in dettaglio: Burn down chart.

Un burn down chart è una rappresentazione grafica del lavoro da fare su un progetto nel tempo. Di solito il lavoro rimanente (o backlog) è indicato sull'asse verticale e il tempo sull'asse orizzontale. Il diagramma rappresenta una serie storica del lavoro da fare. Esso è utile per prevedere quando avverrà il completamento del lavoro.

• Ken Schwaber e Jeff Sutherland, La Guida a Scrum. La Guida Definitiva a Scrum: Le Regole del Gioco (PDF), Scrum.Org and ScrumInc, 2020.

• Metodologia agile
• Extreme Programming
• Kaizen
• Kanban
• Lean software development

• Wikimedia Commons contiene immagini o altri file su Scrum

• Scrum.org.
• Scrum Alliance: transforming the world of work, su scrumalliance.org. URL consultato il 24 novembre 2009 (archiviato dall'url originale il 1º settembre 2010).
• La lista dei corsi pubblici Scrum.org in Italia, su courses.scrum.org. URL consultato il 23 gennaio 2013 (archiviato dall'url originale il 23 marzo 2015).
• Scrum in Praxis Encyclopedia, su praxisframework.org.
• Cosa sono le User Story, su productheroes.it
• Product Manager vs. Product Owner Revisited, su svpg.com, 2016. URL consultato il 13 dicembre 2016.
• Product manager vs product owner - Qual è la differenza?, su 2-pm.it, 2021. URL consultato il 4 aprile 2021.

• (EN) Google Tech Talks, Hyperproductive Distributed Scrum Teams, su YouTube, Jeff Sutherland, 4 settembre 2008. URL consultato il 27 gennaio 2016.
• (EN) Google Tech Talks, Self-Organization: The Secret Sauce for Improving your Scrum team, su YouTube, Jeff Sutherland, 10 febbraio 2009. URL consultato il 27 gennaio 2016.
• Scrum at Large: Managing 100 People and More, su tvagile.com.
• Andrea Tomasini's keynote about Agile in an Enterprise, su slideshare.net.
• Scrum Training Series: Scrum Tutorial, su ScrumTrainingSeries.com.

Portale Informatica: accedi alle voci di Wikipedia che trattano di informatica