Definition of Done in Jira: concorda cosa significa «finito»

Uno sviluppatore termina una modifica e fa avanzare il ticket Jira. Una persona addetta ai test scopre che la nuova schermata funziona, ma un flusso esistente si è rotto. L’assistenza viene a sapere della modifica da un cliente confuso. Tutti hanno usato la parola finito, ma ciascuno intendeva qualcosa di diverso.

Una Definition of Done fornisce al team uno standard di completamento condiviso. Rende visibili i controlli di qualità previsti prima dell’inizio del lavoro, affinché la revisione dipenda meno da chi si ricorda di porre la domanda giusta.

In questa guida costruiremo un esempio per il team immaginario di un portale clienti, distingueremo i controlli di qualità condivisi dai criteri di accettazione specifici della funzionalità e li affiancheremo a un ticket Jira con Definition of Done & AC di Power Pack.

Che cos’è una Definition of Done?

La Guida Scrum descrive la Definition of Done come lo standard di qualità che un Incremento deve soddisfare. Offre una comprensione condivisa del lavoro completato. Dove un’organizzazione ha stabilito uno standard, questo è il minimo per i suoi Scrum Team. Consulta la Guida Scrum ufficiale.

Per il nostro esempio pratico, considerala un piccolo insieme di domande che il team pone su ogni modifica pertinente. L’implementazione è stata revisionata? I controlli di verifica concordati sono stati superati? Sono disponibili le informazioni necessarie a supportare la modifica?

Le domande precise dipendono dal prodotto e dai suoi rischi. Un portale pubblico per clienti, un report interno e un sistema critico per la sicurezza richiedono standard diversi. Copiare la checklist di un altro team senza discuterla può lasciare lacune importanti e aggiungere lavoro inutile.

Uno standard utile descrive un risultato osservabile. «Alta qualità» esprime un’ambizione. «I controlli di regressione concordati sono stati superati, con risultati collegati dal ticket Jira» descrive qualcosa che un revisore può esaminare.

Separa la qualità condivisa dal comportamento della funzionalità

Il nostro team immaginario sta aggiungendo preferenze di notifica. I clienti potranno attivare o disattivare un’email di riepilogo settimanale. I messaggi importanti dell’account restano esclusi da quella preferenza.

La funzionalità necessita di propri criteri di accettazione. Per esempio, una scelta salvata deve essere ancora visibile dopo che il cliente esce e accede di nuovo. Questo requisito appartiene alla funzionalità perché descrive ciò che il cliente dovrebbe sperimentare.

La Definition of Done riguarda lo standard di completamento più ampio. Revisionare l’implementazione, controllare il comportamento esistente interessato e aggiornare le indicazioni per l’assistenza può valere per molte modifiche diverse.

Entrambe le liste contano. Una funzionalità può comportarsi come richiesto pur mancando di attività essenziali per la qualità. Allo stesso modo, codice revisionato e controlli di regressione superati non dimostrano che la funzionalità richiesta si comporti correttamente.

Parti dalle lacune che il team osserva davvero

Riunisci brevemente chi costruisce, verifica e supporta il prodotto. Usa un esempio recente di lavoro apparentemente completo che ha richiesto interventi imprevisti.

Il nostro team del portale identifica tre problemi ricorrenti. I commenti di revisione a volte restano irrisolti. Le impostazioni esistenti dell’account hanno poca copertura di regressione. Le istruzioni per l’assistenza arrivano dopo la disponibilità della funzionalità.

Questi problemi suggeriscono controlli utili. Danno anche al team un motivo per mantenere breve lo standard: ogni voce dovrebbe prevenire un errore riconoscibile o stabilire una condizione di qualità necessaria.

Chiedi come verrà verificata ogni voce proposta. Se nessuno sa descrivere le prove, migliora la formulazione prima di adottarla. «Documentazione completa» potrebbe riferirsi a note di rilascio, note interne di progettazione o un articolo di assistenza per i clienti. Concordate quali informazioni servono e dove devono trovarsi.

Concordate anche chi svolge normalmente i controlli. La conversazione può avvenire nel consueto processo di pianificazione. Una checklist da sola non assegna un revisore né riserva tempo nel suo calendario.

Prepara una checklist condivisa e pratica

Ecco la prima bozza del team del portale. È un accordo di lavoro illustrativo, non uno standard universale.

• La revisione dell’implementazione è completa e i commenti obbligatori sono risolti.
• I criteri di accettazione concordati per il ticket sono stati verificati.
• I controlli di regressione concordati per i flussi dell’account interessati sono stati superati.
• I controlli di accessibilità concordati per le schermate modificate sono stati superati.
• Le indicazioni per l’assistenza riflettono il cambiamento del comportamento per il cliente.
• I risultati delle verifiche e i collegamenti alle revisioni pertinenti sono registrati nel ticket Jira.

Prima di usare questa checklist, il team scrive cosa includono i controlli di regressione e accessibilità. Altrimenti due persone potrebbero spuntare la stessa frase dopo aver svolto attività diverse.

Per il portale, l’insieme concordato di controlli di regressione include l’accesso, l’apertura delle impostazioni dell’account e l’aggiornamento di un campo del profilo esistente. La revisione di accessibilità dei controlli modificati include uso da tastiera, focus visibile ed etichette comprensibili. Sono esempi di controlli scelti da questo team, non uno standard completo di accessibilità.

Anche la voce relativa all’assistenza richiede un’interpretazione pratica. Se una modifica non ha effetti visibili al cliente, il team dovrebbe stabilire in anticipo uno standard appropriato per quel tipo di lavoro. Evita che i revisori improvvisino eccezioni soltanto per rendere verde una lista.

Aggiungi lo standard a un ticket Jira

Apri il ticket Jira pertinente e trova la scheda Definition of Done & AC di Power Pack. Contiene le schede separate Acceptance Criteria e Definition of Done. Seleziona Definition of Done prima di aggiungere i controlli condivisi.

Per una lista breve, inserisci il titolo di un controllo e seleziona Add oppure premi Invio. Mantieni ogni titolo concentrato su una condizione verificabile. Una frase lunga con tre controlli non correlati rende difficile rappresentare il completamento parziale.

Puoi anche selezionare Bulk Import e incollare un elenco Markdown. Per esempio, incolla le sei voci precedenti con un trattino e uno spazio all’inizio di ogni riga. Sono supportate anche le normali caselle di controllo Markdown.

L’importazione aggiunge voci alla scheda selezionata. Controlla la scheda prima di confermare ed esamina poi la lista risultante. Importare nuovamente lo stesso contenuto può aggiungere voci già esistenti: usa quindi l’azione consapevolmente, non come aggiornamento della vista.

Usa voci non selezionate per il lavoro non ancora verificato. Le caselle Markdown selezionate vengono importate come completate; le spunte copiate da un ticket precedente non devono sostituire la revisione della modifica attuale.

Lo standard concordato deve essere inserito manualmente in ogni ticket pertinente. Conserva una copia di riferimento nella documentazione abituale del team e incolla i controlli appropriati nei nuovi ticket. È una pratica del team, non un collegamento automatico tra uno standard centrale e ogni ticket.

Ripercorri una revisione reale

Supponiamo che la funzionalità delle preferenze di notifica sia pronta per la revisione. Maya controlla i risultati per il cliente mentre Priya verifica l’insieme di regressione concordato. Leo risolve i commenti rimanenti della revisione implementativa e collega il relativo resoconto.

Il primo passaggio rivela che la preferenza viene salvata correttamente, ma il focus da tastiera scompare dopo la selezione di Save. Il team lascia incompleto il controllo di accessibilità, registra il problema nella normale discussione Jira e lo corregge prima di ripetere la verifica pertinente.

Anche le indicazioni per l’assistenza sono incomplete. Questo resta visibile nonostante i criteri di accettazione specifici della funzionalità siano completi. Le liste separate aiutano a spiegare perché il team abbia ancora lavoro da svolgere.

Dopo che un controllo è stato effettivamente superato, seleziona il relativo pulsante Done. Selezionalo di nuovo se nuove informazioni richiedono di riportare la voce da fare. Registra risultati dei test, collegamenti alle revisioni e decisioni importanti tramite il normale processo Jira o documentale del team.

Una voce completata registra il giudizio del team. Non esegue il controllo, non raccoglie le prove e non stabilisce chi ha effettuato la verifica. Se l’identità del revisore o il momento della revisione sono importanti, registra esplicitamente queste informazioni nel processo abituale.

Leggi attentamente l’indicatore di preparazione

Lo strumento mostra i conteggi delle voci completate e totali per ogni scheda. L’indicatore di preparazione mostra Ready for Release solo quando entrambe le liste contengono almeno una voce e tutte le voci di entrambe sono completate. Altrimenti mostra In Verification.

Questa regola rende utile l’indicatore per individuare voci incomplete. Spiega anche perché una lista Definition of Done completa non produca lo stato di completamento totale mentre Acceptance Criteria resta vuota.

Considera la dicitura come un riepilogo dello stato della checklist. Non dimostra che i controlli fossero sufficienti, che le prove fossero convincenti o che il prodotto possa essere rilasciato in sicurezza. Un team può segnare come completato un controllo scritto male con la stessa facilità di uno utile.

La checklist inoltre non blocca una transizione Jira o l’unione di una pull request. Continua a usare il normale processo di consegna e rilascio del team per queste decisioni.

Mantieni utile lo standard mentre il lavoro cambia

Rivedi lo standard quando un difetto ripetuto rivela un controllo mancante, quando il prodotto cambia in modo sostanziale o quando un controllo esistente smette di fornire informazioni utili.

Per esempio, il team del portale potrebbe scoprire che le modifiche alle preferenze funzionano subito ma falliscono dopo una sincronizzazione differita. Questo potrebbe portare a una regola di verifica più ampia per funzionalità dipendenti da elaborazioni differite. Il team dovrebbe prima decidere a quali modifiche si applica e quali prove dimostreranno il successo.

Aggiorna lo standard di riferimento e discuti come applicare la modifica al lavoro già in corso. Le liste dei ticket esistenti non ereditano automaticamente la revisione. Esamina i ticket interessati e aggiungi manualmente i nuovi controlli concordati dove appropriato.

Evita di espandere la checklist dopo ogni errore isolato. A volte la risposta migliore è un criterio di accettazione specifico, un’attività implementativa più chiara o una modifica al processo di revisione. Lo standard condiviso deve restare qualcosa che il team possa capire e applicare davvero.

Provalo su un ticket attuale

Scegli un ticket prossimo alla revisione. Concorda un breve standard di qualità condiviso, inseriscilo nella scheda Definition of Done e aggiungi i risultati specifici per il cliente sotto Acceptance Criteria.

Ripercorrete insieme i controlli e collegate le prove dove il team le registra normalmente. Segna le voci come completate soltanto dopo la verifica, quindi esamina il lavoro rimanente tramite il consueto processo di consegna.

Il risultato utile è una conversazione più chiara. Quando qualcuno dice che la modifica alle preferenze di notifica è finita, il team può spiegare quali risultati funzionano, quali controlli di qualità sono stati superati e da dove deriva la conclusione.

• La Guida Scrum — Definition of Done