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.

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?”.

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.

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?”.

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?”.

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:

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.

Giovanni Puliti

Giovanni Puliti ha lavorato per oltre 20 anni come consulente nel settore dell’IT e attualmente svolge la professione di Agile Coach. Nel 1996, insieme ad altri collaboratori, crea MokaByte, la prima rivista italiana web dedicata a Java. Autore di numerosi articoli pubblicate sia su MokaByte.it che su riviste del settore, ha partecipato a diversi progetti editoriali e prende parte regolarmente a conference in qualità di speaker. Dopo aver a lungo lavorato all’interno di progetti di web enterprise, come esperto di tecnologie e architetture, è passato a erogare consulenze in ambito di project management. Da diversi anni ha abbracciato le metodologie agili offrendo ad aziende e organizzazioni il suo supporto sia come coach agile che come business coach. È cofondatore di AgileReloaded, l’azienda italiana per il coaching agile.