9 metodi per scomporre una Storia

Quando una storia (User Story) risulta essere troppo grande, ossia supera la velocità del nostro team di sviluppo, ci vengono in aiuto i pattern di scomposizione. Vediamoli in una valida scheda riassuntiva.

Nei progetti Agile l’elenco delle funzionalità è espresso attraverso le storie utente, ossia una descrizione testuale redatta secondo il seguente schema:

Come <ruolo>
voglio <obiettivo/desiderata>
in modo che <beneficio>

Dove:

• Ruolo = chi vuole utilizzare questa funzionalità
• Obiettivo/desiderata = cosa l’utente vuole ottenere
• Beneficio = perché l’utente vuole questa funzionalità

Un esempio concreto:

Come Content Editor
voglio pubblicare un nuovo articolo sul sito
in modo che sia stato approvato dal Content Manager, SEO Manager e Legal.

Ogni storia dovrebbe soddisfare alcuni criteri per essere considerata tale, l’XP li ricorda grazie all’acronimo INVEST, generato dalle prime lettere delle parole inglesi:

• Independent
  Deve essere indipendente, senza nessuna dipendenza diretta dalle altre storie. Questo consente, in pratica, di rilasciare una nuova funzionalità completa con un aumento di valore del prodotto.
• Negotiable
  Deve essere ben spiegata, attraverso un processo di confronto e discussione tra gli attori in gioco al fine di concordare sul contenuto della storia.
• Valuable
  Possiede un valore intrinseco che si esplica come aumento del valore del prodotto stesso. Deve portare un vantaggio all’utente finale.
• Estimable
  Deve essere stimabile, ossia poterne valutare, con il sistema di misurazione prescelto dal team, la dimensione rispetto al resto delle attività.
• Small
  Piccola, semplice, in una parola, agile.
• Testable
  Deve essere empiricamente verificabile, tanto da poter scrivere prima il test e poi sviluppare la funzionalità stessa.

Uno dei criteri che spesso non viene rispettato è la dimensione ridotta della storia. Con l’idea, non sempre corretta, di ridurre il numero di funzionalità si tende a creare storie corpose. All’atto della stima, però, la dimensione della storia risulta essere maggiore della velocità del team (vedi qui la definizione di velocità di un team), rendendo quindi la storia non adatta alle tempistiche di sviluppo in una iterazione.

Ecco dunque che la storia “extra large” (detta Epic Story) deve essere ridotta per poter rientrare nei parametri di progetto. Questa riduzione può avvenire per scomposizione, ossia creando più storie la cui somma assolva comunque alla funzionalità della storia “padre”. Il tutto facendo sempre in modo che ogni storia più piccola sia a tutti gli effetti una storia e quindi rispetti anch’essa tutti criteri INVEST.

Un esempio di scomposizione non corretta si trova spesso nei nuovi team Agile, quando riducono le storie in base al layer architetturale: ad esempio, creano una storia per l’UI, un’altra per il back end, un’altra per il database, ecc. E’ vero che le storie sono più piccole, ma non rispettano i criteri di indipendenza e di valore intrinseco.

Per meglio scomporre una storia possiamo utilizzare i 9 pattern identificati da Richard Lawrence nel 2009 per Agile for All. Il diagramma sottostante evidenzia in maniera compatta questi pattern.

Riprendendo la storia dell’esempio iniziale possiamo scomporla utilizzando il pattern “Fasi del Workflow”: infatti, il beneficio che il Content Editor vuole ottenere è quello di passare da un processo di approvazione per poi andare on line con un contenuto validato.
Potremmo quindi scomporre la storia creandone una per ogni approvazione necessaria:

Come Content Editor
voglio pubblicare un nuovo articolo sul sito
in modo che sia immediatamente disponibile.

Come Content Editor
voglio pubblicare un nuovo articolo sul sito
in modo che sia stato approvato dal Content Manager.

Come Content Editor
voglio pubblicare un nuovo articolo sul sito
in modo che sia stato approvato dal SEO Manager.

Come Content Editor
voglio pubblicare un nuovo articolo sul sito
in modo che sia stato approvato dal Legal.

La prima storia non prevede nessuna approvazione, andando quindi a descrivere la funzionalità base di pubblicazione; le altre tre aggiungo i livelli di approvazione. Alla fine della realizzazione delle 4 storie derivate, otteniamo comunque lo stesso beneficio della storia originale, avendo però messo il team in condizione di sviluppare le storie secondo la sua velocità intrinseca.

Un suggerimento, stampate il diagramma e appendetelo nella sala dedicata al team: risulterà essere un valido aiuto in molte occasioni.

Nota sul copyright: la versione originale dell’immagine la potete trovare qui. La versione in italiano, pur essendo una mia traduzione, mantiene il copyright originale e non è riutilizzabile se non citando direttamente la fonte originale.