Metodologia Scrum: Come gestire i progetti con Scrum

1 – Preparazione del progetto

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

• stabilire il business case;
• assemblare un team;
• configurare l’infrastruttura del team.

In un progetto 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

E’ 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 “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.

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.

Alcune tecniche di definizione delle priorità sono strettamente associate alla community Agile, per esempio il modello Kano della soddisfazione del cliente e la ponderazione relativa di Karl Wiegers. Altre tecniche di definizione delle priorità, come la definizione delle priorità dei costi, il valore attuale netto e il tasso di rendimento interno, sono ben definite al di fuori della community Agile.

Stimare le storie utente

Il team stima in modo collaborativo ogni storia utente in punti della storia (Fig.7): “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” (“Agile Estimation and Planning”, Mike Cohn, 2005). 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, è consigliato utilizzare tali dati in quanto forniscono la visione migliore della velocità del team. Se non si dispone già di tali dati, dovranno essere raccolti nel corso del progetto.

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. E’ necessario 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. Dopo bisogna 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, è necessario 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.

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.

Per pianificare le versioni assegnandole a iterazioni si devono rispettare i passi seguenti:

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

Preparare il primo sprint

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

2 – 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.

La riunione di pianificazione si svolge in due parti, ciascuna delle quali deve durare metà del tempo complessivo previsto per la riunione. Nella prima parte della riunione il proprietario del prodotto incontra il team per discutere delle storie utente che potrebbero essere incluse nello sprint. Il proprietario del prodotto condividerà le informazioni e risponderà alle domande poste dal team in merito alle storie. Durante questa conversazione potrebbero emergere dettagli quali le origini dati, il layout dell’interfaccia utente, le aspettative in termini di tempi di risposta e considerazioni per la sicurezza e l’usabilità. Il team aggiungerà questi dettagli alle storie utente. Durante questa parte della riunione, il team otterrà informazioni sulla natura della compilazione.

Nella seconda parte della riunione, il team determina come svilupperà e testerà tali storie utente. Il team suddivide quindi le storie utente in attività e stima il lavoro necessario per completarle. La tecnica denominata planning poker consente di stimare le ore dell’attività. Tramite questo strumento, ogni membro del team può partecipare alla stima, anziché dipendere dagli esperti in materia per la stima delle proprie attività. Sia che si utilizzi questa tecnica o un’altra, sarà necessario coinvolgere tutto il team nella determinazione del numero di ore richieste per ogni attività.

Per completare le attività non deve essere necessario più di un giorno. Se il team determina che non è in grado di completare una o più delle storie utente richieste dal proprietario del prodotto perché le ore stimate per le attività superano il numero di ore disponibili, sarà necessario avvisare il proprietario del prodotto. Il proprietario del prodotto potrebbe sostituire una storia con una più piccola, suddividere la storia o mantenere la storia nel backlog del prodotto per uno sprint futuro.

Al termine di entrambe le parti della riunione di pianificazione, il team avrà:

• creato il backlog sprint, con le attività e le ore per ogni storia utente
• confermato che le storie utente verranno recapitate nello sprint
• inteso, come team auto-organizzato, il modo in cui lavorerà unitamente per soddisfare gli impegni

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.

Scegliere le storie utente

Il team sceglie le storie utente che devono essere implementate nello sprint e identifica le storie utente con la massima priorità e i cui punti della storia non superano la velocità stimata. È possibile utilizzare la cartella di lavoro Backlog iterazione per pianificare e tenere traccia dello stato di avanzamento del lavoro per ciascuna iterazione, anche nota come sprint. Questa cartella di lavoro consente di calcolare la capacità del team in base al lavoro richiesto stimato e rimanente definito per le attività. In questa cartella di lavoro sono presenti cinque fogli di lavoro.

I fogli di lavoro vengono utilizzati nei modi seguenti:

• Backlog iterazione: consente di verificare che tutte le attività siano assegnate a storie utente; rivedere e assegnare i livelli di lavoro richiesto a ogni attività; assegnare attività alle iterazioni.
• Impostazioni: consente di programmare l’iterazione.
• Interruzioni: consente di specificare le festività e altri giorni di astensione dal lavoro per il team e per i singoli membri.
• Capacità: consente di bilanciare il carico di lavoro tra il team.
• Burn-down: consente di stimare la fine dell’iterazione in base alle date di inizio per l’iterazione.

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.

3 – Eseguire uno sprint

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.

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. Il team deve tenere riunioni Scrum giornaliere. Ogni membro del team descrive ciò che ha realizzato dall’ultima riunione, il lavoro che prevede di completare nel giorno attuale e qualsiasi problema o difficoltà che potrebbe influire sugli altri membri del team o richiederne il supporto. Lo Scrum Master applica rigorosamente la struttura della riunione e si assicura che inizi puntualmente e si concluda nell’arco di 15 minuti circa. In questa riunione ogni membro del team risponde a tre domande:

1. Che cosa ho portato a termine rispetto all’ultima riunione Scrum?
2. Cosa porterò a termine prima della successiva riunione Scrum?
3. Quali problemi o difficoltà potrebbero influire sul lavoro?

La riunione deve iniziare e finire con puntualità ed essere organizzata alla stessa ora e nello stesso luogo tutti i giorni. Questa coerenza è di aiuto al team perché viene creato un modello a cui conformarsi.
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.

Una volta completata una o più iterazioni o sprint, è possibile analizzare il rapporto burn-down e velocità per determinare la velocità con cui il team ha proceduto con il lavoro.
Il burn-down mostra la tendenza del lavoro completato e rimanente in un periodo di tempo specificato. La velocità fornisce dei calcoli della frequenza di
lavoro completata e richiesta in base al periodo specificato. Inoltre, nel rapporto è presente un grafico che mostra la quantità di lavoro completato e rimanente assegnato ai membri
del team. È possibile visualizzare il rapporto burn-down e velocità basato sulle ore lavorate o sul numero di elementi di lavoro che sono stati risolti e chiusi.

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, è necessario 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à, si prosegue con lo sprint. Se invece non può completare l’attività nello sprint, il team incontra 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.

Nell’ultimo giorno dello sprint, il team incontra il proprietario del prodotto, i clienti e le parti interessate per accettare il lavoro completato e identificare nuovi requisiti. Durante lo sprint, il team deve avere già raccolto e incorporato i commenti e i suggerimenti. Il team deve inoltre avere già eseguito i test di accettazione per ogni storia utente completata. In questa riunione il team dimostrerà tutte le storie utente che ha completato nello sprint. Il proprietario del prodotto, i clienti e le parti interessate accettano le storie utente che soddisfano le aspettative. In base a questa riunione, alcune storie utente verranno accettate come complete. Nel backlog del prodotto verranno mantenute le storie utente incomplete e verranno aggiunte nuove storie utente.

Entrambi i set di storie utente verranno classificati e stimati o stimati di nuovo nella successiva riunione di pianificazione dello sprint. Dopo questa riunione e la riunione retrospettiva, il team pianificherà lo sprint successivo. Poiché le esigenze aziendali cambiano rapidamente, è possibile sfruttare questa riunione con il proprietario del prodotto, i clienti e le parti interessate per rivedere nuovamente le priorità del backlog del prodotto.

4 – 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, gestisce 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.

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 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 a domande del seguente tipo:

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

Per ogni iterazione definita per le aree del prodotto specificate, questo rapporto (Fig.12) visualizza le informazioni seguenti:

• Storie chiuse: il numero di storie utente chiuse. Questi valori sono derivati dai valori correnti specificati per l’iterazione e lo stato di ogni storia utente.
• Stato di avanzamento (Ore): una rappresentazione numerica e visiva a due barre che rappresenta i valori per Stima Originale (grigio), Completato (verde), Rimanente (celeste), basati sul rollup delle ore definite per tutte le attività. Questi valori sono derivati dai valori correnti specificati per l’iterazione e le ore di ogni attività.
• Bug: un valore numerico e una rappresentazione visiva per tutti i bug, raggruppati in base agli stati correnti di Attivo (blu), Risolto (oro) e Chiuso (verde).Questi valori sono derivati dai valori correnti specificati per l’iterazione e lo stato di ogni bug.

Inoltre, è possibile fare clic su un’iterazione per accedere al rapporto burn-down e velocità per quell’iterazione.

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.