Cards, Conversation, Confirmation
Secondo Ron Jeffries le UserStories in XP sono caratterizzate da tre componenti:
- Cards: Una carta deve essere un oggetto fisico
- Conversation: Una carta non deve dettagliare un requisito del progetto, ma deve essere una promessa di conversazione con il cliente sulla funzionalità esibita che rappresenta (in User Stories Applied Mike Cohn definisce le UserStories non come la descrizione di un requisito, ma come la rappresentazione del requisito stesso)
- Confirmation: Una carta deve specificare come la funzionalità che rappresenta possa essere verificata
INVEST in good stories
Quali sono le caratteristiche che fanno di una storia una buona storia? L'acronimo INVEST ci può aiutare a ricordarlo
- Independent: Una storia è molto più facile da lavorare se risulta essere indipendente da tutte le altre
- Negotiable: Una buona storia deve catturare l'essenza di una funzionalità, e non i dettagli, i dettagli possono essere aggiunti successivamente grazie al lavoro congiunto di cliente e sviluppatori
- Valuable: Una storia deve essere importante per il cliente, deve rappresentare una funzionalità che darà maggior valore economico al prodotto finale
- Estimable: Una storia deve essere stimabile in maniera sufficiente da permettere al cliente di valutarne il "costo" durante la pianificazione
- Small: Mantenendo le storie sufficientemente piccole si ha maggior probabilità di fare stime più accurate, inoltre tali storie possono essere implementate in tempi brevi, favorendo iterazioni brevi, aumentando il feedback da parte del cliente
- Testable: Per ogni storia devono poter essere scritti uno o più test che ne verifichino l'effettiva implementazione
Comments (0)
You don't have permission to comment on this page.