Definition of Done

Formato di collaborazione Definition of Done

Criteri di Qualità

Quali standard di qualità deve soddisfare il lavoro per essere fatto?

Questo argomento cattura i benchmark tecnici e di qualità che ogni elemento di lavoro dovrebbe soddisfare prima di essere considerato completo. Incoraggia il team a riflettere su qualità del codice, copertura dei test, prestazioni e standard. Poni domande mirate come 'Cosa ci renderebbe sicuri che questo non si romperà in produzione?' per far emergere le aspettative implicite e trasformarle in criteri espliciti e misurabili.

Documentazione e Comunicazione

Cosa deve essere documentato o condiviso prima del fatto?

Usa questo argomento per far emergere le aspettative di condivisione della conoscenza e documentazione che mantengono il team allineato e riducono la confusione futura. Invita i partecipanti a considerare chi deve essere informato del cambiamento e quali artefatti dovrebbero esistere. Questa è spesso la parte più trascurata del 'fatto', quindi incoraggia una riflessione onesta sulle lacune del passato.

Test e Validazione

Come verifichiamo che il lavoro funzioni davvero?

Questo argomento si concentra sui passaggi di verifica che dimostrano che il lavoro soddisfa i requisiti e si comporta come previsto. Guida il team a pensare oltre i test automatici per includere test manuali, esplorativi e di accettazione. Incoraggiali a definire chi valida il lavoro e in quale ambiente.

Deployment e Prontezza

Cosa deve essere vero per rilasciare il lavoro in sicurezza?

Qui il team definisce cosa significa che il lavoro sia pronto per il rilascio e attivo davanti agli utenti. Stimola la discussione su deployment, monitoraggio, piani di rollback e prontezza operativa. Questo aiuta i team a evitare il divario comune tra 'codice completo' e 'consegnare effettivamente valore'.

Quando utilizzare questa retrospettiva

• Quando un nuovo team si sta formando e ha bisogno di stabilire standard di qualità condivisi fin dall'inizio.
• Quando il lavoro viene frequentemente riaperto o i bug arrivano in produzione, segnalando criteri di completamento poco chiari.
• Prima di iniziare un nuovo progetto o sprint per garantire che tutti concordino su cosa significhi finito.
• Quando si inseriscono nuovi membri che devono comprendere le aspettative di qualità del team.
• Durante una retrospettiva quando il team individua incoerenze nel modo in cui il lavoro viene considerato completo.

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 un giorno non essere davvero finita?

Idee e consigli per la vostra riunione di retrospettiva

• Co-crea la Definition of Done con tutto il team in modo che tutti se ne sentano responsabili — evita che una sola persona detti gli standard.
• Mantieni i criteri realistici e raggiungibili; una DoD troppo ambiziosa che non viene mai soddisfatta ne mina lo scopo.
• Rendi ogni criterio specifico e verificabile in modo che non ci sia ambiguità sul fatto che sia stato soddisfatto.
• Tratta la Definition of Done come un documento vivo e rivisitala periodicamente man mano che gli standard e gli strumenti del tuo team evolvono.
• Incoraggia i membri del team più riservati a contribuire dando a tutti il tempo di aggiungere idee in modo indipendente prima della discussione di gruppo.
• Distingui tra la Definition of Done e i criteri di accettazione — la DoD si applica a tutto il lavoro, mentre i criteri di accettazione sono specifici della singola story.

Domande frequenti