Definizione di "completato" (DoD): lista di controllo ed esempi

La definizione di “completato” (DoD) è la breve lista di controllo che un team concorda e che ogni story deve soddisfare prima di essere considerata completa: revisionata, testata, integrata, implementata, accettata. Si tratta di uno standard valido per l’intero team. I criteri di accettazione sono specifici per ogni story; la definizione di «completato» è invece globale. Confondere i due concetti è il motivo per cui «completato» finisce per significare, in modo implicito, «funziona sul mio computer».

Ogni team ha sperimentato il divario tra «lo sviluppatore afferma che è pronto» e «è effettivamente pronto per la distribuzione». La definizione di “completato” colma tale divario. La si concorda una volta sola e la si applica in ogni sprint, indipendentemente dal contenuto di ogni singola story. Senza di essa, il concetto di «finito» rimane un’opinione soggettiva, e la differenza emerge durante la demo o, peggio ancora, in produzione.

Cosa si intende per “definizione di completamento” in Scrum

La Guida allo Scrum la definisce «una descrizione formale dello stato dell’Incremento nel momento in cui soddisfa i criteri di qualità richiesti per il prodotto». In parole povere, la definizione di “completato” rappresenta l’impegno associato all’Incremento, uno dei tre artefatti dello Scrum. Il lavoro che soddisfa tale definizione entra a far parte dell’Incremento. Il lavoro che non soddisfa tali requisiti non può essere rilasciato né presentato durante la revisione dello sprint; viene quindi reinserito nel Product Backlog.

Se la vostra organizzazione ha già stabilito una definizione di “completato”, ogni team la utilizza come requisito minimo e può integrarla. In caso contrario, il team ne redige una propria. L’idea non si limita a Scrum: i team Kanban spesso redigono lo stesso elenco come linea guida per lo spostamento del lavoro nella colonna finale.

Esempi di definizione di “completato”

Esempio di checklist per la definizione di “completato”: un team di sviluppo software

Un punto di partenza concreto per un team che sta realizzando un’applicazione web:

• I criteri di accettazione sono stati soddisfatti e verificati.
• Il codice è stato revisionato e integrato nel ramo principale.
• I test automatizzati sono stati scritti e hanno superato l’esecuzione; non sono stati rilevati nuovi test instabili.
• Non sono note regressioni né bug critici aperti relativi a questa story.
• La documentazione e il registro delle modifiche sono stati aggiornati laddove la modifica riguarda gli utenti.
• È stato implementato nell’ambiente di staging e sottoposto a test di verifica.
• Il Product Owner lo ha accettato.

Prendete questa definizione e adattatela a ciò che il vostro team applicherà effettivamente. Una definizione di “completato” che contiene una voce che nessuno controlla è peggiore di una breve. Induce il team a considerare l’intero elenco come puramente decorativo. Assicuratevi che stia in una sola schermata e che ogni voce sia verificabile.

Esempio di definizione di “completato”: un team che non rilascia codice

Lo stesso principio vale per un team di marketing, di contenuti o di design. La definizione di “completato” di un team di contenuti potrebbe essere la seguente:

• I criteri di accettazione del brief sono soddisfatti.
• A cura di una persona diversa dall’autore.
• Fatti, cifre e link verificati.
• Elementi fondamentali di accessibilità rispettati: testo alternativo, ordine delle intestazioni, contrasto di leggibilità.
• Approvato da chi ne ha fatto richiesta.
• Pubblicato o consegnato e registrato in un luogo accessibile a tutto il team.

Livelli di story, sprint e rilascio

Lo Scrum richiede una definizione univoca di “completato” per l’incremento. Nella pratica, molti team raggruppano le verifiche in base al contesto in cui si svolgono naturalmente:

Livello	Si applica a	Articoli tipici
Trama	Ogni voce del backlog	Codice revisionato, test superati, criteri di accettazione soddisfatti, approvato dal product owner
Sprint	L’Increment nel suo complesso	Integrato nel ramo principale, suite di regressione superata con esito positivo, distribuito nell’ambiente di staging
Comunicato stampa	Ciò che raggiunge i clienti	Sono state redatte le note di rilascio, sono stati effettuati i controlli di sicurezza e delle prestazioni e il personale di assistenza è stato informato

Mantenete la story come riferimento principale. Se una verifica può avvenire solo al momento del rilascio, indicatelo anche nell’elenco, in modo che nessuno contrassegni una story come completata partendo dal presupposto che qualcun altro si accorgerà in seguito della lacuna.

Come redigere una definizione di “completato”

1. Partite da ciò che continua a sfuggirvi. Esaminate gli ultimi sprint: i bug individuati dopo il “done”, le storie che sono state respinte, le attività riportate. Ognuna di esse indica una linea mancante.
2. Redatelo insieme a tutto il team. Le persone che svolgono il lavoro devono concordarlo nel corso di un’unica sessione, con lo Scrum Master che funge da facilitatore e il Product Owner presente nella sala. Un elenco imposto dall’esterno è un elenco che il team non difenderà quando sarà sotto pressione a causa delle scadenze.
3. Assicuratevi che ogni riga sia verificabile. “Testato” è una sensazione; “test automatizzati scritti e superati nella CI” è una verifica. Se due persone dovessero trovarsi in disaccordo sul fatto che una riga sia stata rispettata, la riscrivete.
4. Limitatevi a ciò che intendete applicare fin da subito. Inizieremmo con cinque-otto righe. Aggiungete gli obiettivi ambiziosi quando il team sarà effettivamente in grado di raggiungerli.
5. Inseritela proprio dove si svolge il lavoro. Una lista di controllo inserita nel modello del ticket o nella colonna “completato” della bacheca viene effettivamente utilizzata. Una pagina sul wiki, invece, finisce per essere dimenticata.
6. Verifichatelo durante la revisione retrospettiva. Quando la stessa lacuna si ripete due volte, aggiungete una riga. Quando una riga viene spuntata senza che nessuno l’abbia verificata, chiedetevi se sia ancora giustificata.

Definizione di “completato” rispetto ai criteri di accettazione

Questa è la distinzione su cui i team inciampano più spesso. I criteri di accettazione per una “storia” relativa al login sono specifici per tale funzione: credenziali corrette consentono di accedere alla dashboard, tre tentativi errati bloccano l’account. La definizione di “completato” (revisionato, testato, implementato) è identica per la “storia” relativa al login, a quella relativa alla ricerca e a quella relativa alla fatturazione. I criteri sono locali e rispondono alla domanda «abbiamo realizzato la cosa giusta?». La definizione di «completato» è globale e risponde alla domanda «il nostro lavoro è mai pronto per essere distribuito?». Una storia non è completata finché non supera entrambi i controlli.

Definizione di “pronto” rispetto alla definizione di “completato”

Si tratta di due estremi, non di gemelli simmetrici. La definizione di “pronto” fa entrare una storia nello sprint: deve essere sufficientemente piccola, chiara e stimata. La definizione di “completato” fa uscire il lavoro finito dallo sprint. “Pronto” riguarda la storia; “completato” riguarda il lavoro. I team che ne hanno solo uno solitamente si concentrano su «pronto» (poiché le storie non pronte si fanno sentire con forza) e lasciano che «completato» passi in secondo piano, ed è così che si accumulano le storie riportate e quelle «complete al 90%».

Le tre liste di controllo smettono di confondersi tra loro una volta che si comprende a cosa si riferisce ciascuna di esse:

	Definizione di “pronto”	Criteri di accettazione	Definizione di “completato”
Ambito di applicazione	A livello globale, ogni storia	Notizie locali: questa notizia	A livello globale, ogni storia
Gates	Ingresso nello sprint	L’esito della storia stessa	Uscita dallo sprint
Risposte	”Possiamo iniziare?"	"Abbiamo realizzato ciò che dovevamo?"	"È pronto per la spedizione?”
Di proprietà di	Il team, insieme al Product Owner	Product Owner, insieme al team	La squadra

A chi spetta la definizione di “completato”?

È il team a definirlo; è il team ad applicarlo. Lo Scrum Master funge da facilitatore e il Product Owner esprime il proprio parere in merito alla soglia di accettazione, ma sono gli ingegneri a decidere quali siano i requisiti tecnici per definire un lavoro “completato”, poiché un concetto di “completato” definito in modo vago rappresenta un debito che ricade su di loro, non sul management. Riesaminate la questione in una retrospettiva quando la stessa lacuna continua a presentarsi; questo è il segnale che manca una linea di demarcazione.

In che modo la definizione di “completato” influisce sulle vostre stime

Gli story point definiscono l’entità del lavoro fino al completamento, non fino al “codice completo”. Pertanto, la definizione di “completato” è integrata in ogni stima. Aggiungete una riga del tipo “prestazioni testate” e ogni story diventerà leggermente più ampia. Quando l’elenco subisce modifiche, ricontrollate le vostre story di riferimento nella successiva sessione di pianificazione, altrimenti la velocità subirà un calo per un motivo che nessuno saprà spiegare.

Cosa va storto

La definizione di “completato” diventa un poster. Viene affissa sul wiki del team, ripetuta durante l’inserimento dei nuovi membri e ignorata sotto la pressione delle scadenze: “scriveremo i test nel prossimo sprint”. Due sprint dopo, il debito di test è diventato strutturale e la definizione è ormai una finzione. Quando il concetto di «completato» è vago, la velocità di sviluppo si gonfia: il team accumula punti per un lavoro che in realtà non è pronto per essere consegnato e la previsione smette silenziosamente di avere alcun significato.

La soluzione non sta in un elenco più lungo, bensì in uno più breve su cui il team manterrà una linea di condotta rigida. Una definizione di “completato” ha valore solo nella misura in cui si è disposti a non contrassegnare come completata una storia che non soddisfa tale definizione.

I criteri di accettazione costituiscono un punto di controllo per la story. La definizione di “completato” costituisce un punto di controllo per il team. Si assicuri che siano sufficientemente concisi da poter essere effettivamente applicati. Un punto di controllo non applicato è solo burocrazia.

Domande frequenti

Qual è la definizione di “completato” nell’approccio agile?

La definizione di “completato” (DoD) consiste in un’unica lista di controllo che ogni story deve soddisfare prima di poter essere considerata completa: in genere, deve essere stata sottoposta a test, revisione del codice, integrazione, documentazione e distribuzione nell’ambiente di staging. Si tratta di uno standard condiviso dall’intero team, non di un elenco specifico per ogni singola story, ed esiste affinché il termine “completato” abbia sempre lo stesso significato ogni volta che viene utilizzato.

Qual è la differenza tra la definizione di “completato” e i criteri di accettazione?

La definizione di “completato” è globale, ovvero lo stesso criterio di accettazione vale per ogni story. I criteri di accettazione sono locali, specifici per una singola story. I criteri di accettazione indicano ciò che questa funzionalità deve fare; la definizione di “completato” indica cosa si intende per “pronto per la consegna” per qualsiasi lavoro prodotto dal team. Una story deve soddisfare entrambi i requisiti.

Che cos’è una checklist relativa alla definizione di “completato”?

Un elenco breve ed esplicito delle condizioni applicabili a ogni story: codice revisionato e integrato, test scritti e superati, nessuna regressione nota, documentazione aggiornata, distribuzione in un ambiente di test e approvazione da parte del product owner. Gli elementi specifici variano a seconda del team, ma l’elenco dovrebbe stare in una sola schermata e ogni riga dovrebbe essere verificabile.

Qual è la differenza tra la definizione di “pronto” e quella di “completato”?

I criteri di “pronto” (ready) segnano l’ingresso nello sprint, rappresentando la soglia che una story deve superare prima che il team si impegni a realizzarla. I criteri di “completato” (done) segnano l’uscita dallo sprint, rappresentando la soglia che il lavoro completato deve superare prima di essere rilasciato. Il criterio “pronto” riguarda la corretta definizione della story; il criterio “completato” riguarda la possibilità di rilasciare il lavoro.

Come si redige una definizione di “completato”?

Iniziate da ciò che continua a sfuggirvi: i bug, le rielaborazioni e le questioni rimaste in sospeso dagli ultimi sprint. Concordate l’elenco come squadra al completo, redigete ogni voce in modo che preveda una risposta sì o no, riducetelo a ciò che intendete effettivamente applicare e inseritelo dove si svolge il lavoro, ad esempio nel modello di ticket. Successivamente, riesaminatelo durante la retrospettiva ogni volta che qualcosa sfugge al controllo.

Chi stabilisce la definizione di “completato”?

La responsabilità ricade sul team di sviluppo, solitamente con il supporto dello Scrum Master. Il Product Owner fornisce il proprio contributo in merito ai criteri di accettazione, ma sono le persone che svolgono il lavoro a decidere quali siano i requisiti tecnici per definire un’attività come “completata”, poiché sono loro a farne le spese qualora tali criteri fossero definiti in modo approssimativo.

Approfondimenti

• Stima agile: la guida completa: qui troverete tutte le informazioni necessarie.
• Criteri di accettazione: il test per ogni story con cui spesso si confonde la definizione di “completato”.
• Definizione di “pronti”: il cancello di ingresso situato all’estremità opposta della pista di sprint.
• Errori nel Planning Poker: come un “fatto” poco rigoroso gonfi la velocità.