"Questo task è stato completato?"
Per rispondere a questa domanda apparentemente semplice è necessario verificare se un incremento di un elemento o di un prodotto è completato o in corso. Tuttavia, per effettuare questa verifica è necessario che il team e i suoi stakeholder abbiano espressamente definito il concetto di "completato".
Nelle metodologie di gestione dei progetti Agile come Kanban o Scrum, il concetto di "completato" si riferisce alla colonna più a destra dedicata agli elementi completati su una board visiva. Stabilire una definizione chiara del concetto di completato consente ai team Agile, inclusi i team DevOps e Scrum, di completare i propri elementi in modo più efficiente.
Questa guida spiega il significato della DoD nelle metodologie Agile e come crearne una per rendere i progetti più efficaci e di valore.
Comprendere la Definition of Done in Agile
Una DoD (dall'inglese Definition of Done, definizione di "fatto") è un insieme di criteri che un incremento di prodotto deve soddisfare affinché il team lo consideri completato e pronto per essere offerto ai clienti. Si tratta di un'intesa condivisa tra i membri del team su quando un incremento di prodotto è pronto per il rilascio, anche quando l'incremento è ampio e comprende molti elementi. Definendo chiaramente cosa significa "fatto" nell'ambito del progetto, un team Agile può concentrarsi sulla creazione di valore ad ogni sprint e sulla riduzione ai minimi termini delle rilavorazioni.
È importante notare che la Definition of Done non viene stabilita da una singola persona, ma deve essere concordata dall'intero team di progetto, compresi sviluppatori, tester, owner di prodotto e altri stakeholder. Ciò garantisce un processo più fluido durante gli sprint poiché tutti utilizzano la DoD come guida insieme a eventuali elenchi di controllo prima di contrassegnare un elemento come completato.
«Se ti occupi dei passaggi di consegne ad altri team, assicurati che la tua definizione di «completato» tenga conto di tutto il necessario per garantire il successo dell'altro team», afferma Mark Cruth, Modern Work Coach di Atlassian. «Collabora con gli altri team del flusso di valore per scoprire cosa dovresti includere nella tua definizione di «completato» per supportarli».
Esempi di Definition of Done
La DoD di un progetto varia a seconda del tipo di progetto e del team coinvolto. I seguenti esempi di DoD mostrano come queste definizioni differiscano in base ai tipi di progetto:
In un progetto di sviluppo di app per dispositivi mobili, la DoD può includere i seguenti criteri:
- Tutte le immagini sono compresse.
Tutto il codice è ridotto al minimo e compresso con gzip.
In un progetto di sviluppo software, la DoD può includere i seguenti criteri:
- Tutto il codice è stato accuratamente testato tramite test unitari, di integrazione e end-to-end.
L'incremento del prodotto è stato implementato in un ambiente di staging e testato dal team.
Un progetto generico potrebbe i seguenti requisiti come DoD:
- Tutti gli errori sono stati risolti.
Tutta la documentazione di rilascio è stata redatta e revisionata.
Definition of Done vs. Definition of Ready
La DoD è un insieme di criteri di alto livello che stabilisce quando un incremento di prodotto è completato, al fine di garantire un risultato finale coerente e di qualità. I team in genere utilizzano la DoD alla fine di uno sprint per verificare la qualità di un incremento di prodotto.
Al contrario, la DoR (dall'inglese Definition of Ready, definizione di "pronto") è un insieme di criteri specifici di basso livello che si applicano solo agli elementi del backlog di prodotto. Il DoR definisce quando un elemento del backlog è pronto per essere lavorato da un team in uno sprint imminente. Un team utilizza il DoR durante il processo di perfezionamento del backlog all'inizio di uno sprint.
Perché la Definition of Done è importante?
Avere una DoD è fondamentale per fornire un prodotto di qualità che i clienti desiderano, poiché chiarisce quando un elemento può essere contrassegnato come completato ed è pronto per essere incluso in un incremento di prodotto. Una DoD ben congegnata offre i seguenti vantaggi:
Migliora la qualità: verificare che ogni incremento di prodotto rispetti i criteri della DoD fa sì che i team Agile tengano sempre a mente gli obiettivi di qualità durante lo sviluppo di un prodotto. In questo modo, si assicurano che gli standard di qualità richiesti per il rilascio vengano costantemente soddisfatti.
Riduce al minimo i rischi: seguire la DoD riduce al minimo il rischio di rilavorazioni o i ritardi che esse potrebbero causare, poiché il team sa esattamente quali criteri deve rispettare un prodotto prima che venga contrassegnato come completato. Ciò garantisce qualità in ogni fase del progetto.
Migliora l'allineamento del team: poiché la DoD è un'intesa condivisa su ciò che significa "fatto" nel contesto del progetto, i team possono concentrarsi più facilmente sulle esigenze dei clienti e offrire valore ad ogni sprint.
Misura i progressi: avere una chiara DoD consente ai team di tenere traccia del numero di incrementi di prodotto che soddisfano i criteri di "fatto". Ad esempio, tra le metriche Scrum può esserci la velocità, che mostra quanti incrementi di prodotto sono stati effettuati da una persona entro un determinato periodo di tempo.
I passaggi per creare una Definition of Done
Sebbene i passaggi esatti per creare una Definition of Done varino a seconda del team e del progetto, il processo segue uno schema simile. I passaggi per creare una DOD sono i seguenti:
1. Lavorare con il team giusto
Quando si crea un DoD, è importante lavorare con i membri del team giusti, poiché i criteri stabiliti costituiscono un'intesa condivisa tra tutti i partecipanti. Ciò significa che bisogna includere tutti coloro che hanno voce in capitolo sulla Definition of Done all'interno del progetto: proprietari dei prodotti, lo Scrum master, membri del team Scrum, tester, product manager, sponsor e altre parti interessate.
Ogni membro del team apporta le proprie conoscenze al progetto e può valutare i criteri più adatti alla propria area di competenza. Se ti rivolgi ai membri del team sbagliati o non includi i membri chiave del team, i criteri della DoD potrebbero non essere completi al cento per cento e ciò risulterà in un prodotto scadente.
2. Stabilire i criteri
L'aspetto più importante della Definition of Done è stabilire i criteri che il team utilizzerà all'interno del progetto. Definire i criteri della DoD è fondamentale in quanto influirà sulla qualità del lavoro svolto.
Come faranno i membri del team a sapere se ciascun componente del progetto è completo? Quali condizioni indicheranno che l'incremento di prodotto è stato effettuato? I criteri devono essere specifici, misurabili, raggiungibili, pertinenti e limitati nel tempo. Per scegliere i criteri appropriati, il team deve porsi principalmente due domande:
- I criteri sono sufficientemente specifici? Non utilizzare frasi vaghe (tutto il codice è stato testato), ma ben specifiche (tutto il codice è stato accuratamente testato tramite test di unità, integrazione e test end-to-end).
- I criteri sono incentrati sul cliente? Un buon esempio è: "Tutta la documentazione scritta e aggiornata", in modo da consentire all'utente finale di trovare facilmente indicazioni sull'uso del prodotto.
«Ricorda che la definizione di «completato» è diversa dai criteri di accettazione», spiega Mark Cruth. «La definizione di «completato» è un insieme di attività che il team ritiene debbano essere completate per definire la storia utente come «completata» (il che potrebbe includere criteri di accettazione) ma è diverso rispetto a dire che la storia utente è stata implementata correttamente».
3. Creare un elenco di controllo di completamento
Un criterio della DoD può sembrare più adatto ai team che lavorano su progetti più grandi, ma i team che lavorano su task, ticket o errori più piccoli possono applicare gli stessi concetti per creare un elenco di controllo per il completamento meno esteso. Un elenco di controllo per il completamento di ogni task o la risoluzione di ogni ticket può garantire che il team realizzi lavori di alta qualità in maniera continuativa.
4. Assegnare criteri di accettazione alle storie degli utenti
Per criteri di accettazione (AC, acceptance criteria) si intendono le condizioni che le storie utente devono soddisfare per essere considerate accettabili per i clienti. Essi differiscono dai criteri della DoD perché riguardano le storie utente o le funzionalità anziché gli incrementi di prodotto.
Tuttavia, come la DoD, anche gli AC sono criteri concordati per stabilire se una storia utente o un'attività individuale è stata completata. Ad esempio, se una storia utente è: "Come utente, voglio poter utilizzare un campo di ricerca per trovare il prodotto che sto cercando", i criteri di accettazione potrebbero includere:
- Il campo di ricerca si trova nella barra di navigazione in alto.
- La ricerca inizia dopo aver premuto il pulsante "Cerca".
Il campo di ricerca contiene un testo segnaposto grigio che dice "Cosa cerchi?"
5. Rivedere e aggiornare la DoD
La DoD non è un documento statico. Ogni bug o errore riscontrato durante uno sprint è un problema di qualità che potrebbe essere stato causato da una definizione poco chiara di "fatto". Aggiornare la DoD diventa quindi fondamentale per fare in modo che il bug non si ripresenti.
«La definizione di «completato» dovrebbe essere un documento dinamico, il che significa che man mano che impari cose nuove sul tuo lavoro, il tuo team dovrebbe aggiornare la definizione», aggiunge Mark Cruth. «Valuta la possibilità di rivedere la definizione di «completato» ogni trimestre per assicurarti che includa tutti gli elementi che ritieni necessari».
Rivedi e aggiorna la DoD durante le revisioni degli sprint in modo che sia sempre pertinente al progetto. Man mano che i progetti avanzano e i team acquisiscono più informazioni sulle esigenze dei clienti, potrebbe essere necessario rivedere anche la DoD per verificare che sia realizzabile. Assicurati che i membri del team abbiano la possibilità di suggerire alcune modifiche da apportare alla DoD durante le revisioni degli sprint o le riunioni di perfezionamento del backlog.
Garantisci una DoD ben definita con Jira
Per i team software, Jira semplifica la creazione della tua Definition of Done. Crea campi personalizzati o scarica un'estensione per creare elenchi di controllo su ogni ticket Jira. Crea una DoD diversa per i vari tipi di lavoro personalizzando le tipologie ticket di Jira.
Milioni di team Agile ad alte prestazioni si affidano a Jira per supportare le loro esigenze di gestione di programmi e progetti, dalla pianificazione Agile alle riunioni stand-up per gli sprint e tutto il resto. Provalo gratis.
Definition of done: domande frequenti
Chi è responsabile della creazione della Definition of Done?
In genere, è il team di sviluppo guidato dallo Scrum Master a creare la DoD.Tuttavia, il team dovrebbe chiedere il contributo anche dei proprietari dei prodotti, dei tester e delle altre parti interessate.
Che differenza c'è tra la Definition of Done e i criteri di accettazione?
La DoD è un insieme di criteri di alto livello che serve a stabilire quando un incremento di prodotto è completato. Si applica a tutti gli incrementi di prodotto e determina la qualità complessiva di un prodotto.
Al contrario, i criteri di accettazione sono condizioni di basso livello che si applicano solo a storie utente o funzionalità specifiche. Gli AC determinano se una storia utente è accettabile per un cliente. Un esempio di DoD potrebbe essere "Tutta la documentazione è scritta e aggiornata". Un esempio di AC potrebbe essere "Il link alla documentazione per l'utente è accessibile dal menu di navigazione".
Quali sono le best practice per creare una Definition of Done?
Definisci i criteri con il tuo team: la DoD deve essere definita attraverso uno sforzo collaborativo che coinvolga l'intero team, compresi sviluppatori, tester, proprietari dei prodotti e altre parti interessate. La creazione di una DoD garantisce un'intesa condivisa su cosa significhi completare l'incremento di un prodotto.
Mantieni la visibilità: la DoD deve essere disponibile e visibile durante la pianificazione dello sprint o quando si calcola la stima degli elementi del backlog di prodotto. Il team deve potervi fare riferimento regolarmente. Stampala e appendila al muro, oppure includila in un wiki o nel piano di progetto.
Non perdere di vista la praticità e la realtà: la DoD deve essere realizzabile entro l'intervallo di tempo stabilito e con le risorse disponibili. Soprattutto, deve essere pertinente alle necessità effettive dei clienti.