Se siete impegnati nello sviluppo di software, avrete sicuramente sentito parlare di user stories. Forse le scrivete anche come manager. O forse sei un cliente e il tuo sviluppatore software vuole che tu inquadri le richieste di funzionalità come user stories.

In questo post, troverai tutto quello che hai sempre voluto sapere sulle user stories.

Cos’è una User Story nello sviluppo software?

Una user story è un formato per inquadrare le caratteristiche e/o i requisiti del software. Come suggerisce la parte “utente”, le storie utente sono scritte in prima persona singolare e descrivono una caratteristica come viene percepita dall’utente dell’applicazione.

Una tipica storia utente segue questa struttura (se stiamo parlando del processo di sviluppo Agile):

Come ,
Voglio ,
Così che .

La prima parte (come un…) specifica il ruolo dell’utente nell’applicazione, che è normalmente associato a ciò che uno è autorizzato a fare lì.

La seconda parte (la caratteristica) indica il pezzo di funzionalità che è usato in questo caso.

La terza parte (il risultato desiderato) è il valore che l’utente vuole ottenere dalla caratteristica. Ecco alcuni esempi.

Esempio 1

Come utente registrato,
voglio essere avvisato quando un amico va a un evento nelle vicinanze
in modo da poter reagire alla notizia o unirmi a lui nell’evento.

Esempio 2

Come pilota,
voglio ottenere uno sconto del 10% ogni 10 viaggi
in modo da essere ricompensato per aver speso costantemente soldi per il servizio.

Ci sono buone ragioni per questo tipo di struttura. Quando i product/project manager hanno a che fare con requisiti software che provengono da una varietà di fonti, a volte è difficile per loro raggiungere l’uniformità. Quale categoria di utenti copre la caratteristica o dove si trova il valore di business può anche essere poco chiaro. Il formato delle storie utente aiuta a catturare questi dettagli critici.

Approcci alla composizione delle storie utente

Le storie utente possono essere scritte in una varietà di modi, a seconda di chi ci lavorerà.

The Gherkin Way

Gherkin è un linguaggio di testo semplice che descrive il comportamento senza specificare la sua implementazione. Ecco un semplice esempio della sintassi di Gherkin:

Feature: Guest contributor functionality
In order to contribute to blog XXY
As a guest author
I want to be able to publish articles on the website


Scenario: I edit my own article
Given I am a contributor
And I am logged in to my account
When I am on a separate article page
And I am the author of this article
Then I can see the "edit" button
And I can click it
And I can use a popup interface for editing my article

Scenario: I edit somebody else's article
Given I am a contributor
And I am logged in to my account
When I am on a separate article page
And I am NOT the author of this article
Then I CANNOT see the "edit" button

Come avrete notato, il rientro definisce la struttura in Gherkin. I parametri di base sono Given/When/Then, e questi possono essere aggiunti da più And se necessario. La sintassi va oltre questi parametri di base, però. Se sei davvero determinato a padroneggiare Gherkin, qui c’è un bel tutorial.

Mentre Gherkin può non essere la scelta migliore quando stai raccogliendo i requisiti iniziali per il progetto, può essere vantaggioso (specialmente per il team QA) quando sviluppi ulteriormente le user stories. Le storie utente scritte in Gherkin sono facili da convertire in casi di test.

Il modo Agile

Molte applicazioni di gestione di progetti Agile offrono una funzionalità per inserire storie utente. Per esempio, abbiamo usato l’applicazione Taiga su alcuni dei nostri progetti interni. Ti aiuta ad organizzare il lavoro intorno alle user stories che possono essere suddivise in compiti individuali nel backlog.

Fonte: Taiga.io interface

Se ci pensi, ha perfettamente senso avere le user stories come elementi del backlog e poi aggiungere più compiti ad una user story. Perché? Perché, diciamo che avete una caratteristica (=storia utente) e tre persone che ci lavorano; avrete bisogno di compiti separati per queste persone. Avrete bisogno di un designer per progettare l’interfaccia, un programmatore HTML/JavaScript per programmare l’interfaccia, e il DevOps per rilasciare l’interfaccia in produzione.

Anche altri strumenti come Pivotal Tracker (che introduce il concetto di “epica” per raggruppare insieme storie correlate) vi permettono di creare storie che possono essere di diversi tipi: Features, Chores, Bugs o Releases.

Fonte: PivotalTracker.com

A parte i vari approcci usati dalle varie aziende, ricordate che c’è un modo semplice e diretto di scrivere le storie utente – esempi dei quali avete visto all’inizio di questo post.

Chi dovrebbe scrivere le storie utente?

Quindi, di chi è la responsabilità di scrivere storie utente? Beh, dipende. Se il tuo team ha accettato di catturare le caratteristiche sotto forma di user stories, è molto probabile che queste vengano dagli azionisti attraverso il Product Owner. Quindi, potrebbe essere il PO che effettivamente le scrive.

Potrebbe anche essere un Project Manager o un QA che potrebbe anche lavorare con il cliente per discutere di caratteristiche e requisiti. Oppure, forse siete una startup di 15 persone e siete il CEO, il CTO e il CMO? In questo caso, potreste dare l’esempio e iniziare a usare le user stories per documentare le caratteristiche.

Molti nell’IT parlano anche di “sviluppo di user story”, che è il processo di registrare prima i dettagli di alto livello (ad esempio, iniziando con una semplice lista di caratteristiche) e poi svilupparli in storie più dettagliate aggiungendo compiti, scenari, ecc.

In conclusione

Alla fine della giornata, formulare caratteristiche sotto forma di user stories vi aiuta a rimanere concentrati sugli obiettivi del business. Vi aiuta anche a rendere i requisiti completi. E, come è stato detto, l’esatto modello/campi da usare potrebbe essere diverso, a seconda della situazione.