tuOtempO, il CRM per le aziende sanitarie sceglie Architectural Clash
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 processo di refactoring con un Architectural Clash.
Agile Coaching
Affianchiamo il cliente tramite workshop e format dedicati per capire quale impatto strategico hanno le decisioni tecnologiche che si prendono nel lavoro di tutti i giorni. Cerchiamo inoltre di passare al cliente per osmosi tutta una serie di buone pratiche quali testing e continuous integration.
Architectural Clash
L’Architectural Clash è un format di due giorni diviso in tre fasi principali. 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.
