Che cos’è una storia utente?
Le user story sono brevi e semplici descrizioni di una funzionalità raccontata dal punto di vista della persona che desidera la nuova funzionalità, di solito un utente o un cliente del sistema. In genere seguono un semplice modello:
Come , voglio così .
Le storie degli utenti sono spesso scritte su schede o note adesive, memorizzate in una scatola da scarpe e disposte su pareti o tavoli per facilitare la pianificazione e la discussione., In quanto tali, spostano fortemente l’attenzione dalla scrittura sulle funzionalità alla loro discussione. In realtà, queste discussioni sono più importanti di qualsiasi testo sia scritto.
Puoi mostrare alcuni esempi di user story?
Uno dei vantaggi delle user story agili è che possono essere scritte a diversi livelli di dettaglio. Possiamo scrivere una storia utente per coprire grandi quantità di funzionalità. Queste grandi storie utente sono generalmente noti come epopee. Ecco un esempio di storia utente agile epico da un prodotto di backup desktop:
- Come utente, posso eseguire il backup dell’intero disco rigido.,
Poiché un epic è generalmente troppo grande per un team agile da completare in un’iterazione, viene suddiviso in più storie utente più piccole prima di essere lavorato. L’epopea sopra potrebbe essere divisa in dozzine (o forse centinaia), inclusi questi due:
- Come utente esperto, posso specificare file o cartelle da eseguire il backup in base alle dimensioni del file, alla data di creazione e alla data di modifica.
- Come utente, posso indicare le cartelle da non eseguire il backup in modo che la mia unità di backup non sia riempita con cose che non mi servono salvate.
Come vengono aggiunti i dettagli alle storie degli utenti?,
I dettagli possono essere aggiunti alle storie utente in due modi:
- Suddividendo una storia utente in più storie utente più piccole.
- Aggiungendo ” condizioni di soddisfazione.”
Quando una storia relativamente grande è divisa in più storie utente agili più piccole, è naturale supporre che siano stati aggiunti dettagli. Dopo tutto, più è stato scritto.
Le condizioni di soddisfazione è semplicemente un test di accettazione di alto livello che sarà vero dopo la storia utente agile è completa., Considera quanto segue come un altro esempio di user story agile:
In qualità di vice presidente del marketing, voglio selezionare una stagione delle vacanze da utilizzare quando rivedo le prestazioni delle campagne pubblicitarie passate in modo da poter identificare quelle redditizie.
Il dettaglio potrebbe essere aggiunto a quell’esempio di user story aggiungendo le seguenti condizioni di soddisfazione:
- Assicurati che funzioni con le principali festività al dettaglio: Natale, Pasqua, President’s Day, Mother’s Day, Father’s Day, Labor Day, New Year’s Day.
- Supporta vacanze che si estendono su due anni civili (nessuno si estende su tre).,
- Le stagioni delle vacanze possono essere impostate da una vacanza all’altra (come il Ringraziamento a Natale).
- Stagioni di vacanza può essere impostato per essere un numero di giorni prima della vacanza.
Chi scrive storie utente?
Chiunque può scrivere storie utente. È responsabilità del product owner assicurarsi che esista un product backlog di storie utente agile, ma ciò non significa che il product owner sia colui che le scrive. Nel corso di un buon progetto agile, dovresti aspettarti di avere esempi di storie utente scritti da ciascun membro del team.,
Inoltre, si noti che chi scrive una storia utente è molto meno importante di chi è coinvolto nelle discussioni di esso.
Quando vengono scritte le storie degli utenti?
Le storie degli utenti sono scritte in tutto il progetto agile. Di solito un workshop di scrittura di storie si tiene vicino all’inizio del progetto agile. Tutti i membri del team partecipano con l’obiettivo di creare un product backlog che descriva completamente la funzionalità da aggiungere nel corso del progetto o un ciclo di rilascio da tre a sei mesi al suo interno.
Alcune di queste agili storie degli utenti saranno senza dubbio epopee., I poemi epici saranno successivamente scomposti in storie più piccole che si adattano più facilmente a una singola iterazione. Inoltre, nuove storie possono essere scritte e aggiunte al product backlog in qualsiasi momento e da chiunque.
Le storie degli utenti sostituiscono un documento dei requisiti?
I progetti Agili, in particolare quelli Scrum, utilizzano un product backlog, che è un elenco con priorità delle funzionalità da sviluppare in un prodotto o servizio. Sebbene gli elementi del product backlog possano essere ciò che il team desidera, le storie degli utenti sono emerse come la forma migliore e più popolare di elementi del product backlog.,
Mentre un product backlog può essere pensato come un sostituto per il documento dei requisiti di un progetto tradizionale, è importante ricordare che la parte scritta di una storia utente agile (“Come utente, voglio want”) è incompleta fino a quando non si verificano le discussioni su quella storia.
Spesso è meglio pensare alla parte scritta come un puntatore al requisito reale. Le storie degli utenti potrebbero indicare un diagramma raffigurante un flusso di lavoro, un foglio di calcolo che mostra come eseguire un calcolo o qualsiasi altro artefatto desiderato dal proprietario del prodotto o dal team.,
Risorse consigliate relative alle storie utente
- Vantaggi del modello di storia utente “Come utente, voglio”.,
- Un Esempio di Formato di un Foglio di calcolo Basato su Backlog di Prodotto
- Vantaggi di Utente Storie per Requisiti
- Requisiti Non funzionali come le Storie Utente
- Introduzione alla User Stories
Leave a Reply