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  nel 2009 per Agile for All. Il diagramma sottostante evidenzia in maniera compatta questi pattern.

Come scomporre una storia - diagramma

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.

Una risposta a "9 metodi per scomporre una Storia"

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo di WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione /  Modifica )

Google photo

Stai commentando usando il tuo account Google. Chiudi sessione /  Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione /  Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione /  Modifica )

Connessione a %s...

Questo sito utilizza Akismet per ridurre lo spam. Scopri come vengono elaborati i dati derivati dai commenti.