Come scrivere storie utente: una guida completa

Le storie degli utenti sono una parte vitale del corretto sviluppo agile del software: diamo un'occhiata al loro ruolo e impariamo come scrivere storie degli utenti.

I framework agili sono un modo popolare ed efficace per strutturare lo sviluppo del software e delegare le attività. Scrivere storie utente (da non confondere con come scrivere una testimonianza) è uno strumento in sviluppo agile che consente agli sviluppatori di capire cosa deve essere fatto e come soddisfare un requisito. Ciò li rende un punto di partenza molto importante, ma significa anche che devono essere costruiti con cura. Ecco cosa dovresti sapere.

Che cos'è una User Story?

È un termine utilizzato nello sviluppo di software all'interno di un framework agile. La user story è generalmente considerata l'unità più piccola nel progetto agile o il primo passo per soddisfare un requisito. Vengono creati quando un progetto è completamente pianificato.

Quindi, cosa significa esattamente? Ogni funzionalità software ha (o dovrebbe avere) uno scopo particolare quando viene aggiunta a un progetto. Tale scopo dovrebbe influenzare il suo intero sviluppo e il modo in cui è incorporato nel quadro generale. Gli sviluppatori possono fare riferimento a questo scopo ogni volta che è necessario per prendere decisioni, in particolare su come suddividere gli obiettivi e a cosa dare la priorità. La "user story" è semplicemente un modo per descrivere lo scopo di una funzionalità.

Le storie degli utenti sono scritte dal punto di vista di un utente, in genere in una o due frasi. Catturano il punto di vista dell'utente e ciò che l'utente vuole fare. Una volta completate, le buone storie degli utenti sono un modo semplice per parlare di obiettivi strategici, quali funzionalità possono essere tranquillamente scartate o dovrebbero essere aggiunte e molto altro ancora.

Come scrivere una storia utente

Passaggio 1. Ottieni input

Ottieni input da proprietari, potenziali utenti e project manager. Una user story forte ha bisogno di molti input per essere accurata. Ottieni spiegazioni chiare da questi gruppi su ciò che vogliono fare. Ricorda, questo non dovrebbe tradursi direttamente nella storia dell'utente ma fornirà le informazioni necessarie. Un proprietario potrebbe dire: "Ho bisogno che le persone siano in grado di pagare con PayPal sulla mia app", il che è molto utile ma non la user story stessa.

Passaggio 2. Decidi come vengono create le User Story

Questo dipende dal tuo flusso di lavoro. Nelle prime fasi, le storie degli utenti vengono catturate su schede o post-it durante la pianificazione del quadro generale. Successivamente, vengono incorporati nel software di gestione dei progetti. Alcuni membri del team saltano la fase del post-it, mentre altri fanno affidamento su di essa, qualunque cosa funzioni per te.

Passaggio 3. Definisci, definisci, definisci

Definire l'utente: con l'input è ora possibile definire l'utente. Tieni presente che questo non è sempre l'utente finale delle funzionalità del prodotto; può variare a seconda del tipo di utente. Crea personaggi utente se necessario. Definire l'azione che l'utente sta intraprendendo e definire l' obiettivo dell'utente nell'eseguire questa azione. Includi queste informazioni chiave quando crei la tua user story per parlare al tuo pubblico di destinazione.

Passaggio 4. Scrivi la storia

Inizia a scrivere la tua user story, dovrebbe essere lunga solo una o due frasi per attirare l'attenzione del lettore. Si è tentati di essere precisi e tecnici qui, ma un linguaggio ampio, come le dichiarazioni di intenti, può essere utile. Rendi chiara la storia e assicurati che possa essere risolta o completata, in modo da poter guardare indietro e confermare: "Sì, ora gli utenti possono farlo!".

Passaggio 5. Dividi in ulteriori passaggi

Le storie degli utenti potrebbero richiedere più passaggi per raggiungere l'obiettivo finale, il che potrebbe richiedere un po' di ristrutturazione a seconda del framework agile che stai utilizzando. Ricorda, la user story è sempre l'unità più piccola nel framework. A questo livello granulare, l'implementazione delle user story dovrebbe richiedere diversi giorni.

Se sembra che impiegheranno molto più tempo, questo è un segno da rivisitare e vedere se l'esperienza dell'utente deve essere ulteriormente scomposta e ristrutturata. Se vengono aggiunti nuovi requisiti, dovranno anche essere suddivisi in storie utente. Sebbene queste poche frasi siano il fulcro di storie utente efficaci, possono anche essere ampliate man mano che lo sviluppo procede. Diamo un'occhiata più da vicino a questo.

Quali sono le 3 C nelle User Story?

Scheda : la fase della scheda si riferisce alla scrittura di storie utente per il team di sviluppo in una o due frasi. Si chiama scheda perché le storie degli utenti erano originariamente scritte su schede e molti team preferiscono ancora farlo in quel modo. La Card è il fulcro del suo specifico requisito software e il punto di partenza per tutte le discussioni. È anche facile verificare se la tua user story è troppo lunga: se non può stare su una scheda che tutti possono leggere, deve essere accorciata.

Conversazione : una volta che le frasi della carta sono state create, è il momento di elaborare i dettagli. Questo di solito inizia con una serie di domande tra gli sviluppatori, come "Quanto tempo ci vorrà per implementarlo?" o "Come possiamo incorporare questa azione?" o "Questa user story è essenziale qui?" E così via.

Questo attento esame della user story produrrà probabilmente ulteriori domande da porre ai project manager e ai product owner, che dovrebbero essere coinvolti nella conversazione se necessario. Man mano che la conversazione continua, le storie degli utenti possono essere modificate, perfezionate, unite o rimosse fino a quando tutti sono sulla stessa pagina. Man mano che le storie degli utenti vengono finalizzate, passano all'implementazione, segno che la conversazione è sostanzialmente finita.

Conferma : la conferma riguarda i test di accettazione, ovvero i criteri di accettazione. Una volta che la modifica è stata implementata e gli sviluppatori segnalano che è pronta, ovvero che la user story è stata soddisfatta, è il momento di testarla.

I test di accettazione dovrebbero essere creati con l'input del proprietario del prodotto e ricollegarsi direttamente alla storia dell'utente. Nella migliore delle ipotesi, è un utente che cerca semplicemente di fare ciò che indica la storia dell'utente e vede se ci riesce. Ma i test di accettazione possono variare e non sono sempre realizzati pensando alle storie degli utenti come dovrebbero essere. Se questo crea un problema, è il momento di tornare alla fase Conversazione fino a quando i test di accettazione e le storie degli utenti non saranno correttamente allineati. Se tutti i test di accettazione sono completati, la storia dell'utente è felice. Ora è il momento di passare alla fase successiva nello sviluppo del prodotto o di rilasciare la funzionalità.

Un 4° Do? : È interessante notare che alcuni sostengono che esista un 4° C essenziale: Contesto. In questo caso, la storia dell'utente viene visualizzata insieme alle altre storie dell'utente nella struttura più ampia del progetto. Qui, gli sviluppatori chiedono se la storia dell'utente integra senza problemi altre storie dell'utente o se ci sono lacune - cose che l'utente deve fare o capire che sono state perse tra le storie dell'utente.

Idealmente, questo viene individuato durante la fase di conversazione, ma non sempre accade. Alcuni team di sviluppo potrebbero volere una revisione finale di come la storia dell'utente completata si inserisce nel tutto più grande e se è necessario svolgere ulteriore lavoro.

Qual è un buon formato per una User Story?

Esaminiamo due tecniche di formattazione che sono molto utili quando si creano frasi di storie utente. Il primo è molto semplice: "Chi, cosa e perché?" In un modello di frase, che può essere descritto in questo modo:

Come [Chi è l'utente], voglio [Cosa vuole l'utente] (in modo che [Perché l'utente lo vuole]).

Questo modello può anche essere inquadrato come: "Come [ruolo], voglio [azione], (in modo che [beneficio])", per una terminologia semplificata. Seguire questo formato di base è sufficiente per creare la maggior parte delle storie degli utenti. In genere è tutto ciò di cui hai bisogno e può aiutarti a risparmiare molto tempo se utilizzato per ogni storia utente.

A volte, tuttavia, le storie degli utenti sono più difficili da definire in progetti più complessi. In questo caso, può essere utile una seconda tecnica di template della user story. Si chiama INVEST, acronimo che sta per:

• Indipendente : le storie dovrebbero essere completamente indipendenti l'una dall'altra e, di conseguenza, le storie dovrebbero poter essere lavorate fuori sequenza.
• Negoziabile : le storie dovrebbero essere progettate per essere modificate durante la parte Conversazione del processo.
• Prezioso : la storia dell'utente dovrebbe dimostrare un chiaro valore per il progetto. In caso contrario, potrebbe essere uno spreco di risorse.
• Stimabile : una user story deve essere misurata in termini di valore e priorità per aiutare a decidere su cosa lavorare in ordine di importanza.
• Piccolo : le storie utente devono essere l'unità di funzionalità più piccola e in caso contrario dovrebbero essere ulteriormente suddivise.
• Testabile : la user story deve essere dichiarata in modo verificabile durante il processo di conferma.

Domande frequenti su come scrivere storie utente

Potrebbe interessarti anche la nostra guida su come scrivere una recensione di un gioco.