In un precedente articolo sul BDD (Behaviour driven design) abbiamo accennato alle user stories, un potente strumento di comunicazione utilizzabile da tutti i partecipanti di un progetto.
Cos’è una User Story?
Una User Story è la descrizione di una funzionalità apprezzabile da un utente che utilizza un software.
Le user stories sono composte da tre aspetti:
- Una descrizione testuale da usare per la pianificazione o come promemoria
- Una conversazione che approfondisca eventuali aspetti non chiari
- Test per verificare se la story è effettivamente completata o meno
La descrizione dovrebbe essere concisa, scritta in un linguaggio naturale e capace di attenersi ad una specifica funzionalità
Un utente può pubblicare un commento agli articoli del blog
Le user stories NON dovrebbero contenere aspetti tecnici.
Per la pubblicazione del commento utilizzare JavaScript
Questo perché la user story in questo caso concerne esclusivamente il lavoro del reparto IT e non degli altri. Le user stories servono per permettere uno scambio tra reparti diversi.
Caratteristiche delle user stories
Le user stories dovrebbero avere sei caratteristiche affinché si possa usufruire al meglio dei vantaggi che portano:
Indipendente. Ogni story dovrebbe essere indipendente nel senso che non dovrebbe dipendere dallo sviluppo di un’altra story. Questo perché potrebbe provocare problemi di pianificazione e di priorità.
Negoziabile. Una user story non è un contratto firmato, ma la descrizione di una funzionalità. Questo potrebbe portare ad aprire una conversazione tra diverse parti coinvolte nel progetto e portare alla luce eventuali incongruenze o incomprensioni prima che la funzionalità venga effettivamente sviluppata.
Apprezzabile dall’utente. Le user stories dovrebbero sempre descrivere qualcosa di effettivamente valutabile dall’utilizzatore del software o quantomeno dal committente; non dovrebbero contenere informazioni che possano essere valutate solo dagli sviluppatori (scelte architetturali, linguaggi, tecnologie, ecc … ).
Stimabile. A ogni user story dovrebbe essere assegnata una stima per quanto riguarda la tempistica di sviluppo. Questo è fondamentale per la pianificazione e la delivery del prodotto. Se si incontrano difficoltà in questa attività, significa che c’è qualcosa che non va: il team di sviluppo potrebbe non essere in grado di effettuare la stima perché non conosce abbastanza il dominio del progetto, oppure le competenze tecniche del team non sono sufficienti, oppure semplicemente la user story in questione è troppo grande e deve essere suddivisa in user stories più specifiche.
Breve. Le user stories devono essere brevi e descrivere una singola caratteristica del software. Se ci si accorge che una user story contiene più funzionalità allora possiamo scriverla con quello che viene definita una “epic” cioè una macro story che può essere collegata a più user stories.
Testabile. Ogni caratteristica descritta deve essere testabile. Una descrizione come questa:
Il pannello utente deve essere facile da utilizzare
…è difficile da misurare. Cerca di usare sempre test facilmente verificabili.
Strumenti utili per gestire le User Stories
Abbiamo provato diversi software per gestire le user stories. E’ difficile dare un parere oggettivo su quale sia il migliore, ma vi vogliamo suggerire i tre che secondo la nostra esperienza sono i più completi: