Assessment del debito tecnico
Assessment del debito tecnico: quale debito vi rallenta, e quale potete lasciare dov'è
Leggiamo il vostro codice e il modo in cui il team lavora, insieme a voi, e vi consegniamo una mappa del debito con le priorità e un piano a 90 e 180 giorni.
Circa 4 settimane, con la prima mappa dei punti critici entro la seconda o la terza
Il debito c'è in ogni software: il problema è non sapere quale vi costa
L'assessment del debito tecnico è un'analisi di circa quattro settimane del codice e del modo di lavorare del team, che si chiude con una mappa delle aree critiche ordinata per impatto sul business e un piano d'intervento a 90 e 180 giorni. Serve perché il debito tecnico non è codice brutto da ripulire: è attrito, e rende più lente e più rischiose proprio le modifiche che portano valore. Finché non si vede dove si concentra, ogni discussione su cosa sistemare resta generica.
Il debito perde sempre la priorità, perché nessuno sa dire quanto costa
Le discussioni su cosa rifattorizzare finiscono in opinioni contrapposte
Avete un report di analisi statica con centinaia di segnalazioni e nessun ordine
Il management chiede quanto pesa il debito sulla roadmap, e la risposta è un'impressione
Si parla di riscrivere tutto, senza sapere cosa si perderebbe
È arrivato un nuovo CTO che deve capire in che stato è il sistema prima di decidere
Il punto è che nessuno ha ancora guardato il sistema per intero
Cosa analizziamo, nel codice e nel modo di lavorare
L'assessment è un'analisi del debito tecnico fatta sul codice reale e con le persone che lo cambiano ogni giorno, non un audit del codice affidato a uno strumento. Gli strumenti di analisi ci aiutano a trovare i punti da guardare; le conclusioni nascono leggendo quei punti insieme al team.
Storico delle modifiche e hotspot
Dal versionamento ricaviamo quali parti cambiano più spesso e quali sono più complesse: dove le due cose coincidono, il debito si paga a ogni modifica.
Accoppiamento e confini dei moduli
Contiamo quanti moduli deve toccare una funzionalità tipica: quando sono troppi, di solito c'è un confine poco chiaro che moltiplica il lavoro e le occasioni di regressione.
Testabilità e rete di test
Non ci fermiamo alla percentuale di copertura: guardiamo cosa descrivono davvero i test esistenti e in quali parti oggi si modifica il codice senza una rete di sicurezza.
Pipeline e flusso di rilascio
Seguiamo il percorso di una modifica fino al rilascio e guardiamo dove resta ferma in attesa, che si tratti di una build lenta o di una verifica manuale.
Dipendenze e librerie
Versioni ferme, librerie senza manutenzione, aggiornamenti rimandati perché nessuno sa cosa si romperebbe.
Interviste al team e a chi guida il prodotto
Parliamo con i developer e con chi guida il prodotto per capire quali funzionalità sono bloccate e dove il lavoro incontra più attrito.
Come si svolge
Le fasi sono cinque, e la prima mappa dei punti critici arriva prima della presentazione finale: così la discutiamo con voi quando c'è ancora tempo per approfondire.
- 01
Accessi e preparazione
Concordiamo il perimetro, otteniamo gli accessi e fissiamo le interviste con le persone giuste.
- 02
Analisi del repository e interviste
Analizziamo lo storico delle modifiche, la struttura del codice e i test; intanto parliamo con il team e con chi segue il prodotto per capire dove il lavoro rallenta.
- 03
Analisi esperta
Leggiamo i punti critici insieme ai developer e confrontiamo i dati con quello che succede davvero. Qui nasce la prima mappa.
- 04
Mappa e piano
Assegniamo a ogni area un'azione e costruiamo il piano d'intervento a 90 e 180 giorni, ordinato per impatto sul business.
- 05
Presentazione finale
Presentiamo mappa, piano ed executive summary a CTO e management, e rispondiamo alle domande di chi deve decidere.
Due formati, scelti in base al sistema
Circa 4 settimane
Formato standard
Per la maggior parte dei prodotti: la prima mappa dei punti critici arriva entro la seconda o la terza settimana, la presentazione finale alla quarta.
Fino a 2 mesi
Formato approfondito
Per codebase grandi o team distribuiti: osserviamo più cicli di rilascio e uno storico delle modifiche più lungo, perché in sistemi così il debito si vede solo nel tempo.
Cosa ricevete
La mappa del debito con le priorità
Ogni area critica con rischio, frequenza di modifica, impatto sul business e una sola azione fra quattro, messa in ordine di intervento.
Un executive summary per il management
Un documento che traduce il debito in conseguenze sulla roadmap, per chi deve decidere senza leggere il codice.
Un piano d'intervento a 90 e 180 giorni
L'ordine in cui affrontare le aree, comprese quelle da lasciare dove sono, e i segnali da osservare per capire se il piano sta funzionando.
Come si presenta la mappa del debito
Un esempio, sul software di un ipotetico e-commerce. Ogni riga è un'area del sistema; le colonne dicono quanto è rischioso toccarla, quanto spesso la si tocca e quanto pesa sul business; l'ultima dice cosa farne.
| Area | Rischio | Frequenza di modifica | Impatto sul business | Azione |
|---|---|---|---|---|
| Gestione delle spedizioniOgni nuovo corriere passa di qui, e ogni modifica rompe un caso particolare | Alto | Alta | Alto | Rifattorizzare per primo |
| Integrazione con il gestionaleFragile, ma cambia una o due volte l'anno | Alto | Bassa | Medio | Contenere |
| Flusso degli ordiniCambia a ogni sprint e quasi nessun test ne descrive il comportamento | Medio | Alta | Alto | Test e poi refactoring |
| Reportistica storicaCodice vecchio e complesso, ma stabile e fuori dal percorso della crescita | Basso | Bassa | Basso | Lasciare com'è |
- Rifattorizzare per primo
- Dove rischio, frequenza di modifica e impatto si sommano: ogni settimana di attesa costa
- Contenere
- Si isola l'area dietro un confine chiaro, così il suo debito non si propaga al resto
- Test e poi refactoring
- Dove il codice cambia spesso ma nessun test ne fissa il comportamento: prima test di caratterizzazione che descrivono come funziona oggi, poi il refactoring in sicurezza
- Lasciare com'è
- Debito noto, stabile e lontano dalla roadmap: intervenire costerebbe più di quanto renda
Il debito che potete lasciare dov'è
Non tutto il debito va pagato. Un modulo complesso che non cambia da anni e non sta sul percorso della crescita costa poco finché resta fermo; rifattorizzarlo per principio significa spendere tempo del team dove non torna nulla.
Per questo fra le azioni della mappa c'è «Lasciare com'è», e per questo la prima domanda che ci facciamo su ogni area è quanto costerà la prossima modifica che dovrete farci. Sapere cosa non toccare libera tempo e attenzione per le due o tre aree che stanno davvero frenando la roadmap.
Cosa non include questo assessment
Il report di uno strumento di analisi statica, con centinaia di segnalazioni senza un ordine
Un giudizio sulle persone: il debito nasce quasi sempre da decisioni sensate in un contesto che poi è cambiato
Un documento da ottanta pagine che nessuno legge dopo la presentazione
Una riscrittura data per scontata: la consigliamo solo quando i criteri la giustificano
Un vincolo con noi: il piano è scritto perché il vostro team possa eseguirlo anche da solo
State valutando un software che non è ancora vostro, per un investimento o un'acquisizione? Quella è una tech due diligence, con domande e tempi diversi. Cos'è una tech due diligence
Dopo l'assessment, tre strade
La mappa vale anche se non lavoreremo più insieme. Quale strada prendere dipende da quanto e dove il debito pesa, e lo decidete voi con la mappa davanti.
Il team procede da solo
Quando il debito è circoscritto e il team ha tempo e competenze
Il piano a 90 e 180 giorni è pensato per essere eseguito dal vostro team: priorità, azioni e segnali da osservare sono già scritti.
Intervento Mirato
Quando emerge un solo nodo che blocca tutto il resto
Un intervento breve e circoscritto su quel punto, lavorando nel codice con il vostro team, senza aprire un programma più ampio.
Com'è fatto l'Intervento MiratoPercorso di refactoring del codice legacy
Quando il debito è diffuso e frena la roadmap su più fronti
Un percorso incrementale nel vostro codice, senza riscrittura totale. La modalità la indica l'assessment: un piccolo team di scopo con i vostri developer quando il danno è serio, refactoring opportunistico durante lo sviluppo quando è contenuto.
Com'è fatto il percorso di refactoringDa dove nasce questo modo di lavorare
In SureVIVE, un software che coordina le missioni di soccorso ed è operativo giorno e notte, la crescita era bloccata dal debito tecnico: un'architettura non più adatta e parti di codice legacy rallentavano il sistema in più punti. Il lavoro è partito da un'analisi condotta insieme al team, sullo stato di salute del software e sulle dinamiche dell'organizzazione.
Da quell'analisi è nato un percorso di refactoring che ha anticipato le funzionalità di prodotto che ne avevano bisogno, senza diventare un cantiere separato: il debito tecnico è sceso del 15% e alcune funzionalità prima irrealizzabili sono diventate sviluppabili.
Domande frequenti
- Serve darvi accesso al codice?
- Sì, al repository e allo storico delle modifiche: senza il codice reale l'assessment diventerebbe un questionario, ed è proprio quello che vogliamo evitare.
- Quanto dura?
- Il formato standard dura circa quattro settimane, con la prima mappa dei punti critici entro la seconda o la terza. Per codebase grandi o team distribuiti c'è un formato approfondito, fino a due mesi, che osserva più cicli di rilascio e uno storico delle modifiche più lungo.
- Su quali tecnologie lavorate?
- Siamo agnostici rispetto al linguaggio: lavoriamo con lo stack che avete e adottiamo le tecnologie che il vostro team usa già. Storico delle modifiche, accoppiamento, testabilità e flusso di rilascio si leggono in ogni stack.
- Usiamo già SonarQube o CodeScene: ci serve comunque?
- Gli strumenti dicono dove il codice è complesso o cambia spesso, e i loro dati ci sono utili. Non dicono quale debito pesa sul business, quale si può lasciare dov'è né in che ordine intervenire: per questo servono le interviste, la lettura del codice con il team e la conoscenza della roadmap.
- Che differenza c'è fra un audit del codice e un assessment del debito tecnico?
- Un audit del codice controlla la qualità rispetto a regole e standard e produce un elenco di problemi. L'assessment del debito tecnico parte dallo stesso codice ma risponde a un'altra domanda: quale debito rallenta le modifiche che contano per il business, e in che ordine affrontarlo. Per questo incrocia il codice con lo storico delle modifiche e con le interviste al team. Se cercate una consulenza o una valutazione del debito tecnico, di solito si comincia da qui.
- Cosa succede se il debito è ovunque?
- Succede raramente che pesi ovunque allo stesso modo. Di solito poche aree concentrano gran parte dell'attrito, perché sono quelle che cambiano più spesso; la mappa serve proprio a separarle dal resto e a decidere da quale cominciare.
- Ha senso prima di decidere una riscrittura?
- È il momento in cui serve di più. La riscrittura ha senso in pochi casi, per esempio tecnologie senza più aggiornamenti di sicurezza o un accoppiamento che rende impossibile isolare qualunque parte. L'assessment dice se il vostro sistema è uno di quei casi, o se un refactoring incrementale arriva prima e con meno rischio.
- Che differenza c'è con una tech due diligence?
- La tech due diligence serve a chi valuta un software che non possiede ancora, prima di un investimento o di un'acquisizione. L'assessment del debito tecnico è per chi il software lo sviluppa già e vuole sapere dove intervenire per tornare a cambiarlo con facilità.
Prima di impegnarvi
Una prima call gratuita
Ci raccontate il sistema e cosa vi frena, e vi diciamo con franchezza se un assessment vi serve e in quale formato; a volte la risposta è che non serve.
Fissa la prima callUn'autovalutazione da fare subito
Il Consistency Impact Calculator stima l'impatto economico della mancata coerenza fra business, struttura dei team e software: un primo ordine di grandezza di quanto vi costa la lentezza.
Apri il Consistency Impact CalculatorProblemi correlati
Spesso questi segnali si presentano insieme. Approfondisci i temi collegati.
Approfondisci su Sapere
Articoli del nostro team che esplorano in dettaglio i temi legati a questa sfida
Come misurare il debito tecnico: dall'architettura al flusso di lavoro
Misurare il debito tecnico non significa installare SonarQube. Significa capire dove il sistema oppone resistenza ai cambiamenti che il business richiede. Una guida operativa alle metriche che contano — e a quelle che distraggono.
I segnali del debito tecnico: nel codice, nel team e nel business
Il debito tecnico manda segnali precisi prima di diventare un'emergenza. Molti vengono interpretati come problemi di persone o di processo. Questa guida li traduce in quello che sono: sintomi di una struttura software che non regge più il ritmo dell'organizzazione.
Cost of change nel software development: perché cresce
Quando il software cresce, modificare il prodotto diventa sempre più difficile. Il cost of change è uno dei segnali più chiari che architettura, organizzazione e delivery non stanno evolvendo insieme.
Debito tecnico: guida per chi decide, dalle cause alla riduzione
Guida al debito tecnico per CTO e CEO in cinque articoli: la definizione, come si accumula, quali segnali manda, come si misura e come si riduce.
Richiedi l'assessment del debito tecnico
Partiamo da una call gratuita: capiamo il sistema e scegliamo insieme formato e perimetro