Scrum e l’antica arte di scrivere user stories di valore

II parte: Organizzare i deliverables di progetto tramite le Impact Mapsdi

Sempre a proposito di Product Backlog…

Nella puntata precedente abbiamo visto qualche suggerimento e indicazione per la scrittura delle storie utente con cui raccogliere i requisiti di un prodotto software. Prima di passare alle tecniche di raffinamento degli elementi di un backlog, vogliamo affrontare una tematica che sta nel mezzo fra la scrittura delle macrostorie e la loro scomposizione in elementi più piccoli, attività di “raffinamento” che, per esempio in Scrum, è nota sotto il nome Backlog Backlog Refinement.

Il Product Backlog è infatti un elenco di cose che il PO vuole vengano realizzate, che spesso contiene (ma non solo) una lista dei bisogni dell’utente finale: se gli elementi sono sufficientemente scomposti e dettagliati, vi si trova anche un’ipotesi di soluzione. Come ormai dovrebbe essere noto ai lettori di questi articoli, tale elenco deve essere ordinato per priorità ossia per valore rilasciato.

Grazie al costante lavoro di raffinamento, nella parte bassa del backlog si trovano elementi non ancora elaborati per cui a grana grossa e poco definiti, mentre in altro elementi più piccoli e molto dettagliati, pronti per essere messi in lavorazione.

La figura 1, ormai più volte utilizzata quando si parla di backlog, raffigura sia la diversa grana che il lavoro di refinement.

Figura 1 — Product Backlog Items.

Figura 1 — Product Backlog Items.

 

Nelle prossime puntate di questa serie parleremo in modo dettagliato delle tecniche di scomposizione degli elementi del backlog, che sono note come User Story Splitting Patterns.

Organizzare il backlog grazie alle Impact Maps

In questa puntata invece parleremo di un altro aspetto che in qualche modo è legato al concetto di priorità degli elementi che lo compongono: vedremo come organizzare gerarchicamente il backlog, ossia come raggruppare gli elementi del backlog in modo da poter avere una visione di sintesi (a seconda del livello di raggruppamento) e facilitare le operazioni di organizzazione dei rilasci (o milestone).

Una delle tecniche molto in uso per svolgere questo lavoro è lo story mapping — l’organizzazione gerarchica appunto — di cui abbiamo già avuto modo di parlare in precedenza [1].

In questo articolo parleremo invece di Impact Map, uno strumento forse meno articolato e certamente più semplice ma che permette, in modo altrettanto rapido ed efficace, di arrivare a una organizzazione delle storie, raggruppandole per macro-obiettivi in funzione dei bisogni degli utenti.

Le Impact Map sono uno strumento presentato nel libro Impact Mapping ([1b]) di Gojko Adzic, al quale mi sono liberamente ispirato per le mie applicazioni sul campo.

 

Come funziona una Impact Map

Una Impact Map è di fatto una “mappa mentale” (mind map) che offre una visualizzazione dello scope di un prodotto e mette in relazione le varie ipotesi connesse per la sua realizzazione. La Impact Map viene realizzata in modo collaborativo e incrementale, durante la discussione che viene condotta — e in un certo senso facilitata — rispondendo a quattro semplici domande:

  1. Perché? Perché dovremmo realizzare questo prodotto? Qual è lo scopo? Quali sono gli obiettivi che ci poniamo? Quale la vision?
  2. Chi? Chi sono gli attori che potrebbero abilitare/influenzare il raggiungimento dell’obiettivo?
  3. Come? Come potrebbe cambiare il comportamento degli attori una volta realizzato il prodotto? In che modo possiamo abilitare questo cambiamento, come team di sviluppo?
  4. Cosa? Sempre dal punto di vista del team di sviluppo, cosa potremmo realizzare?

Vediamo in dettaglio questi quattro aspetti.

 

Perché? Definire l’obiettivo

Il “perché” rappresenta il nodo centrale della mappa e permette di rispondere alla domanda forse più importante: “Perché dovremmo fare questo prodotto / servizio / iniziativa?”.

Figura 2 – Il nodo centrale della Impact Map è rappresentato dalla risposta al “perché” si vuol realizzare il nostro prodotto.

Figura 2 – Il nodo centrale della Impact Map è rappresentato dalla risposta al “perché” si vuol realizzare il nostro prodotto.

 

Rispondendo a questa domanda si riesce a descrivere l’obiettivo che si vuole cercare di raggiungere. Una Impact Map è pensata per descrivere un prodotto nella sua interezza: nel nodo centrale della mappa troviamo quella che forse è la parte più importante e che permette spesso di descrivere in modo sintetico la vision di prodotto, o meglio una parte della vision: obiettivi e scope.

Il focus dovrebbe sempre essere sull’individuare ed evidenziare le necessità degli utenti finali, e non nel provare a fornire soluzioni: pensare alle necessità che si vogliono colmare, piuttosto che al modo in cui fornire un supporto.

Per raggiungere questo obiettivo si potrebbe utilizzare una frase, uno slogan, oppure addirittura qualcosa di più strutturato come per esempio un elevator pitch [2].

Il nodo “perché”: qualche consiglio pratico

Spesso la visione non è del tutto completa a inizio progetto: per questo può valere la pena iniziare a compilare la mappa inserendo una versione abbozzata della visione per poi raffinarla e rivederla man mano che si chiariscono meglio gli obiettivi tramite l’analisi e la compilazione degli altri livelli della mappa.

Scope e vision di un progetto dovrebbero essere sempre ben chiari a tutti i membri del team, e non solo a loro. Per questo è utile rendere la mappa — e in particolare il suo nodo centrale — pubblicamente accessibile e visibile, per esempio appendendola a una parete, in modo che tutti possano sempre averla sottocchio.

È infatti estremamente importante che tutti sappiano cosa fare e come muoversi nel caso si debbano prendere decisioni in modo rapido, apportare correzioni al progetto, gestire cambi di rotta o tamponare emergenze.

 

Chi? Per chi stiamo sviluppando il prodotto?

Il livello “chi” della mappa serve per rispondere alle seguenti domande: “Chi può produrre l’effetto desiderato?”, “Chi potrebbe impedirlo?”, “Chi sono gli utenti / destinatari a cui ci vogliamo rivolgere?”, “Chi ne sarà impattato” con l’uso di un termine derivato da impatto che non è casuale, visto che è alla base del concetto di Impact Map.

Figura 3 – Intorno al nucleo centrale, sviluppiamo un primo livello con le risposte alla nostra domanda “Chi?”, riguardante sia chi è il destinatario impattato dal prodotto che vogliamo sviluppare, sia chi può produrre l’effetto desiderato.

Figura 3 – Intorno al nucleo centrale, sviluppiamo un primo livello con le risposte alla nostra domanda “Chi?”, riguardante sia chi è il destinatario impattato dal prodotto che vogliamo sviluppare, sia chi può produrre l’effetto desiderato.

 

A differenza di quello che si fa con altri strumenti, in questo caso si prendono in considerazione non solo gli utenti finali, ma anche quelle persone/realtà che possono influenzare la realizzazione del prodotto con le loro decisioni.

Attori, utenti e priorità

Un modo per definire il concetto di qualità molto usato all’interno della comunità agile è “valore rilasciato a qualcuno”. Questo qualcuno deve essere ben compreso e descritto: devono essere capite le sue necessità, devono essere individuati i suoi obiettivi e devono essere prese in esame le sue preferenze; dovrebbe essere categorizzato, per indirizzare meglio le varie componenti o declinazioni del prodotto finale. Di fatto, la maggior parte dei tool o di tecniche di Product Definition insistono molto su questo aspetto: si pensi alle Personas [3], tanto per dirne una.

Nell’ottica di una Impact Map, identificare e classificare gli attori può essere utile per identificarne l’importanza delle necessità e quindi riuscire, in modo più semplice, a ordinare per priorità le cose da fare.

Un modo per identificare gli attori potrebbe essere per esempio quello di ordinarli in base al coinvolgimento con il prodotto che si deve realizzare. Alistair Cockburn suggerisce questa semplice classifica [4]:

  1. attori primari, i cui obiettivi devono essere soddisfatti pienamente;
  2. attori secondari, che non sono coinvolti direttamente ma possono fornire un servizio a supporto del prodotto che si deve realizzare;
  3. attori “fuori scena”, i quali sono interessati di riflesso dal sistema ma non lo usano direttamente o non forniscono un servizio.

 

Come?

Questo livello suggerisce il “come” si potrebbe realizzare il prodotto e risponde alle domande: “Come dovrebbe cambiare il comportamento degli attori?”, “Come ci aspettiamo che succeda?”, “In che modo i vari attori possono concretamente aiutarci a ottenere gli obiettivi?”, “Come possono invece impedirlo od ostacolarci?”.

Figura 4 – Il secondo livello intorno al nucleo centrale è quello del “Come”. In che modo cambierà il comportamento dei vari attori e in che modo possono aiutarci a raggiungere gli obiettivi?

Figura 4 – Il secondo livello intorno al nucleo centrale è quello del “Come”. In che modo cambierà il comportamento dei vari attori e in che modo possono aiutarci a raggiungere gli obiettivi?

 

Questo livello della mappa quindi ci aiuta a capire meglio gli obiettivi degli utenti finali: attraverso il “come”, capiamo meglio quali sono le cose che vogliono ottenere; ci permette inoltre di descrivere il cosiddetto change behaviour dell’utente e quindi quali dovranno essere gli impatti del lavoro che si sta realizzando.

Spesso un impatto evidenzia un cambio di comportamento rispetto a quello attuale: potrebbe per esempio essere una buona descrizione “vendere libri online in modo più semplice e rapido”, mentre “vendere libri online” potrebbe essere troppo generico poiché non introduce nessuna variazione dal momento che ci sono già molti e-commerce che lo fanno.

Come… procedere

In realtà in questo caso si parte dal fondo, ossia si elencano gli impatti per capire quali saranno i cambiamenti di comportamento che ci possiamo aspettare dagli utenti.

È interessante notare come le le differenze fra gli attori evidenziate durante la compilazione del livello precedente — quello del “chi” — in questo caso si potranno tradurre in impatti che potrebbero essere legati da un legame di priorità, o che potrebbero essere complementari o del tutto incompatibili fra loro.

In questo caso, per non rischiare di divagare troppo, si dovrebbe cercare di focalizzare l’attenzione solo quegli impatti che possono essere utili a muovere il progetto nella direzione giusta. Detta in questo modo sembra piuttosto difficile: un trucco potrebbe essere quello di rimanere sulle attività di business da implementare, e non di aggiungere genericamente tutte le idee che ci passano per la testa. Di pari passo, è importante non cadere nel “tranello” per cui si finisce a elencare un set di funzionalità del prodotto finale.

 

Cosa

Questo livello della nostra mappa dell’impatto permette di rispondere alle domande: “In quanto team di sviluppo /azienda / organizzazione cosa possiamo fare per supportare o implementare gli impatti desiderati?”, “Cosa possiamo fare per favorire / supportare il cambiamento di comportamento?”.

Figura 5 – Con l’aggiunta del terzo livello, quello del “cosa”, si arriva a individuare elementi che rappresentano i deliverables, le caratteristiche del prodotto ma anche attività relative all’organizzazione.

Figura 5 – Con l’aggiunta del terzo livello, quello del “cosa”, si arriva a individuare elementi che rappresentano i deliverables, le caratteristiche del prodotto ma anche attività relative all’organizzazione.

 

Gli elementi qui presenti corrispondono ai cosiddetti deliverables, alle funzioni software, oppure a semplici attività organizzative.

Bisogni utenti, soluzioni e impatti

Uno degli errori che frequentemente si compiono nella fase di stesura dei requisiti, è quello di limitarsi ad elencare un set di funzionalità senza alcuna contestualizzazione su quali siano gli interessati, e sopratutto sul perché si dovrebbero realizzare queste funzioni.

Dovrebbe ormai essere chiaro quanto sia importante invece collegare i deliverables di progetto con i corrispondenti obiettivi di business e, per ogni collegamento, argomentarne le implicazioni, ossia gli impatti, di business; detto in altro modo, è necessario definire la terna rappresentata da bisogno utente, soluzione e impatto raffigurata nella figura 6:

Figura 6 – Nella stesura dei requisiti è necessario concentrarsi non su un solo aspetto, ma collegarli nella “terna” rappresentata da “utente / bisogno”, “funzione / soluzione” e “impatto / change business behaviour”.

Figura 6 – Nella stesura dei requisiti è necessario concentrarsi non su un solo aspetto, ma collegarli nella “terna” rappresentata da “utente / bisogno”, “funzione / soluzione” e “impatto / change business behaviour”.

 

Collegando i deliverables con gli obiettivi e le conseguenze, la mappa ci aiuta a definire il filo logico che collega una scelta di business con le eventuali soluzioni che possono risolverlo. L’obiettivo di una Impact Map è esattamente questo: creare un collegamento fra quello che deve essere fatto, perché deve essere fatto e per chi.

Questo livello della mappa è il più importante e per questo dovrebbe essere completato in modo incrementale e iterativo.

 

Dalla Impact Map ai deliverables

Per la sua struttura organizzativa a grafo, la Impact Map è di grande aiuto per organizzare gli eventuali rilasci intermedi: i rami (suddivisione verticale) o i livelli (suddivisione orizzontale) potrebbero essere associati alle milestone o release. Anche le eventuali priorità che si instaurano fra gli attori sono di grosso aiuto per definire la sequenza delle cose da realizzare.

Man mano che si rilasciano nuove parti, si potrebbero aggiornare le parti ancora poco complete. I deliverables sono opzioni: non è detto che tutto quello che verrà rappresentato nel livello “cosa” della Impact Map verrà poi effettivamente realizzato. In questo senso, non conviene fissarsi fin da subito sui dettagli, ma è preferibile partire dalla definizione di alto livello dei deliverables; successivamente essi si potranno raffinare tramite le consuete tecniche di splitting come si fa comunemente sugli elementi di un backlog.

 

Conclusioni

Le Impact Map rappresentano un ottimo tool per la definizione del prodotto poiché consentono, da un lato, di mettere a fuoco numerosi aspetti legati alla realizzazione dello stesso, partendo da un nucleo centrale e procedendo per livelli. Sono inoltre molto pratiche poiché i risultati ottenuti da questo particolare tipo di mappa mentale hanno una reale portata “operativa” in quanto si ottiene la definizione di deliverables che possono essere concretamente implementati, oltretutto con una organizzazione gerarchica che permette già di ipotizzare milestones e release, anche in relazione al livello di coinvolgimento dei vari attori.

Nella prossima parte, continueremo a sviluppare questo discorso prendendo in esame la tematica delle tecniche di “raffinamento” degli elementi del Product Backlog.

 

Riferimenti

[1] Giovanni Puliti, Dalla visione al prodotto – III parte: Raccogliere le storie con la User Story Map, MokaByte 202, gennaio 2015

http://www.mokabyte.it/2015/01/liftoff-3/

 

[1b] Gojko Adzic - Impact Mapping

https://books.gojko.net/impact-mapping/

 

[2] Elevator pitch

https://en.wikipedia.org/wiki/Elevator_pitch

 

[3] Hoang Chau Huynh, Prototipare con MEAN.io – II parte: Le cose importanti prima di tutto, MokaByte 198, settembre 2014

http://www.mokabyte.it/2014/09/meanio-2/

 

[4] Alistair Cockburn, Writing Effective Use Cases, Addison-Wesley Professional, 2000

 

Condividi

Pubblicato nel numero
215 marzo 2016
Giovanni Puliti lavora come consulente nel settore dell’IT da oltre 20 anni. Nel 1996, insieme ad altri collaboratori crea MokaByte, la prima rivista italiana web dedicata a Java. Da allora ha svolto attività di formazione e consulenza su tecnologie JavaEE. Autore di numerosi articoli pubblicate sia su MokaByte.it che su…
Articoli nella stessa serie
Ti potrebbe interessare anche