Che cosa sono e perchè utilizzare le User Stories nello sviluppo software

Che cosa sono e perchè utilizzare le User Stories nello sviluppo software

User Stories

Nello sviluppo software, i requisiti del cliente o del Product Owner vengono convertiti, durante il Planning, in User Stories. Una User Story rappresenta un prodotto (anche parziale) che verrà consegnato al termine dello sprint. Può essere una storia a se stante, nel caso la richiesta sia semplice, come ad esempio la raccolta di una informazione supplementare tramite web service.
Nell’ottica dei rilasci incrementali che stà alla base dell’XP, una storia può però anche essere parte di un progetto più ampio che è stato quindi suddiviso in più storie che non necessariamente verranno completate tutte nell’arco di un solo sprint. Ad esempio un progetto che prevede una nuova integrazione web services con servizi esterni all’organizzazione aziendale potrebbe esser diviso in storie del tipo: stabilire la connessione col servizio esterno, generare gli stub per l’interazione col web service, implementare la chiamata ad un determinato servizio, e così via.

Che cosa sono e perchè utilizzare le User Stories nello sviluppo software

Le storie vengono scritte in linguaggio semplice e comprensibile, spesso riccorrendo al paradigma: “In quanto [tipologia di utente] voglio [requisito della storia] in modo da [scopo del requisito]”. Esempi di User Stories potrebbero essere: “In quanto responsabile della user-experience voglio che il pulsante “contattaci” presente nella home page del nostro sito venga posizionato in alto a destra, in modo da renderlo più visibile all’utente finale” oppure “In quanto applicazione di comparazione prezzi, voglio che venga chiamato il servizio “catalogo” dei web services esposti dal fornitore XXX, in modo da poter avere sulla mia applicazione i loro articoli ed i relativi prezzi”.

Le User Stories vengono accompagnate da criteri di accettazione (acceptance criteria). Una serie di test black box, definiti appunto acceptance tests, che verificano l’effettivo rispetto dei requisiti da parte della storia. Questi test vengono eseguiti solitamente a mano da persone diverse rispetto allo sviluppatore o agli sviluppatori che hanno lavorato alla storia (potrebbero essere anche il cliente o il Product Owner) prima che questa venga rilasciata in produzione, allo scopo di “certificare” il lavoro fatto dagli sviluppatori.
L’entità di una User Story deve essere sempre stimabile in fase di planning. Nel caso questo non sia possibile, sono necessarie ulteriori iterazioni con Product Owner e/o cliente al fine di raccogliere gli elementi necessari alla stima. Nel caso questo non sia possibile, si ricorre a spike. Per spike si intende un task che non può esser considerato una User Story in quanto non ne sono chiari requisiti ed entità, ma è comunque necessario che uno o più sviluppatori investano tempo a definire meglio l’attività richiesta affinché possa diventare una User Story.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: www.vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *