Finalmente la guida galattica per scrummers atterra sul pianeta user stories forse una delle tappe più interessanti del nostro intero viaggio. Iniziamo dai concetti principali: il product backlog, il processo di raffinamento della pila delle storie, la differenza fra storie utente, feature ed epiche.

Introduzione

Come si è avuto modo di vedere, la raccolta dei requisiti in Scrum viene svolta anche tramite product backlog, una lista di elementi ognuno dei quali rappresenta una funzionalità da aggiungere al prodotto, funzionalità che risponde a un preciso bisogno di business dell’utente.

Scrum non fornisce alcuna indicazione o obbligo sul formato da utilizzare per la compilazione di tali elementi, anche se ormai è uso comune utilizzare le user stories (o storie utente). Queste infatti offrono molti punti di contatto con l’approccio iterativo e incrementale e con alcuni principi fondanti del manifesto agile.

Lo scopo di una  user story è definire un bisogno di business visto dal punto di vista  dell’utente, tramite un linguaggio naturale e comprensibile sia dal personale tecnico che da utenti e/o esperti di dominio.

Il processo utilizzato per la creazione e le successive modifiche è tipicamente incrementale basato su iterazioni e raffinamenti: nella compilazione della storia si parte dal definire in modo sintetico e ad alto livello le funzionalità che si dovranno implementare per rispondere al bisogno di business in questione. Esula invece dagli obiettivi della storia la definizione dei dettagli tecnici, del design o dell’analisi di dettaglio della funzionalità.

Per poter comprendere il senso delle storie utente e imparare a maneggiarle efficacemente, è utile affrontare il tema “storie utente” dai vari punti di vista: lo scopo, la struttura, le tipologie, il ciclo di vita. Vedremo tutti questi aspetti in questo  e nel successivo articolo.

La raccolta requisiti e bisogni dell’utente

La struttura del product backlog è rappresentabile come una pila (più correttamente una coda, anche se come in questo caso il meccanismo FIFO, “first in, first out” non è strettamente vincolante) in costante evoluzione. Nella pila è continuamente mantenuto l’elenco delle cose da fare: in alto gli elementi piccoli e già pronti per essere messi in lavorazione nello sprint, mentre in basso si trovano elementi a grana grossa, troppo grandi per essere messi in lavorazione e quindi ancora poco dettagliati.

Denominazioni: epiche, features, sprintable stories

Tutti gli elementi del backlog subiscono quindi in modo costante un processo di trasformazione detto raffinamento (termine italiano che sta gradualmente prendendo il posto di quello inglese, grooming): secondo questo processo, gli elementi grossi inseriti in basso nella pila sono continuamente presi in esame, scomposti in parti più piccole o integrati con dettagli mancanti.

Il backlog viene alimentato dal basso con elementi a grana grossa che definiscono un ampio spettro di funzionalità (per esempio “gestione dei clienti”, “gestione carico e scarico magazzino”, “fatturazione”, etc etc). Si parla in questo caso di epiche, proprio per evidenziarne la dimensione più ampia di una singola storia. Il processo di scomposizione delle epiche porta a qualcosa dalle dimensioni più piccole che in questo nostra trattazione chiameremo feature (in alcuni manuali si trovano definizioni invertite o basate su termini equivalenti).

Anche le feature sono ancora troppo grandi per essere messe in lavorazione all’interno dello sprint e quindi non saranno portate dal product owner allo sprint planning: si rende necessario un ulteriore processo di raffinamento che dà luogo alle cosiddette storie utente; proprio per evidenziare il fatto che sono pronte per la messa in lavorazione, queste sono dette anche sprintable stories (la traduzione in italiano in questo caso suona decisamente male, ma vuol dire “storie che possono essere messe in lavorazione per lo sprint”).

Epiche, features e sprintable stories, dal punto di vista strettamente semantico e strutturale, possono essere tutte considerate storie, anche se le dimensioni variano parecchio: per avere un’idea si può provare ad applicare una qualche forma di dimensionamento (qui le grandezze sono del tutto arbitrarie, ma utili per avere un’idea): un’epica può essere vista come una macro storia che può richiedere alcuni mesi per essere realizzata e quindi è grande come o più grande di una release del prodotto. Le feautures invece sono più grandi di uno sprint e possono richiedere alcune settimane per essere completate. Le storie utente infine invece sono più piccole di uno sprint (tanto che il planning serve per stabilire quante storie verranno eseguite all’interno della iterazione) e richiedono qualche giorno per essere realizzate.

Figura 1 – il backlog è composto da elementi a grana variabile. Benche’ siano tutte storie, la grana può variare parecchio, sia per quanto concerne le dimensioni che il livello di dettaglio.

Nella figura 1 è riportato un grafico che mostra le dimensioni (indicative) di epiche, features, storie. Nella parte alta della figura è stata aggiunta una storia scomposta nei suoi task operativi: la loro definizione esula dal processo di grooming  (sono creati durante lo sprint execution quando la storia viene presa in carico da parte del team di sviluppo), ma sono stati qui aggiunti per completare il confronto sulle tempistiche di lavorazione.

Raffinamento del backlog

Le storie che che compongono il backlog possono essere immaginate come tanti elementi in movimento su un nastro trasportatore: il processo di alimentazione del backlog aggiunge elementi (epiche) dal basso, mentre lo sprint planning preleva dall’alto le sprintable stories che sono trasferite  nel backlog di sprint.

Questa sorta di traslazione o evoluzione delle storie non è la sola forma di elaborazione a cui le storie sono soggette: il product owner infatti ha potere di aggiungere epiche, features o storie  a seconda che siano state individuate nuove macroaree di business, nuovi set di funzionalità o semplici nuovi requisiti.

Analogamente la rimozione di un elemento del backlog viene effettuata qualora si ritenga che una storia/feature/epica non sia più necessaria: perche’ è ridondante, per un cambio di scenario, per una revisione del budget o per altri motivi.

Infine, anche il riordinamento degli elementi del backlog è una operazione piuttosto frequente, proprio perche’ il product owner ha il compito di tenere aggiornato l’ordinamento della pila in funzione delle priorità del prodotto .

Figura 2 – Le storie che compongono il backlog di prodotto sono in costante evoluzione sia nella loro struttura che nel posizionamento.

Scrum non definisce alcuna regola circa il quando o il quanto tempo debba essere speso nella fase di raffinamento delle storie; il buon senso suggerisce quindi che dovrebbe essere fatto in maniera costante, continuativa e iterativa in modo da avere sempre sprintable stories (in grigio nella figura 2) che siano pronte per essere travasate nello sprint backlog.

Margine di sicurezza

Se quindi il backlog può essere immaginato come una pipeline di elementi in continuo scorrimento,   il raffinamento deve essere fatto in modo da evitare che si svuoti la parte finale (le sprintable stories) della pila, evento in gergo detto a volte pipeline dry (prosciugamento del condotto che alimenta il flusso).

In tal senso è bene tener presente che, dopo qualche sprint, normalmente il processo di raffinamento e travaso risultano ormai sincronizzati: il product owner riesce a preparare tante sprintable stories quante il team ne consuma al successivo sprint planning. Però è rischioso non tenere alcun margine di sicurezza: la velocity può variare improvvisamente e il team potrebbe completare tutte le storie che si era preso in carico prima della fine dello sprint; e ricordiamo che in tal caso è ammesso che il team di sviluppo prelevi sprintable stories direttamente dal backlog senza dover imbandire un planning. Analogamente il product owner potrebbe avere impedimenti personali o di lavoro che ne rallentino il lavoro di preparazione delle storie.

Un buon modo per gestire queste situazioni è quello di operare in modo preventivo: per prima cosa il product owner dovrebbe nominare un suo vice, costantemente allineato su quello che c’è dentro il backlog, e in grado di sostituirlo eventualmente nel lavoro di raffinamento, ma sopratutto durante gli sprint planning. Contemporaneamente dovrebbe poi portarsi avanti con il lavoro di preparazione delle storie in funzione della velocity stimata storica.

Mentre il team di sviluppo lavora all’implementazione delle storie inserite nello sprint backlog, il product owner è tranquillo perche’ sa che è pronto un buffer di primo livello contenente tante storie quante un dev team è in grado di consumarne in uno sprint. Contemporaneamente egli potrà lavorare alla creazione di buffer di pari dimensione detto a volte buffer di secondo livello. Detto in modo più semplice, in ogni momento il team lavora alle storie prese in carico, sapendo che, se queste dovessero terminare, ce ne sono altrettante pronte nel buffer di primo livello, e altrettante quasi pronte per la lavorazione buffer di secondo livello.

Questa organizzazione non è definita in alcuna regola di Scrum, ma è spesso consigliata come best practice utile per ammortizzare eventuali fluttuazioni delle prestazioni del team o impedimenti di altro tipo. Giusto per aggiungere una nota di colore, dalle mie parti a volte il buffer di primo livello  viene detto frigorifero (provviste conservate ma pronte all’uso), mentre quello si secondo livello congelatore (le provviste non sono immediatamente disponibili, perche’ necessitano di un po’ di tempo per essere “scongelate”, ma comunque sono lì in attesa). Si tratta di termini forse non troppo pertinenti ma che comunque rendono l’idea.

Figura 3 – il processo di alimentazione del backlog è continuativo. La presenza di uno o due buffer permette di ammortizzare eventuali variazioni in accelerazione sulla velocità di lavorazione del team di sviluppo.

Il formato delle storie utente

Lo scopo di una storia utente è quello di definire un requisito utente in modo chiaro senza entrare nei dettagli implementativi: per mezzo di poche parole, e utilizzando un linguaggio naturale, comprensibile sia da personale tecnico che dagli utenti finali, il requisito è descritto dal punto di vista dell’utente.

Questo aspetto è particolarmente importante: diversamente da altri formati, gli use case form in primis, una storia presenta una preciso valore di business raccontato dal punto di vista dell’utente e non del sistema o del software.

Una definizione efficace e sintetica delle storie è quella fornita da Ron Jeffries [1], basata sulle tre C: Card, Conversation, Confirmation. Vediamo questi aspetti nei paragrafi seguenti.

Prima C: Card

Tipicamente le storie sono riportate su un cartoncino di dimensioni medio-piccole, 10 x 15 o 13 x 18. Questo cartoncino (“card”, appunto) è organizzato secondo uno schema piuttosto semplice.

Sul fronte si inserisce il titolo e la descrizione della storia. Il titolo deve raccontare con due o tre parole in modo chiaro e sintetico il bisogno dell’utente. Nella descrizione si inserisce normalmente il ruolo dell’utente a cui la storia si rivolge, la sua necessità legata all’azione che egli vuole compiere e il suo obiettivo nello svolgere una certa azione. A volte può essere utile inserire un codice identificativo, ad esempio un ID come riportato nel sistema di tracking, e il peso in punti, valore che inizialmente è vuoto e che verrà riempito solo dopo il planning.

Sul retro della cartellino sono invece riportati i cosiddetti criteri di accettazione, che permetteranno di stabilire il completamento o meno della storia. Per la compilazione del corpo della storia si segue in genere questo schema:

• in qualità di…
• vorrei che…
• affinche’…

Figura 4 – Un esempio di impaginazione dei due lati di un cartellino secondo uno dei formati più popolari.

Un esempio di una storia potrebbe essere:

• in qualità di utente del sistema di home-banking,
• vorrei poter effettuare il login in modo univoco,
• affinche’ tutte le operazioni eseguite siano collegate al mio account.

Come si può notare non sono inserite nella storia informazioni legate al come realizzare il flusso operativo, ne tantomeno dettagli tecnici pertinenti l’implementazione.

Presentazione e lavorazione della storia

La storia verrà quindi presentata allo sprint planning da parte del product owner al dev team: in questo momento i vari sviluppatori faranno tutte le domande del caso in modo da comprendere tutti i dettagli funzionali non esplicitati. Successivamente, quando la storia verrà presa in lavorazione, da uno o più sviluppatori, essi la arricchiranno con appunti o note in modo da chiarire tutte le informazioni necessarie alla sua realizzazione.

Per questo motivo la storia nel formato della card deve rimanere piccola e semplice. Una celebre frase dice che, se non si è trovato abbastanza spazio per descrivere tutti gli aspetti della funzione che si dovrà andare a implementare, il suggerimento è di… prendere un cartellino più piccolo. Questo vuol significare che durante la prima stesura non si deve perdere tempo nell’inserimento di informazioni che saranno necessarie solo al momento della realizzazione della storia. In fondo perche’ spendere del tempo prima di realizzare la storia, prima che ci sia la conferma che tale storia sia messa effettivamente in lavorazione? Lean è eliminare gli sprechi.

Criteri di accettazione

Il retro del cartellino viene compilato con i cosiddetti criteri di accettazione della storia (in inglese acceptance criteria o AC); fra i vari formati utilizzabili per specificare gli AC,  spesso si usa un semplice elenco di requisiti che dovranno essere rispettati dalla storia affinche’ possa considerarsi correttamente implementata. Ecco un esempio di AC relativo a una storia di autenticazione utente:

• se l’utente inserisce username o password errati verrà visualizzato un messaggio di errore (senza indicare se l’errore è in username o nella password);
• se l’utente inserisce per tre volte consecutive una coppia errata, verrà bloccato il suo account;
• l’utente deve specificare obbligatoriamente se vuole accedere al sistema per effettuare una operazione di consultazione o una dispositiva. Nel secondo caso dovrà eseguire il login avanzato (data di nascita, password di secondo livello);
• …
• …
• …

La lista dei criteri di accettazione rappresenta l’elenco dei vincoli a cui la singola storia deve sottostare: per potersi considerare realmente completa, prima di passare il vaglio della demo (durante la Sprint Review), la storia dovrà soddisfare sia le regole specifiche definite dai vari criteri di accettazione (regole che sono specifiche per la storia in esame), sia tutte le regole specificate nella Definition of Done (vedi articolo precedente), regole che dovranno essere soddisfatte per tutte le storie.

Figura 5 – Un esempio di una storia compilata.

Essendo quindi gli AC validi per la singola storia, mentre la DoD lo è per tutte, è facile comprendere come nella prima finiranno requisiti funzionali (“l’utente deve inserire tutti i campi della form”), mentre nella DoD verranno inseriti requisiti non funzionali: è praticamente impossibile che un requisito funzionale sia da implementare per tutte le storie; se ciò dovesse verificarsi, probabilmente è per una errata scomposizione delle storie e si consiglia in tal caso un refactoring.

Non è raro invece che alcuni requisiti non funzionali siano inseriti negli AC, rendendone necessaria l’implementazione per la singola storia: si pensi a un particolare requisito di efficienza (“la funzione stampa deve essere completata in tot secondi”), di sicurezza (“al momento del login i dati dovranno transitare in modo protetto”)  o altro ancora.

Seconda C: Conversation

La seconda C del modello proposto da Jeffries è legata al processo con cui i requisiti sono individuati e raccolti. Una storia utente non deve essere intesa come lo strumento per catalogare e specificare i requisiti, ma piuttosto il pretesto per intavolare una discussione, in cui far fluire idee, scambiarsi pareri e opinioni. Una buona definizione recita che la storia inserita nel backlog è un impegno a rivedersi.

Per questo si parla si conversazione, che può, anzi deve, aver luogo in tutti i momenti in cui si ritiene necessario:

• durante il raffinamento, quando si inizia a prendere visione dello scopo della stessa;
• durante il planning, quando il product owner risponde a tutte le domande del dev team circa gli aspetti funzionali della storia;
• durante (soprattutto) la fase di implementazione nella sprint execution.

È in questo momento infatti che il programmatore che ha preso in carico la storia andrà ad approfondire e completare gli appunti che si erano presi durante la presentazione al planning: egli quindi  andrà a parlare con i vari interessati al fine di smarcare gli aspetti legati all’analisi funzionale, tecnica, e di implementazioni varie. Questi incontri sono per la maggior parte verbali, dato che si ritiene sia questo il modo più efficace per colmare ogni lacuna e chiarire tutti i dubbi: si ricordi a tal proposito che uno dei principi dell’Agile Manifesto è proprio il “face to face” (conversazione).

Conversazione e documentazione

È ormai convinzione comune che la comunicazione verbale offra una “banda” più larga, un feedback immediato, e permetta in modo più rapido ed economico giungere a una comprensione condivisa. La conversazione è inoltre una forma di scambio di informazione bidirezionale per cui, oltre a permettere una più efficace condivisione, può dar vita a nuove idee e spunti per risolvere determinati problemi.

Ovviamente nulla vieta di usare tutti gli strumenti a supporto che si ritengano utili: dagli schizzi su carta della GUI a riferimenti a documentazione esterna (libri legali, documentazione tecnica, manuali di specifiche UNI) e ad altro ancora. Il concetto fondamentale è che in questa fase non ci sono regole da seguire, ma si lascia spazio alla libera iniziativa. Anche per questo motivo gli sprint devono essere brevi, per evitare che quanto detto in una riunione a inizio sprint vada poi perso nel caso di sprint molto lunghi.

Questo passaggio viene però spesso preso come giustificazione per non corredare il progetto di alcuna documentazione: conversation no documentation. È quindi usato anche come spunto per attaccare le metodologie agili, Scrum in particolare.

In realtà questa è una convinzione quanto mai errata: la documentazione in Scrum viene considerata al pari di ogni altro componente da realizzare per completare la storia. Quindi durante la lavorazione è il team che decide come comportarsi per quanto riguarda la raccolta dei requisiti, consci del fatto che nulla più del codice funzionante potrà dimostrare la correttezza e completezza della storia (altro principio del manifesto agile). Poi, in base agli accordi presi col cliente, o alla policy auto-definita dal team, e quindi in base a quanto inserito nella DoD, si andrà a corredare la storia di eventuali manufatti che ne documentino il funzionamento.

Se, per esempio il cliente ha richiesto come outcome di progetto che ci sia una esaustiva documentazione fatta di documenti testuali che descrivano il flusso di ogni processo, corredati da dettagliati diagrammi UML, questo sarà tradotta come due punti nella DoD: tutte le storie per poter essere considerate complete, e quindi poter essere portate alla demo, dovranno avere documentazione testuale e diagrammi UML.

Questo è un passaggio molto importante, perche’ spesso la documentazione viene vista come un qualcosa che si può fare o non fare, prima o dopo il rilascio e con un diverso grado di approfondimento. In Scrum invece è tutto regolamentato  e condiviso.

Terza C: Confirmation

Dopo aver a lungo conversato, con l’obiettivo di aver raccolto tutti i punti importanti della storia, il solo modo per essere certi che siano stati presi tutti i punti richiesti è quello di verificarli con una serie di criteri di verifica, o come si è visto in precedenza per mezzo dei criteri di accettazione. La terza C, la conferma, fa riferimento esattamente a questo passaggio.

Durante la demo, una semplice e rapida verifica della storia tramite la lettura dei requisiti richiesti negli AC unitamente a quanto richiesto dalla DoD, rappresenta il modo più rapido per confermare o meno se quanto fatto corrisponde a quanto realmente richiesto.

Come si avrà modo di vedere più avanti, la parte di conferma, ovvero la compilazione prima e la validazione poi degli acceptance criteria, rappresenta non solo il modo migliore per inquadrare il lavoro da svolgere ma, grazie a un meccanismo di negoziazione interno al processo stesso, permette di avere un elevato grado di libertà nel lavoro di realizzazione della storia.

Conclusione

Abbiamo visto gli aspetti principali legati alle storie utente: la strutturazione semantica, il processo di raffinamento legato alla pila con epiche, features e storie pronte per lo sprint, le 3C (card, conversation, confirmation). Ma il discorso non finisce qui: per le user stories occorre vedere gli aspetti legati a come esse debbano essere strutturate. Lo faremo nella parte successiva.

Riferimenti

[1] Ron Jeffries, “Essential XP: Card, Conversation, Confirmation”

http://xprogramming.com/articles/expcardconversationconfirmation/