Una storia utente descrive, in modo semplice, un requisito che è di interesse per un utente del sistema software. Ecco alcuni esempi di storie utente.
Le storie sono brevi e non contengo molti dettagli sui requisiti che rappresentano, piuttosto questi vengono discussi in una conversazione con il cliente.
Cos'è una storia utente o meglio una user story:
Si tratta di un modo per rappresentare una funzionalità o un requisito che è di valore per un utente del sistema software o per il suo acquirente.
Essa prevede tre aspetti:
Di solito ciascuna storia viene scritta su una scheda cartacea o su un post-it.
Una scheda è la manifestazione più concreta di una storia utente, ma non è la più importante. Più importante è la conversazione, fra il team di sviluppo e gli utenti/clienti del sistema.
L'esito della conversazione viene poi riassunto sotto forma di test di accettazione, che vengono scritti sul retro della scheda.
Per esempio durante un workshop per i requisiti si potrebbe identificare e scrivere la seguente storia:
un cassiere può inserire gli articoli acquistati da un cliente.
In tale occasione si discute solo quanto basta per capire l'importanza di questo requisito e per produrre una stima ragionevole del lavoro necessario per implementarlo.
Questa storia utente viene poi ripresa successivamente, nell'iterazione in cui va sviluppata. La conversazione ha luogo solo quando è effettivamente utile comprendere ulteriori dettagli sulla storia, ovvero quando il team di sviluppo si appresta a implementarla. Dalla conversazione potrebbe emergere, per esempio, che l'inserimento di ciascun articolo deve avvenire mediante l'inserimento del codice identificativo dell'articolo, e che in alcuni casi il cliente può acquistare più articoli di una stessa categoria.
La conversazione relativa a questa storia non viene poi documentata in forma scritta in modo dettagliato. Piuttosto vengono riassunte le aspettative dell'utente riguardo questa storia sulla scheda sotto forma di test di accettazione:
Anche le descrizioni dei test sono spesso brevi e incomplete. L'obiettivo non è documentare tutti i dettagli.
Il coinvolgimento degli utenti nei progetti è importante. In particolare, i metodi agili prevedono una collaborazione continuativa con utenti e clienti, privilegiando la comunicazione faccia a faccia.
Le parole scritte si rivelano spesso inadeguate a descrivere i bisogni degli utenti (ovvero i requisiti del sistema). Per questo può essere preferibile sostituire la scrittura di lunghi documenti sui requisiti on conversazioni frequenti tra il team di sviluppo, utenti e clienti. Per questo può essere sostituibile la scrittura di lunghi documenti con conversazioni frequenti tra team di sviluppo, gli utenti e i clienti del sistema. Si chiamano storie per questo, poiché evocano una comunicazione piuttosto che qualcosa di scritto. In ogni caso, come abbiamo visto, queste prevedono una piccola parte scritta.
Inoltre le storie consentono di rimandare la conoscenza dei dettagli al momento in cui è effettivamente importante conoscerli.
Premessa: per dimensione non si intende lunghezza testuale, ma portata di una storia
Ecco tre storie diverse:
Per questo è possibile suddividere e combinare le storie.
Vediamo come scrivere le storie.