La Definition of Done (frequentemente indicata con l’acronimo DoD) serve a chiarire quando un determinato lavoro può considerarsi completato.
È una raccolta di criteri che devono essere soddisfatti affinché i requisiti (o meglio, i Product Backlog item) che fanno parte di uno Sprint siano considerati universalmente completati.
È essenzialmente una lista di controllo utilizzata dai team Scrum per creare una comprensione condivisa di ciò che è necessario per rendere un prodotto rilasciabile. Se un elemento del Product Backlog non soddisfa la Definition of Done, non può essere rilasciato.
Ogni membro dello Scrum team potrebbe dare una propria interpretazione al concetto di “fatto”: alcuni potrebbero intenderlo come un software completamente codificato, per altri il concetto di “fatto” potrebbe essere legato ad un software corredato da un’adeguata documentazione. Per allineare tutti circa il livello di qualità atteso, è quindi importante che vi sia una chiara e condivisa Definition of Done.
Per comprendere a pieno la definizione di “done” nel contesto di Scrum, dobbiamo prima delineare due elementi chiave:
- elemento del Product Backlog: si tratta di un miglioramento specifico apportato a un prodotto. Gli elementi possono includere correzioni di bug, user story e specifiche;
- increment: è il risultato del lavoro che lo Scrum Team svolge in un’iterazione o Sprint. Combina tutti gli elementi del Product Backlog completati durante lo Sprint.
Nel momento in cui un elemento del Product Backlog soddisfa la Definition of Done, nasce un Increment.
Condividere la Definition of Done è un modo per garantire il rispetto di uno dei principi cardine del framework Scrum: la trasparenza.
La trasparenza, infatti, è uno dei pilastri empirici di Scrum, essenziale per rendere possibile l’ispezione e il successivo adattamento.
Leggi di più sui pilastri empirici di Scrum, qui.
Un esempio di Definition of Done
Sebbene i dettagli varino da un’organizzazione all’altra, una tipica Definition of Done consiste in una lista contenente una serie di elementi come quelli che seguono:
- Test superato (corredato dalle specifiche)
- Codice rivisto
- Criteri di accettazione soddisfatti
- Test funzionale superato
- Requisiti non-funzionali soddisfatti
- Test di regressione superato
- Accettazione da parte degli stakeholder
Una buona DoD include tutto ciò che l’organizzazione deve tenere in considerazione per poter rilasciare all’utente finale. Gli elementi che la compongono devono essere piccoli e concreti e non generici o astratti, devono esprimere un’azione precisa.
Chi sviluppa la Definition of Done
Se è vero che la Definition of Done è strettamente correlata alle attività del team, è anche vero che deve essere coerente a livello organizzativo. Per questo motivo, se a livello di organizzazione esiste già una lista di criteri, linee guida o standard che definiscono che cosa è richiesto per il completamento di un Increment di prodotto, il team deve rispettarla ed eventualmente adattarla alle proprie esigenze.
In assenza di uno standard a livello di organizzazione, l’intero Scrum Team ha la responsabilità di definire una DoD che sia adeguata per il prodotto, in collaborazione con il Product Owner.
Nel rispetto del principio dell’adattabilità al cambiamento che è proprio dei framework agili, la Definition of Done e le attività che la compongono non sono statiche ma, qualora necessario, possono essere riviste e cambiate al termine di ciascuna iterazione, durante lo Sprint Retrospective.
A cosa serve
Come già detto, la condivisione della Definition of Done assicura il rispetto del livello di qualità atteso e garantisce la trasparenza. Lasciare poco spazio all’interpretazione riduce drasticamente il rischio di conflitti e di incomprensioni e soprattutto permette al team di produrre un Increment che incontri le richieste dell’utente finale. Condividere una visione comune su quale dovrebbe essere il risultato finale è un buon punto di partenza per qualsiasi progetto e concordare le fasi che una funzionalità deve attraversare per raggiungere il completamento allinea le aspettative.
Ricorda che in Scrum il team è auto-gestito, nel senso che definisce in piena autonomia il lavoro da svolgere e come questo deve essere svolto. La selezione di quanto può essere completato all’interno di uno Sprint può essere impegnativa, tuttavia, più i Developer conoscono le loro performance precedenti, la loro capacità futura e la loro Definition of Done, più saranno precisi nelle loro previsioni.
Attenzione a non confondere la Definition of Done con i Criteri di accettazione: i Criteri di accettazione si riferiscono alle singole User Story, mentre la DoD è comune a tutte le User Story incluse in uno Sprint.
Vorresti saperne di più del framework Scrum?
Leggi i nostri articoli:
0 commenti