Cominciamo, con questo numero, una lunga serie che affronterà diverse tematiche legate allo sviluppo con metodologie agili, focalizzandosi soprattutto su temi pratici: agile in azione, insomma. Mese dopo mese, verranno affrontati numerosi argomenti, ma, per partire, occorreva concentrarsi ovviamente sulle storie utente.

Le “storie utente”

Come molti di voi sapranno, la user story nel mondo agile di sviluppo software, rappresenta una caratteristica o requisito di prodotto, che vuole soddisfare una specifica esigenza dell’utente.

Nel definire le storie utente, il linguaggio e il formato utilizzati devono dare una chiara evidenza del valore di business che si intende raccogliere attraverso quella funzionalità e, possibilmente, sottolineare chi è  l’utente coinvolto e le azioni che lo stesso dovrà svolgere, per raggiungere quel risultato.

Le user stories nascono come strumento di dialogo e collaborazione tra due mondi spesso lontani e contrapposti: chi concepisce il prodotto (business) e chi lo deve realizzare (sviluppo). Si tratta di mondi il cui linguaggio può differire anche in maniera estrema.

Figura 1 – Un adeguato linguaggio è l’imperativo per mettere in comunicazione chi concepisce il prodotto e chi lo deve realizzare.

L’importanza di un linguaggio comune

La comunicazione e il linguaggio che si utilizzano assumono quindi grande importanza per mettere in relazione business e sviluppo.

Il business è focalizzato sulla visione generale di prodotto. Presidia i movimenti del mercato, ne percepisce gli andamenti e le tendenze, i segnali deboli, gli orientamenti. Nel descrivere la soluzione, le necessità, evita spesso di entrare troppo nel dettaglio e ragiona in maniera astratta, per schemi.

Chi sviluppa il prodotto, invece, è abituato a studiarne la fattibilità, a generare stime e a ragionare in maniera estremamente logica. Lavora per processi iterativi e incrementali; il dettaglio tecnico è parte consistente del suo quotidiano e, il più delle volte, ne influenza anche il modo di comunicare.

Le differenze di comunicazione di questi due mondi, derivanti dai suddetti differenti approcci, hanno conseguenze negative sul prodotto che difficilmente riuscirà ad avere il successo sperato.

User story, una soluzione collaborativa

Le storie utente nascono proprio come soluzione a questa difficoltà comunicativa, e servono a tradurre in un linguaggio semplice e comprensibile i requisiti e le funzionalità richieste.

Una user story, quindi, deve focalizzarsi sul valore di business che la stessa vuole perseguire, non richiamando alcun dettaglio tecnico, se non per i requisiti non funzionali (NFR, “non functional requirements”), ma questo è un altro discorso.

L’aspetto implementativo di quella funzionalità, infatti, sarà di esclusivo dominio del team di sviluppo che, in completa autonomia e organizzazione, ne analizzerà le attività tecniche necessarie e si prodigherà nella loro esecuzione, puntando a restituire il valore richiesto.

Come è fatta una user story

Bene, vediamo un semplice esempio di user story. In pratica si tratta di “mettersi nei panni” dell’utente e dichiarare che cosa di deve poter fare in quanto utente e con quale risultato positivo (il “valore”). 

• Come utente web della banca
• Devo poter fare un bonifico
• Così da pagare l’affitto, anche se la banca è chiusa

Un requisito espresso in questo modo, cioè dal punto di vista dell’utente (user story), mostra senza possibilità d’errore o malinteso il vero valore di business che si vuole trarne (“poter fare un trasferimento di denaro anche a banca chiusa”), ne esplicita la tipologia dell’utente coinvolto (“utente web della bancaW), circoscrivendo al tempo stesso, la funzionalità a un dominio preciso (“pagamento tramite bonifico bancario”).

Scomporre le user stories

Il grado di scomposizione della user story è un altro elemento fondamentale. Uno dei punti di forza delle discipline agili, e più precisamente di quelle di sviluppo iterativo (p.e., XP e Scrum), sta appunto nella pianificazione e analisi iterativa e incrementale del requisito utente.

Una tecnica di riferimento è chiamata Rolling Wave Planning (in italiano traducibile con un improbabile “pianificazione a finestra mobile”) che, nel project management tradizionale, prevede un’iniziale pianificazione di alto livello basata sulle prime generiche ipotesi fatte in presenza di visibilità e certezza limitate, proprie di progetti ad alto rischio o complessità. Con il passare del tempo e con l’aumentare della conoscenza di progetto, si potrà procedere alla pianificazione per ondate successive (sono queste le “wave” del nome), i cui dettagli saranno via via più chiari e facilmente analizzabili e indirizzabili.

Questa tecnica, applicata al mondo agile, prevede anch’essa una raccolta di alto livello delle necessità utente nello stadio iniziale del progetto, al fine di procedere ad una prima stima dei costi, dei rischi e della pianificazione delle macro-attività.  Successivamente, in modalità iterativa, si procederà alla scomposizione fine dei requisiti che verranno da lì a breve messi in sviluppo.

Tante funzioni poco usate

L’uso della tecnica suddetta è messo in atto per scongiurare quanto lo Standish Group fotografa in uno dei suoi studi più interessanti: i sistemi hanno un elevato numero di funzion, ma solo poche di esse vengono utilizzate realmente. Accade infatti che il 64% delle funzionalità di un sistema siano raramente o mai utilizzate.

Figura 2 – Percentuale di utilizzo delle diverse funzionalità di un sistema. La gran parte delle funzioni è usata raramente, se non addirittura mai.

Questo spreco enorme di risorse è proprio da addebitarsi a problemi di comunicazione, malintesi, errate aspettative, eccessiva analisi di dettaglio in relazione ai tempi di effettiva realizzazione, mancanza di feedback o di confronto con il business.

Ed è proprio da qui che vorrei partire con i consigli per mettere in atto le metodologie agili, scrivendo di una tecnica tanto eccezionale quanto semplice e immediata, che vede tutti gli attori coinvolti nella prima fase di scoperta e identificazione dei requisiti di prodotto, altrimenti detti user stories. La tecnica si chiama User Story Mapping.

User Story Mapping

La User Story Mapping è una tecnica collaborativa, che richiede un po’ di preparazione e di materiali, ma che è sostanzialmente semplice e, soprattutto, molto “remunerativa” in termini di focalizzazione del progetto. È necessario che disponiate di una stanza con un muro piuttosto ampio, post-it di varie dimensioni, pennarelloni, scotch di carta e, perche’ no, una whiteboard attorno alla quale ragionare e un proiettore dove mostrare eventuale materiale a corredo.

Gli invitati alla sessione dovranno essere obbligatoriamente

• chi ha concepito il prodotto (ProductOwner);
• eventuali altri stakeholder con interesse o conoscenza specifica del dominio in analisi;
• chi dovrà sviluppare concretamente sviluppare il prodotto (team di sviluppo).

Ora avete tutti gli ingredienti necessari. Potete inoltrare gli inviti alla riunione, che potrà durare dalle 4 alle 8 ore, in relazione alla complessità del prodotto sotto esame.

Primi passi

La riunione si apre con il rappresentate del business, quello che in Scrum si chiama ProductOwner, che illustra brevemente i punti salienti del prodotto, le sue caratteristiche fondanti e ne illustra le motivazioni di business che hanno spinto l’azienda a finanziare tale progetto. Illustra, per usare un termine oramai comune, la vision.

A questo punto il ProductOwner e il team di sviluppo cominciano ad analizzare le principali funzionalità e caratteristiche del prodotto, non entrando in questa prima fase, in alcun dettaglio funzionale.

Individuare le user stories

Ipotizziamo che il prodotto da sviluppare sia un client di posta elettronica. Utilizzerò quello che in rete sembra essere l’esempio che per questa tecnica è oggi più in voga, in modo da permettere eventuali parallelismi con altre fonti.

Le principali funzionalità potrebbero essere le seguenti: Organizza Email, Gestione Email, Gestione Calendario e Gestione Contatti.

Figura 3 – Le principali funzionalità individuate per un ipotetico client di posta elettronica.

Scrivete quelle funzionalità su post-it e attaccateli nella parte alta del muro. Sono queste le funzionalità principali su cui concentrarsi e dalle quali partire per la successiva fase.

Approfondire le funzionalità

A questo punto, il ProductOwner e il team di sviluppo cominciano a ragionare su quali possano essere le attività o task, che un utente può voler svolgere per ognuna di quelle macro-aree. Comporre un’email, creare un appuntamento, eliminare un contatto, sono ottimi esempi di funzionalità, che in questa fase del processo devono, però, rimanere ancora di alto livello.

Ogni proposta da parte delle persone coinvolte, verrà presa in considerazione e, se ritenuta valida in relazione al prodotto e al valore di business atteso, scritta su un post-it e attaccata nella fila corrispondente.

Ecco che, focalizzandoci volutamente solo sul ramo Organizza Email, l’evoluzione potrebbe essere quella rappresentata in figura 4.

Figura 4 – Lo sviluppo della funzione Organizza Email, su un ulteriore livello.

Scomporre ogni rampo in ulteriori sotto-funzionalità

Ottimo. Ora siamo pronti al passo successivo di scomposizione di ogni ramo in sotto-funzionalità. Il processo, su quel ramo, potrebbe portarvi ad avere la situazione di figura 5.

Figura 5 – Ogni ramo viene ulteriormente scomposto in sotto-funzionalità.

Questa è la fase dove non solo si catturano le principali funzionalità per ogni sotto-ramo (vedi post-it arancioni), ma si comincia anche a rendersi conto di come alcune funzionalità siano veramente importanti, basilari, irrinunciabili, mentre altre potrebbero essere pensate come accessorie o secondarie.

Sarà responsabilità del ProductOwner mettere queste funzionalità, e i relativi post-it, in ordine di importanza rispetto al loro valore di business, partendo dall’alto per le funzionalità con maggior valore e procedendo in scala verso il basso con le restanti.

Nel nostro esempio, per il ramo Composizione Email, questo porterà ad avere la funzionalità di creazione e spedizione di una email base, con testo standard, come prima voce e la spedizione di messaggi in formato RTF, che preveda quindi le principali formattazioni di carattere e paragrafo, con priorità  inferiore.

Figura 6 – La definizione delle caratteristiche viene ulteriormente approfondita, anche in riferimento alle successive release previste per il prodotto.

Procedendo a ragionare sulle priorità assegnate alle singole funzionalità di prodotto e alla loro sequenza, è d’obbligo introdurre il concetto di release di prodotto. Le funzionalità più in alto, per forza di cose, dovranno essere incluse nella prima release, le altre nelle successive.

In questo momento il ProductOwner, con l’aiuto del team e di uno scotch di carta di buona qualità, può circoscrivere e raggruppare orizzontalmente attraverso delle linee, le funzionalità per release come riportato in figura.

Giungere a dei risultati

Bene, abbiamo quasi terminato. Il ProductOwner effettuerà a questo punto diverse fotografie nitide della parete (non vorrete mica perdervi ore di lavoro?), staccherà i post-it in maniera ordinata e riporterà il testo di ognuno in un foglio di calcolo, facendo attenzione a mantenere inalterate le priorità e l’appartenenza ai relativi rami. Quello che avrete appena creato, sarà la prima versione, sebbene ancora embrionale, del Product Backlog.

User stories in formato “standard”

L’ultimo passo per Team e ProductOwner sarà quello di riscrivere le storie nel formato standard vale a dire quello in cui “Come utente… voglio poter fare… in modo da…” e assicurarsi che ogni user story soddisfi una serie di criteri, tutti facilmente richiamabili alla mente tramite l’acronimo INVEST.

Ogni user story deve infatti essere:

• Independent (preferibilmente non dipendente da o accoppiata con altre storie)
• Negotiable (negoziabile in termini di dettaglio tecnico e comportamento)
• Valuable (restituire valore all’utilizzatore)
• Estimable (essere stimabile dal team)
• Sized-properly / Small (di dimensioni contenute per poter essere sviluppata insieme ad alcune altre nell’iterazione)
• Testable (essere testabile)

Conclusioni

Abbiamo visto in questo primo articolo che cosa sono le user stories e come individuarle, proponendo una tecnica semplice ma efficace per mapparle nel dettaglio e assegnare loro una priorità: il punto cruciale sta nel ricordarsi sempre che esse devono restituire un valore per l’utente, e che devono essere aderenti ai principi dell’acronimo I N V E S T.

Nel prossimo articolo, continueremo ad affrontare un altro aspetto pratico del mondo Agile, piuttosto complesso ma altrettanto importante: le stime.