Scrum (informatica)

Da Wikipedia, l'enciclopedia libera.

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

« Scrum è un framework di processo utilizzato dai primi anni 1990 per gestire lo sviluppo di prodotti complessi. Scrum non è un processo o una tecnica per costruire prodotti ma piuttosto è un framework all’interno del quale è possibile utilizzare vari processi e tecniche. Scrum rende chiara l’efficacia relativa del tuo product management e delle pratiche di sviluppo usate in modo da poterle migliorare. »
(Jeff Sutherland, La Guida a Scrum™[1])

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).

Storia[modifica | modifica wikitesto]

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, Ken 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.

La Teoria di Scrum[modifica | modifica wikitesto]

Scrum si basa sulla teoria dei controlli empirici 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 iterativo ed un approccio incrementale per ottimizzare la prevedibilità ed il controllo del rischio.[1]

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

Trasparenza[modifica | modifica wikitesto]

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.

Ispezione[modifica | modifica wikitesto]

Coloro che utilizzano Scrum devono ispezionare frequentemente gli artefatti di Scrum e il progresso verso un obiettivo per rilevare le variazioni indesiderate. Le loro ispezioni non dovrebbero essere così frequenti da superare le soglie di tolleranza del processo alle ispezioni da rappresentare un’interruzione del lavoro. Le ispezioni sono più utili quando diligentemente eseguite da ispettori qualificati in corrispondenza del punto di lavoro.

Adattamento[modifica | modifica wikitesto]

Se chi ispeziona verifica che uno o più aspetti del processo sono al di fuori dei limiti accettabili e che il prodotto finale non potrà essere accettato, deve regolare il processo o il materiale lavorato. La regolazione deve essere portata a termine il più rapidamente possibile per ridurre al minimo l’ulteriore scarto. Scrum prescrive quattro occasioni formali per l’ispezione e l’adattamento, come descritto nella sezione Gli Eventi di Scrum di questo documento.

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

Caratteristiche[modifica | modifica wikitesto]

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 con caratteristiche precise per creare occasioni di ispezione e controllo del lavoro svolto.

Il framework Scrum è costituito dai Team Scrum e dai ruoli, eventi, artefatti e regole a essi associati. 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 gli eventi, i ruoli e gli artefatti governando le relazioni e le interazioni tra essi anche se le strategie specifiche per l’utilizzo del framework Scrum variano e vengono descritte in molti testi specifici.

Ruoli[modifica | modifica wikitesto]

Fino a qualche tempo fa le persone all'interno di un'organizzazione dove si fosse utilizzato Scrum venivano divisi 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.

I ruoli principali nel processo Scrum costituiscono il Team Scrum e sono quelli impegnati nel progetto — sono coloro che realizzano il prodotto (obiettivo del progetto).

Il Team Scrum[modifica | modifica wikitesto]

Il Team Scrum è formato dal Product Owner, Il Team di sviluppo (Development Team) e 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.

Product Owner
Il Product Owner rappresenta gli stakeholders ed è la voce del cliente. È responsabile per assicurare che il team fornisca valore al business. Il Product Owner scrive gli item centrati sui bisogni dei clienti (tipicamente user stories), assegna loro la priorità, e li aggiunge al product backlog. I team Scrum debbono avere un Product Owner e si raccomanda che questo ruolo non sia combinato con quello dello ScrumMaster.[8]
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 3-9 persone, con competenze cross-funzionali, che effettuano il lavoro effettivo (analisi, progettazione, sviluppo, test, comunicazione tecnica, documentazione...). Il Team di sviluppo in Scrum si auto-organizza, sebbene possono esserci un'interfaccia verso il PMO (Project Management Office).
ScrumMaster
Lo ScrumMaster è responsabile della rimozione degli ostacoli che limitano la capacità del team di raggiungere l'obiettivo dello Sprint e i deliverable previsti. Sebbene sia un ruolo manageriale, lo ScrumMaster non è il team leader, ma piuttosto colui che facilita una corretta esecuzione del processo. Lo ScrumMaster detiene l'autorità relativa all'applicazione delle norme, spesso presiede le riunioni importanti e pone sfide alla squadra per migliorarla. Una parte fondamentale del ruolo di ScrumMaster è quello di proteggere il Team di sviluppo e tenerlo concentrato sui compiti fungendo da cuscinetto verso qualsiasi influenza di distrazione. Il ruolo viene anche denominato servant-leader per rinforzare queste due prospettive.
Lo ScrumMaster differisce da un Project Manager in quanto questi ultimi possono avere responsabilità di gestione del personale che invece non sono in carico allo ScrumMaster.

Ruoli ausiliari[modifica | modifica wikitesto]

I ruoli ausiliari nei team Scrum sono quelli che non hanno alcun ruolo formale o coinvolgimento frequente nel processo Scrum — ma comunque devono essere presi in considerazione.

Stakeholder
I principali stakeholder sono clienti, venditori. Sono le persone che permettono il progetto e per i quali il progetto produce i benefici concordati che ne giustificano la produzione. Sono coinvolti direttamente nel processo solo durante le Sprint Review.
Manager
Persone che controllano l'ambiente di lavoro.

Sprint[modifica | modifica wikitesto]

Processo Scrum.

Lo sprint è un'unità di base dello sviluppo in Scrum ed è di durata fissa, generalmente da una a quattro settimane.

Ogni Sprint è preceduto da una riunione di pianificazione in cui vengono identificati gli obiettivi e vengono stimati i tempi. Durante uno sprint non è permesso cambiare gli obiettivi, quindi le modifiche sono sospese fino alla successiva riunione di pianificazione, in cui potranno essere inserite nel prossimo sprint.

Al termine di ogni sprint il team di sviluppo consegna una versione potenzialmente completa e funzionante del prodotto, contenente gli avanzamenti decisi nella riunione di pianificazione dello sprint.

Nel corso di ogni sprint, il team crea porzioni complete di un prodotto. L'insieme delle funzionalità che vengono inserite in un determinato sprint provengono dal product "backlog", che è una lista ordinata di requisiti. La selezione di quali item del backlog verranno effettivamente inseriti nello sprint (a costituire l'obiettivo dello sprint o "sprint goal") viene effettuata durante lo sprint planning meeting. Durante questo meeting, il Product Owner comunica al team quali item del product backlog vorrebbe che fossero completati (quelli con più alta priorità). Il team determina quindi quanti di questi pensa di poter completare durante il prossimo sprint e registra questo dato nello sprint backlog.[2]

Lo sprint backlog è di esclusiva proprietà del team di sviluppo, quindi durante uno sprint la modifica dello sprint backlog non è consentita a nessun altro ad eccezione del team di sviluppo. Lo sprint goal non dovrebbe essere cambiato durante lo sprint. Lo sviluppo è di durata fissa, in modo tale che lo sprint termini alla data prefissata; 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.

Eventi[modifica | modifica wikitesto]

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 è trascorsa pianificando senza permettere l’introduzione di sprechi nel processo di pianificazione.[9] Oltre allo stesso Sprint, che è un contenitore di tutti gli altri eventi, ogni evento in Scrum è una 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 del meeting Sprint Planning, 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.

Sprint Planning meeting[modifica | modifica wikitesto]

All'inizio di ogni ciclo di sprint (ogni 7–30 giorni), viene tenuto uno “Sprint planning meeting”[10].

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

Il meeting Sprint Planning è un incontro della durata di otto ore per uno Sprint di un mese. Per Sprint più brevi, l’evento è proporzionalmente più rapido. Ad esempio, Sprint di due settimane ha un meeting Sprint Planning 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 30 giorni)
    • (Prima parte) l'intero Scrum team:[11] definisce insieme al Product Owner l'obiettivo dello Sprint e l'insieme di storie su cui impegnarsi.
    • (Seconda parte) il Team di sviluppo:[12] definisce un piano per lo Sprint, risultante nello Sprint Backlog.

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

Daily Scrum[modifica | modifica wikitesto]

Un incontro daily scrum nel stanza del team. La scelta di questo posto consente al team di iniziare in tempo.

Ogni giorno durante lo Sprint, viene tenuta una riunione di comunicazione del team di progetto. Questo meeting viene chiamato "daily scrum", o "daily standup" ed 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 15 minuti
  • Si partecipa rimanendo in piedi, per non dare modo ai partecipanti di distrarsi ed 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:[13]

  • Che cosa è stato fatto dopo l’ultima riunione?
  • Che cosa si farà prima della prossima riunione?
  • Quali sono gli ostacoli impedimenti / ostacoli incontrati?
  • Gli eventuali impedimenti / ostacoli identificati durante questo meeting vengono documentati dallo ScrumMaster 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 Development Team 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 Meeting 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 d’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"

Backlog Grooming: storytime[modifica | modifica wikitesto]

Il team dovrebbe impiegare del tempo durante uno sprint per effettuare il product backlog grooming. Questo è il processo di stima del backlog esistente utilizzando sforzo/punti, 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 grooming 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.

Scrum of Scrums[modifica | modifica wikitesto]

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”

Sprint Review[modifica | modifica wikitesto]

Alla fine dello Sprint si tiene l’incontro di Sprint Review[14] 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 una 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’è. Lui o lei progetta la possibile data di completamento in base alla misura del progresso fino ad oggi;
  • L’intero gruppo collabora su cosa fare dopo, così la Sprint Review fornisce un prezioso contributo alle successive riunioni di Sprint Planning.

Sprint Retrospective[modifica | modifica wikitesto]

La Sprint Retrospective [15] è l’occasione per il Team Scrum per ispezionare se 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 lo 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 è andato per quanto riguarda le persone, le relazioni, I processi e gli strumenti;
  • Identificare e ordinare i maggiori elementi che son andati bene e il potenziale di miglioramento;
  • Creare un piano per attuare i miglioramenti al modo di lavorare dello Scrum Team.

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 una opportunità formale per focalizzarsi sull’ispezione e l’adattamento.

Artefatti[modifica | modifica wikitesto]

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”.

Product Backlog[modifica | modifica wikitesto]

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).

Sprint Backlog[modifica | modifica wikitesto]

La scrum task board.

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”.

Incremento[modifica | modifica wikitesto]

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.

Burn down[modifica | modifica wikitesto]

Un esempio di burn down chart fper un'iterazione completata, mostra l'effort rimanente e le attività per ciascuno dei 21 giorni di lavoro di una iterazione lunga un mese.
Exquisite-kfind.png Per approfondire, vedi 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.

Note[modifica | modifica wikitesto]

  1. ^ a b Ken Schwaber e Jeff Sutherland, La Guida a Scrum™, p. 3.
  2. ^ a b Ken Schwaber, Agile Project Management with Scrum, Microsoft Press, 1º febbraio 2004, ISBN 978-0-7356-1993-7.
  3. ^ New New Product Development Game, Cb.hbsp.harvard.edu, 1º gennaio 1986. URL consultato il 13 settembre 2012.
  4. ^ The Knowledge Creating Company, Books.google.ru. URL consultato il 13 settembre 2012.
  5. ^ a b Hirotaka Takeuchi, Nonaka, Ikujiro, The New Product Development Game (PDF) in Harvard Business Review, gennaio–febbraio 1986. URL consultato il 9 giugno 2010.
  6. ^ (EN) Ken Schwaber e Mike Beedle, Agile software development with Scrum, Prentice Hall, 2002, ISBN 0-13-067634-9.
  7. ^ (EN) Ken Schwaber, Agile software development with Scrum, Microsoft, 2004, ISBN 0-7356-1993-X.
  8. ^ Scrum, Scrum Developer Courses, Scrum Knowledge Assessment, Scrum Guide, Ken Schwaber - Scrum Guides, Scrum.org, 2009. URL consultato il 3 aprile 2010.
  9. ^ Ken Schwaber e Jeff Sutherland, La Guida a Scrum™, p. 7.
  10. ^ Schwaber, p. 133
  11. ^ Ken Schwaber e Jeff Sutherland, La Guida a Scrum™, p. 9.
  12. ^ Ken Schwaber e Jeff Sutherland, La Guida a Scrum™, pp. 9–10.
  13. ^ Schwaber, p. 135
  14. ^ Schwaber, p. 137
  15. ^ Schwaber, p. 138

Voci correlate[modifica | modifica wikitesto]

Altri progetti[modifica | modifica wikitesto]

Collegamenti esterni[modifica | modifica wikitesto]

Video e slide[modifica | modifica wikitesto]