La Definition of Ready: vantaggi e pericoli

Usata meno frequentemente della Definition of Done, la Definition of Ready viene utilizzata da alcuni team per stabilire quali Product Backlog Item possono essere inclusi in un'iterazione.

Puoi immaginare la Definition of Ready come un buttafuori grande e forte che sta davanti alla porta della prossima iterazione. Proprio come un buttafuori che lascia entrare solo determinate persone nel club – quelle giovani, alla moda e ben vestite – anche la Definition of Ready lascia entrare nell'iterazione solo determinate User Story.

E proprio come un club può decidere da solo chi i buttafuori possono far entrare e chi no, ogni team o organizzazione può decidere autonomamente quale sia la propria Definition of Ready. Non esiste una Definition of Ready universalmente valida per tutti i team.

Un modello per la Definition of Ready

Che tipo di Story potrebbe far entrare il nostro buttafuori nell'iterazione? Potrebbe ad esempio ammettere Story che soddisfano questi o simili criteri:

• Le Conditions of Satisfaction per la rispettiva Story sono state completamente definite.

• La Story è stata stimata e ha una dimensione massima stabilita. Se il team lavora ad esempio con gli Story Point, i membri del team stabiliscono un determinato numero di Story Point e ammettono nell'iterazione solo Story che corrispondono a quel numero o sono più piccole. Spesso questa dimensione massima corrisponde a circa la metà della Velocity del team.

• Lo User Interface Designer ha già creato un mock-up o l'intero design per le schermate correlate alla Story.

• Le dipendenze esterne sono state eliminate, indipendentemente dal fatto che si tratti di dipendenze interne o esterne al team.

Una Definition of Ready definisce le precondizioni

Una Definition of Ready consente al team di stabilire criteri che devono essere soddisfatti prima che una Story possa essere inclusa in un'iterazione. L'obiettivo è prevenire i problemi prima che abbiano la possibilità di presentarsi.

Dire che solo Story fino a una certa dimensione massima possono essere incluse in un'iterazione impedisce, ad esempio, che venga iniziata una Story troppo grande per essere completata in una singola iterazione.

Allo stesso modo, non ammettere nell'iterazione nessuna Story che presenti dipendenze esterne può proteggere dal rischio che queste dipendenze compromettano la Story o l'intera iterazione, nel caso in cui l'altro team non riesca a mantenere il proprio impegno.

Immagina, ad esempio, che il tuo team dipenda a volte dal fatto che prima un altro team completi una parte del lavoro. Le tue User Story possono quindi essere completate solo se l'altro team ha terminato il suo lavoro – e in tempo perché il tuo team abbia ancora la possibilità di integrare quelle cose.

Se quell'altro team ha già deluso regolarmente il tuo team perché non ha finito qualcosa entro il momento in cui lo aveva promesso, sarebbe logico che il tuo team decidesse di non includere più nell'iterazione Story con una dipendenza non ancora risolta con l'altro team.

Una Definition of Ready che stabilisce che tutte le dipendenze esterne devono essere eliminate prima che una Story possa essere inclusa nell'iterazione potrebbe avere senso per un team del genere.

Una Definition of Ready non è sempre una buona idea

Alcune regole del nostro buttafuori sono quindi evidentemente una buona idea. Ad esempio, non ho problemi se un team decide che nessuna Story al di sopra di una certa dimensione possa essere inclusa in un'iterazione.

Tuttavia, alcune regole che vedo frequentemente nella Definition of Ready possono causare problemi – problemi grandi. Lascia che ti spieghi.

La Definition of Ready è come il cancello dell'iterazione. Le regole vengono stabilite e il nostro buttafuori si assicura che entrino solo Story conformi a queste regole.

Se queste regole stabiliscono, tra le altre cose, che qualcosa deve essere completato al 100% prima che una Story possa essere inclusa nell'iterazione, la Definition of Ready diventa un passo piuttosto grande verso un approccio sequenziale stage-gate. Questo impedisce al team di essere agile.

Una Definition of Ready può portare a stage e gate

Lascia che ti spieghi brevemente. Un approccio stage-gate è caratterizzato da una serie di fasi (stage) per lo sviluppo. Inoltre, nell'approccio stage-gate vengono definiti i cosiddetti cancelli (gate) o checkpoint. I lavori possono passare da una fase alla successiva solo superando un cancello.

Quando ero bambino, mia madre usava un approccio stage-gate per la cena. Avevo il dolce solo se avevo finito di mangiare. Non potevo mangiare la cena e il dolce contemporaneamente.

Per dirla con un esempio dallo sviluppo prodotto, immagina un processo con fasi separate di design e codifica. Per passare dalla fase di design a quella di codifica, i lavori devono superare un cancello di design review. Il cancello deve garantire la completezza e la cura del lavoro nella fase precedente.

Se ora una Definition of Ready include una regola secondo cui qualcosa deve essere completato prima che qualcos'altro possa essere iniziato, questo porta il team pericolosamente vicino a un processo stage-gate. E questo comprometterà la capacità del team di essere agile. Un approccio stage-gate è infatti solo un altro modo di dire processo waterfall.

I team agili dovrebbero praticare lo sviluppo simultaneo

Non appena una cosa non può iniziare finché un'altra non è completata, il lavoro del team non può più avvenire contemporaneamente. L'esecuzione contemporanea dei lavori è però uno degli indicatori più evidenti del fatto che un team è agile. Un team agile dovrebbe sempre svolgere un po' di analisi, design, testing e codifica contemporaneamente. Inserendo cancelli nel processo di sviluppo, si impedisce proprio questo.

I team agili dovrebbero praticare lo sviluppo simultaneo, in cui le diverse attività per la consegna di software funzionante si sovrappongono. Attività come l'analisi, il design, la scrittura del codice e il testing non avverranno mai completamente in parallelo – e questo non è nemmeno l'obiettivo. L'obiettivo è che queste attività si sovrappongano il più possibile.

Il fatto che in un approccio stage-gate determinate attività debbano essere completate al 100% impedisce che altre attività possano iniziare. E una Definition of Ready può portare direttamente a un tale approccio stage-gate, se regole di questo tipo vengono incluse nella Definition of Ready.

Per questo motivo raccomando alla maggior parte dei team di non lavorare con una Definition of Ready. Spesso è uno sforzo inutile. E, cosa ancora peggiore, può rappresentare un grande e pericoloso passo indietro verso un processo waterfall.

In alcuni casi, tuttavia, una Definition of Ready può effettivamente risolvere problemi e valere quindi la pena di essere utilizzata.

Usare correttamente la Definition of Ready

Per utilizzare con successo la Definition of Ready, dovresti evitare regole che richiedono che qualcosa sia completato al 100% prima che una Story possa essere inclusa nell'iterazione – forse con l'eccezione delle dipendenze da determinati team o fornitori. Inoltre, dovresti optare per linee guida piuttosto che regole nella tua Definition of Ready.

Ecco un esempio di una regola che il team dovrebbe riformulare: "Per ogni Story devono esserci mock-up dettagliati per tutte le nuove schermate."

Una regola del genere rappresenta un cancello. Impedisce che i lavori avvengano contemporaneamente. Un team con questa regola non può praticare lo sviluppo simultaneo. Finché non è stato elaborato un design dettagliato per ogni singola Story, non c'è lavoro dall'altra parte del cancello.

La variante migliore sarebbe: "Se una Story include nuove schermate importanti, dovrebbero essere stati già creati in anticipo mock-up sufficienti delle nuove schermate, in modo che il team possa chiarire le domande e i problemi rimanenti durante l'iterazione."

Piccolo cambiamento, grande effetto nella Definition of Ready:

1. La regola diventa una linea guida.
2. Dicendo che i mock-up devono solo essere sufficienti invece che completati, consentiamo lavori simultanei.

Questi due cambiamenti introducono un po' più di soggettività nell'uso di una Definition of Ready. Stiamo ancora dicendo al buttafuori che vogliamo persone giovani, alla moda e ben vestite nel nostro club. Tuttavia, gli diamo più libertà di decidere da solo cosa significhi effettivamente "ben vestito".

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