Le user stories sono uno strumento che ha avuto origine dall’Extreme Programming e sono diventate il modo de facto in cui i team Agile documentano e raccolgono i loro requisiti. C’è molto scritto sulle user stories (link, link, link), quindi mi limiterò a parlare di ciò che considero importante nello scrivere buone storie, dato che ne vedo molte di pessime là fuori oggi.
Per quelli che non lo sanno, le storie sono un artefatto leggero che ci permette sia di catturare i bisogni del business che di pianificare il lavoro. Sono tipicamente scritte su schede (sì…piccole carte 3×5 o 4×6) nella lingua del business o del cliente. Con le user stories, scriviamo solo quanto basta per catturare i bisogni dell’utente e non di più. Tendiamo a vedere le storie non come specifiche complete dei requisiti, ma come segnaposti per le conversazioni successive tra gli sviluppatori e il business.
Quando usato correttamente, la mancanza di dettagli di una storia utente ci fornisce una grande utilità – possiamo usare lo stesso documento per parlare di un requisito da un alto livello, zoomare sui dettagli di implementazione e saltare indietro, tutto nel corso di poche frasi. Poi, una volta che abbiamo finito di parlare di requisiti, possiamo considerare il rischio, identificare le dipendenze e creare un piano di progetto senza dover mai mettere giù il cartoncino. Wow! Non conosco nessun altro artefatto di requisiti là fuori che ci permetta una tale utilità.
Nel corso degli anni le persone che hanno veramente successo con le storie hanno stabilito alcuni punti in comune che si trovano in tutte le storie:
- Ruolo: chi, o cosa, userà questa caratteristica?
- Caratteristica (o capacità): cosa il team consegnerà, o aggiungerà, dopo aver finito il suo lavoro?
- Valore: perché il business vuole questa caratteristica? Che impatto avrà sul business?
- Criteri di accettazione: come sapremo se questa feature è stata fatta?
- Stima: quanto pensa che costerà questa feature?
IMO, perché una storia sia considerata completa deve avere TUTTE le caratteristiche descritte sopra. Trovo che quando le persone hanno difficoltà a definire tutte le caratteristiche, le storie non sono quello che io chiamo mature, cioè non sono state pensate abbastanza bene per essere utilizzabili dal Team. Oltre a queste caratteristiche, le storie dovrebbero anche seguire i criteri INVEST (questo grande articolo di J.B. Rainsberger parla anche di INVEST).
Mike Cohn ha scritto un grande libro sulle user stories. Sfortunatamente, per tutta la bontà del libro, la gente sembra essersi concentrata sull’unico pezzo di spazzatura nel libro – il modello di storia utente. Nel suo libro, Mike offre un modello che alcuni team hanno trovato utile per scrivere le storie e da lì questo modello è stato la fonte di così tante brutte storie che non ho intenzione di dargli più inchiostro (o bit). Quello che non mi piace del modello è che fa sì che le persone smettano di pensare mentre compilano meccanicamente ruolo, caratteristica e valore e omettono i criteri di accettazione e la stima (presumibilmente perché mancano dal modello). Quando vedo le persone lottare con le storie, è perché stanno cercando di incastrare il loro business in qualche modello che ha aiutato qualche team senza nome (che probabilmente non usa più questo modello) cinque o sei anni fa e – sorpresa – non si adatta alla loro situazione attuale.
C’è un processo di pensiero che deve avvenire prima di scrivere una singola storia. I passi che tendo a vedere le persone che hanno successo nello scrivere storie sono elencati qui sotto. Per favore tenete a mente che, mentre questi passi sono lineari nel mio post, si può saltare indietro, avanti e saltare intorno come ha senso. L’obiettivo è quello di aver risposto a queste domande nel momento in cui avete finito l’esplorazione della vostra storia utente.
- Quali sono i ruoli (o gli utenti) che useranno il vostro sistema?
- Quali sono i loro bisogni? In che modo il prodotto li aiuta a soddisfarle?
- Quali caratteristiche (o capacità) volete fornire a questi ruoli?
- Perché queste caratteristiche sono preziose per il business? Che tipo di risultati di business possiamo aspettarci da queste funzionalità?
- Quali sono le priorità di queste funzionalità? Abbiamo già fatto una promessa di consegnarne qualcuna?
- Come si fa a sapere se queste caratteristiche sono state fatte?
Infine, le persone hanno la tendenza a voler scrivere un sacco di dettagli sulla parte anteriore della story card. Ho due suggerimenti per queste persone. Primo, usate carte più piccole – davvero. Le storie utente NON sono specifiche o documenti di requisiti. Sono solo schede che catturano i bisogni dell’utente e ricordano che dobbiamo catturare quei dettagli di implementazione più tardi. Se state cercando di stipare sempre di più su una scheda, questo potrebbe essere un segno che potreste aver bisogno di specifiche o qualche tipo di documentazione di progettazione oltre alle storie utente. Secondo, i tipi di dettagli che le persone stanno cercando di scrivere sono in realtà criteri di accettazione. Spingendo questi dettagli nei casi di test, manteniamo la storia nella lingua del business e manteniamo l’attenzione sulla caratteristica e sul valore che il vostro team sta fornendo.