User story maps nell’ambito della programmazione software significa avere le giuste capacità nel mappare le storie degli utenti. La tecnica è diventata popolare attraverso una cospicua letteratura finalizzata a ottimizzare i backlog e tutto il lavoro dei team DevOps.
Esistono molte spiegazioni su cosa siano le mappe delle storie utente, ma le persone raramente parlano del loro valore e di come vadano fatte.
User story maps: a cosa serve
La mappatura della storia dell’utente è una tecnica che offre diversi vantaggi:
- permette di vedere il quadro generale del backlog
- offre uno strumento migliore per prendere decisioni su come governare e dare priorità all’arretrato
- Promuove il brainstorming silenzioso e un approccio collaborativo nel generare le storie degli utenti
- Incoraggia un approccio di sviluppo iterativo in cui le consegne anticipate convalidano sia l’architettura sviluppata che la soluzione
- È un’ottima alternativa visiva rispetto ai piani di progetto tradizionali.
- È un modello utile in fase di confronto e di discussione
- Consente di visualizzare la pianificazione dimensionale e le opzioni reali per ogni tipo di progetto/prodotto
I team di sviluppo impiegano del tempo per creare e testare user story maps finalizzate a migliorare la qualità del software. In effetti, la mappatura e il test della storia dell’utente richiedono un coinvolgimento approfondito e continuo da parte di vari membri del team. Una maggiore esperienza nella storia degli utenti non solo contribuisce a migliorare le mappe, ma permette anche di ottenere migliori requisiti del software, allineando tutti i gruppi di lavoro.
Cosa comportano le mappe di storie utente
Una mappa della storia dell’utente crea un backlog strutturato, che include dettagli sufficienti a far lavorare bene tutti i team di sviluppo, aiutando al contempo gli esperti di marketing a promuovere il risultato della progettazione.
La tabella sottostante è un esempio di come funzioni l’approccio e riflette tutti gli aspetti rappresentativi: dalle preoccupazioni più grandi a quelle piccole e specifiche. Le aree di interesse sono in cima alla mappa della storia dell’utente per lo sviluppo delle funzionalità.
Queste aree si scompongono negli elementi in azzurro della mappa. Sotto quelle caratteristiche ci sono i pezzi gialli della mappa, ovvero le storie degli utenti. Queste storie sono ordinate per priorità e classificate per versioni progressive. In definitiva, le user story maps una volta completate traducono la visione delle parti interessate allo sviluppo del software, aiutando a definire la tabella di marcia per costruirle.
User story maps: ecco come si crea
In teoria, costruire una user story maps degli utenti è semplice: basta coinvolgere le persone giuste in una stanza e, in meno di un paio d’ore, viene visualizzata la mappa.
In realtà, senza seguire una struttura, è molto probabile che i membri del team del software si ritrovino a discutere più del significato delle caratteristiche principali. In questo caso i creatori di mappe si trovano in difficoltà e costruiscono user story maps piuttosto superficiali, che possono generare anche gravi (e costosi) malintesi.
Per creare una mappa di storie utente, gli esperti consigliano di seguire quattro linee guida generali, che vanno poi personalizzate per adattarle sia al proprio team che alla tipologia del progetto.
#1 Disporre le fasi
Una mappa della storia utente ha due elementi organizzativi:
- le fasi che i creatori della mappa raggruppano in verticali
- le caratteristiche che i creatori della mappa rappresentano in orizzontale
Se il lavoro viene diviso in fasi, ogni fase rappresenta tre mesi di lavoro. Va condiviso un comunicato stampa che riassume lo stato della programmazione e un aggiornamento dei materiali di formazione. Tale impostazione fornisce alle persone coinvolte ipotesi ragionevoli sulle date di spedizione del software. Tuttavia, un team di sviluppo software non deve suddividere il lavoro in fasi. Un team di consegna continua può estrarre storie una alla volta, spostandosi da sinistra a destra, quindi ricominciare da capo con la storia successiva.
#2 Stimare le funzionalità
Quando entrano in un progetto software, molti team hanno le loro idee in merito a tempi, focus e priorità delle funzionalità. Un marketer del prodotto dovrebbe conoscere le aspettative dei team prima ancora che venga mappata la storia dell’utente. Ad esempio, i membri del team potrebbero ritenere opportuno concentrarsi sulla ricerca nel primo trimestre e sulle funzionalità mobili nel secondo trimestre.
#3 Iniziare con una visione chiara
Le caratteristiche devono essere sufficientemente chiare per tutti i membri del team in modo da evitare un accordo superficiale. È necessario tenere traccia della qualità, misurando la quantità di modifiche e incomprensioni nel software che i tester o i clienti possono scoprire. Se tutti sono sulla stessa pagina e non esiste un pensiero di gruppo, anche per questo mappare le storie degli utenti è importante. In caso contrario, bisogna predisporre riunioni di visualizzazione del prodotto per discutere e perfezionare le funzionalità. I creatori di mappe non devono dettagliare in modo esauriente le funzionalità; tutti devono capire bene l’obiettivo e l’ampio sforzo di lavoro richiesto per raggiungerlo.
#4 Concretizzare le rappresentazioni
Prima di una riunione, bisogna munirsi di una bacheca o una lavagna. I colori aiutano la visualizzazione delle informazioni: usare nastro adesivo colorato per creare un contorno delle user story maps. Bisogna poi orientare le fasi, ragionando su disposizione in verticale mentre le aree di messa a fuoco vanno disposte in orizzontale. Se non si è capaci a usare le aree di messa a fuoco, si può scegliere un criterio di mappatura delle affinità (vedasi tabella sottostante), in cui i creatori di mappe creano funzionalità su note adesive, organizzandole in gruppi. I gruppi rappresentano le aree di interesse del software.
Come condurre l’incontro
Coinvolgere nella riunione una persona che abbia conoscenza del prodotto funge da facilitatore. Il proprietario del prodotto che ha già lavorato con il team o è un esperto in materia è in genere un buon moderatore, aiutando a mantenere focalizzate tutte le parti interessate e garantendo che nessuna voce prevalga sulle altre.
Durante l’incontro, le parti interessate creano schede che rappresentano micro-caratteristiche, quindi le inseriscono sul tabellone: è importante focalizzarsi sull’ordine delle micro-caratteristiche e sulla fase in cui ognuna dovrebbe apparire. Se c’è disaccordo, si può risolvere la questione tramite una votazione per punti, in cui ogni partecipante esprime il proprio grado di impegno.
I team hanno molti strumenti di pianificazione grafica tra cui scegliere e spesso trasferiscono la scheda fisica a queste versioni virtuali. È allettante iniziare con una scheda digitale, ma i supporti fisici aiutano le persone a visualizzare il lavoro in corso meglio delle stesse informazioni su uno schermo. Ad esempio, se un’area della bacheca ha tanto spazio, diventa immediatamente ovvio quando la squadra si è inceppata troppo in un’area. La mappatura fisica si collega anche con i membri del progetto a vari livelli: discutono, guardano le note cartacee e le toccano. Ovviamente quando la riunione è online i team devono scegliere un’opzione virtuale.
La mappa delle storie utente che si riunisce in questo incontro è più simile a una prima bozza che a un manoscritto pubblicato, ma garantisce una visione condivisa e un vocabolario comune sul progetto.
User story maps: chi dovrebbe partecipare alla riunione
La maggior parte delle organizzazioni desidera discutere la visione di un progetto software nell’ambito dello sviluppo di più alto livello. Durante le riunioni di mappatura delle storie degli utenti, generalmente sono coinvolti il project manager, il master Scrum, i designer e i proprietari di prodotti. Quando la gestione non coinvolge il lato tecnico, potrebbe essere coinvolto anche un responsabile dello sviluppo, così come un lead o un architetto. È fondamentale che sia presente qualcuno con una vasta conoscenza del prodotto e dei casi d’uso dei clienti. Questa persona dovrebbe essere in grado di scavare nei dettagli, alla stregua di un tester di software, chiarendo cosa sia realmente la funzione del programma ed evidenziando incoerenze o approcci sbagliati. Il ruolo di questa figura non è quello di fare da avvocato del diavolo al project manager o ai designer. Sono importanti perché nel lavoro di gruppo contribuiscono in modo significativo a definire un piano migliore basato sulla realtà. Gli esperti suggeriscono che i creatori di user story maps siano costituiti da team da tre a sette persone.
