In questo tutorial, imparerai un’importante parte dell’approccio Agile allo sviluppo software: le user stories.

Ti guiderò attraverso cosa sono le user stories, le trappole comuni che ho visto nella creazione delle user stories e i framework che esistono per convalidare se la tua user story è “buona”.

Ecco cosa tratteremo:

I Primi Passi dell’Agile

Probabilmente hai sentito parlare dello Sviluppo Agile e delle Storie degli Utenti. Ma se non lo hai fatto, facciamo una breve lezione di storia:

Le Storie degli Utenti fanno parte di un concetto più ampio chiamato metodologie Agili.

Le metodologie Agili esistono dal 2001 quando 17 ingegneri del software molto rispettati si sono incontrati in un resort sciistico nello Utah e hanno creato il famoso Manifesto Agile.

Se nomi come Robert Martin, Martin Fowler e Kent Beck non ti dicono nulla, una volta finito questo articolo, vai a cercarli. Hanno una grande conoscenza e insieme hanno dato al mondo del software un modo più fluido per consegnare i progetti, chiamato Agile.

Cos’è l’Agile?

L’Agile è più un modo di pensare che un metodo prescritto. Esistono metodi prescritti, come Scrum e Kanban, ma l’Agile è un concetto.

L’Agile promuove la collaborazione, un feedback rapido e la consegna frequente di valore all’utente.

Il modo di pensare Agile incoraggia la flessibilità nella pianificazione del progetto, che è in netto contrasto con il suo concorrente dell’epoca, la pianificazione a cascata, che era molto rigida su cosa veniva consegnato e quando.

Le metodologie Agile promuovono di fare “giusto abbastanza” ricerca all’inizio per avviare il progetto, e poi apprendere, iterare e modificare il design e il deliverable secondo necessità durante il progetto fino alla consegna del codice finale. Questo approccio di “cambiare e apprendere mentre si procede” è chiamato “pianificazione adattativa”.

Agile promuove la consegna di qualcosa di valore rapidamente e frequentemente, solitamente sotto forma di codice consegnato in produzione alla fine di ogni “sprint” di due settimane. Questo, di nuovo, è molto diverso dalla pianificazione tradizionale a cascata che spesso richiederebbe mesi di sviluppo prima che qualsiasi cambiamento visibile dagli utenti potesse essere consegnato in produzione.

Un altro aspetto chiave di Agile è il focus che pone sulla collaborazione stretta e frequente tra gli stakeholder. Prodotto, QA, Ingegneria e Vendite hanno tutti un grande contributo e un costante feedback sul progetto durante il ciclo di vita del progetto.

Ora che sai un po’ di più su come funziona Agile, approfondiamo come convalidiamo il valore per l’utente.

Entriamo nella User Story.

Cosa è una User Story?

Una user story è un modo in inglese semplice per collegare l’ingegnere all’obiettivo finale del software.

È progettata in modo che una persona non tecnica possa leggerla e comprendere cosa viene consegnato, e così che un ingegnere possa guardarla e vedere il valore e come convalidare che hai consegnato quel valore.

Struttura di una User Story

Come [tipo di utente], quando [eseguo azione], [risultato atteso]

Nella sua forma più basilare, questo è tutto.

Stai ponendo l’accento sull’utente finale e sul “valore” che fornirai.

Esploriamo gli input:

  • Tipo di utente: Non esiste un “utente” unico per tutti. Hai “utenti admin”, hai “utenti connessi”, hai “utenti con permesso X” o “utenti nel ruolo Y”. Questo è specifico riguardo chi sta eseguendo l’azione

  • Eseguire azione: Cosa sta facendo l’utente? Cliccando sul pulsante “login”? Eliminando un record? Inviando un modulo?

  • Risultato atteso: Una volta che l’utente ha eseguito l’azione, cosa dovrebbe succedere? Se hanno cliccato su “login” con l’indirizzo email e la password corretti, dove dovrebbero essere indirizzati? Se hanno cliccato su “login” con un indirizzo email e una password errati, cosa dovrebbe succedere?

Esempio di Storie Utente:

Esaminiamo esempi di storie utente per una pagina di login.

Non c’è niente di meglio degli esempi.

Immaginiamo la scena. Hai una pagina di login con una casella di testo per inserire un indirizzo email e una casella di testo per inserire una password. Hai un pulsante di invio. Tutto qui.

Quali sono le diverse permutazioni che possono avvenire su questa pagina dal punto di vista dell’utente?

Come utente autenticato, quando la pagina si carica, vengo reindirizzato alla home page degli utenti autenticati.

Se sono già autenticato, non voglio dover reinserire i miei dati, basta reindirizzarmi alla home page degli utenti autenticati.

Come utente non autenticato, quando inserisco l’indirizzo email corretto ma la password errata e clicco su Login, appare un messaggio di errore.

Sono un utente che non è già autenticato e ho inserito i dati errati. Non dovrei essere autenticato.

Come utente non autenticato, quando inserisco un indirizzo email e una password errati e clicco su login, appare un messaggio di errore.

Ancora. Non sono un utente autenticato. Ho inserito dati errati, non dovrei essere autenticato.

Come utente non autenticato, quando inserisco l’indirizzo email corretto e la password corretta e clicco su login, vengo reindirizzato alla home page degli utenti autenticati.

Questa volta, non sono già autenticato, inserisco i dati corretti e clicco su login. Sono autenticato nel sistema.

Puoi vedere come tutti questi esempi siano focalizzati sull’utente?

Potresti notare che alcuni dei “comportamenti attesi” sopra non sono completamente definiti. Affronteremo questo in seguito nei criteri di accettazione.

Come creare buone User Stories

Esiste un buon modello chiamato modello INVEST che mostra in modo molto semplice come capire se le tue user stories sono valide.

Modello INVEST:

  • Indipendenti: Possono essere sviluppati separatamente.

  • Negoziabili: Aperti a discussioni e modifiche.

  • Valorosi: Forniscono valore all’utente.

  • Estimabili: Possono essere stimati in base allo sforzo.

  • Semplici: Si inseriscono all’interno di uno sprint.

  • Testabili: Hanno criteri di accettazione chiari.

Applichiamo questo modello INVEST a uno degli esempi di user stories sopra:

Come utente non registrato, quando inserisco l’indirizzo email e la password corretti e clicco su login, vengo reindirizzato alla pagina principale per gli utenti registrati.

(Farò alcune assunzioni qui, poiché questo è un codice teorico e un progetto teorico)

È questa storia Indipendente? Direi di sì, sì. È una piccola storia che coinvolge solo pochi componenti che probabilmente esistono già. Se il database non è ancora stato creato per il progetto, questo ci darebbe una dipendenza. Non sarebbe più indipendente.

È Negoziabile? Bene, di nuovo, sì. Questa storia potrebbe essere facilmente cambiata per reindirizzare alla pagina del profilo dell’utente piuttosto che alla loro home page.

Questa storia è sicuramente valiosa. Una volta implementata, l’utente può accedere. Se la storia fosse:

Come utente non registrato, quando inserisco l’indirizzo email corretto e la password e clicco su accedi, non succede nulla

Questo non sarebbe prezioso. L’utente non otterrebbe nulla da questo.

È la storia stimabile? Di nuovo, dobbiamo fare alcune assunzioni in questo scenario inventato, ma spero certamente che questo possa essere facilmente stimato. È una storia concisa, che coinvolge pochi componenti, in un dominio con cui tutti sono familiari e ha chiari criteri di accettazione.

La storia è certamente piccola. C’è poca ambiguità su ciò che deve essere fatto, c’è un solo percorso dell’utente e risultati chiari. Diamo un’occhiata a una storia che sarebbe troppo grande:

Come utente non registrato, la pagina di accesso dovrebbe funzionare come previsto.

Come discusso più sopra in questo articolo, ci sono molti modi in cui la pagina di accesso può e dovrebbe funzionare. “Dovrebbe funzionare come previsto” sembra coprire tutte quelle permutazioni. Questo sarebbe troppo grande per essere dimensionato efficacemente come una storia e probabilmente troppo grande per essere completato in uno sprint.

La storia è sicuramente testabile. Ci sono chiare azioni da parte dell’utente che hanno un risultato chiaro. Questa user story può essere coperta da Test Unitari, Test di Integrazione e Test Manuali.

Sembra che abbiamo creato una buona user story!

Se usi la struttura che ho definito sopra, e la storia soddisfa i criteri del modello INVEST, probabilmente è una buona storia.

Errori comuni nella creazione di User Story

Ho visto storie degli utenti andare storte in passato dove le persone hanno trascurato alcuni aspetti cruciali della user story:

Concentrarsi sugli aspetti tecnici

Come i miei esempi mostrano sopra, la user story è non tecnica.

Non dovrebbero esserci riferimenti a un nome di servizio, un nome di database, o validazione basata su qualcosa che l’utente non può vedere.

Appena la tua storia non è più comprensibile dall’utente finale, hai sbagliato.

Concentrati su cosa farà l’utente, e su cosa vedrà l’utente.

Vediamo un esempio di una storia focalizzata tecnicamente:

Come utente non autenticato, quando faccio clic sul link password dimenticata con un indirizzo email corretto, viene registrato un record in una tabella del database che attesta che il link di reset della password è stato inviato.

Questa storia non può essere verificata da un utente e gli utenti non tecnici potrebbero non capire cosa significa.

Correggiamola:

Come utente non autenticato, quando faccio clic sul link password dimenticata con un indirizzo email corretto, viene inviata un’email all’indirizzo email fornito con un link di reset della password dimenticata.

Gli utenti non tecnici possono capire questo e pone l’accento sull’utente, non sul prodotto.

Collaborazione tra Stakeholder

L’Agile è collaborativo.

Le user stories necessitano di input da parte di Product, BA, QA, ingegneri e, soprattutto, degli utenti.

Questo è il modo in cui garantirai di fornire ciò che l’utente desidera. Molte mani rendono il lavoro leggero.

Se, ad esempio, solo un team di ingegneria avesse creato le user stories, potrebbero apparire così:

Come utente registrato, quando la pagina si carica, vengo reindirizzato alla home page per utenti registrati

Come utente non registrato, quando inserisco l’indirizzo email corretto ma la password errata e clicco su Login, appare un messaggio di errore

Come utente non registrato, quando inserisco un indirizzo email e una password errati e clicco su login, appare un messaggio di errore.

E questo è fantastico. Ma ora coinvolgiamo il QA, che proviene da una prospettiva diversa poiché ha esperienze diverse con il software:

Come utente non registrato, quando inserisco un indirizzo email corretto in ebraico e una password corretta, vengo reindirizzato alla home page

Come utente non registrato, quando inserisco un indirizzo email e una password corretti e clicco ripetutamente su login, vengo reindirizzato alla home page

Ottimo. Stiamo ottenendo un insieme più completo di user stories che coprono più situazioni. Ma cosa succede se coinvolgiamo il Product?

Come utente non registrato, quando la pagina si carica, il mio gestore di password dovrebbe caricare automaticamente il mio nome utente e la mia password, quando clicco su login, vengo reindirizzato alla home page

Il team di prodotto conosce gli utenti. Sanno che le persone utilizzano davvero i gestori di password. Dobbiamo assicurarci che quando l’utente non digita effettivamente nulla (poiché il testo viene caricato dal gestore di password), il login funzioni comunque correttamente.

Storie Utente Vague

L’idea alla base di una buona storia utente è che chiunque, indipendentemente dall’esperienza, possa comprenderla.

Se hai scritto una storia utente che può essere interpretata in 10 modi diversi da 10 persone diverse, hai sbagliato un po’.

Ho accennato sopra che avrei parlato dei criteri di accettazione, e ora è il momento di farlo.

Rivediamo la seguente storia utente:

Come utente non autenticato, quando inserisco un indirizzo email e una password errati e clicco su login, appare un messaggio di errore.

C’è vaghezza qui.

Quale messaggio dovrebbe apparire? Quando la pagina si ricarica dopo un tentativo di login non valido, la casella di testo del nome utente deve essere ripristinata a vuota o deve essere precompilata con il valore precedentemente inserito? Cosa significa “indirizzo email errato”? Un indirizzo email che non è mai stato visto prima, o un indirizzo email che non è valido al momento (non ha pagato l’abbonamento, abbonamento annullato, ecc.)

Quindi, come puoi vedere, i dettagli contano.

Questa storia utente è un esempio abbastanza costruito e sono riuscito a trovare molte domande al riguardo.

Correggiamo il problema:

Come utente non autenticato, quando inserisco un indirizzo email che non è registrato nel sistema, quando clicco su login, appare un messaggio di errore.

Ciò ha rimosso i dubbi sull’azione dell’utente ma non ha risolto il problema relativo al messaggio di errore atteso.

Inserire i criteri di accettazione.

All’interno della user story, è necessario avere un insieme di criteri di accettazione che definiscano se l’implementazione della user story è conforme alle aspettative.

Cose come:

  • Messaggio di errore: “Indirizzo email o password non validi”

  • Casella di testo dell’indirizzo email e della password reimpostata a vuota al ricaricamento della pagina

  • Utente non in grado di accedere alle pagine in cui è richiesto il login

  • All’utente viene suggerito un “password dimenticata”.

I criteri di accettazione definiscono ciò che ci si aspetta dall’implementazione.

Come iniziare con le User Stories

Cominciare con qualcosa di piccolo.

All’inizio non sarete perfetti nel perfezionare e creare user stories.

Creare user stories è tanto un’arte quanto una scienza. La pratica porta alla perfezione.

La creazione delle User Stories dovrebbe essere fatta in gruppo. Spesso, ciò avviene con l’approccio dei “3 Amigos”, in cui si ha un ingegnere, una persona del prodotto e un QA che si siedono insieme e brainstormano le diverse permutazioni che è necessario supportare.

Una volta che hai consegnato il tuo progetto, retrospettiva. Guarda indietro e vedi quali lacune hai nelle tue storie utente. Ci saranno bug che gli utenti troveranno, che QA e UAT troveranno, e questi sono dovuti a lacune nelle tue storie utente o lacune nei tuoi test. In ogni caso, dovresti imparare da essi per la prossima volta.

Conclusione

Agile è collaborativo. Scrum è collaborativo. Creare storie utente è collaborativo. Ricorda questo.

Più persone di diverse aree di expertise hai a brainstorming per la creazione di storie utente, più è probabile che copri l’intero insieme di flussi di lavoro.

L’utente è al centro. Se stai mai includendo terminologia che il tuo utente non comprende, ripensa alla storia utente.

Non sarai perfetto in questo fin dall’inizio, ma più farai, più rapidamente e in modo efficace diventerai. Prendi questo da qualcuno che lo fa da oltre 10 anni. La differenza in velocità e qualità della mia creazione di storie utente oggi rispetto a 10 anni fa è abissale.

Controlla i miei post sul blog sul mio sito web, Just Another Tech Lead, oppure iscriviti alla mia newsletter settimanale qui.