User Stories ed Epics

Prima di dire qualsiasi altra cosa, voglio dire questo: non perdere troppo tempo a cercare di aderire a una buona pratica oa un formato prescritto. Invece, fai semplicemente ciò che ti consente di acquisire i requisiti e andare avanti. " Individui e interazioni su processi e strumenti ", ricordi?

Detto questo, una user story che specifica chi / cosa / perché è orientata verso progetti enterprisy, dove si hanno utenti che hanno un ruolo specifico nell'organizzazione ("who"), e vogliono una certa capacità ("cosa") perché hanno bisogno di fare un po 'di lavoro ("perché"). Quindi, una User story è una descrizione di alto livello, intesa a facilitare la comprensione del motivo per cui l'azienda ha bisogno di determinate funzionalità e di come tutto si adatta all'interno dei processi di business e dei flussi di lavoro generali. È pensato per essere semplice e al punto. Non è una specifica dei requisiti formali. Il tuo esempio è, probabilmente, alquanto al di fuori di tale quadro, quindi probabilmente dovresti adattare la formula per soddisfare meglio le tue esigenze.

Ora i clienti spesso specificano i requisiti in un modo che include alcune decisioni di progettazione ("dovrebbe esserci una pagina con collegamenti ", invece di "abbiamo bisogno di un modo per fornire elenchi di film "), e se non stai attento a questo, li inserirai nella specifica dei requisiti e sarai vincolato a tali decisioni senza averle prima valutate. È compito tuo prendere in considerazione diverse opzioni, consultare il cliente e prendere quelle decisioni, non le loro. Potresti finire per farlo in un modo diverso, o potresti decidere di farlo nel modo in cui lo hanno originariamente descritto.

Quindi non dire che l'utente vuole una pagina principale; invece, dì "Come utente anonimo, voglio poter accedere agli elenchi di film convenzionali, perché [perché - se applicabile]", e associare una descrizione ad esso, spiegando che cosa significa "elenchi di film convenzionali" (o, se sei mantenendo un glossario dei termini del dominio, puoi inserire la spiegazione qui: elenchi di film convenzionali - Nuove uscite, Film più votati e consigliati, Generi).

Oppure potresti farlo in un modo più granulare, creando una storia separata per ogni elenco, se questo ha senso, ma, di nuovo, probabilmente dovrai documentare da qualche parte che questi sono correlati, per mettere le cose nel loro contesto.

O potresti solo fare
"Come utente anonimo, voglio poter accedere

Nuove versioni,
Film più votati,
Film consigliati,
Generi,

perché ... "e sii fatto con esso.

Probabilmente non ha molta importanza, a seconda di quanto sia importante capire le complessità del flusso di lavoro di un utente anonimo. Suppongo che non sia business-critical. Vuoi capire abbastanza in modo che l'utente abbia una buona esperienza con il software.

Vorrei, innanzitutto, essere completamente d'accordo con Filip e suggerire inoltre quanto segue per essere una deficiency dell'ideale di "user story".

• L'unica persona del mondo reale che può effettivamente scrivere una simile "user story" è un programmatore di computer, non un vero utente.

... perché questa "storia di (sic) " utente viene espressa interamente in termini di software (implementazione), come se la "storia" dell'utente potesse effettivamente colmare il divario tecnologico tra " un utente, raccontando una storia, "e" ciò che è necessario per causare un piccolo chip di silicio per eseguire un utile analogo di ciò che è descritto da quella "storia", nel contesto di una [vasta] applicazione software esistente. "

"Le storie degli utenti" non possono realmente fare una cosa del genere, perché gli utenti non sono programmatori.

Ma ciò che loro possono fare utilmente è semplicemente essere "storie vere", che presentano il requisito al team dal punto di vista dell'utente finale - non (!) dal prospettiva della crescente applicazione. Quindi, invece di essere filtrati mentalmente attraverso la comprensione di come funziona l'applicazione software, questa è la prospettiva più naturale di qualsiasi ingegnere del software, parlano per l'utente nei termini e nella voce dell'utente. Quindi, "la storia dell'utente" non direttamente viene mappata in un piano di implementazione software, e forse questo è esattamente il punto.