Cos’è il Debito Tecnico (E Ne Hai Troppo?)
All'inizio della mia carriera come neo-associate product manager, quando ho sentito parlare per la prima volta di debito tecnico (anche noto come tech debt), non ero del tutto sicuro di cosa significasse. Divertentemente, pensavo si riferisse a un prestito che avevamo contratto per acquistare software di terze parti, e ho usato in modo sicuro questo termine in modo scorretto per due o tre settimane. Immaginate il mio imbarazzo quando i miei ingegneri mi hanno preso da parte dopo la standup per correggermi gentilmente!
Quindi, per risparmiarci qualche rossore sul lavoro e per aiutarci a guadagnare credibilità con i nostri ingegneri, vediamo insieme che cos'è il debito tecnico e perché, come product manager, dovremmo occuparcene.
Che cos'è il debito tecnico e quando diventa un problema?
Lo sviluppo software riguarda sempre il bilanciare la gamma di funzionalità del prodotto con la qualità del codice. Durante questo percorso, a volte prendiamo scorciatoie per accelerare lo sviluppo: queste scorciatoie sono chiamate debito tecnico o tech debt.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
Quando ha senso accumulare debito tecnico e quando invece diventa una bomba a orologeria? Per rispondere a questa domanda, dobbiamo prima dare uno sguardo alla storia del debito tecnico.
Che cos'è il debito tecnico?
Ward Cunningham, la persona che ha coniato il termine, paragona il debito tecnico a un debito finanziario: va bene "prendere in prestito" contro una futura velocità e stabilità, ma dobbiamo prima o poi ripagare questo debito. È un concetto che ogni team di sviluppo dovrebbe comprendere, e che ogni product manager dovrebbe considerare quando prende decisioni di prodotto.
Il tech debt ci aiuta a lanciare i prodotti in anticipo sulle scadenze e a portarli più rapidamente nelle mani dei clienti. Tuttavia, dobbiamo alla fine "ripagare il debito" investendo nella qualità del nostro codice.
Idealmente, dovremmo decidere attivamente se vogliamo sfruttare il debito tecnico o se vogliamo evitarlo. Proprio come per il debito finanziario, non vogliamo ritrovarci un giorno con costi imprevisti!
Una definizione semplificata di debito tecnico
Il debito tecnico (a volte chiamato anche debito di codice in alcuni team), si riferisce al costo implicito del lavoro futuro necessario quando si sceglie una scorciatoia a breve termine invece di un approccio migliore, ma più lungo. È come pagare gli interessi su un prestito: il costo del debito tecnico aumenta col tempo.
Un'analogia che utilizzo è quella della rasatura della barba. Se ho poco tempo e mi faccio una rasatura veloce, probabilmente non sarà mai perfetta e devo tornare successivamente per rifinirla.
Il tempo e lo sforzo necessari per entrambe le rasature—quella iniziale e quella di "pulizia"—saranno totali maggiori rispetto a se avessi fatto una buona rasatura fin dall'inizio.
Ma a volte, quando il tempo è pochissimo, bisogna accontentarsi della rasatura veloce!
Confronto tra debito finanziario e debito tecnico
Per rendere concreto questo concetto, approfondiamo il paragone tra debito finanziario e debito tecnico. In fondo, i product manager devono comprendere sia i concetti di finanza aziendale sia quelli legati al codice!
Pro del debito finanziario: Il debito finanziario consente di avere leva. Prendere denaro in prestito può fornire il capitale necessario per investire in opportunità di crescita. Inoltre, il debito finanziario permette di avere accesso immediato a risorse o asset senza bisogno di pagare subito.
Contro del debito finanziario: Il debito finanziario comporta molti tipi di costi. Gli interessi sul debito finanziario possono accumularsi, riducendo la redditività complessiva. E se non viene gestito correttamente, può portare a instabilità finanziaria.
Inoltre, il debito può ridurre la flessibilità finanziaria e impedirci di percorrere determinate strade in futuro. E il mancato adempimento delle obbligazioni finanziarie può danneggiare la reputazione di un'organizzazione.
Pro del debito tecnico: Il debito tecnico permette uno sviluppo iniziale del prodotto più rapido, aiutando a rispettare scadenze strette o a cogliere opportunità di mercato. E, analogamente alla leva finanziaria, assumersi debito tecnico può ridurre i costi di sviluppo iniziali.
Contro del debito tecnico: Proprio come gli interessi si accumulano sul debito finanziario, il debito tecnico si accumula man mano che nuove funzionalità o cambiamenti vengono costruiti sopra le scorciatoie esistenti, rendendo lo sviluppo futuro più complesso e costoso. Inoltre, il debito tecnico spesso significa codice di qualità inferiore, con costi di manutenzione più alti nel tempo.
Il debito tecnico può ostacolare la capacità di un prodotto di adattarsi a condizioni di mercato in evoluzione o di integrare nuove funzionalità. E se non viene affrontato, può portare a guasti di sistema, vulnerabilità di sicurezza o problemi di prestazioni, mettendo a rischio la validità stessa del prodotto.
Cosa significa questo per noi? Beh, sia per il debito finanziario che per quello tecnico, l'obiettivo non è evitarli del tutto. Piuttosto, la chiave sta in una gestione prudente.
Pur essendo strategico mantenere un certo livello di debito per la crescita, dobbiamo monitorare e gestire con attenzione il debito per minimizzare le conseguenze negative a lungo termine.
Esempi di debito tecnico
Nell’ambito dell’ingegneria del software, i team di sviluppo si imbattono regolarmente nel debito tecnico. Vediamo insieme alcuni degli esempi più comuni.
Codice legacy
Alcuni team possono utilizzare codice legacy obsoleto per rilasciare rapidamente una funzionalità. Questo può fornire funzionalità immediate, ma potrebbe richiedere un significativo refactoring in seguito, soprattutto quando si aggiungono nuove funzionalità. Proprio come un antico manoscritto, il codice legacy è stato tramandato attraverso generazioni di sviluppatori, accumulando il peso della storia.
Sebbene abbia servito egregiamente il suo scopo nella sua epoca, il tempo tende a erodere la sua adattabilità e manutenibilità. Interruzioni e bug in produzione tendono a manifestarsi quando ci affidiamo troppo al codice legacy!
Hardcoding
Hardcoding si riferisce alla pratica di inserire valori o costanti specifici direttamente nel codice invece di utilizzare impostazioni configurabili.
Sebbene questo approccio possa offrire uno sviluppo rapido nel breve termine, spesso porta a complicazioni in futuro. Immagina uno scenario in cui un valore hardcoded, come un percorso file o una soglia di timeout, debba essere cambiato in un ampio codice sorgente. Questo può rapidamente trasformarsi in un compito dispendioso in termini di tempo e soggetto a errori, mettendo a repentaglio la manutenibilità e la flessibilità del software.
Per evitare questa trappola, gli sviluppatori dovrebbero optare per opzioni configurabili, migliorando così l'adattabilità del loro codice.
Duplicazione del Codice
La duplicazione del codice si verifica quando frammenti di codice simili o identici compaiono in più punti all'interno del progetto. All'inizio, può sembrare una scorciatoia conveniente, che fa risparmiare tempo durante lo sviluppo. Tuttavia, con l'evoluzione del software e il cambiamento dei requisiti, mantenere la coerenza e fare aggiornamenti diventa un processo intricato.
La duplicazione del codice non solo aumenta il rischio di introdurre bug, ma moltiplica anche lo sforzo necessario per futuri miglioramenti e correzioni. Il perseguimento della riusabilità del codice e l'eliminazione del codice ridondante sono principi fondamentali per contrastare questo problema.
Mancanza di Documentazione
La documentazione funge da filo conduttore che illumina il percorso per gli sviluppatori presenti e futuri. L'assenza di una documentazione completa equivale a intraprendere un viaggio complesso senza una mappa. Può iniziare con la mancanza di commenti inline che spiegano la logica dietro alcune scelte di codice o aggravarsi fino a guide utente e documentazione dell'architettura di sistema mancanti.
Sebbene la fase iniziale di sviluppo possa procedere agilmente, le conseguenze a lungo termine possono essere gravi. Il debug diventa un'impresa criptica, il trasferimento di conoscenza tra i membri del team diventa difficile e la scalabilità del progetto spesso assomiglia a navigare in un labirinto al buio. Adottare una documentazione accurata è la luce guida che illumina il percorso dello sviluppo software.
Mancanza di Test Automatizzati
L'assenza di test automatizzati è come navigare una barca senza prima controllare che non ci siano falle. I test automatizzati (inclusi test unitari, di integrazione e di regressione) sono i guardiani vigili della qualità e della stabilità del codice.
Quando vengono trascurati, le conseguenze potrebbero non essere immediatamente evidenti. All'inizio, lo sviluppo può progredire rapidamente e il software può sembrare funzionante. Tuttavia, con l'espansione e l'evoluzione del codice sorgente, iniziano a emergere problemi inattesi. I bug di regressione, cioè funzionalità che prima funzionavano e che ora non funzionano più a causa di nuove modifiche, diventano comuni.
Senza test automatizzati a fare da rete di sicurezza, il team di sviluppo deve affidarsi a test manuali, un processo laborioso e soggetto a errori. Adottare i test automatizzati fin dall'inizio assicura un percorso stabile nel mare tempestoso dello sviluppo software.
Qual è il Ruolo del Debito Tecnico nell'Agile?
Ah, lo sviluppo Agile! Le sue metodologie scrum e i principi del manifesto Agile abbracciano il cambiamento e la velocità. Ma dove si colloca il debito tecnico? Dopotutto, il debito tecnico non viene discusso specificamente nei documenti fondanti dell'Agile.
Bene, ecco un'analogia tratta da Star Wars: il Millennium Falcon subiva continue manutenzioni da parte di Han Solo e Chewbacca per restare sempre in forma per le loro imprese. Allo stesso modo, un team Agile di prodotto gestisce il debito tecnico per mantenere la qualità del software e consentire avventure eroiche ai propri clienti!
Come Usare e Gestire il Debito Tecnico
Nei team Agile, si comprende che a volte si può incorrere in un po' di debito tecnico per soddisfare rapidamente esigenze di business. Ricorda, incorrere nel debito tecnico non è sempre un male. Martin Fowler, uno dei pensatori di riferimento nello sviluppo Agile, sottolinea che si tratta di compromessi. Potresti accettare del debito all'inizio del ciclo di vita di un prodotto software per validare un concetto o raggiungere più rapidamente il mercato.
La chiave è gestire il debito tecnico. Il debito tecnico dovrebbe essere documentato nel backlog, prioritizzato e affrontato negli sprint futuri. Perché ciò accada, i product manager devono fare affidamento su una solida gestione dei progetti e devono avere una buona conoscenza della quantità di debito tecnico accumulato fino a quel momento.
Quando il Debito Tecnico è un Problema?
Quando gli stakeholder ignorano il debito tecnico o quando il processo di sviluppo si basa troppo su soluzioni temporanee, è il momento di far scattare l’allarme. Perché?
- È Invisibile: Senza metriche o revisioni regolari del codice, possono emergere vulnerabilità nascoste.
- Impatta l'esperienza utente: Se i problemi sottostanti iniziano ad influire sulla funzionalità, non è solo un problema degli sviluppatori, ma diventa un problema di business.
- Ostacola le nuove funzionalità: I programmatori impantanati in un codice disordinato sono meno produttivi e la creatività diminuisce.
- Non è presente nella roadmap: I team dovrebbero essere consapevoli del debito tecnico e avere una strategia a riguardo. Non esitare a sfruttare webinar esterni e risorse per costruire un piano d’azione.
Come Misurare il Debito Tecnico
Utilizzando strumenti come pratiche DevOps e automazione, i team possono monitorare il proprio codice e tenere sotto controllo il debito tecnico accumulato finora. Di seguito, ho raccolto dodici modi diversi per tracciare il debito tecnico.
Non è necessario usarli tutti! Considera invece questo elenco come un punto di partenza. Scegline uno o due da implementare nel prossimo mese e poi aumenta gradualmente la competenza del tuo team nel monitorare e risolvere il debito tecnico.
1) Analisi Statica del Codice: Strumenti come SonarQube, ESLint o FindBugs possono analizzare automaticamente il codice individuando vari problemi come complessità, code smell e possibili bug. Forniscono metriche quantitative sulla qualità del codice e sul debito tecnico basandosi su regole e soglie predefinite.
2) Copertura del Codice: È possibile valutare quanta parte della base di codice è coperta da test automatici misurando la copertura con strumenti come JaCoCo o Istanbul. Una bassa copertura può indicare una mancanza di test e un potenziale debito tecnico.
3) Revisioni del Codice fra Colleghi: Effettuare revisioni del codice fra pari permette agli sviluppatori di individuare e discutere elementi di debito tecnico. E due cervelli sono meglio di uno—è un ottimo modo per evitare cattive pratiche! I team possono utilizzare checklist o linee guida per valutare la qualità del codice e documentare i problemi riscontrati. Il numero e la gravità dei problemi trovati durante le revisioni rappresentano una misura qualitativa del debito tecnico.
4) Ispezioni Manuali del Codice: Sviluppatori e team possono effettuare ispezioni manuali del codice o walkthrough per identificare parti della base di codice che potrebbero beneficiare di un refactoring. Questo processo prevede spesso la revisione da parte di sviluppatori esperti, che tendono ad avere la miglior percezione del debito di design tecnico.
5) Backlog del Debito Tecnico: Mantenere un product backlog o un elenco degli elementi di debito tecnico individuati è una pratica comune. Ogni elemento del backlog dovrebbe includere una descrizione, una valutazione dell’impatto e una priorità. La dimensione e la priorità degli elementi offrono una misura qualitativa del debito tecnico.
6) Monitoraggio di Bug e Problemi: Analizzare il processo di triage dei bug può rivelare la frequenza e la gravità dei problemi collegati al debito tecnico. Un numero elevato di segnalazioni di bug o ricorrenze frequenti degli stessi problemi può indicare debito tecnico sottostante.
7) Stima e Story Point: Quando si pianificano nuovi lavori o user story, i team di sviluppo possono stimare lo sforzo necessario per affrontare il debito tecnico. Questa stima dello sforzo, spesso in story point nelle metodologie Agile, quantifica il lavoro necessario per risolvere il debito tecnico.
8) Metriche di Complessità del Codice: Metriche come complessità ciclomatica, numero di righe di codice e code churn possono fornire informazioni sulla complessità e la manutenibilità della base di codice. Una complessità elevata e cambiamenti eccessivi possono indicare debito tecnico.
9) Feedback degli Utenti: Il feedback degli utenti e le richieste di supporto possono evidenziare indirettamente il debito tecnico. I frequenti reclami relativi alle prestazioni, all’affidabilità o a comportamenti inattesi del sistema possono segnalare problemi sottostanti da risolvere.
10) Metriche di Test Automatico: Monitorare metriche relative al test automatico, come i tempi di esecuzione dei test, i tassi di fallimento e i test instabili, può aiutare a valutare lo stato della struttura di test e identificare le aree impattate dal debito tecnico.
11) Sondaggi e Interviste: Intervistare e sottoporre sondaggi ai team di sviluppo può fornire spunti qualitativi sul livello percepito di debito tecnico e il suo impatto sulla produttività e sulla qualità del codice. Inoltre, raccogliere feedback dagli stakeholder aiuta a capire dove potrebbe essere necessario intervenire per il rework.
12) Quadrante del debito tecnico: Uno strumento particolarmente utile è il quadrante del debito tecnico introdotto da Martin Fowler. Questo strumento classifica le cause del debito tecnico tra deliberate vs. involontarie e sconsiderate vs. prudenti, aiutando i team a comprendere meglio i trade-off.
Oltre a questi dodici modi per misurare il debito tecnico, non esitare a utilizzare strumenti di product management per aiutarti nella gestione del monitoraggio e della risoluzione del debito tecnico del tuo team!
Estinzione del Debito Tecnico
Abbiamo parlato molto di accumulare debito tecnico, ma non abbiamo ancora affrontato come estinguerlo. Come product manager, è nostra responsabilità guidare i nostri team nel decidere quando ripagare il debito rispetto a quando incorrere in ulteriore debito tecnico.
Ripaghiamo il debito tecnico quando gli ingegneri aggiornano il codice per affrontare elementi di debito tecnico precedentemente identificati. Questo può includere la riprogettazione di funzionalità per renderle più efficienti, l'implementazione di test automatici o la creazione di una documentazione approfondita sul codice.
Uno dei modi migliori per estinguerlo è riservare del tempo in ogni sprint per rafforzare il codice e ridurre il debito. Pensalo come fare pagamenti mensili su un mutuo: più velocemente ripaghiamo il mutuo, meno interessi dovremo pagare complessivamente!
Una buona regola pratica è la regola dell’80/20. Ossia, dedicare circa l’80% del tempo di ogni sprint allo sviluppo di nuove funzionalità, e il 20% alla priorità degli investimenti e miglioramenti tecnici.
Quando pianifichi di estinguere il debito tecnico, valuta di inserirlo nella tua roadmap di prodotto di conseguenza.
Considerazioni Finali sul Debito Tecnico
Per concludere, la gestione del debito tecnico non è solo una questione per gli sviluppatori. I product manager, i team Agile e gli stakeholder aziendali hanno tutti un ruolo.
L’obiettivo finale? Consegnare un prodotto software di alta qualità che risponda agli obiettivi di business senza accumulare debiti insostenibili.
Quindi, che tu stia navigando nei mari profondi dello sviluppo software o stia semplicemente cercando di capire perché il tuo team di sviluppo parla sempre di refactoring, la comprensione e la gestione del debito tecnico è la bussola di cui hai bisogno.
E, che tu sia agli inizi della tua carriera nel prodotto, o che tu sia già un veterano nel product management, quasi sempre trarrai vantaggio dall’approfondire la tua comprensione del gergo tecnico.
Spero che eviterai di commettere lo stesso errore che feci all’inizio della mia carriera: non affidarti solo ai contesti per intuire concetti tecnici sconosciuti!
Al contrario, prenditi il tempo per ricercare, consultare guide esterne come questa e confrontarti con i tuoi ingegneri per arricchire le tue conoscenze.
Per ulteriori approfondimenti e guide sul product management, non dimenticare di iscriverti alla nostra newsletter!
