Dopo il talk di Stefano Dominici, di cui abbiam parlato lunedì, ecco un altro argomento che, da Better Software 2010, riveste un deciso interesse per chi si occupa di progettazione centrata sull’utente. Parliamo delle “User Stories”, quelle che Edoardo Schepis, project manager in Funambol dopo un’esperienza in Sun Microsystem, illustrerà. Gli abbiamo posto qualche domanda per introdurre il suo workshop.

Cosa sono le User Stories e chi le ha inventate?

Credo che la prima definizione di User Story si debba a Kent Beck nel 1999 e ha subito poi vari raffinamenti e chiarificazioni in seguito, grazie al contributo di altri esperti del settore (Ron Jeffries di xprogramming fra tutti). Ecco alcune definizioni che si trovano in letteratura:

• “A concise, written description of a piece of functionality that will be valuable to a user (or owner) of the software”.
• “A user story is a software system requirement formulated as one or more sentences in the everyday or business language of the user. “

Aldilà della pura definizione però è importante capire da quale esigenza vengono fuori le user stories.

Una delle considerazioni che ha portato alla creazione delle user stories è che i requisiti richiedono sempre (o almeno dovrebbero) un forte coinvolgimento dell’utente finale del prodotto software: credo a tutti sia capitato di leggere requisiti nei quali non venisse mai citato l’utente del sistema, ma sempre il sistema stesso. Per esempio “il sistema deve gestire richieste criptate” oppure “il sistema A deve interrogare il sistema B e produrre il risultato X su file”.

Sfortunatamente, sì.

Questo “atteggiamento” nella definizione dei requisiti è stato riconosciuto come una delle cause dei fallimenti dei progetti software: tradurre le richieste dell’utente (cliente) in requisiti del sistema (e quindi in linguaggio tecnico) e dimenticare il punto di vista dell’utente stesso.

Con le user stories si cerca di ribaltare tale abitudine, sponsorizzando un approccio collaborativo fra il cliente/utente e il team di sviluppo del progetto software: la user story traccia i requisiti sempre definendo le esigenze dell’utente.

Proprio per questo la user story spinge alla collaborazione e alla interazione tra le due parti (cliente-team di sviluppo) e lo fa attraverso le “3 C” che di solito la contraddistingono: card, conversation e confirmation.

Una user story deve essere scritta come un pezzo di funzionalità definita dal punto di vista dell’utente, deve stimolare la discussione attorno alla quale si sviluppano i dettagli relativi a quella funzionalità e deve includere una definizione di come confermare (al momento del rilascio) che quella funzionalità è stata correttamente implementata (test di accettazione).

In cosa le User Stories differiscono da altri strumenti, in questo caso sviluppati in ambito di UCD, come gli Use cases, gli Scenari, le Personas?

Una delle principali differenze che si evidenziano spesso in questo settore è quella tra le user stories e gli use cases: le user stories riportano le esigenze dell’utente e sono facili da leggere e capire, gli use cases parlano del comportamento del sistema e delle sue interazioni con altri attori (utenti o sistemi) e descrivono piu’ un processo nei suoi dettagli.

E’ evidente che una semplice definizione o frase “As a user…” non basta per implementare i mille dettagli di cui poi l’utente avrà bisogno: per questo spesso le user stories sono in numero maggiore rispetto all’equivalente use case.

Negli use cases si parla di paths: questo si trasforma, nel caso delle user stories, in più user stories (a grana fine) che aggiungono un pezzo alla volta alla funzionalità.

Alla fine le user stories risultano molto utili per una migliore comprensione da parte di tutti gli attori di un processo di sviluppo software (ingegneri, product manager, cliente, utente, sistemista, amministratore) proprio per la loro definizione chiara e concisa, pur non trascurando i dettagli necessaari per l’implementazione. Le user stories sposano bene un modello di sviluppo del software iterativo e incrementale, nel quale una funzionalità è suddivisa in piccoli incrementi rilasciabili che forniscono valore un po’ alla volta al cliente.

Come distinguere storie pertinenti ad un progetto e scartare quelle non pertinenti?

Spesso nella definizione dei requisiti si raggiunge quella fase definita anche come “over-design” o io direi frenesia da analista dei requisiti: ci si lascia coinvolgere nella definizione di un progetto anche nelle parti non essenziali o non di alta priorità dal punto di vista del valore del progetto stesso.
Le user stories sono definite dal cliente e dall’utente del sistema e quindi parafrasando un noto motto “il cliente ha sempre ragione”.

Purtroppo nei progetti reali il cliente non ha sempre ragione. E i casi in cui non ha ragione sono proprio quelli in cui non tiene conto del punto di vista dell’utente… Per cui credo che tutti gli strumenti che contribuiscano a portare l’attenzione sull’utente finale siano utili.

Con le user stories bisogna solo fare in modo che il cliente definisca una lista di priorità e quindi formi il cosiddetto backlog delle user stories con associate le relative priorità. Se vuole costruire “Ebay”, il cliente chiederà l’implementazione di storie quali “As a user I want to sell my item” o “As a user I want to participate to an auction” e solo dopo (con priorità più bassa) chiederà l’implementazione di user stories quali “As a user I want to provide a feedback to sellers”.

In buona sostanza si tratta di definire i requisiti e dargli un valore.

Poi si passerà alla fase delle stime dove ogni user story avrà associato un valore che evidenzia l’effort necessario, la complessità e il rischio ad essa associata e che sono il punto di partenza per la definizione di un piano di lavoro.

Quando sono utili dati empirici, di realtà, nell’identificazione di US, e quando invece è importante un lavoro a tavolino, di riflessione creativa?

Proprio da quello che dicevo sopra, l’identificazione delle user stories e la loro definizione è un lavoro semplice perchè fatto utilizzando il linguaggio naturale, ma non consiste solo nella loro definizione formale nella forma “As a user….”

La user story è un punto di partenza per una collaborazione con il cliente/utente che porterà ad un agreement sulla funzionalità da implementare: vengono discussi i dettagli e soprattutto (caso unico nell’area della definizione dei requisiti) viene definito il test di accettazione (lavoro a tavolino di collaborazione).

Già dalla partenza quindi si concorda con il cliente/utente cosa è necessario per la validazione di una funzionalità (la “C” di confirmation) e si lavora insieme per il raggiungimento dell’obiettivo comune: far passare i test definiti insieme.

Naturalmente tutte le tecniche e i metodi che normalmente vengono utilizzati per la definizione dei requisiti restano validi anche nel caso delle user stories: penso alla creazione di spikes per validare un’idea con dati alla mano e alle prove sul campo con piccole demo. Penso soprattutto ai casi in cui sono coinvolte interfacce grafiche (UI) e dove la user experience ha un ruolo dominante: in questi casi infatti il cliente/utente ha bisogno di toccare con mano prima di validare l’idea.

Il workshop di Edoardo Schepis si terrà giovedì 6 maggio 2010 alle 15.10. Ricordiamo che fino al 4 aprile è disponibile la tariffa early bird per l’evento fiorentino.