makka

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 che siano sempre ben visibili e scrivere dei test che che ne controllano inviolabilità.
• Scrivere storie piccole per le funzionalità che il team implementerà a breve e storie "di alto livello" per le funzionalità che verrano in futuro.
• Evitare di inserire riferimenti all'interfaccia utente nelle storie.
• Inserire un riferimento al ruolo utente all'interno di una storia se ne aumenta la chiarezza.
• Scrivere storie per  singoli utenti.
• Far scrivere le storie al cliente invece che agli sviluppatori
• Scrivere storie corte: il loro scopo e ricordare la conversazione in cui abbiamo parlato dei dettagli.
• Non numerare le storie.

Hammett, il PM del progetto Castle, è stato invitato a Redmon per dare la sua opinione su nuovo framework MVC che a breve verrà rilasciato da MS. Qui le sue impressioni.

Technorati tags: ASP.NET, MVC, Model View Controller

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.

 

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 personali a fronte di rilasci del software)
• il personale che viene dal ramo commerciale, spesso è un buon user proxy. Deve però puntare più sulla qualità che quantità delle funzionalità.
• il commerciale può essere utile quando è in contatto con un'ampia varietà di utenti reali. Questo tipo di user proxy non si deve però focalizzare solo sulle storie che gli avrebbero permesso di conquistare l'ultimo cliente perso. In ogni caso il personale commerciale resta un buon contatto con gli utenti reali.
• gli esperti di dominio posso essere ottimi user proxy ma devo 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 o persone del supporto tecnico per essere buoni user proxy non devono cadere nella tentazione di focalizzarsi solo sugli aspetti del software che vedono tutti i giorni.

Inoltre quando si è costretti a lavorare con gli user proxy alcuni fattori di successo possono essere:

• 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

• 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.