Definizione di [Fatto] (Definition of Done - DoD)

La Definizione di "Fatto" (Definition of Done - DoD) è un altro accordo cruciale e condiviso all'interno di un team agile.

Funge da lista di controllo (checklist) che stabilisce i criteri che un elemento del backlog (come una User Story) o un Incremento di prodotto deve soddisfare per essere considerato completamente completato.

A differenza dei Criteri di Accettazione (specifici per ogni storia), il DoD è uno standard unificato che si applica a tutto il lavoro svolto dal team.

Il suo scopo è quello di creare una comprensione condivisa e trasparente della qualità e della completezza attese, evitando ambiguità e il problema del lavoro "quasi finito".

Garantire la qualità e la completezza dell'incremento

L'obiettivo principale del DoD è garantire la qualità e assicurare che quando il team dichiara qualcosa come "Fatto", lo sia davvero, senza lasciare lavoro nascosto in sospeso.

Aiuta a evitare situazioni in cui una funzionalità è considerata completata dal punto di vista della codifica, ma mancano ancora passaggi importanti come test approfonditi, revisioni del codice, aggiornamento della documentazione o pulizia del codice.

Il DoD definisce tutte le attività necessarie affinché un incremento di prodotto sia potenzialmente consegnabile e di alta qualità, assicurando che non si accumuli debito tecnico inutile e che il lavoro sia conforme agli standard concordati dal team.

Creazione collaborativa della lista di controllo DoD

Come la definizione di "pronto", la DoD non è imposta, ma deve essere creata e concordata in modo collaborativo da tutto il team Scrum (o team agile).

Viene definita attraverso una discussione in cui il team stabilisce i propri standard di qualità e completezza.

Questa lista di controllo è unica per ogni team e il suo contesto.

Gli elementi comuni che di solito sono inclusi in una DoD sono:

• Codice completato.
• Revisioni del codice effettuate.
• Test unitari scritti e superati (spesso con una copertura minima in percentuale).
• Test di integrazione effettuati.
• Test di regressione superati.
• Test di automazione aggiornati (con una percentuale di copertura).
• Documentazione necessaria aggiornata.
• Accettazione da parte del proprietario del prodotto.
• Revisione e accettazione da parte del progettista UX (se applicabile).

L'elenco deve essere chiaro, ma non eccessivamente complesso per non diventare burocratico. Può essere un elenco fisico o un accordo condiviso.

DoD e il suo impatto sulla stima

Un DoD chiaro e condiviso ha un impatto diretto e positivo sulla stima del lavoro.

Quando il team stima una User Story (ad esempio, utilizzando i punti storia), non deve considerare solo lo sforzo di codifica, ma tutto il lavoro necessario per soddisfare il DoD.

Ciò include il tempo necessario per i test, la documentazione, le revisioni, ecc.

Senza una DoD chiara, le stime posso