I nostri prodotti

  • Agile Farm: la fattoria agile
  • Agile Grammelot
  • Antifragile framework map
  • ARchetipo: il kit per fare envisioning di prodotti
  • Disney Method: nuove idee in modo creativo
  • Reverse story mapping
  • Succeeding with feature teams
  • User Story Splitting
  • Verso agile
  • Reverse story mapping

    Un workshop per ricreare da capo un'applicazione usando la tecnica dello User Story Mapping… al contrario

    Un caso reale

    In questo workshop si impara a risolvere un problema non banale, ma piuttosto comune: ricreare un’applicazione legacy da capo, partendo dall’applicazione stessa.

    Per farlo, impiegheremo una tecnica originale da noi messa a punto su un progetto reale presso un nostro cliente (che, oltrettutto, ci ha gentilmente consentito di utilizzare il materiale realizzato presso la sua azienda). Si tratta semplicemente di quelo che di solito si fa in questi casi, ma applicato… al contrario.

     

    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.

    Si tratta di 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.

    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.

     

    “Smontare il macchinario”

    Certo, sarebbe possibile affrontare questa operazione di reverse engineering  con un classico approccio under the hood: si analizzano i codici sorgenti e si  cerca di ricavare da quelli il funzionamento del prodotto.

    Ma questa strada si rivela difficile e non dà 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.

    Nel nostro caso reale, le cose sono andate come segue. Per prima cosa, il team ha disegnato su fogli di carta molto grandi le schermate del flusso principale basico, vale a dire il minimo delle funzioni indispensabili perché il prodotto svolgesse i suoi compiti. Si tratta di qualcosa molto simile a ciò che Jeff Patton chiama walking skeleton nel suo libro User Story Mapping.

    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à dietro quel widget. Sono stati usati dei Post-it di colore diverso per connotare ogni tipologia di codice (JavaScript, frontend, server-side) 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 JavaScript, frontend o server-side.

     

    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 vengono 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 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 ricomincia il processo: guidati dal Product Owner, i componenti del gruppo hanno rimuovono 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.

     

    Una tecnica utile e risolutiva

    Grazie all’adattamento della tecnica di User Story Mapping, è 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.

    Il workshop Reverse Story Mapping consente di apprendere e sperimentare questa tecnica in maniera strutturata, proficua e veloce. Un “attrezzo” in più nella cassetta di chi deve confrontarsi quotidianamente con progetti reali.