La Definition of Done (abbreviato DoD) è una lista informale di attività che devono essere portate a termine affinché un requisito, espresso in genere sotto forma di user story, possa essere considerato “fatto”, o “completato”.
Come è composta la Definition of Done
Le attività da includere nella 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.
Quando si pianifica un’iterazione la DoD può essere aggiunta, dove applicabile, all’elenco dei task necessari a implementare il requisito.
I task inclusi nella Definition of Done, così come i task necessari al requisito, possono essere stimati in termini di tempo e aggiunti al dettaglio di ciascuna user story. Puoi leggere l’articolo Lo Sprint Backlog in Scrum per avere un riferimento concreto a quanto ti sto dicendo. L’articolo nello specifico parla di Scrum, ma il concetto è valido anche per altre metodologie agili, come per esempio XP.
È una buona idea stampare la Definition of Done e tenerla ben in vista nello spazio di lavoro del team.
Dove è applicabile
A livello teorico può esistere anche più di una Definition of Done: si può scriverne una a livello di user story, un’altra a livello di iterazione e un’altra ancora per i rilasci. Se non si hanno particolari esigenze il consiglio è di adottarne soltanto una, quella a livello di user story.
Il motivo è che a livello di iterazione una buona pianificazione è più che sufficiente; si può piuttosto pensare di assegnare, a ciascuna iterazione, un obiettivo che il team deve raggiungere per decretarne il successo.
A livello di release non è sempre consigliabile definire una DoD, vista la variabilità delle condizioni ed eventuali dipendenze tra gruppi di lavoro. È infatti una buona regola non includere nella DoD tutte quelle attività che non possono essere svolte a livello di team, ovvero tutto ciò che ha dipendenze esterne, dato che non se ne ha pieno controllo.
Perché è importante
La DoD è fondamentale per stabilire quando un requisito può essere considerato completato, principalmente per i seguenti motivi:
- Tracciabilità – vedi più sotto il paragrafo su Definition of Done e velocity.
- Evitare incomprensioni – l’immagine qui sotto può essere un buon esempio.
- Credibilità nei confronti degli stakeholder.
Puoi pensare alla Definition of Done come una lista degli ingredienti per una cena perfetta. Pensa che figura faresti con un ospite importante se, al momento di sederti a tavola, ti rendessi conto di aver dimenticato il vino in cantina!
Esempio pratico
Un esempio di DoD è il seguente:
- Scrivere Unit Test
- Code review
- Codice presente su VCS
- Eseguire il deploy sull’ambiente di stage
- Eseguire test di accettazione
Non esiste una Definition of Done che si adatti a qualsiasi gruppo o ambiente di lavoro; essa può variare notevolmente a seconda del team, anche nell’ambito della stessa organizzazione.
È possibile che non tutte le attività elencate nella DoD siano applicabili a tutte le user story. In tal caso, come suggerisce il buon senso, si include soltanto ciò che è applicabile.
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, come visto nell’esempio del paragrafo precedente: rilasci in ambiente di stage, code review, unit test, 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 può essere ripianificato, nelle sue parti mancanti, nell’iterazione successiva.
Lettura consigliata
Fare il doppio in metà tempo. Puntare al successo con il metodo Scrum
Formati: Ebook e Copertina rigida, 278 pagine
Editore: Rizzoli Etas
Lingua: Italiano
