Cos'è la Definition of Done e in cosa differisce dall'accettazione?
La Definition of Done (DoD) è la soglia di qualità che un team di sviluppo si impegna a rispettare su ogni consegna prima di dichiararla finita al committente.
La Definition of Done (DoD) è la descrizione formale dello stato che il lavoro deve raggiungere per dirsi finito: un elenco scritto e condiviso di condizioni di qualità, valido per tutto ciò che un team di sviluppo consegna. Il testo di riferimento è la Scrum Guide 2020, la definizione ufficiale di Scrum (un framework per sviluppare un prodotto a cicli brevi di durata fissa), che la descrive come lo stato dell'incremento, cioè la parte di prodotto funzionante realizzata in un ciclo, quando soddisfa le misure di qualità richieste per il prodotto. Una DoD tipica chiede che un collega abbia rivisto il codice e che i test automatici passino. Il PMI, l'associazione internazionale dei project manager, nel suo Lexicon la definisce invece come la lista di controllo dei criteri da soddisfare perché una consegna sia pronta per l'uso del cliente. A mio avviso, in entrambi i casi è la soglia che il team si impone, distinta dalla decisione del committente di accettare ciò che riceve.
Leggi anche: Scrum · Framework di sviluppo a cicli di durata fissa, con tre responsabilità e cinque eventi: utile solo se il product owner decide davvero.
L'impegno del team nella Scrum Guide
La Scrum Guide chiama la DoD l'impegno legato all'incremento. Un'attività che non la soddisfa non può essere rilasciata né mostrata alla sprint review, la riunione di fine ciclo in cui si presenta il risultato agli interessati: torna nel product backlog, l'elenco ordinato del lavoro da fare. Se l'organizzazione ha una DoD aziendale, tutti i team la adottano come base minima; più team sullo stesso prodotto ne condividono una sola, e i Developer, cioè chi costruisce il prodotto, sono tenuti a rispettarla. Secondo la Guida la DoD crea trasparenza: tutti condividono la stessa idea di quale lavoro è stato completato.
DoD, criteri di accettazione e accettazione contrattuale
La Scrum Guide non parla mai di criteri di accettazione. Il PMI li definisce come le condizioni da soddisfare prima che le consegne siano accettate; il glossario ISTQB, l'organismo internazionale che certifica i tester del software, come i criteri che un prodotto deve soddisfare per essere accettato da chi ne ha interesse. Da queste definizioni ricavo tre livelli, che nei contratti si confondono spesso. La DoD è una soglia unica, uguale per ogni consegna, fissata dallo scrum team, che comprende il product owner (chi decide le priorità), o dall'organizzazione. I criteri di accettazione appartengono alla singola consegna e dicono che cosa quella consegna deve fare. L'accettazione contrattuale è l'atto con cui il committente decide se accettare, di solito dopo un test di accettazione utente. Una consegna può quindi superare la DoD e mancare i propri criteri.
Un esempio enterprise
Un'azienda manifatturiera affida a un fornitore, con cicli (sprint) di due settimane, un cruscotto che calcola ogni giorno i tempi di consegna dei fornitori. Lo statement of work, il documento che descrive cosa sarà consegnato, dice soltanto che ogni rilascio rispetterà la Definition of Done del fornitore. A ogni sprint review tutto risulta finito. Al go-live l'ufficio acquisti scopre che il cruscotto ignora le consegne parziali e mostra tempi migliori di quelli reali. Nessuno aveva scritto come contare le consegne parziali, né su quali ordini verificarlo: il fornitore ha rispettato la DoD e il committente non ha un parametro misurabile a cui appellarsi. Aggiungere ora quel requisito senza rivedere prezzo e tempi apre la strada allo scope creep, l'espansione del perimetro senza adeguare tempi e costi.
Perché conta per chi decide
Una clausola che considera accettata ogni consegna conforme alla DoD lascia la decisione sull'accettazione al team del fornitore. Negli appalti pubblici l'accettazione resta un atto dell'ente: la verifica di conformità, con modalità e tempi fissati nel capitolato (art. 116 del D.Lgs. 36/2023). In un contratto privato conviene la stessa separazione: criteri di accettazione per ogni consegna, con il metodo di misura, nel documento che descrive il lavoro; la DoD del fornitore in allegato, letta prima di firmare, perché dice quale qualità è compresa nel prezzo, per esempio se include i test di sicurezza.
Questa voce è informativa e non costituisce consulenza legale: per un contratto specifico coinvolgi il tuo legale.
Domande frequenti
Termini correlati
- Scrum · Framework di sviluppo a cicli di durata fissa, con tre responsabilità e cinque eventi: utile solo se il product owner decide davvero.
- UAT (User Acceptance Testing) · L'UAT (user acceptance testing) è la prova in cui gli utenti di un sistema lo usano su casi reali per decidere se accettarlo: spesso ne dipende il pagamento.
- Statement of Work (SOW) · Lo statement of work (SOW) è il documento che descrive cosa un fornitore deve consegnare: risultato, dati, criteri di accettazione, modifiche ed esclusioni.
- Scope creep · Lo scope creep è la crescita del perimetro di un progetto senza adeguare tempi, costi e risorse: lavoro in più che nessuno ha stimato, quotato o ripianificato.
- Agile · Organizzare lo sviluppo in cicli brevi ridecidendo le priorità: funziona se il contratto permette di cambiare il perimetro.
Se è una scelta tecnica che stai rimandando, è la decisione che ti aiuto a prendere.
VEDI TOOL CUSTOM E GOVERNANCE