La Definition of Done, abbreviata DoD, descrive tutte le attività che devono essere portate a termine affinché i requisiti (o meglio, i product backlog item) che fanno parte di uno Sprint siano considerati “completati”, in linea con i criteri di qualità richiesti per il prodotto, e pronti per essere parte di un incremento. Spesso è espressa sotto forma di lista.
Secondo la guida di Scrum, che indica la Definition of Done come un “commitment” del Product Increment, un incremento di prodotto nasce ufficialmente quando un requisito (espresso in genere sotto forma di user story), soddisfa la Definition of Done.
In parole povere, il termine “completato” equivale a “rilasciabile”, dato che un incremento di software in Scrum deve sempre essere potenzialmente rilasciabile.
Come è composta la Definition of Done
La Definition of Done serve quindi per creare trasparenza all’interno del team, ma soprattutto per garantire un livello di qualità minima per il prodotto. Una buona DoD include tutto ciò che l’organizzazione deve tenere in considerazione per poter rilasciare all’utente finale.
Solitamente le attività da includere all’interno della Definition of Done vengono individuate e approvate dal team. Non sono statiche e immutabili ma, se necessario, possono essere riviste e cambiate al termine di ciascuna iterazione.
Gli elementi che compongono la DoD devono essere piccoli e concreti. Non devono essere generici o astratti, ma devono esprimere un’azione precisa. Tutte le attività identificate come parte della Definition of Done possono essere stimate in in fase di backlog refinement dagli sviluppatori dello Scrum team.
Chi scrive la Definition of Done
Se da un lato la Definition of Done è strettamente correlata alle attività del team, dall’altro ha molto a che fare con i processi organizzativi dell’azienda.
Per questo motivo, se a livello di organizzazione esiste una lista di criteri, linee guida o standard minimi che definiscono che cosa è richiesto per il completamento di un incremento, il team dovrebbe come minimo adottare questa lista ed eventualmente estenderla per adattarla alle proprie esigenze.
In assenza di standard a livello di organizzazione, l’intero Scrum Team ha la responsabilità di definire una DoD che sia adeguata per il prodotto. Questa attività è solitamente svolta dai Developer in collaborazione con il Product Owner.
Dove è applicabile
A livello teorico può esistere anche più di una Definition of Done. Soprattutto in ambienti dove Scrum viene utilizzato in larga scala, si possono trovare DoD a livello di user story, di Epic, di Feature, eccetera.
Dal mio punto di vista questa non è una buona pratica e il mio consiglio è di adottare una sola Definition of Done, quella a livello di incremento, così come descritto dalla guida ufficiale di Scrum. Il rischio è di creare standard diversi e liste che alla fine sono troppo difficili da mantenere o da seguire.
In contesti dove Scrum è implementato in larga scala, o dove ci sono più team che lavorano su uno stesso prodotto, è ideale che i team coinvolti si accordino su un’unica Definition of Done, dato che l’obiettivo comune è avere un incremento di software funzionante al termine dello Sprint.
Ogni team, se lo desidera, può creare una propria Definition of Done, estendendo o definendo criteri più stringenti. Ma non può in ogni caso applicare criteri meno rigorosi di quelli definiti in comune accordo per l’incremento.
Perché è importante
Come detto in precedenza la DoD è fondamentale per stabilire il livello di qualità richiesto per produrre un incremento potenzialmente rilasciabile. Ma è indubbiamente un ottimo strumento anche per quanto riguarda:
- Tracciabilità – vedi più sotto il paragrafo su Definition of Done e velocity
- Evitare incomprensioni – l’immagine qui sotto può essere un buon esempio
- Trasparenza nei confronti del team e degli stakeholder
Affinché il team non perda di vista ciò che è importante per il prodotto, e ai fini della trasparenza, il consiglio è di stampare la DoD e tenerla ben in vista all’interno dello spazio di lavoro. Nel caso di team remoti, sarebbe opportuno renderla facilmente accessibile o raggiungibile in qualsiasi momento.
Per semplificare, puoi pensare alla Definition of Done come una lista di criteri per una cena perfetta. Puoi aver cucinato il miglior ragù seguendo la ricetta della nonna. Ma che figura faresti con un ospite importante se, al momento di sederti a tavola, ti rendessi conto di aver dimenticato il vino in cantina e di non aver preparato la playlist giusta?
Esempio pratico
Un esempio di DoD è il seguente:
- Copertura Unit Test minimo 85%
- Code review da parte di un altro sviluppatore
- Codice integrato frequentemente
- Test di accettazione eseguiti senza errori
- Documentazione tecnica e funzionale per il manuale utente
Non esiste una Definition of Done che si adatti a qualsiasi gruppo o ambiente di lavoro; essa può variare notevolmente di organizzazione in organizzazione. Ma anche nell’ambito della stessa azienda, se ci sono team che lavorano su prodotti diversi.
È possibile che non tutte le attività elencate nella DoD siano perfettamente raggiungibili dal team Scrum. L’obiettivo in questo caso è di migliorare continuamente questa lista, o di cercare di capire come rimuovere gli impedimenti che ne prevengono la completa adozione.
Definition of Done e acceptance criteria
Come abbiamo visto in questo articolo, gli acceptance criteria sono anch’essi un elenco di condizioni che devono essere soddisfatte in sede di implementazione del requisito.
Che differenza c’è, allora, tra acceptance criteria e Definition of Done? La differenza è che mentre i primi sono specifici per ciascuna user story, i secondi sono comuni a tutte le user story incluse in un’iterazione.
Si può quindi sostenere che mentre gli acceptance criteria soddisfano requisiti tecnici e funzionali e variano di caso in caso, la DoD soddisfa requisiti di progetto o di prodotto, come visto nell’esempio del paragrafo precedente: copertura unit test, code review, documentazione, eccetera.
Faccio un esempio che esula dall’ambito software ma che rende l’idea: prendiamo il caso di una nuova automobile. Se gli acceptance criteria definiscono cosa è necessario per costruirla (motore, cambio, volante, ruote…), la Definition of Done si occupa di stabilire cosa è richiesto per poterla guidare su strada (controlli tecnici, omologazioni, eccetera…).
Definition of Done e velocity
Come già detto, la Definition of Done decreta che cosa si intende per “completato” e ci dà quindi la possibilità di riconoscere tutto ciò che è stato fatto da ciò che è incompleto. Come abbiamo visto, questa informazione è utile per tracciare la velocity del team.
Al termine dell’iterazione tutte quelle user story che non hanno soddisfatto tutti i punti espressi nella DoD sono da considerarsi incomplete e non devono essere aggiunte al calcolo della velocity, mentre quelle completate vengono incluse nel conteggio.
Un requisito che non soddisfa tutti i punti della DoD torna a far parte del Product Backlog e può essere eventualmente ripianificato, nelle sue parti mancanti, nell’iterazione successiva.
È FINALMENTE DISPONIBILE IL VIDEOCORSO DI AGILE WAY!
CORSO APPROFONDITO SU SCRUM E SULLE METODOLOGIE AGILI
Aggiornato all’ultima versione della guida ufficiale di Scrum!
Più di 3,5 ore di video lezioni su Scrum, ideale per prepararsi a un esame di certificazione PSM I e per comprendere i valori, i principi e le pratiche dei metodi Agili. In questo corso imparerai:
- Origine, nascita e significato delle metodologie Agili
- Differenze tra Scrum e i modelli tradizionali
- Tutte le componenti del framework Scrum, i valori, le pratiche e le metriche
- Come gestire al meglio un progetto e un prodotto con Scrum
- Come mantenere un’attenzione continua al valore generato e al cliente
- Simulatore di esame di certificazione (80 domande)
- Tanto altro…
* Offerta limitata nel tempo
