Che cos'è la Definition of Done?
Vi è mai capitato di rilasciare qualcosa e scoprire poi che non era davvero finito? La Definition of Done (DoD) è l'elenco condiviso dei criteri che ogni lavoro deve soddisfare prima che qualcuno lo dichiari completato. Vale per ogni user story, funzionalità e incremento, così "fatto" significa la stessa cosa a prescindere da chi ha svolto il lavoro. In Scrum la Definition of Done è lo standard di qualità di ogni incremento. Metterla per iscritto chiude le discussioni del tipo "ma è finito?" durante la review e impedisce che il lavoro nascosto, come test o documentazione mancanti, scivoli nello sprint successivo. Questa sessione coinvolge sviluppatori, tester, designer e product owner nella costruzione dell'elenco, in modo che includa i passaggi che ognuno di loro sa essere spesso trascurati. La board ha quattro colonne: Criteri di qualità, Documentazione e comunicazione, Test e validazione, Rilascio e prontezza. Ognuno aggiunge i propri criteri, poi il team li raggruppa e li vota per concordare l'elenco. Considerate il risultato un documento vivo e rivedetelo man mano che strumenti e standard cambiano. Per approfondire, consultate la guida di Scrum.org alla Definition of Done.
Formato collaborativo Definition of Done
Criteri di qualità
Quali standard di qualità deve rispettare il lavoro finito?
Elencate i controlli tecnici e di qualità che ogni lavoro deve superare, come code review, copertura dei test, prestazioni e standard di codifica. Chiedete "Cosa ci darebbe la certezza che non si romperà in produzione?" per far emergere le aspettative non scritte e renderle misurabili.
Documentazione e comunicazione
Cosa va documentato o condiviso prima di considerarlo finito?
Affrontate ciò che va messo per iscritto, o comunicato, prima che il lavoro possa dirsi finito. Chiedete chi deve essere informato di una modifica e cosa dovrebbe esistere dopo. Spesso i team saltano questa parte, quindi chiedete delle lacune emerse in passato.
Test e validazione
Come verifichiamo che il lavoro funzioni davvero?
Concordate le verifiche che dimostrano che il lavoro fa ciò che deve. Andate oltre i test automatici includendo test manuali, esplorativi e di accettazione, e decidete chi approva e in quale ambiente.
Rilascio e prontezza
Cosa deve essere vero per rilasciare il lavoro in sicurezza?
Definite cosa deve essere vero prima che il lavoro vada live. Parlate di deployment, monitoraggio, piani di rollback e di chi se ne occupa dopo il rilascio. Così si colma la distanza tra codice finito e una funzionalità che le persone possono davvero usare.
Quando utilizzare questa analisi retrospettiva
- Quando si forma un nuovo team che deve concordare fin dall'inizio gli standard di qualità.
- Quando il lavoro viene riaperto di continuo o i bug arrivano in produzione, segno che di solito le persone non sono d'accordo su cosa significhi "finito".
- Prima dell'avvio di un nuovo progetto, così il team concorda lo standard prima di iniziare a lavorare.
- Durante l'onboarding di nuovi membri che devono conoscere le aspettative di qualità del team.
- Quando una retrospettiva rivela che le persone del team intendono il completamento in modi diversi.
Domande suggerite per rompere il ghiaccio
- Se "fatto" avesse una personalità, come sarebbe: perfezionista, pragmatico o eroe dell'ultimo minuto?
- Qual è la cosa più sorprendente che hai scoperto non essere davvero finita?
Desiderate un esercizio di riscaldamento che la vostra squadra possa svolgere, anziché limitarsi a rispondere ad alta voce? Sfogliate gli esercizi per rompighiaccio gratuiti →
Idee e consigli per la vostra riunione di retrospettiva
- Costruite la Definition of Done con tutto il team, così che tutti se ne sentano responsabili. Non lasciate che la scriva una persona da sola.
- Mantenete criteri realistici. Una DoD che il team non rispetta mai finisce per essere ignorata.
- Rendete ogni criterio abbastanza specifico da poter essere verificato, così non ci sono discussioni sul fatto che sia stato soddisfatto.
- Rivedetela ogni pochi sprint, man mano che standard e strumenti cambiano.
- Date a tutti il tempo di aggiungere idee individualmente prima della discussione di gruppo, così contribuiscono anche le persone più riservate.
- Tenetela distinta dai criteri di accettazione. La DoD vale per tutto il lavoro, mentre i criteri di accettazione riguardano una singola story.