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
Technorati tags:
user stories,
agile
posted @ domenica 18 novembre 2007 17:33