Eventi e artefatti di Scrum

Di seguito vengono spiegati non solo gli eventi e gli artefatti più importanti di Scrum, ma anche come sono collegati tra loro.

Il Product Owner ha una determinata visione del prodotto. Poiché il prodotto può essere molto complesso, viene suddiviso attraverso il cosiddetto backlog grooming in funzionalità più piccole (elementi) che vengono elencate in una lista prioritaria, il Product Backlog.

Uno Sprint inizia con lo Sprint Planning, include il lavoro di sviluppo (Sprint Execution) durante lo Sprint e termina con la Review e la Retrospective. Il numero di elementi nel Product Backlog è solitamente superiore a quello che un team di sviluppo potrebbe gestire in una breve fase di Sprint. Pertanto, il team di sviluppo deve inizialmente determinare un numero di elementi del Product Backlog che ritiene di poter completare (Sprint Planning). L’obiettivo è avere un incremento di prodotto potenzialmente rilasciabile alla fine dello Sprint.

Una nota a margine

Nel 2011 una modifica nella “Guida Scrum” (Schwaber e Sutherland 2011) ha innescato un dibattito sulla questione se il termine appropriato per descrivere il risultato dello Sprint Planning debba essere “previsione” o “impegno”. I sostenitori del termine previsione preferiscono questa espressione perché anche la migliore stima può cambiare durante uno Sprint a causa di nuove informazioni. Esiste anche l’opinione che un impegno da parte del team porti a un peggioramento della qualità del lavoro, poiché si tenta di raggiungere l’obiettivo prefissato in ogni caso, oppure perché il team potrebbe tendere a fissare obiettivi troppo bassi per poterli comunque raggiungere.

Non c’è dubbio che ogni team di sviluppo dovrebbe fare una valutazione di ciò che ritiene di poter raggiungere in uno Sprint. Tuttavia, molti team di sviluppo potrebbero trarre vantaggio dal derivare un impegno da una previsione. Gli impegni portano a una maggiore fiducia tra il Product Owner e il team di sviluppo, così come tra i singoli membri del team. Gli impegni facilitano anche la pianificazione a breve termine e un processo decisionale significativo all’interno dell’organizzazione. Quando più team sono coinvolti nello sviluppo del prodotto, gli impegni consentono loro di allineare meglio la propria pianificazione – un team può basare le proprie decisioni sull’impegno di un altro team. Tuttavia, un impegno dovrebbe basarsi principalmente sullo Sprint Goal e non tanto sui singoli task aperti. Con l’aumento delle conoscenze, i team spesso riescono a raggiungere lo Sprint Goal in modo diverso da quello inizialmente previsto. (Il termine impegno è quello più utilizzato nel seguito. Tuttavia, dove il contesto lo richiede, viene utilizzato anche il termine previsione di tanto in tanto).

Per garantire che il team di sviluppo abbia assunto un impegno significativo, i membri del team creano un secondo backlog durante lo Sprint Planning, chiamato anche Sprint Backlog. Questo Sprint Backlog utilizza dei dettagli per descrivere come il team prevede di progettare, sviluppare, integrare e testare le singole funzionalità dal Product Backlog durante questo Sprint.

Il passo successivo è chiamato Sprint Execution. Qui il team di sviluppo esegue i task necessari per implementare le funzionalità selezionate. In questa fase si svolgono i Daily Scrum, durante i quali vengono eseguite attività di sincronizzazione e verifica nonché attività di pianificazione adattiva. Questo consente ai membri del team di gestire meglio i propri flussi di lavoro. Alla fine dello Sprint Execution, il team ha prodotto un incremento di prodotto potenzialmente rilasciabile che rappresenta già una parte di ciò che il Product Owner aveva in mente.

Il team Scrum conclude lo Sprint con l’ispezione e l’adattamento del prodotto e del processo Scrum. Il prodotto viene esaminato nello Sprint Review dal team Scrum e dagli stakeholder. La revisione del processo Scrum utilizzato per creare un prodotto viene effettuata dai membri del team in un processo chiamato Retrospective. Di conseguenza, possono essere apportate modifiche al Product Backlog o al processo di sviluppo.

A questo punto il ciclo di Sprint ricomincia da capo. Il team di sviluppo determina ora i successivi elementi del Product Backlog che può completare. Dopo un numero adeguato di Sprint, la visione del Product Owner sarà stata realizzata e il risultato potrà essere presentato.

Ciascuno di questi eventi e artefatti verrà discusso in dettaglio di seguito.

Product Backlog

Quando si lavora con Scrum, il lavoro più prezioso viene sempre svolto per primo. Il Product Owner – coinvolgendo il team di sviluppo e gli stakeholder – è il responsabile ultimo della sequenza di queste fasi di lavoro e deve comunicarle in una lista prioritaria, il Product Backlog. Nello sviluppo di nuovi prodotti, i Product Backlog Item sono inizialmente solo quelle funzionalità necessarie per realizzare la visione del Product Owner. Nell’ulteriore sviluppo dei prodotti, il Product Backlog può contenere anche nuove funzionalità, nonché modifiche di funzionalità esistenti, correzioni necessarie di difetti o miglioramenti tecnici, ecc.

Il Product Owner lavora con gli stakeholder interni ed esterni per raccogliere e determinare gli elementi del Product Backlog. Deve quindi assicurarsi che tutti gli elementi siano messi nel giusto ordine (in termini di valore, costo, conoscenza e rischio) in modo che gli elementi più preziosi appaiano in cima al Product Backlog e quelli meno preziosi più in basso. Il Product Backlog è un artefatto in continua evoluzione. Se le circostanze per un’azienda cambiano o la comprensione del prodotto da parte del team Scrum (attraverso il feedback durante gli Sprint) cresce, gli elementi possono essere aggiunti, rimossi e rivisti dal Product Owner.

Fondamentalmente, la progettazione, l’elaborazione, la valutazione e la prioritizzazione dei Product Backlog Item si chiama Backlog Grooming o Backlog Refinement.

Tuttavia, prima di poter completare la prioritizzazione o l’ordinamento degli elementi nel Product Backlog, è necessario conoscere la dimensione dei singoli elementi. La dimensione determina i costi, e il Product Owner deve conoscerli per determinare la priorità di un elemento. Scrum non specifica un’unità di misura specifica. Nella pratica molti team utilizzano unità di misura relative come gli Story Point o gli Ideal Day. Un’unità di misura relativa non esprime la dimensione assoluta di un elemento, ma solo la sua dimensione in relazione ad altri elementi.

Sprint

In Scrum esistono iterazioni o cicli della durata massima di un mese chiamati Sprint. Uno Sprint completato dovrebbe sempre produrre qualcosa di valore tangibile per il cliente o l’utente.

Per tutti gli Sprint esiste un arco temporale (Timebox) con un inizio e una fine fissi, che dovrebbero essere gli stessi per tutti gli Sprint. Il completamento di uno Sprint precedente è immediatamente seguito da un nuovo Sprint. Anche se ci sono cambiamenti nell’ambito dei servizi o nel personale che influenzerebbero l’obiettivo e che quindi non dovrebbero essere effettuati durante uno Sprint, a volte ciò è inevitabile a causa di determinate esigenze aziendali.

Sprint Planning

Il lavoro in un Product Backlog può richiedere diverse settimane o mesi, molto più di quanto possa essere realizzato in un singolo Sprint breve. Nello Sprint Planning, il Product Owner, il team di sviluppo e lo Scrum Master determinano quali sono i Product Backlog Item più importanti per il prossimo Sprint. In questa pianificazione, il Product Owner e il team di sviluppo concordano uno Sprint Goal, ovvero una definizione di ciò che deve essere raggiunto nello Sprint successivo. Sulla base di questo obiettivo, il team di sviluppo esamina il Product Backlog e nomina gli elementi più preziosi che il team può effettivamente completare nel prossimo Sprint. La velocità di lavoro, nota anche come Sustainable Pace, dovrebbe essere scelta in modo tale da poter essere mantenuta agevolmente per un lungo periodo.

Per avere un’idea di ciò che è fattibile, molti team suddividono ogni Product Backlog Item in diversi task. Insieme agli elementi corrispondenti, questi formano un secondo backlog, lo Sprint Backlog.

I team di sviluppo forniscono quindi una stima dell’impegno richiesto per ogni elemento (solitamente in ore). La suddivisione dei Product Backlog Item in task è una forma di progettazione e pianificazione just-in-time per il completamento delle funzionalità. Se lo Sprint dura da una a quattro settimane, lo Sprint Planning dovrebbe essere completato in un tempo compreso tra due e otto ore – questo è tutto il tempo che dovresti concedere. Esistono diversi approcci, uno dei più popolari si basa su un semplice ciclo: selezioni un Product Backlog Item (se possibile, il successivo nella classifica del Product Owner), lo dividi in task e decidi se si inserisce bene nello Sprint (rispetto ad altri elementi previsti per questo Sprint). Se si inserisce nello Sprint e c’è ancora tempo sufficiente, il processo viene ripetuto fino a esaurire la capacità del team per ulteriori task.

In una procedura alternativa, il Product Owner e il team determinano tutti i Product Backlog Item desiderati contemporaneamente. Solo il team di sviluppo esegue la suddivisione in singoli task, confermando così di poter completare tutti gli elementi desiderati.

Sprint Execution

Una volta che il team Scrum ha completato lo Sprint Planning e concordato il contenuto del prossimo Sprint, il team di sviluppo si mette al lavoro (a livello di task) necessario per completare le funzionalità. Completamento in questo caso significa che tutto il lavoro necessario per produrre funzionalità di alta qualità è stato svolto.

Nessuno dice al team di sviluppo come e in quale ordine svolgere il lavoro nello Sprint Backlog a livello di task. Questo consente ai membri del team di definire il proprio lavoro a livello di task e di organizzarsi nel modo che ritengono migliore per raggiungere lo Sprint Goal.

Daily Scrum / Daily Standup

Ogni giorno durante lo Sprint, preferibilmente alla stessa ora e nello stesso luogo, i membri del team tengono una riunione chiamata Daily Scrum. Questa riunione dovrebbe durare al massimo 15 minuti. Questo processo di ispezione e adattamento è talvolta chiamato Daily Stand-Up, poiché nella pratica tutti i presenti spesso restano in piedi per mantenere la riunione breve.

Una procedura comune per il Daily Scrum prevede che ogni membro del team risponda a tre domande, il che è molto utile per il resto del team.

- Cosa ho realizzato dall’ultimo Daily Scrum?
- Su cosa penso di lavorare fino al prossimo Daily Scrum?
- Cosa esattamente mi impedisce di fare progressi?

Rispondendo a queste domande, tutti ottengono una panoramica di ciò che sta accadendo, dei progressi verso lo Sprint Goal, dei cambiamenti nel piano per il giorno successivo e dei problemi che devono essere affrontati. Il Daily Scrum è essenziale per garantire che il team possa lavorare rapidamente e in modo flessibile durante uno Sprint.

I problemi non vengono risolti nel Daily Scrum. Piuttosto, dopo il Daily Scrum i team possono riunirsi con tutte le persone interessate in piccoli gruppi per discutere i problemi. Il Daily Scrum Meeting non è nemmeno una tradizionale riunione di stato come quelle convocate da un project manager per informarsi sull’ultimo stato del progetto. Il Daily Scrum è piuttosto pensato per comunicare lo stato degli elementi dello Sprint Backlog all’interno del team di sviluppo. Principalmente, il Daily Scrum è un’attività in cui vengono eseguite verifiche, sincronizzazioni e attività di pianificazione adattiva, consentendo a un team auto-organizzato di svolgere un lavoro ancora migliore.

Definition of Done

In Scrum i risultati degli Sprint sono chiamati incrementi di prodotto potenzialmente rilasciabili. Questo significa che tutto ciò che il team Scrum voleva creare è stato fatto secondo la Definition of Done concordata (definizione di ciò che può essere considerato completato). Questa definizione specifica il grado in cui il risultato del lavoro è di buona qualità e potenzialmente rilasciabile. Nello sviluppo software, ad esempio, la Definition of Done dovrebbe specificare, come minimo assoluto, lo sviluppo completo di una funzionalità del prodotto che sia progettata, sviluppata, integrata, testata e documentata.

Una Definition of Done aggressiva consente a un’azienda di decidere a ogni Sprint se rilasciare ciò che è stato sviluppato ai clienti interni o esterni.

Per chiarire: “potenzialmente rilasciabile” non significa che qualcosa debba effettivamente essere rilasciato. Questa è una decisione aziendale che è costantemente influenzata da fattori come “Abbiamo abbastanza funzionalità o abbiamo fatto abbastanza per soddisfare il cliente?” oppure “I nostri clienti possono tollerare un altro cambiamento se abbiamo rilasciato qualcosa due settimane fa?”

“Potenzialmente rilasciabile” dovrebbe piuttosto essere visto come il grado di ciò che è stato effettivamente realizzato nello Sprint. Questo significa che nessun lavoro importante (come test o integrazione importanti, ecc.) rimane incompleto e debba essere completato prima che il risultato dello Sprint possa essere rilasciato. La Definition of Done non è scritta nella pietra e, come tutto il resto, dovrebbe essere soggetta a revisione e adeguamento regolari. Nella pratica, molti team modificano la propria Definition of Done nel tempo.

Sprint Review

Alla fine di ogni Sprint ci sono altre due attività di ispezione e adattamento. Una di queste si chiama Sprint Review.

L’obiettivo di questo evento Scrum è esaminare e adattare il prodotto desiderato. Una parte essenziale è la comunicazione tra il team Scrum, gli stakeholder, gli sponsor, i clienti e i membri interessati di altri team. L’attenzione è rivolta alla verifica delle funzionalità appena completate rispetto all’impegno complessivo di sviluppo. Tutti i presenti ottengono un’idea chiara di ciò che sta accadendo e hanno l’opportunità di influenzare lo sviluppo futuro per consentire la migliore soluzione per l’azienda.

Una review di successo produce un flusso di informazioni in entrambe le direzioni. Le persone che non fanno parte del team Scrum possono ottenere informazioni sullo stato del prodotto e influenzare i prossimi passi. Allo stesso tempo, i membri del team Scrum hanno l’opportunità di sviluppare una migliore comprensione degli aspetti aziendali e di marketing ottenendo un feedback costante sul fatto che lo sviluppo del prodotto sia sulla buona strada per entusiasmare clienti e utenti. Quindi la Sprint Review è un’opportunità pianificata per esaminare e adattare un prodotto. Le persone esterne al team Scrum possono condurre revisioni delle funzionalità durante uno Sprint e fornire feedback, il che a sua volta aiuta il team Scrum a raggiungere il proprio Sprint Goal.

Sprint Retrospective

Il secondo evento di ispezione e adattamento alla fine di uno Sprint è la Sprint Retrospective, che si svolge regolarmente dopo la Sprint Review e prima del successivo Sprint Planning. Mentre la Sprint Review serve per esaminare e adattare un prodotto, la Sprint Retrospective è un’opportunità per esaminare e adattare il processo. Durante una Sprint Retrospective il team di sviluppo, lo Scrum Master e il Product Owner si riuniscono e discutono cosa funziona e cosa non funziona nella pratica con Scrum. L’attenzione è sul miglioramento continuo del processo attraverso il quale un buon team Scrum può diventare un grande team Scrum. Alla fine di una Sprint Retrospective il team Scrum dovrebbe identificare un insieme significativo di azioni di miglioramento che implementerà nel prossimo Sprint.

Quando la Sprint Retrospective è terminata, l’intero processo ricomincia da capo – a partire da un nuovo Sprint Planning in cui viene determinato il lavoro più prezioso su cui il team deve concentrarsi.