Di seguito alcune linee guida addizionali per scrivere buone storie: Per identificare le storie considerare lo scopo di ogni ruolo utente del sistema. Quando si divide una storia cercare di avere storie che attraversano tutti gli strati dell'applicazione. Scrivere storie di una dimensione tale per cui lo sviluppatore, dopo averla conclusa, si senta giustificato nel prendere un caffè. Completare le storie con ogni tipo di documentazione ci sembra utile per comprendere meglio il dominio applicativo. Creare storie anche per le costanti applicative, esporle in modo...

Alcune considerazione relative ai test di acettazione sono usati per esprimere i dettagli delle conversazioni intercorse tra il "team del cliente" e gli sviluppatori provano che il "team del cliente" e gli sviluppatoriche hanno discusso una storia. danno una base per capire se la storia è completamente implementata dovrebbero essere scritti dal cliente piuttosto che dagli sviluppatori vanno scritti prima di cominciare a scrivere il codice è inutile aggiungere nuovi test quando questi non danno ulteriore chiarezza alla storia che si deve realizzare Fit e FitNesse sono ottimi tool per scrivere test di acettazione.   Technorati tags: user stories, agile,...

La cosa migliore è poter far scrivere le storie agli utenti reali ma questo non è sempre possibile e quinid si utilizzano degli user proxies. Ve ne sono diversi tipi ma tutti non sono ma il soggetto adattato per scivere le storie. Ad esempi se lo user proxy è : lo user manager potrebbe essere inappropriato a meno che non sia anch'esso un utente reale. il develompent manager è una delle peggiori situazioni perchè costui potrebbe può falsare le priorità di realizzazione delle storie non essendo un utente reale, ignorando il dominio applicativo e magari con conflitto di interessi (causato da benefit...

Le storie si possono trovare attraverso interviste ed osservando gli utenti, tramite questionario  o durante un laboratorio dedicato. I requisiti: l'idea di carpirli e catturarli è errata. Gli utenti non hanno da subito ben chiaro quali siamo di preciso ed inoltre non è possibile catturali ed imprigionarli in una gabbia dove restino immutabili. La metafora della "pesca a strascico dei requisiti"  può essere utile. Cattura l'idea che esistono requisiti con diverso peso e che possono varie nel tempo. Technorati tags: user stories, agile

In questo capitolo si parla della modellazione dei ruoli: In molti progetti si considera solo un tipo di utente. Questo porta ad ignorare le necessità di molti utilizzatori del prodotto. Per evitare di scrivere storie per un singolo utente è prima necessario identificare in vari tipi di utenti che interagiranno con il software. 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. La persona è una rappresentazione figurativa del ruolo. La persona ha un nome, una faccia ed...

Per le storie si può usare l'acronimo INVEST per definirne 6 attibuti: Indipendent: idealmente una storia dovrebbe essere indiependente dalle altre, così da poter decidere liberamente in quale ordine implementarle. Negotiable: i dettagli di una storia sono negoziati tra il "team del cliente" e gli sviluppatori Value to users or customers: le storie dovrebbero essere scritte in modo da rappresentare una chiaro valore per il commitente o per gli utenti. Il modo migliore per raggiugere questo risultato è far scrivere le storie al "team del cliente" Estimable: deve essere sempre possibile stimare lo sforzo necessario per realizzare...

In questo periodo sto leggendo "User stories applied" di Mike Cohn. Tempo permettendo vorrei segnarmi degli appunti per ogni capitolo.Di seguito quelli del primo capitolo: Una storia contiene una breve descrizione di una funzionalità che ha valore per il cliente/utente La carta è la parte visibile della storia ma le parti più importati sono le conversazioni tra i clienti e gli sviluppatori Il "team del cliente" è composto da chi garantisce che il software faccia ciò che vuole l'utente finale. Quindi può essere formato da tester, un product manager e utenti reali. Le storie sono ordinate...