User stories Claudio Maccari Mail: cmaccari@absistemi.it Blog (ITA): http://blogs.ugidotnet.org/makka Blog (ENG): http://testdrivendevelopment.wordpress.com/ User stories

Cosa sono breve descrizione di una funzionalità che ha valore per il cliente/utente un mezzo per favorire la comunicazione verbale la carta è la parte visibile della storia il loro scopo è ricordare la conversazione in cui abbiamo parlato dei dettagli. sono comprese sia dagli sviluppatori sia dal "team del cliente“ il "team del cliente" è composto da chi garantisce che il software faccia ciò che vuole l'utente finale (tester, un product manager e utenti reali) ordinate in base al valore che hanno per l'organizzazione

Come funzionano funzionano bene in processo di sviluppo iterativo rilasci e iterazioni sono pianificati inserendo le storie all'interno delle varie iterazioni la velocità è l'ammontare di lavoro che può essere svolto dagli sviluppatori durante una iterazione la somma del costo delle storie messe in una iterazione non può superare la velocità prevista dagli sviluppatori scritte dal cliente, non dagli sviluppatori

L'acronimo I.N.V.E.S.T. Indipendent: idealmente sono indipendente tra di loro Negotiable: i dettagli sono negoziati tra "team del cliente" e sviluppatori Value to users or customers: rappresentano un chiaro valore per commitente e/o utenti. Estimable: deve essere sempre possibile stimare lo sforzo di realizzazione. Quando non è possibile stimare prima faccio uno spike solo per stimare poi la realizzazione vera e propria (in due iterazioni differenti) Small: se troppo complessa va divisa in più storie se troppo brevi vanno combinate in un'unica Testable: deve essere possibile eseguirne il test

Modellazione dei ruoli considerare solo un tipo di utente porta ad ignorare le necessità di molti utilizzatori del prodotto. evitare di scrivere storie per un singolo utente, prima identificare in vari tipi di utenti definire attributi per ogni ruolo permette un migliore confronto e comprensione del tipo di utente. in casi alcuni i ruoli possono trovare beneficio nell'essere descritti come persona.

Raccolgliere le storie Attraverso interviste Osservando gli utenti Tramite questionario Durante un laboratorio dedicato. I requisiti: l'idea di carpirli e catturarli è errata. gli utenti non hanno da subito ben chiaro quali siano di preciso inoltre non è possibile catturali ed imprigionarli in una gabbia dove restino immutabili.

Lavorare con gli "user proxy" La cosa migliore è poter far scrivere le storie agli utenti reali Se non è possibile usiamo gli user proxies. user manager: potrebbe essere inappropriato a meno che non sia anch'esso un utente reale. development manager (una delle peggiori situazioni ): può falsare le priorità non essendo un utente reale magari con conflitto di interessi (benefit personali a fronte di rilasci del software) personale commerciale (buon user proxy) deve puntare più alla qualità che alla quantità delle funzionalità. utile perchè in contatto con un'ampia varietà di utenti reali non si deve però focalizzare solo sulle storie che gli avrebbero permesso di conquistare l'ultimo cliente perso esperti di dominio (ottimi user proxy) devono evitare di scrivere storie per realizzare un software che solo persone con la loro esperienza possano utilizzare. il cliente (colui che decide di acquistare) può essere un ottimo user proxy se è in stretto contatto con gli utenti reali se è anche un utente reale è una combinazione fantastica. formatori /supporto tecnico (buoni user proxy ) non devono focalizzarsi solo sugli aspetti del software che vedono tutti i giorni. Fattori di successo con gli user proxy: creare una "task force" di utenti reali utilizzare più user proxy (es. un esperto di dominio ed una persona del marketing) analizzare i prodotti concorrenti rilasciare frequentemente

Test di acettazione esprimono i dettagli delle conversazioni intercorse tra il "team del cliente" e gli sviluppatori provano che il "team del cliente" e gli sviluppatori hanno discusso una storia. danno una base per capire se la storia è completamente implementata meglio se scritti dal cliente scritti prima di cominciare a scrivere il codice inutile aggiungerne nuovi test se non danno ulteriore chiarezza alla storia tools: Fit e FitNesse

Altri suggerimenti per identificarle considerare ogni ruolo utente del sistema. se si dividono cercare di avere storie che attraversano tutti gli strati dell'applicazione. completarle con ogni tipo di documentazione utile per comprendere meglio il dominio applicativo. creare storie anche per le costanti applicative che siano sempre ben visibili scrivere test che ne controllano inviolabilità. piccole per le funzionalità che il team implementerà a breve "di alto livello" per le funzionalità che verrano in futuro. evitare di inserire riferimenti all'interfaccia utente per singoli utenti. corte non numerare le storie.

User stories per oggi Come visitatore... Come utente... 1 Come visitatore del blog devo poter vedere in home page gli ultimi 10 post pubblicati (facile) 2 Come visitatore devo poter contattare l'utente del blog (facile) Come visitatore del blog devo poter aggiungere un commento ad un post indicando il mio nome e il testo del commento (media) conferma mezzo mail del commento (facile) Come utente... 1 Come utente devo avere la possibilità di creare un post indicando Titolo, testo (media) 2 Categoria su post (facile) Come utente devo avere la possibilità di visualizzare l'elenco dei post di una certa categoria (facile) Come utente devo poter creare delle categorie, e devo poterle modificare e cancellare (difficile) [categoria di default] Come utente devo avere la possibilità di cancellare un post (facile) Come utente devo poter moderare i commenti (media)