Architectural clash …e il tuo software legacy (ri)torna a creare valore

L’application modernization ricopre un ruolo sempre più centrale nell’ecosistema dello sviluppo software.

Now Every Company Is A Software Company.

Vero, per citare una famosa frase di Forbes, ma al tempo stesso una larga fetta delle software enterprise non è pronta per i cambiamenti repentini richiesti oggi dal mercato.

Come azienda, stiamo aiutando molti clienti che sono in affanno nel riammodernare i loro software. Nella maggior parte dei casi veniamo ingaggiati per aiutare i team di sviluppo quando sono bloccati nell’implementare una serie di feature che sembrano non fattibili a causa delle condizioni della base di codice. Le cause di questi roadblock possono essere legati a framework, architetture non più adatte o a un accumulo di debito tecnico che rende difficile – a volte impossibile – evolvere il software. Questo spesso comporta che il software dei nostri clienti non è più uno strumento che porta valore al loro core business, ma addirittura diventa un ostacolo.

Con lo scopo di rimuovere questi roadblock abbiamo creato un workshop dedicato: Architectural clash.

Il vantaggio principale dell’Architectural clash è quello di essere estremamente pratico: non sprechiamo tempo ed energie in analisi e ipotesi, ma iniziamo fin da subito a lavorare sulla base di codice esistente. Il format ha una durata di due giornate e metà di questo tempo è infatti hands-on: un nostro team di esperti affianca il team del nostro cliente aiutandolo ad affrontare i problemi della base di codice.

Un Architectural clash è diviso in tre fasi: Sense-Making, Clash e Decide.

Sense-Making

La prima fase è il Sense-Making, focalizzata sull’aiutare tutti i partecipanti a comprendere i confini del problema. In questa fase è necessaria la presenza, lato cliente, di tutti gli stakeholder del progetto, non solo il suo team di sviluppo.

Lo scopo principale è capire come i problemi tecnologici sono legati ai problemi del business. La maggior parte delle volte, infatti, i processi di refactoring falliscono perché non direttamente legati a questi obiettivi.

Quando un team crede che il problema sia una base di codice legacy confusa o senza test, o lavorare con vecchie tecnologie o framework, noi scaviamo più a fondo cercando di capire quali sono le conseguenze e i collegamenti nascosti tra quei problemi tecnici e il core business. Ad esempio, mettendo in mostra la connessione del lavorare con una big ball of mud con il throughput del team.

Lo facciamo con una serie di esercizi che chiaroscono l’obiettivo del business e cercando di capire i roadblock che non permettono di raggiungere quel goal. E per ogni roadblock proponiamo delle soluzioni.

L’outcome della prima fase è quindi una lista di possibili soluzioni, che saranno l’ingrediente principale della prossiam fase: il Clash.

Clash

Il Clash – la parte centrale del format – ha lo scopo di lavorare al più alto numero possibile di soluzioni permettondoci di validarle, scartarle o approfondirle in un secondo momento. Le otto ore a cui si lavora al Clash sono divise in otto slot da un’ora l’uno.

In ogni slot il team si divide in piccoli gruppi che lavorano in parallelo, ognuno ad una differente soluzione per 45 minuti. Alla fine di questo timebox, i gruppi si riuniscono per confrontarsi nei successivi 15 minuti su quanto ottenuto e su cosa fare nello slot successivo. Lo scopo in questa fase non è andare in profondità, ma in ampiezza, per cercare di prendere più informazioni possibili nel minor tempo possibile.

Decide

Nell’ultima fase chiamata Decide tutte le informazioni, i successi e i fallimenti della fase Clash vengono analizzate e messe in relazione con i business goal per creare una roadmap allineata ai tempi del business. 

Per fare ciò riportiamo al tavolo gli stakeholder e mettiamo in priorità le attività calibrando lo sforzo da sostenere con il suo vantaggio strategico. 

Dove lo abbiamo applicato? Come è andata? Qui trovi il racconto di un Architectural clash fatto per un nostro cliente.