Programmazione:AGILE

Modello AGILE

User Story

Cos’è una user story?

Definiamo una user story 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

Qualche parola va spesa 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.

Riferimenti esterni

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.