makka

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 una storia. Quando non è possibile dividere un la storia alter due: la prima è lo spike , ovvero un piccolo esperimento in cui gli sviluppatori creano un piccolo esperimento per giusto per capire quando costa realizzare la richiesta del cliente, la seconda storia è la realizzazione vera è propria della richiesta del cliente. Le due storie andrebbe realizzate in due iterazioni differenti.
• Small: una storia è troppo complessa e articolata va divisa in più storie, storie troppo brevi vanno combiante in un'unica
• Testable: deve essere possibile testare una storia

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 in base al valore che hanno per l'organzzazione
• Rilasci e iterazioni sono pianificati inserendo le storie all'interno delle varie iterazioni
• La velocità è l'ammontare di lavoro che può essere svolto dagli sviluppatori durante una iterazione
• La somma del costo delle storie messe in una iterazione non può superare la velocità prevista dagli sviluppatori
• Gli "acceptance tests" servono per validare ogni singola storia scritta.
• Le storie hanno valore perchè favoriscono la comunicazione verbale, perchè sono comprese sia da sviluppatori sia dal "team del cliente", perchè permetteno di pianificare un'iterazione. Funzionano bene in processo di sviluppo iterativo ed ingoraggiano la definizione dei dettagli.

Nel weekend è stato aggiornato il sito che contiene la documentazione di mbUnit: http://docs.mbunit.com