Definition of Done: semplice eppure complessa

La Definition of Done (DoD) è un importante strumento agile che aiuta i team a pianificare ed eseguire il lavoro. In linea di principio, la Definition of Done è solo una serie di criteri che il prodotto deve soddisfare per essere considerato completato. Tuttavia, nonostante il concetto sia così semplice, la sua implementazione nella realtà non è altrettanto facile. Il contesto e le possibilità di interpretazione creano infatti una zona grigia.

Contesto e criteri di accettazione

Il primo livello di complessità consiste nel fatto che la Definition of Done deve sempre essere vista nel contesto dell'ambiente, il che si riferisce alla completezza tecnica e funzionale e all'accettazione da parte del Product Owner. Il fatto che il Product Owner accetti il prodotto rappresenta il valore del prodotto. I criteri di accettazione – comunque vengano chiamati – riflettono se il codice può risolvere un determinato problema di business definito dalla User Story o da un requisito. I criteri di accettazione servono a confermare che la Story faccia davvero ciò per cui è stata pensata e possono essere utilizzati per creare test di accettazione.

Formalmente, la Definition of Done è spesso un riflesso degli standard tecnici e di processo di un'organizzazione. Ad esempio, le organizzazioni hanno spesso standard per la scrittura del codice e degli unit test, e quindi la Definition of Done può contenere i requisiti per la struttura del codice, la documentazione e il testing. Può anche includere componenti legati alla funzionalità. Tuttavia, la funzionalità è fondamentalmente già inclusa nella definizione tramite i criteri di accettazione. In alcuni casi ho visto dichiarazioni nella Definition of Done che indicavano che i criteri di accettazione dovevano essere rispettati. Dopo aver superato la doppia barriera di Definition of Done e criteri di accettazione, il Product Owner deve fornire la valutazione del valore della soluzione consegnata. Segue poi la valutazione finale, in cui accetta o rifiuta la soluzione. Il risultato di questo processo viene anche descritto come done-done o addirittura done-done-done.

Ostacoli e domande importanti sulla DoD

Per implementare il concetto di "Done" in modo solido, bisogna superare tre ostacoli: i criteri della Definition of Done, i criteri di accettazione (come parte di una User Story) e l'accettazione da parte del Product Owner. A ciò si aggiunge la valutazione di alcune domande che rendono il processo, altrimenti relativamente semplice, un po' più difficile. Tra queste:

1. Chi decide cosa significa Done?
   In molte organizzazioni, i criteri di Done vengono spesso lasciati ai singoli team. Questo avviene normalmente entro i limiti degli standard tecnici e di processo definiti dall'organizzazione. Ad esempio, qualche anno fa un team di sviluppo con standard rigorosi per il coding e gli unit test mi chiese se potevano omettere i requisiti di unit test per il loro codice. Gli unit test erano un criterio nella loro Definition of Done. La loro motivazione era che i tester avrebbero scoperto più avanti nel processo se funzionava, e che il Product Owner non apprezzava i test dei programmatori. Tuttavia, il team doveva attenersi agli standard stabiliti dall'organizzazione e non era in discussione l'eliminazione dei requisiti per gli unit test.

2. È accettabile che i criteri non vengano completamente soddisfatti?
   Ogni team con cui ho lavorato si è chiesto prima o poi se fosse possibile interpretare diversamente la Definition of Done e aggirarla. Spesso la risposta è "sì". Questo però significa solitamente una discussione sulla zona grigia, l'accettazione del debito tecnico e quando tale debito debba essere saldato.

3. Le esigenze dell'organizzazione possono essere più importanti di quelle del Product Owner?
   Questo è l'alter ego della domanda precedente. Tutti nel team, incluso il Product Owner, devono sapere quando e dove gli standard e/o le esigenze dell'organizzazione sono più importanti dell'accettazione da parte del Product Owner. La pressione di dover consegnare qualcosa può indurre team e Product Owner a far avanzare il codice per poi rielaborarlo in Sprint successivi, portando standard e architettura ai propri limiti. La maggior parte delle organizzazioni più mature traccia confini chiari, cosicché tutti sappiano quando gli standard e le esigenze dell'organizzazione debbano essere rispettati.

Conclusione sulla Definition of Done (DoD)

Tutte le definizioni della parola "Done" implicano un certo grado di finalità e completezza. Nello sviluppo, miglioramento e manutenzione del software, il concetto di Done può essere molto stratificato. Ognuno di questi livelli può avere le proprie sfumature tecniche, funzionali e legate al valore. I team imparano rapidamente che un lavoro deve essere davvero done, done e done per essere effettivamente completato.

Questo testo proviene dal blog di SPaMCAST ed è stato tradotto in italiano.