Durante lo sviluppo di un progetto con una metodologia agile come SCRUM è necessario svolgere diversi meeting con obiettivi e modalità diversi.
Le riunioni previste in Agile/SCRUM (dette anche Cerimonie) sono: Release Planning, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, Backlog Refinement.
Nel Release Planning Meeting il Product Owner, lo Scrum Master ed il Team di Sviluppo si incontrano per condividere la Roadmap e cioè una visione complessiva del progetto e del numero di Sprint.
I team agili di solito prevedono un ciclo di rilascio che comprende da 3-5 sprint.
Un Release Planning con orizzonte a medio termine consente al team di avere una visione per il futuro in modo che l’architettura o il design delle funzionalità pianificate possano essere se necessario adattati senza doverli ridisegnare.
Nello Sprint Planning Meeting il Product Owner, lo Scrum Master ed il Team di Sviluppo si incontrano per pianificare uno Sprint< e decidere insieme quali user stories e funzionalità il team cercherà di sviluppare durante lo Sprint (iterazione).
Il Product Owner ha la responsabilità di indicare nello Sprint Planning quali argomenti sono più importanti dal punto di vista del business.
Il Team di Sviluppo sotto la guida dello Scrum Master è responsabile di scegliere l’ammontare di lavoro che ritiene di poter implementare senza accumulare ritardi. E’ normale attendersi che finché un team non ha imparato a stimare correttamente cosa inserire in uno Sprint, tenderà a ridurre gli argomenti sui quali impegnarsi.
A fine riunione, il Team deve essere in grado di produrre la lista dei task che ha accettato di sviluppare. La riunione può durare al massimo 8 ore, per uno Sprint di 30 giorni.
In seguito ogni giorno il Team di Sviluppo sotto la guida dello Scrum Master si riunisce per 15 minuti in un Daily Scrum Meeting. In questa riunione giornaliera ogni membro del team illustra agli altri: 1) cosa ha fatto il giorno prima, 2) cosa farà oggi e 3) quali ostacoli ha incontrato.
Privilegiando la sintesi, se nel Daily Scrum emergono argomenti da approfondire, si possono discutere in un incontro successivo.
E’ bene avere uno Sprint Backlog contenente ciò che rimane da fare durante lo Sprint integrato da un elenco dei task in lavorazione, e un grafico degli Sprint realizzati (burndown chart) nonché la lista degli ostacoli e delle inefficienze incontrati.
Può essere utile che il Product Owner partecipi a questa breve riunione evitando però che il suo ruolo prevalga sugli altri durante il processo decisionale.
Riunioni di follow-up
Alla fine di ogni Sprint viene effettuato lo Sprint Review Meeting. In questo incontro il team illustra al Product Owner, al management e/o alla committenza l’incremento di prodotto realizzato.
Successivamente alla Sprint Review, il Product Owner rivede gli impegni concordati nella riunione di inizio Sprint e dichiara cosa considera fatto (Done) e cosa considera non ancora realizzato.
Le funzionalità non completate rientrano nel product backlog con la priorità che gli assegna il Product Owner.
Questa riunione può fissare ulteriori requisiti di prodotto, comportando la revisione delle priorità da parte del Product Owner.
Ogni Sprint si conclude con una verifica retrospettiva (Sprint Retrospective).
In questa riunione il Team è invitato a riflettere sul lavoro svolto, analizzando il proprio comportamento e intraprendendo azioni di miglioramento per gli Sprint successivi.
Nella Sprint Retrospective lo Scrum Master cerca alternative ai comportamenti che si sono rivelati poco efficaci evitando discussioni conflittuali. Ciò significa che ogni valutazione andrà documentata sulla base di dati oggettivi che devono essere raccolti durante lo Sprint.
Il Backlog Refinement Meeting è invece una riunione periodica finalizzata a revisionare e perfezionare il Backlog.
All’incontro di Backlog Refinement partecipa tutto il team insieme con il product owner e lo scrum master con lo scopo di mantenere il product backlog aggiornato:
- Rendendo più chiare le priorità
- Definendo nuove user story o articolando meglio quelle esistenti
- Rivedendo le stime delle user story esistenti alla luce di nuovi requisiti
- Scomponendo le user story più grandi (dette Epiche) in user story più piccole
- Rimuovendo le user story non più rilevanti
- Aggiungendo o aggiornando i criteri di accettazione e validazione
- Effettuando una previsione dei successivi rilasci
Tag: 
Categoria: