Definizione di Done: Cos’è e Come Utilizzarla

Ecco le caratteristiche chiave di una definition of done efficace:

• Trasparente: Tutti nel team e tra gli stakeholder chiave possono vederla, leggerla e farvi riferimento in qualsiasi momento.
• Misurabile: Ogni criterio è binario. Il lavoro lo soddisfa o non lo soddisfa, ma la soglia scelta per i criteri quantitativi merita vera attenzione. Una copertura del codice dell’80% è binaria nell’applicazione, ma la scelta dell’80% rispetto al 70% o 90% è una decisione consapevole che dovresti prendere deliberatamente.
• Universalmente compresa: Ogni membro del team Scrum deve saper interpretare ogni elemento nello stesso modo.
• Applicata in modo coerente: La stessa checklist deve essere applicata a ogni deliverable ed elemento del product backlog. 
• Raggiungibile in uno sprint: I criteri devono essere realistici e permettere al team di soddisfarli durante un singolo sprint o iterazione.

Nei progetti di sviluppo software, sono di solito gli sviluppatori a detenere la definition of done perché sono loro responsabili nel rispettarla. Detto questo, anche product owner e scrum master dovrebbero contribuire.

Se la tua organizzazione ha standard propri per la definition of done, ogni team Scrum deve seguirli come base minima. I team possono sempre aggiungere criteri più restrittivi, ma non possono scendere al di sotto del livello organizzativo.

Perché la Definition of Done è importante

Una definition of done chiara è importante perché impedisce che lavori parzialmente completati passino inosservati e fornisce uno standard di qualità condiviso.

Ecco altri motivi per cui una definition of done condivisa è fondamentale:

• Agisce come barriera di qualità integrata: Ogni elemento deve superare la stessa soglia prima di essere considerato completo. Questo evita che lavori a metà entrino nell’incremento del prodotto accumulando technical debt.
• Elimina l’ambiguità: Quando il team condivide una sola definizione, non ci si trova in situazioni in cui definizioni in conflitto incidono sulla velocità o sulla qualità del lavoro. Una definition of done condivisa significa meno conflitti, meno sorprese e demo più pulite.
• Migliora la previsione: Quando "completo" significa la stessa cosa ad ogni sprint, puoi prevedere la velocità con sicurezza e pianificare i rilasci senza dover gonfiare le stime per compensare rilavorazioni.
• Costruisce fiducia con gli stakeholder: Quando product owner, leadership e stakeholder esterni vedono che il team applica uno standard di qualità chiaro, si fidano dei tuoi risultati. 
• Previene il caos nell’integrazione: Se lavori in modo tale che il team debba integrare il proprio lavoro in un incremento condiviso, una comprensione uniforme della definition of done è la base per incrementi coerenti e rilasciabili. 

Come creare una Definition of Done

Ecco i passaggi principali per il processo di creazione di una definition of done.

1. Analizza il tuo flusso di lavoro attuale: Mappa ogni fase che il tuo lavoro compie prima di arrivare in produzione. Parla con sviluppatori, tester, designer e chiunque altro sia coinvolto. Scoprirai passaggi informali di controllo qualità che è opportuno formalizzare.
2. Individua i criteri di qualità imprescindibili: Decidi quali attività devono avvenire per ogni consegna. Di solito includono revisioni del codice, test automatici, aggiornamento della documentazione e scansioni di sicurezza. Sii onesto su ciò che attualmente viene saltato.
3. Stila la checklist in modo collaborativo: Coinvolgi tutto il team e discutila insieme, usando una lavagna o un documento condiviso dove tutti possano aggiungere, contestare e perfezionare gli elementi in tempo reale. Una definition of done adottata per consenso regge molto meglio sotto pressione rispetto a una decisa a maggioranza.
4. Verifica rispetto agli standard aziendali: Confronta la bozza con eventuali politiche di qualità aziendali, requisiti normativi o standard di settore che il tuo prodotto deve rispettare. Se l’organizzazione ha già una definition of done di base, parti da lì e adattala.
5. Rendila visibile: Pubblica la definition of done dove il team lavora quotidianamente. Questo può significare un poster sul muro, un messaggio fissato in Slack o un pannello nel tuo strumento di gestione dei progetti.
6. Impegnati a farla rispettare: Una definition of done che viene ignorata sotto scadenza è peggio che non averne affatto, perché crea una falsa sensazione di qualità. 

Esempi di Definition of Done

Ecco alcuni esempi di definition of done per diversi tipi di progetti:

Definition of Done per progetti di sviluppo software

I progetti software affrontano un’ampia varietà di rischi qualitativi: bug, vulnerabilità di sicurezza, regressioni di performance e fallimenti di integrazione. La definition of done di un team software deve coprire l’intero percorso dal codice a uno stato pronto per il rilascio.

Potrebbe presentarsi così:

• Tutto il codice scritto e revisionato da almeno un altro sviluppatore
• Test unitari superati con la copertura concordata
• Test di integrazione superati nella pipeline CI/CD
• Nessun bug aperto a gravità critica o alta
• Documentazione tecnica aggiornata per riflettere le modifiche
• Codice integrato nella main branch
• Product owner ha revisionato e accettato il lavoro
• Soglie di performance raggiunte secondo gli accordi

Definition of Done per progetti di marketing 

Il lavoro di marketing spesso include dimensioni di conformità, branding e misurazione che differiscono dal software. 

Ecco come potrebbe apparire la definition of done per un progetto di marketing:

• Contenuti revisionati e approvati dal team legale
• SEO checklist completata, compresi meta description, testo alternativo e link interni
• Tutti gli asset caricati nel CMS e formattati correttamente
• Configurazione del monitoraggio analytics verificata nell’ambiente di staging
• Testo finale revisionato da un secondo membro del team
• Checklist di lancio della campagna approvata dal team lead

Definition of Done per progetti di design 

I team di design necessitano che la loro definition of done colmi il divario tra intento creativo e passaggio tecnico. Senza una definition of done, i design arrivano allo sviluppo incompleti, con specifiche mancanti, comportamento responsivo non validato o problemi di accessibilità che vengono scoperti troppo tardi.

Ecco un esempio di definition of done per un progetto di design:

• Design revisionato rispetto agli standard di accessibilità secondo WCAG 2.2
• File di handoff preparato nello strumento concordato con tutte le specifiche, asset e annotazioni
• Approvazione e documentazione del consenso degli stakeholder
• Componenti del design system aggiornati se introdotti nuovi pattern
• Comportamento responsivo validato sugli intervalli concordati

Definition of Done vs. Acceptance Criteria

La definition of done è lo standard qualitativo del team, mentre gli acceptance criteria sono requisiti funzionali specifici della funzionalità.

Pensa alla definizione di fatto come la base che si applica universalmente, mentre i criteri di accettazione sono unici per ogni sprint backlog o singolo item del product backlog. Un elemento del backlog di prodotto è considerato completato quando soddisfa sia i suoi criteri di accettazione sia la definizione di fatto del team.

Errori Comuni e Insidie

Ecco alcuni errori comuni da evitare mentre si creano le definizioni di fatto:

• Saltare elementi per andare più veloci: I team sotto pressione spesso lasciano da parte criteri come la revisione della sicurezza, i test di accessibilità o la documentazione. Questo genera un debito tecnico nascosto che riemerge più avanti come bug, rilavorazioni o problemi di conformità.
• Checklist troppo dettagliata: Una definizione di fatto eccessivamente dettagliata diventa una fatica burocratica. Se la checklist conta 30 voci e gli sviluppatori passano più tempo a spuntare riquadri che a costruire software, si è esagerato. Bisogna essere specifici abbastanza da essere significativi, ma generali abbastanza da restare pratici.
• Modificare la definizione di fatto per ogni story: Il punto della definizione di fatto è la coerenza. Le condizioni specifiche di funzionalità vanno nei criteri di accettazione (come i criteri di accettazione dato-quando-allora), non nella definizione di fatto.
• Non rivederla mai: Una definizione di fatto dovrebbe evolversi con la maturità delle pratiche, i cambiamenti negli strumenti o la crescita del prodotto. Si consiglia di rivederla durante le retrospettive almeno una volta a trimestre e adattarla se il team individua lacune o frizioni.
• Non farla rispettare: Una definizione che viene ignorata se lo chiede qualcuno di importante è inutile. Il compito dello Scrum master è proteggere la definizione, anche quando un portatore di interessi vuole rilasciare qualcosa che non raggiunge il livello richiesto. Se i criteri vengono regolarmente aggirati, il team perde fiducia nello standard e smette di prenderlo sul serio.
• Confondere "fatto" con distribuito: La definizione di fatto stabilisce se un incremento è rilasciabile, non se è stato effettivamente rilasciato. Un elemento del backlog di prodotto può essere fatto senza essere stato distribuito. Non aggiungere "distribuito in produzione" alla definizione di fatto a meno che il team non gestisca davvero l'intero processo di rilascio, dall'inizio alla fine.
• Dimenticare di riferirsi ad essa: Molti team hanno tecnicamente una definizione di fatto, ma se nessuno la consulta da sei mesi, non sta funzionando come standard di qualità.

E adesso?

Migliora i tuoi processi agili e il tuo modo di lavorare con strumenti pratici, modelli e approfondimenti di esperti grazie a una iscrizione gratuita a DPM, e rafforza i sistemi che aiutano i team a garantire la qualità del lavoro in modo costante.