Criteri di qualità

Quali standard di qualità deve rispettare il lavoro finito?

Tutto il codice è stato revisionato e approvato da almeno un altro sviluppatore.
La copertura dei test unitari raggiunge la soglia concordata dell'80% o più.
Non restano aperti bug critici o ad alta gravità.
Documentazione e comunicazione

Cosa va documentato o condiviso prima di considerarlo finito?

La documentazione per gli utenti è stata aggiornata in base alla modifica.
Le note di rilascio e le voci del changelog sono complete.
La documentazione delle API riflette gli endpoint nuovi o modificati.
Test e validazione

Come verifichiamo che il lavoro funzioni davvero?

Tutti i criteri di accettazione della user story sono stati soddisfatti.
Test manuali completati su tutti i browser e dispositivi supportati.
Funzionalità validata dal product owner prima della chiusura.
Rilascio e prontezza

Cosa deve essere vero per rilasciare il lavoro in sicurezza?

La funzionalità è rilasciata in produzione o dietro un feature flag.
Monitoraggio e alert sono configurati per la nuova funzionalità.
Esiste un piano di rollback o di ripristino nel caso qualcosa vada storto.

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.

Domande frequenti

Che cos'è la Definition of Done in agile?
È un elenco condiviso di criteri che ogni lavoro deve soddisfare prima che il team lo consideri completato. Offre a tutti lo stesso standard di qualità e mette fine alle discussioni su cosa significhi "finito".
In cosa la Definition of Done è diversa dai criteri di accettazione?
La Definition of Done vale per ogni elemento di lavoro. I criteri di accettazione riguardano una singola user story e descrivono cosa deve fare quella story. Il lavoro è completo solo quando soddisfa entrambi.
Chi dovrebbe partecipare alla creazione della Definition of Done?
Tutto il team, compresi sviluppatori, tester, designer e product owner. Le persone rispettano uno standard che hanno contribuito a scrivere, e ogni ruolo sa cosa tende a essere trascurato nel proprio ambito.
Ogni quanto dovremmo aggiornare la nostra Definition of Done?
Rivedetela ogni pochi sprint, spesso durante una retrospettiva, oppure quando cambiano strumenti o competenze. Aggiungete criteri man mano che il team diventa in grado di rispettarli.
Quanto tempo serve per creare una Definition of Done?
Una prima sessione richiede di solito tra 45 e 90 minuti, a seconda delle dimensioni del team e di quanto il team sia già allineato. Le revisioni successive sono molto più brevi.
È pronto a condurre questa retrospettiva?Provi questa esibizione dal vivo in chiave retrospettiva