Dopo aver esaminato e analizzato oltre 10.000 storie di utenti provenienti da diverse fonti, abbiamo acquisito alcune informazioni su ciò che rappresenta una buona storia di utenti. Se tu volessi imparare a scrivere storie utente migliori, dovresti trovare utile questo articolo.
Cos'è una storia utente?
Prima di iniziare con i 10 passaggi, rivisitiamo la questione di cosa sia una user story. Una storia utente viene generalmente descritta come un segnaposto per una conversazione su un'esigenza dell'utente. Tipicamente ci riferiamo alle tre C: Carta, Conversazione E Collaborazione. In molte organizzazioni, tuttavia, le storie degli utenti SONO l'elenco dei requisiti.
I puristi e gli allenatori agili in genere affermano che la storia dell'utente non dovrebbe essere considerata un sostituto dei requisiti scritti, poiché ciò mina la promozione della collaborazione tra i membri del team. Tuttavia, nella maggior parte dei casi nella maggior parte delle organizzazioni l'elenco delle storie utente è l'elenco dei requisiti.
E ora, vediamo 10 passaggi per scrivere storie utente migliori:
1. Concentrarsi sui bisogni funzionali
La funzionalità dovrebbe essere scritta come segue, ove possibile: Come __ ho bisogno di __ . In ogni storia includi tutte le funzionalità che la rendono completa. Includere movimenti di dati tra sistemi (a condizione che il tuo scopo sia aggiungere, modificare o eliminare tale funzionalità). Una storia utente che inizia con "Quando" anziché "Come" va bene purché descriva un evento funzionale che include un utente, un oggetto e un'azione. es. “quando il sensore di temperatura rileva 100 gradi invia un segnale per disattivare la fonte di calore”
Escludere le attività del team e qualsiasi lavoro di configurazione non direttamente correlato alla fornitura di funzionalità nuove, modificate o eliminate.
2. Chiaro e inequivocabile
Se una storia utente non è chiara, porterà a bug. Questo è assolutamente cruciale da risolvere e risolvere presto. Dovrebbe essere inequivocabile per il pubblico di lettori previsto (almeno: utenti, sviluppatore, tester, analista, progettista). Il semplice test per l’ambiguità è garantire che due lettori qualsiasi dello stesso testo raggiungano la stessa comprensione di quale funzionalità deve essere fornita – in caso di dubbi, chiediglielo.
Utilizza verbi relativi ai dati come aggiornamento, Inviare O salva. Evita verbi come: considerare, fornire, volere, decidere, sostenere E valutare . Questi potrebbero trarre in inganno il lettore.
3. Prezioso e riconducibile ai risultati aziendali
Questo è per molti aspetti l'attributo più importante di una user story. Se la storia non è utile all'azienda allora dovrebbe essere esclusa. Idealmente il valore della storia può collegarsi direttamente a Capacità E Risultati che sono misurabili. ovvero esiste una chiara tracciabilità tra la funzionalità della user story e la capacità necessaria per raggiungere l'obiettivo misurabile risultato.
4. Dal punto di vista dell'utente
Concentrarsi sull'esperienza dell'utente specifico dell'applicazione. Cerca anche di essere specifico riguardo al tipo e al contesto dell'utente. Ad esempio, invece di "come utente", prova a fornire il contesto all'interno dei tuoi nomi utente, ad esempio: loggedin_customer, loggedin_marketing_agent. loggato_amministratore. Questo è informativo sul contesto senza essere prolisso.
5. Conciso
Storie di utenti eccessivamente prolisse che includono troppi dettagli su esigenze funzionali, dichiarazioni di progettazione e criteri di test porteranno a confusione. Conserva le tue storie breve, semplice e preciso. È meglio essere brevi e chiari che essere troppo specifici.
Cerca di mantenere le storie degli utenti piccole e semplici ma sufficientemente complete da evitare la proliferazione delle storie. Due suggerimenti specifici riguardano il riferimento agli oggetti e non ai tipi di oggetti (troppo grandi) o agli attributi degli oggetti (troppo dettagliati). Per esempio "come loggedin_customer posso aggiornare il mio profilo” è meglio di "come loggedin_customer posso aggiornare qualsiasi dato” O "Come cliente loggato posso aggiornare il mio numero di telefono"
6. Coerente
Sii coerente con il tuo nomi utente E nomi degli oggetti.
Con i dati conservati all'interno del sistema sii coerente con i nomi che usi, cerca di fare riferimento il più possibile solo a oggetti e tipi di oggetti, evita gli attributi degli oggetti all'interno delle storie. per esempio profilo utente (che include un attributo per la data di nascita) è migliore di data di nascita.
7. Completarsi in sé
Se una storia utente richiede più passaggi funzionali, includili tutti. per esempio
Prima: Come utente desidero aggiornare i dettagli del negozio.
Dopo: In qualità di amministratore loggato, devo verificare la mia autorizzazione [per aggiornare store_record]. Posso quindi aggiornare il file store_record
Le due istruzioni funzionali indicano che è necessario verificare le autorizzazioni prima di poter eseguire un aggiornamento.
8. CRUD Completo e non duplicato in un set
Se stiamo aggiornando informazione di magazzino nell'esempio sopra, esiste anche una user story simile che ci permette di creare un negozio? Un'altra storia per eliminare un negozio? E un'altra storia per esporre un negozio? Le storie mancanti sono la causa dello spostamento dell'ambito, che spesso fa sì che i progetti vadano oltre il loro programma originale.
Allo stesso modo, fai attenzione alle storie utente duplicate. I requisiti duplicati sono meno comuni, ma si verificano, quindi controlla di non aver raddoppiato la funzionalità.
9. Testabile
Se un lettore non riesce a capire facilmente come testare la user story, allora non è testabile. Ci riferiamo qui al test dal punto di vista funzionale. Eventuali vincoli dovrebbero essere inclusi e tutti i vincoli scalari dovrebbero essere quantificati.
10. Non contiene alcun disegno
Le storie degli utenti non devono contenere dichiarazioni di progettazione.
Conclusione
Questi sono 10 dei miei suggerimenti preferiti per scrivere storie utente migliori. Te lo garantisco se segui questi suggerimenti scriverai storie utente migliori, e questo porterà alla scrittura software migliore.
Cosa succede se le mie storie utente non sono buone? Ha importanza, purché io abbia il nocciolo della storia? Sì, lo fa. Anche una sola ambiguità comporterà uno spreco di tempo e fatica nell'interpretazione, in interpretazioni errate e in un certo grado di rielaborazione. Un'omissione potrebbe richiedere una revisione importante del progetto (o introdurre un debito tecnico se è troppo tardi per modificare il progetto). Quindi sì, è necessaria molta cura quando si scrivono storie o requisiti degli utenti. Buoni requisiti possono portare ad una consegna puntuale. Requisiti scadenti costeranno sicuramente di più e richiederanno più tempo.
Bisogno di piu
Dai un'occhiata a questo eccellente esempio lavorato di migliorare la storia di un utente.
