Porting di un sistema legacy: definire un product backlog tramite il reverse story mapping

Il racconto di come abbiamo affrontato e risolto un problema insieme a un nostro cliente: come rifare una applicazione da capo tramite una tecnica basata sull’uso dello User Story Mapping… al contrario.

Un caso reale

Di recente, durante una attività di coaching presso un nostro cliente, ci siamo trovati a dover risolvere un problema non banale, e abbiamo applicato una tecnica originale, impiegando un metodo basato su  quello che normalmente si fa in questi casi, ma applicandolo…. al contrario.

Pensiamo che questo caso possa essere interessante per altre persone, e quindi lo raccontiamo in questo post, anche grazie alla disponibilità dei responsabili del team in cui stavamo lavorando che ci hanno autorizzato a pubblicare il materiale.  

Prossimamente inseriremo questo metodo nel nostro framework ARchetipo: con ogni probabilità, si presenteranno ulteriori casi simili, in cui tale tecnica potrà essere d’aiuto anche ad altri team di lavoro.

 

Il problema: clonare un prodotto legacy

Il team in questione aveva la necessità di clonare un prodotto vecchio in uso, in modo da ricreare le stesse funzionalità in un nuovo prodotto software che però fosse basato su un’architettura moderna e su tecnologie aggiornate.

reverse-archetipo-fig1
Figura 1 – Il prodotto vecchio esiste già e ha le sue schermate con le loro funzionalità. Dobbiamo ricrearne uno uguale, ma basato su architettura e tecnologie moderne. Nel caso reale, le schermate erano 6.

È uno dei progetti più classici: il porting di un prodotto esistente su nuove tecnologie per ammodernarlo sia dal punto di vista tecnologico che da quello dell’esperienza utente. In questo scenario, il prodotto vecchio diventa una sorta di product backlog per quello nuovo.

 

“Smontare il macchinario”

Questa operazione di reverse engineering è stata affrontata dapprima con un approccio under the hood: si sono analizzati i codici sorgenti e si è cercato di ricavare da quelli il funzionamento del prodotto. Questa strada si è rivelata difficile e non ha dato buoni risultati: troppa complessità, troppi elementi non comprensibili.

 

Story mapping… al contrario

Perché, invece, non ricorrere a quanto abbiamo utilizzato positivamente in tante occasioni? Le pratiche legate all’utilizzo delle User Story si sono rivelate funzionali e affidabili: a ben guardare, qui si trattava semplicemente di un processo di story mapping che andava però fatto al contrario.

Per prima cosa, il team ha disegnato su fogli di carta molto grandi le schermate di quello che era stato individuato come flusso principale basico, vale a dire il minimo delle funzioni indispensabili perché il prodotto svolgesse i suoi compiti. Facendo riferimento a User Story Mapping di Jeff Patton, si tratta di qualcosa molto simile a ciò che lui chiama walking skeleton.

A livello pratico, per individuare il minimum viable UI flow, nelle nostre “schermate” di carta, abbiamo coperto con uno scotch colorato i componenti dell’interfaccia che non erano strettamente necessari.

reverse-archetipo-fig2
Figura 2 – Con uno scotch colorato (nell’immagine è verde chiaro) sono stati coperti i componenti dell’interfaccia non strettamente necessari.

In tal modo, sono rimasti visibili solo alcuni componenti grafici, quelli ritenuti fondamentali. A questo punto, il team ha analizzato proprio i componenti non coperti da nastro: per ciascuno di essi, ha elencato le funzionalità che sono dietro quel widget. Sono stati usati dei Post-it di colore diverso per connotare ogni tipologia di codice (JavaScript, frontend, serverside) con cui implmentare tali funzionalità.

reverse-archetipo-fig3
Figura 3 – Ci si concentra sui componenti principali, non coperti da nastro. Per ciascuno di essi, si individua la tipologia di codice che implementa la funzionalità, applicanoci sopra un Post-it di colore diverso, che serve a identificare se si tratta di JS, frontend o serverside.

Dopo aver lavorato in questo modo sulle 6 schermate della interfaccia, i biglietti raccolti rappresentano le funzionalità da implementare per permettere la realizzazione della prima versione minimale dell’applicazione. I  bigliettini sono stati riportati su una board organizzandoli in colonne: ogni colonna è uno step del wizard.

reverse-archetipo-fig4
Figura 4 – Si raccolgono i Post-it che identificano i componenti grafici principali e le loro funzionalità e li si collocano su una board. Questa prima riga della board rappresenta ciò che Patton chiama il walking skeleton dell’applicazione.

 

Iterazioni successive

Ora che le funzionalità principali sono state individuate, restano tutte le altre funzionalità rappresentate dai componenti coperti dal nastro adesivo. A questo punto, quindi, il team ha ricominciato il processo: guidati dal Product Owner, i componenti del gruppo hanno rimosso il nastro “mascherante” dalle funzionalità che avrebbero voluto implementare in una seconda iterazione.

reverse-archetipo-fig5
Figura 5 – Si passa alle funzioni da implementare in una seconda iterazione, rimuovendo il nastro che le mascherava e procedendo a identifcare la tipologia di componenti interessati con Post-it colorati (nella figura, sono quelli in celeste).

In maniera analoga a quanto fatto prima, si trasportano i biglietti adesivi dalle “schermate” di  carta alla lavagna, collocandoli in una seconda riga.

reverse-archetipo-fig6
Figura 6 – La seconda riga della board rappresenta una seconda iterazione con funzioni da implementare in un secondo tempo.

Si procede così, continuando a scoprire i componenti grafici, identificandone funzione e tipologia di codice grazie a dei Post-it, e riportando poi tali bigliettini sulla lavagna.

 

Per concludere

Con queste brevi note, abbiamo voluto illustrare come, grazie all’adattamento della tecnica di User Story Mapping, sia possibile affrontare un caso neanche tanto raro e riportarlo nell’alveo degli strumenti e delle metodologie che usiamo quotidianamente. I principi e le metodologie dell’agilità ci danno un’infrastruttura ideale e operativa, all’interno della quale si può applicare la creatività e il buon senso. E improvvisare, se necessario.