One of the worst myths of agile, is that people think agile means to not plan at all. Actually, we do not plan in a traditional way, because we use the rolling wave planning technique and we make a great use of visual management.

1. home mb188
Home Apéritif Technologique Formazione Eventi Download SemanticPortal Community Forum
Agile in action
I parte: User story mapping
Abstract:Cominciamo, con questo numero, una lunga serie che affronterà diverse tematiche legate allo sviluppo con metodologie
agili, focalizzandosi soprattutto su temi pratici: agile in azione, insomma. Mese dopo mese, verranno affrontati numerosi argomenti,
ma, per partire, occorreva concentrarsi ovviamente sulle storie utente.
tags: Agile storie utente user storymapping Product Owner requisiti
Numerovisite:69 di
EmilianoSoldi
Le "storie utente"
Come molti di voi sapranno, la user story nel mondo agile di sviluppo software, rappresenta una caratteristica o
requisito di prodotto, che vuole soddisfare una specifica esigenza dell’utente.
Nel definire le storie utente, il linguaggio e il formato utilizzati devono dare una chiara evidenza del valore di
business che si intende raccogliere attraverso quella funzionalità e, possibilmente, sottolineare chi è l’utente
coinvolto e le azioni che lo stesso dovrà svolgere, per raggiungere quel risultato.
Le user stories nascono come strumento di dialogo e collaborazione tra due mondi spesso lontani e
contrapposti: chi concepisce il prodotto (business) e chi lo deve realizzare (sviluppo). Si tratta di mondi il cui
linguaggio può differire anche in maniera estrema.
Figura 1 - Un adeguato linguaggio è l’imperativo per mettere in comunicazione chi concepisce il
prodotto e chi lo deve realizzare.
L’importanza di un linguaggio comune
La comunicazione e il linguaggio che si utilizzano assumono quindi grande importanza per mettere in relazione
business e sviluppo.
Il business è focalizzato sulla visione generale di prodotto. Presidia i movimenti del mercato, ne percepisce gli
andamenti e le tendenze, i segnali deboli, gli orientamenti. Nel descrivere la soluzione, le necessità, evita spesso
di entrare troppo nel dettaglio e ragiona in maniera astratta, per schemi.
Chi sviluppa il prodotto, invece, è abituato a studiarne la fattibilità, a generare stime e a ragionare in maniera
estremamente logica. Lavora per processi iterativi e incrementali; il dettaglio tecnico è parte consistente del
suo quotidiano e, il più delle volte, ne influenza anche il modo di comunicare.
Le differenze di comunicazione di questi due mondi, derivanti dai suddetti differenti approcci, hanno conseguenze
Mi piace 0
SOMMARIO
Le "storie utente"
Come è fatta una user story
User StoryMapping
Conclusioni
NELLO STESSO NUMERO
AgileInAction
EnterpriseData
OracleCoherence-3
AgileGrammelot
VersoAgile-1
NELLASTESSASERIE
AgileInAction-1
UTILS
Stampa questa pagina
Segnala errori
Permalink
ARCHIVIO
Settembre 2013
LuglioAgosto
Cerca
MokaByte 188 - Ottobre 2013
converted by Web2PDFConvert.com

2. negative sul prodotto che difficilmente riuscirà ad avere il successo sperato.
User story, una soluzione collaborativa
Le storie utente nascono proprio come soluzione a questa difficoltà comunicativa, e servono a tradurre in un
linguaggio semplice e comprensibile i requisiti e le funzionalità richieste.
Una user story, quindi, deve focalizzarsi sul valore di business che la stessa vuole perseguire, non richiamando
alcun dettaglio tecnico, se non per i requisiti non funzionali (NFR, "non functional requirements"), ma questo è
un altro discorso.
L’aspetto implementativo di quella funzionalità, infatti, sarà di esclusivo dominio del team di sviluppo che, in
completa autonomia e organizzazione, ne analizzerà le attività tecniche necessarie e si prodigherà nella loro
esecuzione, puntando a restituire il valore richiesto.
Come è fatta una user story
Bene, vediamo un semplice esempio di user story. In pratica si tratta di "mettersi nei panni" dell’utente e dichiarare
che cosa di deve poter fare in quanto utente e con quale risultato positivo (il "valore").
Come utente web della banca
Devo poter fare un bonifico
Così da pagare l’affitto, anche se la banca è chiusa
Un requisito espresso in questo modo, cioè dal punto di vista dell’utente (user story), mostra senza possibilità
d’errore o malinteso il vero valore di business che si vuole trarne ("poter fare un trasferimento di denaro anche a
banca chiusa"), ne esplicita la tipologia dell’utente coinvolto ("utente web della bancaW), circoscrivendo al tempo
stesso, la funzionalità a un dominio preciso ("pagamento tramite bonifico bancario").
Scomporre le user stories
Il grado di scomposizione della user story è un altro elemento fondamentale. Uno dei punti di forza delle
discipline agili, e più precisamente di quelle di sviluppo iterativo (p.e., XP e Scrum), sta appunto nella
pianificazione e analisi iterativa e incrementale del requisito utente.
Una tecnica di riferimento è chiamata Rolling Wave Planning (in italiano traducibile con un improbabile
"pianificazione a finestra mobile") che, nel project management tradizionale, prevede un’iniziale pianificazione di
alto livello basata sulle prime generiche ipotesi fatte in presenza di visibilità e certezza limitate, proprie di progetti
ad alto rischio o complessità. Con il passare del tempo e con l’aumentare della conoscenza di progetto, si potrà
procedere alla pianificazione per ondate successive (sono queste le "wave" del nome), i cui dettagli saranno
via via più chiari e facilmente analizzabili e indirizzabili.
Questa tecnica, applicata al mondo agile, prevede anch’essa una raccolta di alto livello delle necessità utente
nello stadio iniziale del progetto, al fine di procedere ad una prima stima dei costi, dei rischi e della pianificazione
delle macro-attività. Successivamente, in modalità iterativa, si procederà alla scomposizione fine dei requisiti che
verranno da lì a breve messi in sviluppo.
Tante funzioni poco usate
L’uso della tecnica suddetta è messo in atto per scongiurare quanto lo Standish Group fotografa in uno dei suoi
studi più interessanti: i sistemi hanno un elevato numero di funzion, ma solo poche di esse vengono utilizzate
realmente. Accade infatti che il 64%delle funzionalità di un sistema siano raramente o mai utilizzate.
converted by Web2PDFConvert.com

3. Figura 2 - Percentuale di utilizzo delle diverse funzionalità di un sistema. La gran parte delle funzioni è
usata raramente, se non addirittura mai.
Questo spreco enorme di risorse è proprio da addebitarsi a problemi di comunicazione, malintesi, errate
aspettative, eccessiva analisi di dettaglio in relazione ai tempi di effettiva realizzazione, mancanza di feedback o di
confronto con il business.
Ed è proprio da qui che vorrei partire con i consigli per mettere in atto le metodologie agili, scrivendo di una
tecnica tanto eccezionale quanto semplice e immediata, che vede tutti gli attori coinvolti nella prima fase di
scoperta e identificazione dei requisiti di prodotto, altrimenti detti user stories. La tecnica si chiama User Story
Mapping.
User Story Mapping
La User Story Mapping è una tecnica collaborativa, che richiede un po’ di preparazione e di materiali, ma che è
sostanzialmente semplice e, soprattutto, molto "remunerativa" in termini di focalizzazione del progetto. È
necessario che disponiate di una stanza con un muro piuttosto ampio, post-it di varie dimensioni, pennarelloni,
scotch di carta e, perche’ no, una whiteboard attorno alla quale ragionare e un proiettore dove mostrare
eventuale materiale a corredo.
Gli invitati alla sessione dovranno essere obbligatoriamente
chi ha concepito il prodotto (ProductOwner);
eventuali altri stakeholder con interesse o conoscenza specifica del dominio in analisi;
chi dovrà sviluppare concretamente sviluppare il prodotto (team di sviluppo).
Ora avete tutti gli ingredienti necessari. Potete inoltrare gli inviti alla riunione, che potrà durare dalle 4 alle 8 ore,
in relazione alla complessità del prodotto sotto esame.
Primi passi
La riunione si apre con il rappresentate del business, quello che in Scrum si chiama ProductOwner, che illustra
brevemente i punti salienti del prodotto, le sue caratteristiche fondanti e ne illustra le motivazioni di business
che hanno spinto l’azienda a finanziare tale progetto. Illustra, per usare un termine oramai comune, la vision.
A questo punto il ProductOwner e il team di sviluppo cominciano ad analizzare le principali funzionalità e
caratteristiche del prodotto, non entrando in questa prima fase, in alcun dettaglio funzionale.
Individuare le user stories
Ipotizziamo che il prodotto da sviluppare sia un client di posta elettronica. Utilizzerò quello che in rete sembra
essere l’esempio che per questa tecnica è oggi più in voga, in modo da permettere eventuali parallelismi con altre
fonti.
Le principali funzionalità potrebbero essere le seguenti: Organizza Email, Gestione Email, Gestione
Calendario e Gestione Contatti.
Figura 3 - Le principali funzionalità individuate per un ipotetico client di posta elettronica.
Scrivete quelle funzionalità su post-it e attaccateli nella parte alta del muro. Sono queste le funzionalità
principali su cui concentrarsi e dalle quali partire per la successiva fase.
Approfondire le funzionalità
A questo punto, il ProductOwner e il team di sviluppo cominciano a ragionare su quali possano essere le attivit
à o task, che un utente può voler svolgere per ognuna di quelle macro-aree. Comporre un’email, creare un
appuntamento, eliminare un contatto, sono ottimi esempi di funzionalità, che in questa fase del processo
devono, però, rimanere ancora di alto livello.
Ogni proposta da parte delle persone coinvolte, verrà presa in considerazione e, se ritenuta valida in relazione al
prodotto e al valore di business atteso, scritta su un post-it e attaccata nella fila corrispondente.
Ecco che, focalizzandoci volutamente solo sul ramo Organizza Email, l’evoluzione potrebbe essere quella
rappresentata in figura 4.
converted by Web2PDFConvert.com

4. Figura 4 - Lo sviluppo della funzione Organizza Email, su un ulteriore livello.
Scomporre ogni rampo in ulteriori sotto-funzionalità
Ottimo. Ora siamo pronti al passo successivo di scomposizione di ogni ramo in sotto-funzionalità. Il processo, su
quel ramo, potrebbe portarvi ad avere la situazione di figura 5.
Figura 5 - Ogni ramo viene ulteriormente scomposto in sotto-funzionalità.
Questa è la fase dove non solo si catturano le principali funzionalità per ogni sotto-ramo (vedi post-it arancioni),
ma si comincia anche a rendersi conto di come alcune funzionalità siano veramente importanti, basilari,
irrinunciabili, mentre altre potrebbero essere pensate come accessorie o secondarie.
Sarà responsabilità del ProductOwner mettere queste funzionalità, e i relativi post-it, in ordine di importanza
rispetto al loro valore di business, partendo dall’alto per le funzionalità con maggior valore e procedendo in
scala verso il basso con le restanti.
Nel nostro esempio, per il ramo Composizione Email, questo porterà ad avere la funzionalità di creazione e
spedizione di una email base, con testo standard, come prima voce e la spedizione di messaggi in formato
RTF, che preveda quindi le principali formattazioni di carattere e paragrafo, con priorità inferiore.
Muovendosi oltre con la definizione delle caratteristiche, sempre sul ramo Organizza Email, ci potremmo trovare
converted by Web2PDFConvert.com

5. di fronte alla situazione di figura 6.
Figura 6 - La definizione delle caratteristiche viene ulteriormente approfondita, anche in riferimento
alle successive release previste per il prodotto.
Procedendo a ragionare sulle priorità assegnate alle singole funzionalità di prodotto e alla loro sequenza, è
d’obbligo introdurre il concetto di release di prodotto. Le funzionalità più in alto, per forza di cose, dovranno
essere incluse nella prima release, le altre nelle successive.
In questo momento il ProductOwner, con l’aiuto del team e di uno scotch di carta di buona qualità, può
circoscrivere e raggruppare orizzontalmente attraverso delle linee, le funzionalità per release come riportato in
figura.
Giungere a dei risultati
Bene, abbiamo quasi terminato. Il ProductOwner effettuerà a questo punto diverse fotografie nitide della parete
(non vorrete mica perdervi ore di lavoro?), staccherà i post-it in maniera ordinata e riporterà il testo di ognuno
in un foglio di calcolo, facendo attenzione a mantenere inalterate le priorità e l’appartenenza ai relativi rami.
Quello che avrete appena creato, sarà la prima versione, sebbene ancora embrionale, del Product Backlog.
User stories in formato "standard"
L’ultimo passo per Team e ProductOwner sarà quello di riscrivere le storie nel formato standard vale a dire
quello in cui "Come utente… voglio poter fare… in modo da…" e assicurarsi che ogni user story soddisfi una serie
di criteri, tutti facilmente richiamabili alla mente tramite l’acronimo INVEST.
Ogni user story deve infatti essere:
Independent (preferibilmente non dipendente da o accoppiata con altre storie)
Negotiable (negoziabile in termini di dettaglio tecnico e comportamento)
Valuable (restituire valore all’utilizzatore)
Estimable (essere stimabile dal team)
Sized-properly / Small (di dimensioni contenute per poter essere sviluppata insieme ad alcune altre
nell’iterazione)
Testable (essere testabile)
Conclusioni
Abbiamo visto in questo primo articolo che cosa sono le user stories e come individuarle, proponendo una tecnica
semplice ma efficace per mapparle nel dettaglio e assegnare loro una priorità: il punto cruciale sta nel ricordarsi
sempre che esse devono restituire un valore per l’utente, e che devono essere aderenti ai principi dell’acronimo I
N V E S T.
converted by Web2PDFConvert.com

6. e-mail
Nel prossimo articolo, continueremo ad affrontare un altro aspetto pratico del mondo Agile, piuttosto complesso
ma altrettanto importante: le stime.
Emiliano Soldi
Emiliano Soldi è un professionista capace e appassionato. Ha alle spalle una solida esperienza
principalmente nella gestione di progetti ITC attraverso l'uso di entrambi gli approcci, tradizionale e
agile maturata nel corso dei vent’anni di attività e consolidata attraverso il conseguimento di diverse
certificazioni professionali (PMP, PMI-ACP, CSP, CSM). ÈAgile Practice Leader e Coach di Inspearit
Italy, dove si occupa di facilitare le organizzazioni nella transizione al modelloAgile/Lean per lo
sviluppo del prodotto e la gestione dei progetti. Èinoltre responsabile dell'evoluzione e del
miglioramento della praticaAgile all'interno della sua azienda. Trainer entusiasta, con spiccate doti
comunicative, ha formato nel tempo alcune centinaia di persone. Èstato socio fondatore di Diesys
Informatica dove si è occupato, tra le altre cose, dei principali aspetti di management aziendale.
Membro attivo in diverse comunità di gestione progetti (PMI-NIC, ScrumAlliance,Agile Lean Europe,
ItalianAgile Movement) ha contribuito, in qualità di speaker, a diversi convegni, conferenze e seminari
(PMI-NIC, PMI Rome, IPMA, IIBA-NYC, Better SWconf, LUISS).
Chi siamo Contattaci MokaByte èunmarchioregistratodaMokaBytes.r.l. - PartitaIVA:05039150486, CF:05039150486
Attenzione: http://www2.mokabyte.it:80/cms/p/mb188/AgileInAction-1 non è raggiungibile.
Plug-in sociale di Facebook
Aggiungi un commento...
converted by Web2PDFConvert.com