Gestire il debito tecnico con DX e AI

Ogni azienda, grande o piccola, si preoccupa del debito tecnico. Stime di Gartner che circa il 40% dei sistemi infrastrutturali presenta questo problema. In un sondaggio tra i CIO condotto da McKinsey, quasi un terzo riteneva che oltre% 20 del budget per il nuovo prodotto è stato destinato alla risoluzione di problemi legati al debito tecnico. Ma contrariamente a quanto molti credono, non si tratta solo di un problema di programmazione; è anche un problema di esperienza di sviluppo (DX). Perché quando gli sviluppatori devono lavorare con un'architettura inadeguata, strumenti obsoleti e flussi di lavoro di sviluppo scadenti, produttività, prestazioni e morale ne risentono.

Dare priorità al debito tecnico tenendo a mente lo sviluppatore, concentrandosi sul suo approccio al lavoro, sugli strumenti che utilizza e sulle opportunità di carriera che può ottenere, aiuta i team a concentrarsi e a velocizzare le consegne. Ecco perché il modo in cui le aziende gestiscono il debito tecnico sta cambiando, guidato dalla Digital Experience e da una maggiore attenzione agli strumenti basati sull'intelligenza artificiale.

Sostenendo DX

Il modo in cui gli sviluppatori vengono spesso integrati lascia molto a desiderare. Potrebbero volerci un paio di settimane prima che qualcuno inizi a contribuire a un progetto. Una volta che finalmente sono riusciti ad aggiungere piccole funzionalità o patch, non è raro vedere il servizio di integrazione continua (CI) fallire a causa di qualcosa di completamente estraneo alle modifiche su cui hanno lavorato. In pratica, si tratta della suite di test che fallisce a causa di problemi di scarsa qualità, e lo sviluppatore non ha inviato le modifiche necessarie per far sì che la suite di test non funzionasse. Si tratta di un test instabile e mal scritto che funziona solo nel 90% dei casi. Il team esistente probabilmente lo accetta – rallenta solo i processi – ma gli strumenti potrebbero essere obsoleti e demoralizzanti per chiunque al di fuori dell'organizzazione.

Questo è solo uno dei tanti esempi che impediscono la corretta DX. Un modo per evitarlo è avere un responsabile designato nel team di ingegneria e sviluppo software. Molte piccole organizzazioni non hanno un responsabile DX, ma quelle grandi e di successo sì. Questi professionisti tengono traccia di fattori come il tempo impiegato da un nuovo sviluppatore per configurare un ambiente. E se due settimane sono troppe, trovano il modo di dimezzare quel tempo.

Esistono strumenti che possono aiutare, come CircleCI, con funzionalità native che monitorano le instabilità di una suite di test. Ciò che serve è qualcuno che prenda la guida e si fermi dopo ogni sprint per affrontare alcune delle modifiche che renderanno il codice più facile da manutenere e utilizzare in futuro. Si tratta di avere un leader interessato a migliorare il DX. Per raggiungere questo obiettivo, cercate un ingegnere senior, accompagnato da un membro dello staff relativamente nuovo che possa fornire feedback su eventuali lacune.

Inoltre, IDC prevede che il mercato dell’automazione dei test software basata sull’intelligenza artificiale continuerà crescendo a un CAGR del 31.2% fino al 2027, quindi assicurati di sfruttare al meglio questa tecnologia.

Metriche e segnali di allarme

Esistono numerose metriche che puoi monitorare per valutare l'impatto del debito tecnico sul tuo team. Alcune di base sono il "tempo di correzione" o il "tempo di pubblicazione delle funzionalità". Supponiamo che tu noti un bug e sappia come risolverlo. Alcuni strumenti possono monitorare il tempo impiegato dalla scrittura del codice alla produzione. Ad esempio, potresti vedere che una patch molto piccola ha richiesto due giorni lavorativi per essere risolta e pubblicata, quando il tuo team dovrebbe essere in grado di farlo in poche ore. Puoi anche monitorare i rapporti, come il numero di correzioni di bug rispetto alle funzionalità completate.

Esistono anche modi per identificare quando i problemi di morale incidono sulle prestazioni del team. I responsabili dello sviluppo creativo (DX) possono condurre sondaggi trimestrali per determinare il livello di soddisfazione di uno sviluppatore nel lavorare su un progetto o su una sua parte. Possono approfondire e chiedere informazioni su aree specifiche, come il processo di Continuity (CI). E puoi sempre monitorare il tasso di abbandono o il turnaround nel tuo team. Se noti che i dipendenti continuano ad andarsene, potrebbero avere la sensazione che le loro preoccupazioni non vengano ascoltate.

Lavorare con l'intelligenza artificiale

L'ascesa degli strumenti di intelligenza artificiale dovrebbe rendere sviluppatori e ingegneri più produttivi e accelerare la distribuzione dei prodotti, ma il debito tecnico rallenta tutto questo. Supponiamo che tu utilizzi uno strumento come GitHub o Copilot per aiutarti con le modifiche al codice, quindi invii la richiesta di pull e CI impiega un paio d'ore per rispondere. Nel frattempo, uno sviluppatore lavora ad altro? Controlla le email? È un cambio di contesto e un killer della produttività.

Gli sviluppatori vogliono lavorare su prodotti in cui possono concentrarsi esclusivamente sul codice. Gli strumenti servono ad aiutarli a raggiungere la produzione, non a rappresentare un ostacolo costante. L'intelligenza artificiale può far risparmiare tempo, ma spetta ai team di ingegneri definire i propri standard di complessità accettabile. Per fare ciò, assicuratevi innanzitutto che qualsiasi codice aggiunto al branch principale abbia un livello accettabile di debito tecnico. Prima di ciò, avviate una discussione aperta e ottenete l'approvazione del team di ingegneri sulla soglia accettabile di debito tecnico e qualità del codice. Assicuratevi che tutti sappiano che superare tale soglia richiede un intervento immediato. Una volta definiti questi standard, entra in gioco l'intelligenza artificiale.

Esiste un caso in cui gli agenti di intelligenza artificiale (IA) debbano essere gestiti da ingegneri che agiscano come orchestratori. Un sondaggio Capgemini condotto su 1,100 dirigenti di grandi aziende ha rivelato che L'82% prevede di integrare agenti AI nei prossimi tre anni, e stanno già avendo un impatto sulla futuro del lavoroPotresti esaminare un bug report e scoprire che è abbastanza piccolo da poter essere gestito da un agente di intelligenza artificiale dall'inizio alla revisione del codice, risparmiando tempo al tuo team e liberandolo per occuparsi di lavori più complessi. Tuttavia, a volte, quando seguiamo ciecamente questi strumenti, ci sono compromessi che l'intelligenza artificiale fa fatica a considerare.

È allora che l'opinione umana diventa il fattore decisivo.

Allineare il debito tecnico agli obiettivi

Come si allinea la riduzione del debito tecnico con gli obiettivi che si vogliono raggiungere o con risultati misurabili? Si torna a un debito tecnico accettabile e, a volte, nel mondo degli affari, è necessario consegnare rapidamente. È possibile farlo sapendo che un prodotto non è scalabile e che potrebbero verificarsi problemi di prestazioni con il passare del tempo. Spesso, uno sviluppatore si annota di tornare su questo aspetto in seguito, quando ci sarà tempo per risolvere questi problemi, ma ciò accade raramente. E quando questa cultura aziendale negativa prende il sopravvento, in cui si è costantemente costretti a consegnare il prodotto il giorno dopo, l'impatto del debito diventa estremamente chiaro.

Questo è comprensibile per una startup, ma non per un'azienda che esiste da un decennio. È necessario iniziare a cambiare la propria cultura aziendale in anticipo e attivamente per gestire il debito tecnico; altrimenti, si spenderanno un sacco di soldi per risolvere bug di produzione o per preoccuparsi di sicurezza e conformità.

Infine, esistono metriche che aiutano a comunicare il valore del refactoring o del pagamento del debito tecnico agli stakeholder. Il tempo può essere uno di questi, dall'inizio alla produzione, o dall'apertura di una pull request alla sua fusione e spedizione in produzione. Un altro è il tempo medio di riparazione (MTTR). In questo caso, potresti aver trovato un bug o una build non funzionante e misurare quanto tempo impiega il tuo team a risolverlo. Potresti anche monitorare il numero di bug presenti in produzione. Se vedi che questo numero aumenta, potrebbe esserci un problema legato al debito tecnico.

Debito tecnico con interessi

Ogni organizzazione può dedicare qualche ora alla settimana per migliorare il proprio DX e ridurre il debito tecnico. In caso contrario, si rischia di pagarne le conseguenze in seguito, probabilmente a causa di prestazioni ridotte, un notevole rallentamento della velocità di sviluppo o problemi di sicurezza. Ad esempio, il team di ingegneri e sviluppatori potrebbe aver rimandato gli aggiornamenti a Ruby on Rails per un decennio. Improvvisamente, il costo di un progetto aumenta di mezzo milione di dollari perché la versione di Ruby è indietro di quattro generazioni, lasciandovi con una massa di codice e dipendenze obsolete.

Se avessi effettuato l'aggiornamento gradualmente, non ti troveresti in questa situazione. Quindi, supporta il tuo team di sviluppo software e paga a consumo. Altrimenti, quel debito tecnico tornerà a perseguitarti, con gli interessi.