Una slide introduttiva al concetto delle user story. In larga parte traduzione delle slide omonime di Craig Brown.

1. INVESTire
in buone storie

2. Le richieste del nostro progetto sono
definite tramite le
User Story
(Storie utente)

3. Una user story è la descrizione di quello
che l'utente vuole ottenere dal sistema

4. Le user story sono legate alle descrizioni
delle funzionalità

5. Le user story esaltano il ruolo dell'utente...

6. ...lo scopo che cercano di ottenere...

7. ...e il valore di tale scopo

8. Possono definire l'USO

9. Come <tipo di utente>
Voglio <ottenere un obiettivo>
In modo da <avere un valore>

10. Come correntista
Voglio il mobile banking
In modo da pagare i conti con lo
smartphone

11. Possono definire il COMPORTAMENTO

12. Quando <situazione iniziale>
Se <effettuo un'azione>
Allora <ottengo un risultato>

13. Quando lo schermo dello smartphone indica
“Paga”
Se premo il pulsante
Allora si verifica la transazione

14. Non è una richiesta tecnica
Non è un contratto
Non è un piano di sviluppo software

15. Come per i libri, ci sono storie buone
e storie cattive.

16. Per ottenere obiettivi sensati
(S.M.A.R.T.) bisogna investire
(I.N.V.E.S.T.) nelle user story

17. SMART
Specifici
Misurabili
Accettati
Realistici
Temporizzati

18. INVEST
Independent
Negotiable
Valuable
Estimable
Sized right
Testable

19. Independent
Negotiable
Valuable
Estimable
Sized right
Testable

20. Le storie non sono scolpite
nella pietra
Independent
Negotiable
Né sono perfette
Valuable
Il dettaglio può essere
eccessivo. Occorre verificare
Estimable
con il cliente Sized right
Senza esagerare...alcune Testable
limitazioni sono fisse

21. Devono mostrare qual è il
vantaggio per il cliente e altri
Independent
partecipanti al progetto
Negotiable
Servono ad evitare le “storie Valuable
tecniche”
Estimable
Sized right
Testable

22. Il dettaglio deve essere
sufficente per stimare quando
Independent
tempo servirà
Negotiable
Ogni team avrà una stima Valuable
diversa (ma consistente)
Estimable
Scale: lineari, fibonacci, T-shirt,
ore
Sized right
Testable
Spesso si usa il Planning Poker

23. Le storie devono essere
completabili in un'iterazione
Independent
Negotiable
Più si è vicini al lavoro, più deve
essere specifica. Valuable
Si può partire con storie molto Estimable
grandi ma dovranno essere
spezzate (modello a piramide) Sized right
Testable

24. Independent
Storia
Negotiable
Valuable
Tema
Estimable
Sized right
Epica
Testable

25. I criteri di accettazione fanno
diventare realtà le user story
Independent
Negotiable
Assicurano che il risultato sia
quello previsto dal cliente Valuable
I test dovrebbero essere
Estimable
automatizzati (se possibile) Sized right
Non si dovrebbe iniziare la Testable
codifica prima di avere chiari
criteri di accettazione

26. Come giocatore
Voglio che il nemico
reagisca quando è
stato colpito
Per capire se l'ho colpito

27. Come giocatore Quando il nemico è
Voglio che il nemico colpito in testa, fa un
reagisca quando è passo indietro
stato colpito Quando è colpito al
Per capire se l'ho colpito braccio, si gira
Quando è colpito ai
piedi, solleva i piedi
Quando lo manco, non
fa nulla
Quando colpisco un
oggetto, non fa nulla

28. Come si fa ad ottenere delle buone storie
utente?

29. Come per i libri e i film:
Avere un protagonista
Avere una trama avvincente
Avere un lieto fine, che non lascia in
sospeso
Dare qualcosa al pubblico

30. Identificare l'utente (non generico)
Identificare l'interazione utente-prodotto
Schematizzare usi e comportamenti
Decidere il risultato
Progettare la validazione del risultato

31. Evitare le storie troppo grosse
Evitare la sindrome della miniaturizzazione
Imparare a spezzare le Epiche in Temi e in
Storie
(Richiede esperienza!)

32. Per incominciare, conviene attenersi ad un
formato standardizzato
Per esempio usando il linguaggio gherkin
https://github.com/cucumber/cucumber/wiki/G
Utilizzabile DIRETTAMENTE in alcuni
programmi come strumento di test, e in
ambito più ampio, come strumento di

33. Feature: Some terse yet
descriptive text of what is
desired
In order to realize a named
business value
As an explicit system actor
I want to gain some beneficial
outcome which furthers the
goal

34. #language: it
Funzionalità: Una descrizione
chiara e precisa del risultato
Per ottenere un dato valore
Come un agente esplicito del
sistema
Voglio ottenere un risultato
che mi avvicina all'obiettivo

35. # language: it
# Updated: Tue May 25 15:52:01
+0200 2010
Funzionalità: somma
Per evitare di fare errori
stupidi
Come utente
Voglio sapere la somma di due
numeri

36. Grazie per l'attenzione
Prof. Marcello Missiroli
(standing on the shoulders of giants :-) )
ITIS Corni
prof.missiroli@gmail.com

37. Riferimenti
Base di questa presentazione (layout incluso):
INVEST in good user stories – Craig Brown
http://www.slideshare.net/craigwbrown/invest-in-good-user-
stories-presentation
Extreme Programming Explored - William Wake
http://www.scribd.com/doc/12720/Extreme-Programming-
Explored-William-Wake
Six features of a good user story
http://agilesoftwaredevelopment.com/blog/vaibhav/good-user-
story-invest
INVEST in Good Stories, and SMART Tasks
http://xp123.com/xplor/xp0308/index.shtml
The INVEST Model fo User stories – Bill Wake
http://zomobo.net/play.php?id=L_NyCczp0Fk

38. Licenza
http://creativecommons.org/licenses/by-
sa/3.0/deed.it