case-study

tuOtempO: fare lean refactoring guidati da Architectural Clash

case-study

tuOtempO è il primo CRM per gestire sia i pazienti che le prenotazioni di visite ed esami per aziende sanitarie.
Uno dei fronti sui quali collaboriamo è il refactoring della parte frontend della loro applicazione.
Noi crediamo che un refactoring senza un piano e soprattutto senza una visione condivisa sia destinato a fallire. Proprio per questo motivo abbiamo deciso di iniziare il questo processo con un Architectural Clash, per capire quale impatto strategico hanno le decisioni tecnologiche che si prendono nel lavoro di tutti i giorni.

Architectural Clash

L’Architectural Clash è un format di due giorni diviso in tre fasi principali: raccolta informazioni, micro-esperimenti e definizione di un piano di refactoring. Proprio per questa sua natura lo abbiamo proposto a tuOtempO.

Come accennato, la prima fase serve per raccogliere informazioni sul progetto e sul contesto in cui questo progetto vive. Caratteristica importante di questa fase del format è la presenza non solo di tecnici al tavolo ma anche di decision maker.
Questo approccio ci permette di rendere esplicito il collegamento tra le scelte tecnologiche e quelle di business, perché crediamo che creare allineamento tra obiettivi di business e scelte tecniche sia fondamentale per far partire in maniera sana un processo di refactoring.
Nel caso di un refactoring di solito approcciamo questa fase cercando di estrapolare i punti di forza e di debolezza della base di codice da più punti di vista. Il refactoring che metteremo in campo deve risolvere i problemi segnalati, mantenendo inalterati i punti di forza.

La seconda parte è quella del clash vero e proprio. Si affrontano i problemi emersi durante la prima fase con micro-esperimenti da un’ora. Questi esperimenti vengono presi in carico da team che si formano in maniera autonoma intorno all’argomento. Ogni slot è formato da 45 minuti in cui il team mette le mani in pasta nel codice cercando di risolvere il problema, e 15 minuti finali che servono per tirare delle conclusioni ed esporle agli altri team presenti.

Nell’ultima parte del workshop tutti i team si riuniscono per definire un piano di refactoring. Gli esperimenti, infatti, non servono per risolvere i problemi estrapolati durante la prima fase, ma per imparare e trovare eventuali roadblock. Queste informazioni vengono ordinate per creare una roadmap di refactoring. Nel caso specifico abbiamo ricavato delle azioni dai nostri esperimenti e posizionato su un Change Options Canvas che aiutasse a far capire per ogni azione la relazione che c’è tra il costo e il valore dell’azione stessa. Questo ha permesso al team di tuOtempO di mettere in priorità le varie attività e di avviare il percorso di refactoring.

Flowing ci ha proposto l’Architectural Clash dopo aver analizzato la complessità dei nostri obiettivi ed aver percepito una certa nebulosità nella roadmap da noi maturata fino a quel momento. La natura del format ne rispecchia molto il titolo in quanto si estende in 2 giornate caratterizzate da un enorme livello di attenzione e consapevolezza costante dei temi trattati e richiedono un grosso dispendio di energia perché tendono a spianare qualsiasi intoppo sulla via della stesura di un piano d’azione il più efficace e adeguato possibile. La cosa importante è che di questo dispendio di energia si fa carico in buonissima parte proprio Flowing, che alla fine della 2 giorni se ne va un po’ stremato anche lui ma con il risultato di averci messo in condizione di chiarire e priorizzare i nostri obiettivi e addirittura stilare una pianificazione ben bilanciata degli interventi, certamente non definitiva, ma che ci ha permesso di iniziare a lavorare concretamente, indirizzandoci oltretutto nelle principali scelte tecnologiche.

Emanuele Luchetti, CTO @ tuOtempO

Team