La definizione di “completato” consiste in un’unica lista di controllo per l’intero team: lo standard che ogni story deve soddisfare prima di poter essere considerata completa. I criteri di accettazione sono specifici per ogni story; la definizione di “completato” è invece globale. Confondere i due concetti è ciò che porta silenziosamente il termine “completato” ad assumere il significato di “funziona sul mio computer”.

Ogni team ha sperimentato il divario tra «lo sviluppatore dice che è pronto» e «è effettivamente pronto per essere distribuito». La definizione di “completato” colma tale divario. La si concorda una volta sola e la si applica in ogni sprint, indipendentemente dal contenuto di ogni singola story. Senza di essa, il concetto di «finito» rimane un’opinione soggettiva — e la differenza emerge durante la demo o, peggio ancora, in produzione.

Una lista di controllo relativa alla definizione di “completato” (esempio)

Un punto di partenza concreto per un team che si occupa dello sviluppo di un’applicazione web:

  • I criteri di accettazione sono stati soddisfatti e verificati.
  • Il codice è stato revisionato e integrato nel ramo principale.
  • I test automatizzati sono stati scritti e hanno superato l’esecuzione; non sono stati rilevati nuovi test instabili.
  • Non sono note regressioni né bug critici aperti relativi a questa story.
  • La documentazione e il registro delle modifiche sono stati aggiornati laddove le modifiche riguardano gli utenti.
  • È stato implementato nell’ambiente di staging e sottoposto a test di verifica.
  • Il Product Owner lo ha accettato.

Prendete questa definizione e adattatela a ciò che il vostro team applicherà effettivamente. Una definizione di “completato” che contiene un criterio che nessuno verifica è peggiore di una breve: induce il team a considerare l’intero elenco come puramente formale. Assicuratevi che stia in una sola schermata e che ogni voce sia verificabile.

Definizione di “completato” rispetto ai criteri di accettazione

Questa è la distinzione su cui i team inciampano più spesso. I criteri di accettazione per una storia relativa al login sono specifici per il login stesso: credenziali corrette consentono di accedere alla dashboard, tre tentativi errati bloccano l’account. La definizione di “completato” — revisionato, testato, implementato — è identica per la storia relativa al login, quella relativa alla ricerca e quella relativa alla fatturazione. I criteri sono locali e rispondono alla domanda «abbiamo realizzato la cosa giusta?». La definizione di «completato» è globale e risponde alla domanda «il nostro lavoro è mai pronto per essere distribuito?». Una storia non è completata finché non supera entrambi i controlli.

Definizione di “pronto” rispetto alla definizione di “completato”

Si tratta di due elementi complementari, non di gemelli simmetrici. La definizione di “pronto” consente a una storia di entrare nello sprint — purché sia sufficientemente piccola, chiara e stimata. La definizione di “completato” consente al lavoro finito di uscire dallo sprint. “Pronto” riguarda la storia; “completato” riguarda il lavoro. I team che ne hanno solo una di solito si concentrano su «pronto» (perché le storie non pronte si fanno sentire) e lasciano che «completato» passi in secondo piano — ed è così che si accumulano le storie riportate allo sprint successivo e quelle «complete al 90%».

Le tre liste di controllo smettono di confondersi tra loro una volta che si capisce a cosa serve ciascuna di esse:

Definizione di “pronto”Criteri di accettazioneDefinizione di “completato”
Ambito di applicazioneA livello globale — ogni storiaNotizie locali — questo articoloA livello globale — ogni storia
GatesIngresso nello sprintL’esito stesso della storiaUscita dallo sprint
Risposte”Possiamo iniziare?""Abbiamo realizzato la cosa giusta?""È pronto per la spedizione?”
Di proprietà diIl team, insieme al product ownerProduct Owner, insieme al teamLa squadra

A chi spetta la definizione di “completato”?

È il team a definirlo; è il team ad applicarlo. Lo Scrum Master funge da facilitatore e il Product Owner interviene per stabilire i criteri di accettazione, ma sono gli ingegneri a decidere quali siano i requisiti tecnici per definire un lavoro “completato” — poiché un concetto di “completato” definito in modo vago rappresenta un debito che spetta a loro ripagare, non al management. Riesaminate la questione in una retrospettiva quando lo stesso divario continua a presentarsi; questo è il segnale che manca una linea guida.

Cosa va storto

La definizione di “completato” diventa un poster. Viene affissa sul wiki del team, ripetuta durante l’inserimento dei nuovi membri e ignorata sotto la pressione delle scadenze — “scriveremo i test nel prossimo sprint”. Due sprint dopo, il debito di test è diventato strutturale e la definizione è ormai una finzione. Quando il concetto di «completato» è vago, la velocità si gonfia: il team accumula punti per un lavoro che non è realmente pronto per la consegna e la previsione smette silenziosamente di avere alcun significato.

La soluzione non sta in un elenco più lungo, bensì in uno più breve su cui il team manterrà una linea di condotta rigida. Una definizione di “completato” ha valore solo nella misura in cui si è disposti a non contrassegnare come completata una storia che non soddisfa tale definizione.

I criteri di accettazione fungono da filtro per la story. La definizione di “completato” funge da filtro per il team. Assicuratevi che siano sufficientemente concisi da poter essere effettivamente applicati: un filtro non applicato è solo burocrazia.

Domande frequenti

Qual è la definizione di “completato” nell’approccio agile?

La definizione di “completato” consiste in un’unica lista di controllo che ogni story deve soddisfare prima di poter essere considerata completa — in genere: testata, sottoposta a revisione del codice, integrata, documentata e distribuita nell’ambiente di staging. Si tratta di uno standard condiviso da tutto il team, non di un elenco specifico per ogni singola story, ed esiste affinché il termine “completato” abbia sempre lo stesso significato ogni volta che viene utilizzato.

Qual è la differenza tra la definizione di “completato” e i criteri di accettazione?

La definizione di “completato” è globale: lo stesso criterio di accettazione vale per ogni story. I criteri di accettazione sono locali, ovvero specifici per una singola story. I criteri di accettazione indicano ciò che questa funzionalità deve fare; la definizione di “completato” indica cosa si intende per “pronto per la consegna” per qualsiasi lavoro prodotto dal team. Una story deve soddisfare entrambi i requisiti.

Che cos’è una checklist relativa alla definizione di “completato”?

Un elenco breve ed esplicito delle condizioni applicabili a ogni story: codice revisionato e integrato, test scritti e superati, nessuna regressione nota, documentazione aggiornata, implementazione in un ambiente di test e approvazione da parte del product owner. Gli elementi specifici variano a seconda del team, ma l’elenco dovrebbe stare in una sola schermata e ogni riga dovrebbe essere verificabile.

Qual è la differenza tra la definizione di “pronto” e quella di “completato”?

I criteri di “pronto” segnano l’ingresso nello sprint — la soglia che una story deve superare prima che il team si impegni a realizzarla. I criteri di “completato” segnano l’uscita dallo sprint — la soglia che il lavoro completato deve superare prima di essere rilasciato. Il criterio “pronto” riguarda la corretta formulazione della story; il criterio “completato” riguarda la possibilità di rilasciare il lavoro.

Chi stabilisce la definizione di “completato”?

La responsabilità ricade sul team di sviluppo, solitamente con il supporto dello Scrum Master. Il Product Owner fornisce il proprio contributo in merito ai criteri di accettazione, ma sono le persone che svolgono il lavoro a decidere quali siano i requisiti tecnici per definire un’attività come “completata” — poiché sono loro a farne le spese quando tali criteri vengono definiti in modo approssimativo.

Letture correlate