User stories: una guida pratica

Da circa un paio di anni ho iniziato a lavorare con internet company italiane vicine ad un approccio Agile per la realizzazione dei loro progetti.

La metodologia Agile comprende molte pratiche da attuare durante il ciclo di vita del progetto e quello che per me è stato il punto di partenza è la scrittura delle user stories.

Cos’è una user story?

Non è facile dare una definizione di una user story. Mi piace pensarla come la descrizione ad alto livello di una funzionalità utile al raggiungimento di un obiettivo di business. Con ‘storia’ definiamo in maniera non dettagliata una funzionalità che un software deve avere e che dà valore al prodotto finale consegnato al cliente/utente.

Perché utilizzarle?

Una ‘storia’ ci permette di descrivere ed evidenziare l’importanza e l’impatto che una funzionalità avrà nel business, aiuta a far capire – e decidere – al cliente l’utilità della funzione stessa e la sua priorità, in alcuni casi fino a decidere di non realizzarla affatto.

Le prime volte che scrivevo storie un dubbio mi assaliva: “Questa descrizione non è dettagliata. Non mi spiega cosa dovrò fare”.
La risposta è la vera essenza della user story: la discussione. La storia ‘costringe’ al dialogo con il cliente/utente. La discussione serve per dettagliare e chiarire i vari aspetti che la storia nasconde, ci permette di entrare in sintonia con il cliente e con gli altri membri del team fino ad avere una buona conoscenza del dominio e del perché stiamo sviluppando la funzionalità.

Una volta che sappiamo cosa dobbiamo fare, il gioco è fatto.
Le questioni tecniche non sono mai scogli insormontabili, quelle di comunicazione inefficace e comprensione del dominio lo possono diventare molto facilmente.

Un altro aspetto fondamentale della storia è che deve essere cotta e mangiata. Non discutiamo di storie che faremo tra due mesi, parliamo di storie che faremo in questa iterazione. Per iterazione intendo un ciclo di sviluppo – ad esempio di una settimana – al termine del quale si farà una review delle cose fatte. Alcune storie verranno accettate, altre scartate e verranno discusse le prossime su cui lavorare.

Le user stories ci evitano di scrivere tonnellate di specifiche up-front che diventerebbero obsolete poco dopo averle scritte dato che, nel mondo reale, le cose cambiamo molto più velocemente di quello che pensiamo.
Le user stories ci aiutano a non commettere uno dei più gravi errori possibili: fare supposizioni. Non diamo mai per scontato nulla. Se abbiamo dubbi, fermiamoci fino a quando non abbiamo chiarito. Se siamo bloccati c’è sempre il ping pong

Come deve essere una user story?

Il format classico di una storia è il seguente:

• COME < ruolo >
• VOGLIO < fare qualcosa >
• COSI CHE < possa ottenere valore per il business >

Niente di particolarmente difficile: ogni storia si focalizza sul descrivere cosa fare, per chi e perché deve essere fatto. Comprensibile al tecnico e al cliente nella stessa maniera.

Durante la fase di discussione cerchiamo di non essere passivi. Cerchiamo di focalizzare bene tutte e tre le componenti della storia, facciamo domande, cerchiamo di capire bene l’obiettivo di business che ha la storia e a chi sarà rivolta. Spesso capita che è il solo cliente/utente a decidere quale sia l’obiettivo e il team lì ad annuire.

Dato che siamo gli esperti tecnici e il cliente/utente è esperto di dominio (non sempre vero) cerchiamo di mettere a servizio tutte le nostre conoscenze per la buona riuscita del progetto. Utilizziamo esempi, disegniamo, scriviamo. Se esiste qualcosa di simile online, osserviamolo insieme. Usiamo tutto quello che può essere utile per abbattere barriere culturali ed ottenere un linguaggio comune.

Una user story deve essere INVEST:

• Independent: ogni storia deve essere indipendente dall’altra. Anche se è molto difficile, dovremo evitare situazioni nelle quali per fare una storia dobbiamo per forza farne un’altra prima. Avere storie indipendenti ci rende più liberi quando facciamo planning dato che possiamo spostare la priorità a nostro piacimento.
• Negotiable: una storia non definisce contratti o requisiti che il software DEVE implementare. La storia definisce una breve e poco dettagliata descrizione della funzionalità che dovrà essere discussa e probabilmente modificata, riscritta o eliminata.
• Valuable: misurabile in termini di valore da tutti gli attori coinvolti. Ogni storia deve consegnare valore al suo utilizzatore finale (tipicamente utente/cliente).
• Estimable: dovremo essere sempre in grado di stimare le storie che scriviamo.
• Small: le storie devono essere ragionevolmente piccole ovvero non ci devono mettere in difficoltà in fase di planning e prioritizzazione. Scrivere storie troppo grandi aumenta la probabilità di sbagliare la stima e di allungare i tempi di feedback. Storie grandi (dette epic) vanno spezzate in storie più piccole.
• Testable: le storie devo essere scritte in modo tale da poter essere testate. Quando una storia passa i suoi test significa che molto probabilmente è stata sviluppata correttamente. Non possono esistere storie che non possano essere testate. La non testabilità spesso è data dall’utilizzo di parole ‘non deterministiche’. Ad esempio:come utente voglio ricevere uno sconto molto elevato dopo che faccio qualche acquisto cosi che sarò incentivato a acquistare altri prodotti.Non riusciremo mai a testare il “molto elevato” oppure “dopo che faccio qualche acquisto”. Infine – dove possibile – i test dovrebbero essere automatici. Questo ci permette anche di lasciare una documentazione ‘vivente’ del progetto. Per vivente intendiamo una documentazione che riesce a mutare naturalmente al mutare dei requisiti (vedi specification by example).

Una volta che abbiamo scritto delle storie rileggiamole come si fa con un tema. Cerchiamo di scrivere e rileggere le user stories insieme ad altri membri del team. Verranno fuori cose che prima erano invisibili.

Evitiamo che qualcun altro scriva o discuta user stories per noi, ovvero storie che svilupperemo ma che non abbiamo scritto o discusso. Questo è il male totale.

Test di accettazione

Prima di concludere vorrei spendere due parole sui test di accettazione ovvero quei criteri base che devono essere utilizzati per determinare se una storia è stata implementata correttamente e nella sua interezza. Per ogni storia dovremo scrivere uno o più test di accettazione che saranno il risultato della fase di discussione tra team, cliente/utente. Il risultato dovrà essere un elenco puntato di test che andremo a depennare nel caso in cui sia accettato.

In questa fase si cerca di catturare tutto quello che il cliente/utente si aspetta di avere alla consegna della storia. E’ qui che dovremo esplicitare tutte le possibili assunzioni fatte.

Ogni test di accettazione va scritto prima dell’inizio della storia dato che ci deve guidare nell’implementazione della storia stessa. Per esperienza, capita spesso di accorgersi che durante lo sviluppo ci siano aspetti non chiari. In questo caso il consiglio è di fermarsi, contattare il cliente (o chiunque potrebbe aiutarci), discutere e scrivere eventuali nuovi test di accettazione, modifcare o cancellare test esistenti.

Conclusione

In tutte le discipline che vogliamo apprendere, il primo passo da fare è studiare cercando di fare nostri i concetti definiti in tale disciplina. Mentre studiamo mettiamo anche in pratica le cose che abbiamo imparato. Sbagliamo e sbagliamo di nuovo fino a quando non acquisiamo esperienza e conoscenza pratica della disciplina. Una volta arrivati ad un certo livello, siamo in grado di staccarci dalla didatticità del metodo e farlo realmente nostro adattandolo ai nostri casi d’uso. Pensate a chi suona uno strumento musicale. Salvo rari casi di geniliatà o follia incontrollata, molti musicisti imparano a suonare studiando la musica e mettendo in pratica quello che stanno imparando. Una volta che governano lo strumento cominciano a fare quello che vogliono inventando nuovi suoni, mescolando stili e apprendendo nuovi concetti.

Nello studio, nell’applicazione pratica delle metodologie Agili e – nel nostro caso – nella scrittura delle user stories è la stessa cosa. Naturalmente il risultato ottenuto è misurabile con parametri molto più oggettivi di quelli musicali :).

La user story è una parte fondamentale del mondo delle metodologie Agili. Nella mia personale esperienza mi ha aiutato a ‘de-ingegnerizzare’ il mio cervello facendomi mettere da parte aspetti tecnici e dando rilevanza alle persone con cui lavoro, alla comunicazione e al business.

Applicare questo metodo ha realmente migliorato la qualità del mio lavoro, mi ha permesso di entrare in contatto con realtà dove ‘la persona’ viene messa al centro di tutto, dove c’è cultura dell’errore e voglia di mettere le proprie esperienze a servizio degli altri.

Consiglio fortemente la lettura di User stories applied scritto da Mike Cohn come punto di ingresso per conoscere quelle che sono le best practice su user stories e metodologia Agile.