Gestione del debito tecnico con DX e AI

Ogni azienda, grande o piccola, si preoccupa del debito tecnico. Gartner stima che circa il 40% dei sistemi di infrastruttura ha questo problema. In un sondaggio di CIO condotto da McKinsey, quasi un terzo ha ritenuto che oltre il 20% del loro budget per nuovi prodotti sia stato utilizzato per risolvere problemi legati al debito tecnico. Ma a differenza di quanto molti credono, questo non è solo un problema di codifica; è anche un problema di esperienza dello sviluppatore (DX). Perché quando gli sviluppatori devono lavorare con un’architettura inadeguata, strumenti obsoleti e flussi di lavoro di sviluppo scadenti, la produttività, le prestazioni e il morale soffrono.

Prioritizzare il debito tecnico con lo sviluppatore in mente, concentrandosi su come affrontano il lavoro, quali strumenti utilizzano e quali progressi di carriera possono ottenere, aiuta i team a concentrarsi e a spedire più velocemente. Questo è il motivo per cui il modo in cui le aziende gestiscono il debito tecnico sta cambiando, guidato da DX e da un aumento dell’attenzione agli strumenti alimentati da AI.

Championing DX

Il modo in cui gli sviluppatori sono spesso introdotti lascia molto a desiderare. Potrebbe volerci un paio di settimane perché qualcuno inizi a contribuire a un progetto. Una volta che hanno finalmente potuto aggiungere piccole funzionalità o patch, non è insolito vedere il servizio di integrazione continua (CI) che fallisce a causa di qualcosa di completamente non correlato ai cambiamenti che hanno lavorato. Questo è fondamentalmente il test suite che fallisce a causa di problemi di qualità scadenti, e lo sviluppatore non ha inviato modifiche per far fallire il test suite. È un test scritto male e instabile che funziona solo il 90% del tempo. Il team esistente probabilmente va bene – rallenta solo i processi – ma gli strumenti potrebbero essere obsoleti e demoralizzanti per chiunque sia al di fuori dell’organizzazione.

Questo è solo un esempio di molti che ostacolano la giusta DX. Un modo per prevenire questo è avere un campione designato nel tuo team di ingegneria e sviluppo software. Molte piccole organizzazioni non hanno un leader DX, ma le grandi e di successo sì. Questi professionisti tengono traccia di cose come il tempo che ci vuole a un nuovo sviluppatore per impostare un ambiente. E se due settimane sono troppo a lungo, scoprono come tagliare quel tempo a metà.

C’è uno strumento là fuori per aiutare, come CircleCI, con funzionalità native che tracceranno l’instabilità di un test suite. Ciò che è necessario è qualcuno che prenda il comando e si fermi dopo ogni sprint per affrontare alcuni dei cambiamenti che renderanno il codice più facile da mantenere e lavorare in futuro. Si tratta di avere un leader interessato a migliorare la DX. Per farlo, cerca un ingegnere senior, accompagnato da un membro dello staff relativamente nuovo che possa fornire feedback su possibili lacune.

Inoltre, IDC prevede che il mercato della automazione dei test del software alimentata da AI continuerà a crescere a un tasso di crescita annuo composto del 31,2% fino al 2027, quindi assicurati di sfruttare al massimo questa tecnologia.

Metriche e segnali di allarme

Ci sono molte metriche che puoi tracciare quando valuti come il debito tecnico sta impattando il tuo team. Alcune di base sono “tempo di risoluzione” o “tempo di funzionalità”. Supponi di notare un bug e di sapere come risolverlo. Alcuni strumenti possono tracciare il tempo trascorso dalla scrittura del codice alla produzione. Ad esempio, potresti vedere che una piccola patch ha richiesto due giorni lavorativi per essere risolta e spedita, quando il tuo team deve essere in grado di farlo in poche ore. Puoi anche tracciare rapporti, come il numero di correzioni di bug rispetto alle funzionalità completate.

Ci sono anche modi per identificare quando i problemi di morale influenzano le prestazioni del tuo team. I leader DX possono eseguire sondaggi trimestrali per determinare quanto è felice uno sviluppatore nel lavorare su un progetto o su una parte di esso. Possono approfondire e chiedere informazioni su aree specifiche come il processo CI. E puoi sempre tracciare il turnover o il ricambio nel tuo team. Se noti che le persone continuano a lasciare, potrebbero sentirsi come se le loro preoccupazioni non stessero essere ascoltate.

Tooling con AI

La crescita degli strumenti alimentati da AI dovrebbe rendere gli sviluppatori e gli ingegneri più produttivi e far spedire i prodotti più velocemente, ma il debito tecnico rallenta questo processo. Supponi di utilizzare uno strumento come GitHub o Copilot per aiutare con le modifiche al codice, quindi invii la richiesta di pull e il CI impiega un paio di ore per tornare da te. Nel frattempo, uno sviluppatore lavora su qualcos’altro? Controlla le email? È un cambio di contesto e un killer di produttività.

Gli sviluppatori vogliono lavorare su prodotti in cui possono semplicemente concentrarsi sul codice. Gli strumenti sono lì per aiutarli a portarlo in produzione, non per essere un ostacolo costante. L’AI può risparmiare tempo, ma spetta ai team di ingegneria definire i propri standard per la complessità accettabile. Per farlo, assicurati innanzitutto che qualsiasi codice aggiunto al ramo principale abbia un livello di debito tecnico accettabile. Prima di tutto, hai una discussione aperta e ottieni l’approvazione del team di ingegneria sulla soglia di debito tecnico e qualità del codice accettabile. Assicurati che tutti sappiano che superare quel segno richiede una risoluzione immediata. Una volta che hai definito quegli standard, l’AI entra in gioco.

C’è un caso per gli agenti AI con gli ingegneri che agiscono come orchestratori. Un sondaggio di Capgemini di 1.100 dirigenti di grandi aziende ha rivelato che l’82% pianifica di integrare gli agenti AI nei prossimi tre anni, e stanno già impattando il futuro del lavoro. Potresti stare guardando un rapporto di bug e vedere che è abbastanza piccolo per essere gestito da un agente AI dall’inizio alla revisione del codice, risparmiando tempo al tuo team e liberandoli per lavorare su attività più complesse. Tuttavia, a volte, quando seguiamo ciecamente questi strumenti, ci sono compromessi che l’AI fatica a considerare.

È allora che un’opinione umana diventa il fattore decisivo.

Allineare il debito tecnico con gli obiettivi

Come allinei la riduzione del debito tecnico con gli obiettivi che sto cercando di raggiungere o con risultati misurabili? Torna al debito tecnico accettabile e, a volte, in azienda, devi spedire velocemente. Puoi farlo sapendo che un prodotto non scala e potrebbero esserci problemi di prestazioni con il passare del tempo. Spesso, uno sviluppatore farà una nota per tornare su questo più tardi, quando ci sarà il tempo per affrontare questi problemi, ma raramente accade. E quando questa cattiva cultura prende il sopravvento, in cui devi costantemente spedire domani, l’impatto del debito diventa abbondantemente chiaro.

Questo è comprensibile per una startup, ma non per un’azienda che è in attività da un decennio. Devi iniziare a cambiare la tua cultura presto e attivamente per gestire il debito tecnico; altrimenti, spenderai un sacco di soldi per risolvere bug di produzione o preoccuparti della sicurezza e della conformità.

Infine, ci sono metriche per aiutare a comunicare il valore della rifattorizzazione o del pagamento del debito tecnico agli stakeholder. Il tempo potrebbe essere uno, dall’inizio alla produzione, o dall’apertura di una richiesta di pull alla fusione e alla spedizione in produzione. Un altro è il tempo medio di riparazione (MTTR). In questo caso, potresti aver trovato un bug o una build rotta e misurare quanto tempo ci vuole al tuo team per risolverlo. Potresti tracciare il numero di bug che hai in produzione. Se vedi che quel numero aumenta, potrebbe esserci un problema legato al debito tecnico.

Debito tecnico con interessi

Ogni organizzazione può dedicare alcune ore ogni settimana per migliorare la propria DX e aiutare a ridurre il debito tecnico. Se non lo fai, potresti pagare per questo più tardi, probabilmente con prestazioni lente, un rallentamento significativo nella velocità di sviluppo o problemi di sicurezza. Ad esempio, il tuo team di ingegneri e sviluppatori potrebbe aver rinviato gli aggiornamenti a Ruby on Rails per un decennio. Improvvisamente, il costo del progetto aumenta di mezzo milione di dollari perché la versione di Ruby è quattro generazioni indietro, lasciandoti con una massa di codice e dipendenze obsolete.

Se avessi aggiornato gradualmente, non saresti in questa situazione. Quindi, sostieni il tuo team di sviluppo software e paga man mano che vai. Altrimenti, quel debito tecnico tornerà a perseguitarti, con interessi.