Seguiamo o non seguiamo un processo iterativo nello sviluppo?
Se la risposta è sì controlliamo attentamente il nostro Backlog.
Non può contenere una miriade di user stories…
Un numero eccessivo di storie sono una trappola infernale perché il loro reale significato tende a stemperarsi. Apparentemente stiamo iterando, ma in realtà finiamo per seguire un piano stabilito mesi prima con le conseguenze nefaste del caso:
- molto tempo impiegato nel dettagliare item che possono rivelarsi non necessari
- rischio di buttar via lavoro già fatto se emergono nuove opportunità di mercato
- rischio di nascondere nella massa di dettagli lo scope creep (o derive dell’ambito)
Se il processo è realmente iterativo non ha senso arrivare subito a questo livello di dettaglio o definire l’intero ambito con mesi di anticipo. Dobbiamo lasciarci un margine di flessibilità.
Teniamo anche presente che user stories di piccole dimensioni sono perfette nel momento in cui vanno in mano al team ma solitamente non offrono al management il giusto punto di vista in relazione ai macro-obiettivi di business.
Da qui l’idea di applicare livelli gerarchici nel product backlog che corrispondono a differenti livelli di astrazione.
Gojco Adzic – l’autore di “50 idee veloci per migliorare le vostre user stories” – propone di sperimentarne 4:
- i macro obiettivi di business (la cosidetta “big picture”)
- i singoli obiettivi di business che contribuiscono alla big picture (i cambiamenti che vogliamo indurre nel comportamento dei nostri utenti)
- i deliverable software che possono supportare il cambiamento
- deliverable più piccoli che possono essere rilasciati indipendentemente l’uno dall’altro (solo qui siamo al livello atomico delle user stories!)
Quali sono i vantaggi di questo approccio?
Sostanzialmente due: il team può realizzare uno sviluppo realmente iterativo perché lavora su item indipendenti e può reagire tempestivamente alle opportunità di mercato. Allo stesso tempo è possibile monitorare l’avanzamento in relazione agli impatti di business (l’unica prospettiva realmente rilevante per il management).
In sintesi l’esperimento che propone Adzic è di ridurre il numero di item nel product backlog e mantenere una connessione visibile con la “big picture” così da poter monitorare, discutere e ricondurre in ogni momento le singole user stories ai macro-obiettivi di business.
Questo suggerimento arriva con un tempismo perfetto.
In questo momento sto proprio cercando di spostare la prospettiva del team e degli stakeholders dalla “lista dei progetti che dobbiamo fare” agli obiettivi di business che vogliamo raggiungere.
Il Backlog rivisitato in un’ottica gerarchica e multilivello potrebbe essere la risposta (c’è chi parla di 4 livelli per i requisiti). In ogni caso è un esperimento che intendo provare…
Liberamente tratto da “50 idee veloci per migliorare le vostre user stories”, ebook in progress che contiene spunti assai interessanti…