4 livelli per requisiti agili

Recentemente ho avuto occasione di seguire un workshop di Sally Elatta dal titolo “4 levels of Agile Requirements”.
L’idea centrale della relatrice – fondatrice di Agile Transformation e Agile coach – è che sia fondamentale approcciare i requisiti agili secondo diversi gradi di astrazione.

Questo modus operandi non è una novità.
Abbiamo già parlato di come l’introduzione di una gerarchia nel Product Backlog possa essere d’aiuto sia per il team sia nei rapporti con gli stakeholder di progetto.

Sally Elatta ripropone questa idea sottolineando l’importanza di avere punti di vista sul progetto che vanno dal generale al particolare, ovvero:
epiche
funzionalità
user stories
– singole attività (task)

Considerare i requisiti secondo questi 4 livelli di astrazione consente di legare le singole attività implementative con la “big picture” del progetto e dare così valore alle scelte che dovremo effettuare nel corso dello sviluppo.

Livelli di progetto

La continuità tra i vari livelli è ben rappresentata nell’immagine.
In relazione al Backlog ci interessa concentrare l’attenzione sui 3 livelli centrali.

USER STORIES

Le user story rappresentano il secondo livello dal basso, quello in cui propriamente avviene l’azione o interazione.
Descrivono brevemente ciò che il sistema può fare per risolvere un problema specifico di un utente ben definito.
La caratteristica principale delle storie è essere focalizzate sul valore che producono per il soggetto, a differenza dei singoli task che sono invece una segmentazione delle attività ai fini della lavorazione da parte del team.

 

FUNZIONALITA’

Ad un livello superiore di astrazione rispetto alle user stories troviamo le funzionalità (features), che costituiscono una descrizione più tradizionale del comportamento del sistema.
Sono il livello intermedio tra i bisogni dell’utente e la soluzione progettuale complessiva.
Il concetto di funzionalità ha dal mio punto di vista un enorme pregio: collega le singole attività portate avanti dal Team Scrum con una terminologia utilizzata abitualmente da figure professionali quali Program Manager, Product Manager e manager in generale.
Mediante un elenco di funzionalità siamo in grado di descrivere il nostro progetto con un discreto grado di approfondimento e di spiegarlo anche ad interlocutori non avvezzi alle metodologie agili.

In alcune realtà aziendali di dimensioni medio-grandi anche i team di sviluppatori potrebbero essere organizzati intorno a queste feature.

 

EPICHE

Infine le epiche rappresentano il livello più alto di espressione del bisogno di un utente.
Sono i pilastri della big picture, le caratteristiche costituenti.

Le epiche sono i primi elementi che emergono dal concept di progetto. Si tratta di storie di grandi o grandissime dimensioni che
permettono di comunicare il perimetro di progetto in poche battute ma non consentono di effettuare una stima iniziale dato l’elevato livello di astrazione.

Il collegamento tra questi 3 livelli – storie, funzionalità ed epiche – ci consente di avere maggiore controllo sullo stato di avanzamento del progetto ed offre una chiave di lettura di immediata comprensione agli interlocutori.

Per questo motivo può essere molto utile verificare la consistenza del backlog salendo e scendendo attraverso questi 3 livelli.

Facciamo qualche esempio di “prova del 9“:

  • Possiamo ricondurre tutte le user stories ad un’epica corrispondente?
    Se non è così probabilmente potremmo avere “lavoro sommerso” e sprint goal poco definiti.
  • Ci sono epiche a cui sono collegate pochissime user stories?Verifichiamo di aver compreso bene le aspettative degli stakeholder. Potremmo aver perso qualcosa per strada o non aver spacchettato correttamente il lavoro.
  • Siamo in grado di tradurre il backlog della release in una lista di funzionalità? Possiamo sintetizzare con una percentuale di avanzamento a che punto sono queste feature ?

Potreste accorgervi – come nel mio caso – che non state utilizzando coerentemente o con continuità tutti e 3 i livelli.
Non resta che ispezionare e adattare il backlog, in perfetto spirito agile…

 

User stories efficaci: 5 regole per non sbagliare

Una guida per scrivere user stories

Quest’estate, mentre ero alla ricerca di titoli relativi al product management e alla raccolta dei requisiti, mi sono imbattuta in un piccolo manualetto dal titolo “Writing effective user stories” di Thomas e Angela Hathaway.

Si tratta di un libro in formato digitale di dimensioni molto contenute (si legge in un soffio) che offre alcuni consigli di taglio molto pratico sulla formulazione delle user stories.

La formula delle user stories a cui fa riferimento il testo è quella classica, costituita da 3 elementi cardine: il punto di vista dell’utente (meglio sarebbe dire dello stakeholder), il risultato atteso e la motivazione per la quale viene realizzata l’attività in questione.

Ovvero: “In qualità di <utente> desidero che <risultato> così da <motivo>”.

La formula sembra facile, addirittura banale rispetto ai classici documenti di requisiti. Eppure nella sua essenzialità si rivela veramente efficace per descrivere ciò che dev’essere realizzato… a patto che… a patto che si rispettino queste 5 semplici regole!

Perseguire la semplicità

La user story deve indicare un solo risultato atteso, non di più!
Gli autori suggeriscono di evitare l’utilizzo di frasi composte e perifrasi, di star ben attenti alle espressioni che contengono congiunzioni quali “se”, “e” o “ma” ma anche “a meno che” ed “eccetto”, perché è molto probabile che – data la formulazione – nascondano più obiettivi o risultati.
In questo caso è sempre meglio separare più concetti in diverse storie, così da garantire maggiore facilità di elaborazione.

Esprimere il cosa, non il come

E’ fondamentale distinguere tra il cosa (il risultato atteso) ed il come (la soluzione adottata per raggiungere quel determinato risultato).
Il “come” è oggetto di elaborazione del team di sviluppo, non degli stakeholder.
Focalizzarsi sul risultato di business evitando di concentrarsi su come raggiungerlo ci consente di non arrivare a prospettare una soluzione troppo presto.
Pensiamo alla meta finale, non al viaggio.
Evitiamo premature decisioni tecnologiche e lasciamo al team l’onere e l’onore di individuare il modo più adeguato di soddisfare il bisogno.
Una user story che si focalizza sul “cosa” esprime maggior valore.
Per esperienza non è così semplice astrarsi dal “come”… meglio rileggere più volte ciò che è stato formulato.

Mantenere la rilevanza nei confronti del progetto

La user story è coerente con la finalità generale del progetto? E’ in linea con il project charter (se presente)? E’ sempre bene porsi questa domanda, perché troppo spesso nel backlog sopravvivono requisiti poco rilevanti o di nessuna utilità.
Una user story rilevante descrive funzionalità rilevanti per il progetto in termini di business, che non eccedono o sono al di fuori del suo scopo e che non creano effetti “a cascata”.
Mantenere solo le storie rilevanti fa risparmiare all’azienda tempo e denaro, oltre a sostenere la motivazione del team.

Evitare l’ambiguità

Dato che è difficile individuare formulazioni ambigue quando si è gli autori delle user story in prima persona gli autori ci suggeriscono di provare a cambiare prospettiva.
Tentiamo di metterci nei panni del lettore.
Proviamo a rileggere quanto abbiamo scritto in un contesto diverso, ad un’ora diversa del giorno.
Meglio ancora – se ne abbiamo la possibilità – chiediamo a qualcuno di riscrivere o riformulare la nostra user story mantenendone il significato ma utilizzando tutte parole diverse.
Questo trucco costringe l’interlocutore a pensare fuori dagli schemi.
Una volta che la “traduzione” è fatta verificheremo se le due storie coincidono nel significato. Se c’è aderenza la user story iniziale non presenta ambiguità; in caso contrario si disporrà di indicazioni preziose per riformulare la storia.
Il semplice atto di analizzare il modo in cui qualcun altro interpreta le nostre storie originarie offre preziosissime indicazioni.

Rendere misurabili i requisiti non funzionali

Non è sufficiente formulare il risultato che si vuole ottenere, dobbiamo poterlo esprimere in termini misurabili in modo da renderlo chiaro a qualsiasi tipo di pubblico.
Per sviluppare una soluzione che soddisfi i bisogni del richiedente gli sviluppatori hanno la necessità di avere requisiti funzionali e non funzionali espressi in termini misurabili (ricadono tra questi ultimi quelli relativi ad esempio a frequenza, urgenza, volumi, accuratezza, usabilità, flessibilità, scalabilità, affidabilità, ecc.).
Ricordiamoci che ciò che è oggettivamente misurabile può essere validata anche da terze parti.
Solo fornendo un requisito realmente misurabile saremo in grado – a lavoro terminato – di verificare il raggiungimento del nostro obiettivo.