Il media che reinventa l'impresa
Il media che reinventa l'impresa
Le User Stories sono uno strumento centrale nella collaborazione dei team agili. Il loro campo di applicazione è ampissimo e va dalla soddisfazione di specifiche esigenze dei clienti, al supporto dei team Scrum.
Ma cos’è esattamente una User Story e come si fa a realizzarla? In questo articolo faremo chiarezza su questo concetto: vi mostreremo come va strutturata una storia utente e come lavorare con successo con questo strumento.
User Story è una dicitura inglese che, letteralmente, è traducibile con “storia utente”. Nell’ambito della gestione agile dei progetti e dello sviluppo di software, la User Story è uno strumento che consente di descrivere le funzionalità di un dato sistema dal punto di vista dell’esperienza dell’utente.
La funzione della User Story è quella di soddisfare specifiche esigenze dell’utente e le sue aspettative riguardo ad alcune funzionalità di un software o di una soluzione proposta.
La storia utente, infatti, ha lo scopo di far comprendere al lettore quale sia il beneficio del sistema preso in esame. In questo modo è possibile raggiungere un più alto grado di sensibilizzazione rispetto ai vantaggi apportati dal prodotto o servizio presentato.
Una User Story, in fin dei conti, serve, dunque, a far aumentare la comprensione di un sistema e, quindi, ad incentivare il suo grado di successo tra gli utenti.
Lo Use Case, o caso d’uso, può essere considerato come una versione più massiccia della User Story. Infatti, esso è molto elaborato e dettagliato, copre un contesto più ampio ed è, quindi, più completo di una storia utente. Solitamente esso comprende addirittura più User Stories.
Il caso d’uso è normalmente più durevole di una storia utente. Esso, infatti, viene di solito mantenuto per tutto lo sviluppo del sistema, mentre la User Story scompare al suo completamento in uno Sprint.
Le storie utente possono essere scritte da o per gli utenti.
Normalmente la User Story è frutto di un team di lavoro, che si dedica alla sua redazione e ottimizzazione. Normalmente il gruppo si concentra, innanzitutto, sullo sviluppo di determinati criteri attorno ai quali sviluppare la propria storia. Questi possono essere, ad esempio, il grado di complessità, il modello da seguire, l’impostazione delle informazioni, e così via.
Da principio, dunque, vanno definite le proprietà strutturali che si vogliono attribuire alla storia. Se si opera in team, è bene suddividere i compiti all’interno del gruppo e fissare l’arco temporale in cui il lavoro deve essere svolto.
Per cominciare, vanno, quindi, stabiliti degli Story Points, ovvero numeri arbitrari utilizzati per stimare quanto lavoro il team è in grado di portare a termine in ogni iterazione.
Quindi, vanno fissati eventualmente anche degli Sprint, ovvero dei cicli di lavoro di durata da una a quattro settimane. L’insieme degli Story Points e degli Sprint costituiscono la base del Planning della User Story.
☝ In questo contesto si è parlato di Sprint al plurale. Tuttavia, si noti che, per la realizzazione di una User Story, è spesso necessaria una sola iterazione o Sprint.
Lo step successivo è quello di assicurarsi che le task siano espresse in modo chiaro e siano assegnate a diversi membri del gruppo di lavoro. L’organizzazione e la coordinazione sono, infatti, fondamentali per poter redigere una User Story di qualità.
Tuttavia, capita che le User Stories vengano redatte senza che ci sia stata un’analisi dettagliata delle attività da svolgere. Il grado di strutturazione della storia è, infatti, un fattore arbitrario e soggetto alla libera scelta del gruppo di lavoro. Chiaramente, più un team mira a garantire servizi di eccellenza, più prediligerà una pianificazione articolata della User Story.
☝ Il planning della User Story deve avere come fine il beneficio dell’utente, non la promozione della soluzione, prodotto o servizio in esame.
Le storie utente vengono gestite nel Backlog. In questo contesto entra in gioco il concetto DEEP, sviluppato da Roman Pichler. Egli ha ideato questo modello al fine di operare un Backlog corretto. DEEP è un acronimo, che sta a designare le seguenti parole:
Quando si è in procinto di scrivere una storia utente, è bene tenere a mente una struttura raccomandata di base:
Come x (ruolo di chi scrive), vorrei xy (riferimento alla funzionalità desiderata), al fine di yy (scopo).
Oltre a questo modello di base esistono altre alternative. Un altro modello possibile per una storia utente è, ad esempio:
Per poter yy (scopo), dal momento che sono x (ruolo), vorrei xy (funzionalità).
☝ Il ruolo deve essere fatto coincidere le vostre Personas. Una Persona è un tipico rappresentante del vostro gruppo target.
Le storie utente, come d’altra parte tutte le storie, possono variare nel grado di dettagli fornito. Infatti, alcune storie possono limitarsi a fornire un contenuto molto approssimativo. Altre, invece, possono presentare un esordio generico, per poi perfezionarsi solo successivamente. Altre ancora possono mostrarsi dettagliate fin dal principio.
Attenersi ad un modello per formulare la propria User Story non è obbligatorio, ma risulta pratico. L’esperienza nel settore delle storie utente ha mostrato che il mantenimento della struttura di base raccomandata non solo favorisce la formulazione, ma facilita anche la comprensione da parte del lettore.
La lingua da preferire per scrivere una User Story è l’inglese. Potrebbe risultare una scelta strana, soprattutto se si è attivi nel panorama italiano. Tuttavia, ormai da tempo l’inglese è diventato la lingua franca in quasi tutti i paesi ed è una lingua ormai parlata a livello internazionale.
Per di più, questa lingua consente un alto grado di concisione, dal momento che si presenta estremamente sintetica e diretta.
Per questo può risultare una scelta assennata proporre la propria User Story in inglese.
Di seguito alcuni esempi di applicazione dei modelli di storia utente proposti.
1. Come amante dei romanzi storici, vorrei essere informato sui relativi libri in uscita, al fine di poter ordinarli per tempo in libreria.
2. Come amante dei film di avventura, vorrei sapere che pellicole di questo genere sono uscite nel vostro cinema, al fine da poter acquistare i biglietti online.
3. Per poter trovare un abbonamento conveniente, dal momento che sono un amante del cinema, vorrei ricevere informazioni sulle promozioni disponibili nel vostro cinema.
Dal momento che la User Story mira ad essere recepita e compresa nel minor tempo possibile, è importante che essa:
Secondo le parole di Mike Cohn, uno dei principali contributori all'invenzione della metodologia di sviluppo software Scrum, tutte le storie utente agili includono solo una o due frasi scritte in modo semplice e, cosa più importante, una serie di conversazioni attivate di conseguenza sulla funzionalità desiderata.
Si può essere sicuri che una User Story è stata completamente implementata, quando i criteri di accettazione si dimostrano essere stati rispettati. Ma cosa sono i criteri di accettazione?
Con criteri di accettazione in riferimento ad una storia utente si intende definire i parametri che dimostrano che i risultati chiave della storia utente sono stati raggiunti.
I parametri a cui stiamo facendo riferimento sono le W-Questions (Who? What? Why? When? Where? Ecc.).
Queste permettono di capire se una User Story è efficace e risponde a tutte le possibili esigenze cognitive del lettore.
I criteri di accettazione sono, dunque, dei test che vengono applicati alla storia utente per verificarne l’adeguatezza in base allo scopo di impiego. Particolare attenzione in questo contesto deve essere concessa all’individuazione e alla valorizzazione delle parole chiave, ovvero l’uso di verbi, aggettivi e sostantivi pertinenti.
Un modo per testare l’efficacia della vostra User Story è ricorrere al principio formulato da William Wake. Anche INVEST è un acronimo e sta per:
In fin dei conti, tutti i punti del principio INVEST servono a valutare la qualità di una storia utente e, anche, a pilotarne la realizzazione perché essa risulti efficace. Attenersi ai punti proposti in questo modello di svolgimento può fare la differenza nel determinare il successo della vostra User Story!
Come palesato dal principio INVEST, le storie utente dovrebbero essere indipendenti tra loro. Tuttavia, nella pratica, accade spesso che esistano delle interdipendenze tra varie User Stories. La dipendenza delle storie utente può essere di tipo diverso. Ad esempio, essa può avvenire a livello contenutistico, tecnico, normativo o regolamentare, temporale, e così via.
L’esistenza di interdipendenze tra le User Stories non è spesso evidente, ecco perché è utile utilizzare uno User Story Mapping, al fine di scovarle e rimuoverle.
Esiste una differenziazione di base all’interno della macrocategoria delle storie utente. Infatti, in base alla portata dei benefici forniti da queste ultime al lettore, le User Stories possono essere anche assumere la denominazione di Epic Stories.
La differenziazione di queste due categorie non è omogenea e sempre uguale a se stessa. Ciò significa che non esiste uno standard riconosciuto in base al quale una storia viene classificata automaticamente come User o Epic.
In linea generale, tuttavia, si può definire una Epic Story come una storia utente che possegga un alto grado di pregnanza tecnica e specialistica. Le Epic Stories, normalmente, infatti, descrivono le funzionalità in modo assolutamente dettagliato, tecnico e specifico.
Una User Story è uno strumento pratico e poco dispendioso a livello di costi e di tempo da dedicarvi. Ad essa sono, tuttavia, legati diversi vantaggi, come :
Al giorno d’oggi le storie utente sono uno degli strumenti prediletti per formulare e discutere le funzionalità di un prodotto o servizio. Ecco perché conoscerne i meccanismi ed imparare a padroneggiarli è fondamentale per un’implementazione mirata di un qualsivoglia sistema.
