Scrum

Scrum è un framework per l'esecuzione di progetti basato su principi e valori Agile. Definisce un set di attività che consentono al team di offrire più valore ai clienti in meno tempo. Queste attività offrono ai clienti la possibilità di esaminare, guidare e influire sul lavoro del team durante lo sviluppo. Questo approccio non tenta di definire tutto all'inizio di un progetto. Al contrario, il team lavora in brevi iterazioni (noti anche come sprint) perfezionando il piano man mano che il lavoro procede. Per informazioni sui principi e sui valori Agile su cui si basa Scrum, vedere Principi e valori di Agile di Jeff Sutherland.

MSF for Agile Software Development v5.0 si basa su Scrum. Pertanto, il team può adottare Scrum utilizzando gli strumenti integrati con le attività di sviluppo principali.

In questo argomento Preparare il progetto Pianificare il progetto Pianificare uno sprint Eseguire uno sprint Tenere traccia del progetto

Preparare il progetto

Prima di iniziare il progetto, è necessario effettuare le attività seguenti:

• stabilire il business case

• assemblare un team

• configurare l'infrastruttura del team

Per stabilire un business case, identificare la giustificazione e l'esigenza aziendale, definire la visione e ottenere il finanziamento. Il libro di Geoffrey Moore "Crossing the Chasm" rappresenta un'ottima linea guida per delineare la visione. Per ulteriori informazioni, vedere le informazioni sulla pubblicazione Crossing the Chasm relativa alle strategie di marketing specifiche per i prodotti ad alta tecnologia.

Dopo avere stabilito il business case, è necessario assemblare il team e identificare lo ScrumMaster e il proprietario del prodotto. Per ulteriori informazioni, vedere Ruoli.

Infine, il team deve configurare l'infrastruttura. Ad esempio, installare Visual Studio Team Foundation Server e Visual Studio Application Lifecycle Management (ALM), creare e possibilmente personalizzare il progetto team e configurare le procedure di progettazione. Per ulteriori informazioni, vedere Introduzione a Visual Studio Application Lifecycle Management, Personalizzazione del progetto team e Procedure di progettazione.

Pianificare il progetto

In un progetto di Scrum, il team impiegherà la maggior parte del tempo a sviluppare il prodotto in una serie di sprint. Tuttavia, il team deve innanzitutto creare un piano di alto livello per il progetto. Questo piano rappresenta una guida di orientamento per le decisioni più dettagliate che il team prenderà durante il corso del progetto, che cambierà man mano che viene implementato. Al termine della pianificazione del progetto, il team avrà creato un backlog del prodotto e, se necessario, un piano di rilascio.

Compilare il backlog del prodotto

Il backlog del prodotto è un elenco di storie utente che descrivono le necessità e le stime degli utenti. Le storie utente vengono classificate in ordine di priorità in base al valore e al rischio aziendale e il team valuta le storie utente in unità astratte definite punti della storia.

	Creare storie utente: secondo la definizione tratta dal libro "User Stories Applied" di Mike Cohn "una storia utente descrive funzionalità utili sia per l'utente che per l'acquirente di un sistema o di un software". Le storie utente sono scritte dal punto di vista dell'utente finale. Di seguito è riportato un esempio: "Essendo già cliente, desidero trovare un pasto che ho ordinato in precedenza". Per ulteriori informazioni, vedere Creazione di un backlog prodotto di grandi dimensioni.
	Classificare le storie utente in ordine di priorità: il proprietario del prodotto classifica le storie utente in ordine di priorità nel backlog del prodotto collaborando con i clienti per comprendere ciò che loro ritengono importante e con il team per comprendere rischi e dipendenze. Il proprietario del prodotto specifica le priorità assegnando una classificazione a ogni storia utente per indicare l'ordine in cui il team deve implementarle. Il proprietario del prodotto può utilizzare molte tecniche per analizzare e confrontare il valore delle storie utente. Se il team già dispone di un metodo comprovato di definizione delle priorità, utilizzare tale metodo. Alcune tecniche di definizione delle priorità sono strettamente associate alla community Agile, ad esempio il modello Kano della soddisfazione del cliente e la ponderazione relativa di Karl Wiegers. Per ulteriori informazioni sulla ponderazione relativa, vedere la pagina seguente sul Web: First Things First: Prioritizing Requirements. Altre tecniche di definizione delle priorità, ad esempio definizione delle priorità dei costi, valore attuale netto, tasso di rendimento interno, sono ben definite al di fuori della community Agile. Queste tecniche sono anche valide e appropriate per definire le priorità nel backlog del prodotto in un progetto Scrum. Per ulteriori informazioni, vedere la seconda parte "Estimating Size" della pubblicazione Agile Estimation and Planning relativa alle stime e alla pianificazione Agile.
	Stimare le storie utente: Il team stima in modo collaborativo ogni storia utente in punti della storia. Secondo la definizione tratta dal libro "Agile Estimation and Planning" di Mike Cohn "i punti della storia sono un'unità di misura per esprimere le dimensioni complessive di una storia utente, una funzionalità o un altro elemento di lavoro". I punti della storia sono valori relativi che non vengono tradotti direttamente in un numero specifico di ore. I punti della storia consentono invece a un team di quantificare le dimensioni generali della storia utente. Queste stime relative sono meno precise in modo da richiedere meno sforzo in fase di determinazione ma perdurano meglio nel tempo. Realizzando stime in punti della storia, il team fornirà inizialmente le dimensioni generali delle storie utente e svilupperà successivamente una stima più dettagliata delle ore di lavoro necessarie, quando i membri del team saranno pronti per iniziare l'implementazione delle storie utente.

Determinare la velocità del team

Prima di creare il piano di rilascio e pianificare ogni sprint, il team deve determinare la velocità. La velocità del team è rappresentata dal numero di punti della storia che possono essere completati in uno sprint.

Se il team ha calcolato la velocità raccogliendo i dati che indicano il numero di storie utente completate in un determinato periodo di tempo, utilizzare tali dati, in quanto forniscono la visione migliore della velocità del team. Se non si dispone già di tali dati ma si sta iniziando a eseguire il progetto utilizzando ALM di Visual Studio e MSF for Agile Software Development v5.0, questi dati verranno raccolti nel corso del progetto. Per ulteriori informazioni, vedere Rapporto Stato di tutte le iterazioni.

Se i dati cronologici non sono disponibili, il team può effettuare una stima approssimativa del numero di punti della storia che possono essere completati nel primo sprint. Esaminare le storie utente valutate in cima allo stack di priorità ed eseguire una rapida valutazione di quante storie potrebbero essere completate in uno sprint. Aggiungere i punti della storia per ognuna di tali storie utente per ottenere una stima iniziale. Dopo il primo sprint, è possibile utilizzare dati cronologici per determinare la velocità del team. Nei primi sprint è possibile aspettarsi una variazione sostanziale in quanto il team sta imparando come effettuare le stime in modo coerente. Dopo diversi sprint la velocità calcolata del team dovrebbe diventare più stabile. Non appena la velocità calcolata del team diventa stabile, valutare nuovamente il piano di rilascio.

La stima della velocità del team fornisce un punto iniziale da utilizzare per determinare quante storie utente devono essere implementate nello sprint, ma la stima non costituisce la base dell'impegno del team. L'impegno del team dovrà basarsi su stime più dettagliate delle attività richieste per completare le storie utente. Per ulteriori informazioni, vedere Cartella di lavoro Pianificazione prodotto.

Determinare il piano di rilascio

A ogni sprint il team completerà un incremento nel prodotto da rilasciare. Sebbene le storie utente che il team implementa siano pronte per essere distribuite alla fine dello sprint, è possibile che non apportino sufficiente valore aziendale da giustificare effettivamente il rilascio del prodotto. Pianificare le versioni assegnandole a iterazioni:

• Identificare gruppi di storie utente che, insieme, garantiscano valore aziendale sufficiente da offrire ai clienti.

• Determinare gli sprint in cui il team prevede di completare tali gruppi di storie utente.

Man mano che il team procede con il lavoro, verranno aggiunte storie utente al backlog del prodotto, mentre altre potranno essere rimosse. Inoltre, la priorità di alcune storie utente potrebbe cambiare ed è possibile che determinate storie utente vengano implementate in anticipo o in ritardo rispetto a quanto originariamente previsto. Il proprietario del prodotto gestirà il piano di rilascio insieme al backlog del prodotto per tutta la durata del progetto.

Per ulteriori informazioni, vedere Cartella di lavoro Pianificazione prodotto.

Preparare il primo sprint

Uno sprint è un'iterazione limitata nel tempo dello sviluppo che in genere dura da uno a quattro settimane e che produce un incremento nel prodotto da rilasciare. Prima che il team inizi il primo sprint, il proprietario del prodotto prepara il backlog del prodotto. Le storie utente con una priorità sufficientemente elevata da essere inserite nel primo sprint devono essere pronte affinché vengano implementate dal team. Il proprietario del prodotto deve preparare il backlog del prodotto eseguendo le attività seguenti:

• Suddividere le storie utente in storie minori.

• Fornire informazioni dettagliate sulle storie utente che il team dovrà suddividere in attività.

Il proprietario del prodotto riterrà eccessive le dimensioni di una storia utente se essa rappresenta una quantità significativa della velocità totale del team. Ad esempio, una storia utente costituita da 15 punti della storia è considerata troppo grande da rientrare nella riunione di pianificazione dello sprint se la velocità del team è costituita da 30 punti della storia. Il team accetterà solo metà dello sprint per completare la storia utente.

Il team chiederà inoltre i dettagli sulle storie utente per essere in grado di suddividerle in attività e di stimare tali attività. Quando, ad esempio, il team esamina la storia utente "Come cliente desidero poter cercare un tipo di pasto", il team potrebbe porre i tipi di domande seguenti:

• "Deve trattarsi di una ricerca a testo libero o può essere una scelta da un elenco di tipi disponibili?"

• "Se più fornitori forniscono un pasto che corrisponde alla ricerca, come devono essere ordinati i risultati?"

Per ulteriori informazioni, vedere Preparazione per lo sprint successivo.

Pianificare uno sprint

Una volta che il team ha sviluppato il backlog del prodotto e ha stabilito un piano di rilascio, può iniziare a lavorare in sprint. Il team inizia lo sprint con una riunione di pianificazione dello sprint in cui si impegna a completare un set di storie utente dal backlog del prodotto. Il set di storie utente e le attività di supporto costituiscono insieme il backlog dello sprint. Per ulteriori informazioni, vedere Confronto tra i backlog prodotto e sprint.

Dopo l'inizio dello sprint, le storie utente presenti nel backlog dello sprint non vengono modificate. Pertanto, il piano deve essere sufficientemente dettagliato affinché il team possa tranquillamente adempiere all'impegno.

Per ulteriori informazioni, vedere Riunione di pianificazione dello sprint.

Scegliere le storie utente

Il team sceglie le storie utente che devono essere implementate nello sprint. Identifica le storie utente con la massima priorità e i cui punti della storia non superano la velocità stimata. Ad esempio, le quattro storie utente con la massima priorità potrebbero avere 8, 3, 7, 6 e 2 punti della storia. Se il team ha una capacità di 25 punti della storia per sprint, dovrà includere le prime quattro storie nel backlog dello sprint.

Per ulteriori informazioni, vedere Cartella di lavoro Backlog iterazione.

Identificare le attività

Il team valuta ogni storia utente per determinare le attività da svolgere per implementare la storia. Suddivide le storie utente in attività in modo da poter avere una migliore comprensione delle storie stesse al fine di riuscire ad adempiere all'impegno di completarle nello sprint.

I team che hanno già acquisito una certa esperienza con Scrum possono adempiere all'impegno senza dover suddividere le storie utente in attività.

Stimare le attività

Dopo aver identificato le attività, il team stima il tempo (in ore) impiegato per ogni attività. I team utilizzano spesso la tecnica denominata planning poker per stimare le attività. Questa tecnica è utile in quanto consente al team di non effettuare stime più accurate del necessario.

Impegnarsi nelle storie utente

Il team utilizza la cartella di lavoro Backlog iterazione per assicurarsi di avere a disposizione un numero di ore di lavoro sufficiente per completare tutte le attività. Se lo sprint implica più lavoro di quanto possa essere gestito dal team nello sprint, le storie utente con la classificazione più bassa devono essere rimosse affinché il lavoro rientri nella capacità del team per lo sprint. È possibile sostituire le storie più grandi che non si adattano allo sprint con storie più piccole con una priorità più bassa.

Il team si impegna a completare le storie utente prefissate. Assume questo impegno fatto salvo che il proprietario del prodotto non tenterà di introdurre lavoro aggiuntivo o modificare le priorità delle storie utente in fase di implementazione nello sprint.

Eseguire uno sprint

Durante uno sprint, il team completa le attività necessarie allo scopo di implementare le storie utente nel backlog dello sprint. Il team può tenere traccia dello stato di avanzamento e assicurarsi di rispettare i criteri di accettazione dei clienti e i criteri del team per il software finito prima della fine di ogni sprint.

Completare le storie utente

Dopo aver pianificato lo sprint, il team avrà un elenco di storie utente che deve completare durante lo sprint. Queste storie utente sono state suddivise in attività. Ogni membro del team si iscrive a un'attività quando inizia lo sprint. Dopo avere completato tale attività, il membro del team aggiorna lo stato e si iscrive a un'altra attività. In questo modo, il team lavora rispettando l'elenco delle attività, completando le storie utente nel backlog dello sprint. Un membro del team può indicare le attività che vengono completate durante l'archiviazione del codice. Per ulteriori informazioni, vedere Associare elementi di lavoro agli insiemi di modifiche.

Per ulteriori informazioni sull'assegnazione delle attività e l'aggiornamento del relativo stato, vedere Attività (Agile).

Scrum si basa sulla comunicazione tra le persone più che sui processi formali per garantire che vengano comprese le dipendenze, venga condivisa l'esperienza e le modifiche ai piani vengano apportate in modo efficace. Tenere ogni giorno una breve riunione Scrum in cui ogni membro del team condivide alcuni dettagli sul lavoro portato a termine nel corso del giorno precedente, su quello che intende portare a termine in giornata e su eventuali problemi o ostacoli che potrebbero interessare altri membri del team o richiederne il supporto. Per ulteriori informazioni, vedere Riunione scrum giornaliera.

Nel libro "Extreme Programming Explained" Kent Beck spiega come sia più conveniente correggere un bug il prima possibile. Il team deve inoltre capire cosa sia importante per il cliente. Forse il cliente valuta la qualità anziché un numero maggiore di funzionalità. Il proprietario del prodotto deve conoscere questo tipo di informazioni poiché i clienti controllano il flusso del lavoro al team.

Il software prodotto da un team Scrum non dovrebbe contenere errori. Tuttavia, è probabile che il team rileverà alcuni bug nei progetti. Gestire i bug tenendo presente il fatto che è più conveniente e più rapido correggerli appena trovati anziché rimandarli a un momento successivo. Quando il team rileva dei bug, deve correggerli immediatamente. Se il team non può correggere il bug nello stesso giorno in cui è stato trovato, creare un elemento di lavoro bug in ALM di Visual Studio ed eseguire la correzione prima della fine dello sprint.

Per ulteriori informazioni, vedere Bug (Agile).

Tenere traccia dello stato di avanzamento dello sprint

Il team può tenere traccia dello stato di avanzamento dello sprint per assicurarsi che il lavoro venga completato come previsto e che soddisfi i criteri di accettazione. I team Scrum utilizzano molto spesso un rapporto burn-down per tenere traccia dello stato di avanzamento di uno sprint. MSF for Agile Software Development v5.0 offre un set di rapporti che i team possono utilizzare per tenere traccia dello stato di avanzamento di uno sprint.

Rapporto Burn-down e velocità (Agile)

Rapporto Indicatori di qualità di compilazione

Rapporto Stato di avanzamento piano test

Rapporto Stato storie (Agile)

I team constatano spesso di aver bisogno di più o meno tempo per completare un'attività di quanto stimato durante la riunione di pianificazione dello sprint. Questo tipo di variazione è normale. È possibile registrare queste informazioni specificando il tempo effettivo impiegato dal team per lo svolgimento dell'attività.

Durante l'avanzamento dello sprint il team potrebbe identificare la necessità di dover svolgere un lavoro non previsto che però si è rivelato necessario al fine del completamento di una storia utente. In questo caso, creare un'attività, stimarla e determinare quindi se il team può completarla nelle ore rimanenti dello sprint. Se il team è in grado di completare l'attività, proseguire con lo sprint. Se invece non può completare l'attività nello sprint, incontrare il proprietario del prodotto per stabilire come procedere. Il proprietario del prodotto e il team possono risolvere il problema apportando i tipi di modifiche seguenti:

• Ridurre i criteri di accettazione per la storia utente, in modo da rendere l'attività non necessaria.

• Rimuovere la storia utente dal backlog dello sprint.

• Annullare lo sprint.

Finire lo sprint

Quando lo sprint volge al termine, assicurarsi che il team stia completando tutte le storie utente o i requisiti. Verificare, ad esempio, che i test di accettazione vengano superati e che ogni storia utente soddisfi i criteri definiti dal team. Per ulteriori informazioni sulle attività da eseguire, vedere la pagina Web Mitch Lacey & Associates, Inc..

Rapporto sullo stato dei bug

Rapporto Tendenze del bug

L'ultimo giorno dello sprint, il team illustrerà al proprietario del prodotto e possibilmente ai clienti le storie utente completate. Il proprietario del prodotto e clienti determineranno se accettano ogni storia utente. Per ulteriori informazioni, vedere Riunione della revisione sprint.

Dopo la revisione del cliente, il team terrà una retrospettiva. Per ulteriori informazioni, vedere Riunione retrospettiva.

Tenere traccia del progetto

Come il team lavora in sprint per produrre incrementi nel progetto, così i clienti sviluppano una migliore comprensione delle necessità rimanenti, il che può implicare eventuali modifiche all'ambiente aziendale. Il proprietario del prodotto lavora insieme ai clienti per capire tali modifiche. Il proprietario del prodotto gestirà il backlog del prodotto e il piano di rilascio per riflettere le modifiche e assicurarsi che il team disponga di tutto il necessario all'inizio di ogni sprint. Il team tiene traccia dello stato di avanzamento del prodotto nel suo complesso per assicurarsi che i progressi verso il completamento del progetto procedano correttamente.

Preparare lo sprint successivo

La validità del backlog del prodotto ha una relazione diretta con la qualità complessiva e la completezza del progetto. Il backlog deve essere regolarmente aggiornato, modificato e riformulato per assicurarsi che sia pronto ogni volta che il team sta per iniziare uno sprint.

Il proprietario del prodotto prepara il backlog del prodotto per lo sprint successivo eseguendo le attività seguenti:

• Aggiornamento delle storie utente e delle relative priorità in base alle nuove esigenze dei clienti.

• Suddivisione delle storie utente la cui implementazione è prevista nello sprint successivo.

Quando il team finisce uno sprint, le altre storie utente si avvicinano all'inizio del backlog del prodotto. Il proprietario del prodotto deve analizzare e suddividere le storie che si trovano all'inizio, in modo tale che il team possa implementarle nello sprint successivo. Per ulteriori informazioni, vedere la sezione Preparare il primo sprint riportata precedentemente in questo argomento. Mike Cohn definisce spesso questo processo come iceberg del backlog del prodotto. Man mano che il team lavora su un set di funzionalità, l'iceberg si scioglie lasciando affiorare nuovo lavoro e riducendo le proprie dimensioni. In questo processo, emergono ulteriori dettagli aggiuntivi, senza vincoli di spazio e tempo.

Mentre il team è impegnato nell'esecuzione di uno sprint, il proprietario del prodotto non può aspettarsi di avere dal team lo stesso livello di coinvolgimento nella gestione del backlog del prodotto avuto durante la preparazione del primo sprint. Per aiutare il proprietario del prodotto a preparare il backlog del prodotto con un'interruzione minima dello sprint, il team e il proprietario del prodotto discuteranno i problemi aperti relativi al backlog del prodotto nel corso dello sprint.

Tenere traccia dello stato di avanzamento del rilascio

Con l'avanzamento del progetto sprint dopo sprint, il team tiene traccia dello stato di avanzamento complessivo verso il rilascio successivo. Il team terrà traccia dello stato di avanzamento anche per stimare e migliorare la velocità. Man mano che il team tiene traccia dello stato di avanzamento, deve tentare di rispondere ai tipi di domande seguenti:

• Stiamo lavorando sulle storie utente più appropriate? Il backlog del prodotto viene ridefinito con nuove storie utente con l'avanzamento del progetto. Tuttavia, se il numero totale di storie nel backlog non diminuisce, sebbene vengano completate storie a ogni sprint, il team deve esaminare la causa. Le storie completate potrebbero non rappresentare le scelte migliori. Il team deve prefissarsi una visione e un obiettivo per ogni rilascio e deve assicurarsi che le storie siano collegate direttamente a ciò che viene richiesto dal cliente.

• Siamo in presenza di un debito tecnico? Alcuni team considerano una storia utente finita anche se rimane ancora del lavoro da completare come, ad esempio, correggere alcuni bug. Tali team si assumono un debito tecnico che devono pagare in un secondo momento, generalmente a un costo maggiore.

ALM di Visual Studio fornisce molti rapporti per aiutare il team a tenere traccia dello stato di avanzamento per molti sprint.

Rapporto Stato di tutte le iterazioni

Rapporto Panoramica storie (Agile)

Rapporto Stato storie (Agile)

È possibile creare rapporti e query elemento di lavoro personalizzati per tenere traccia dello stato di avanzamento. Per ulteriori informazioni, vedere Creazione e personalizzazione di rapporti per Visual Studio ALM e Individuazione di bug, attività e altri elementi di lavoro.

Finire il rilascio

Se il team non accumula alcun debito tecnico, può rilasciare il prodotto non appena ha completato gli sprint del rilascio, senza alcun lavoro aggiuntivo. Il team e il proprietario del prodotto tengono riunioni retrospettive e per la revisione del cliente al fine di esaminare il rilascio nel suo complesso.

Tuttavia, il debito tecnico è un problema difficile che i team non possono eliminare facilmente. Se il proprio team, come molti altri, continua ad accumulare debito tecnico, sarà necessario dedicare tempo allo svolgimento di tutto il lavoro rimanente per finire le storie utente prima di rilasciare il prodotto. Nella retrospettiva per il rilascio, considerare le azioni che il team deve eseguire negli sprint successivi al fine di evitare di assumere altro debito.

Vedere anche

Concetti

Procedure di progettazione

Scegliere un modello di processo

Pianificazione e rilevamento di progetti

Altre risorse

MSF for Agile Software Development v5.0