Ti sarà già capitato almeno una volta di accorgerti ad un certo punto dello sviluppo di un software che quest’ultimo presentava alcune problematiche a livello di codice. Probabilmente ti sarai anche accorto che a quel punto le azioni per rimediare ti hanno fatto sprecare tempo e risorse.
In terminologia Agile, questo fenomeno ha un nome: debito tecnico.
L’articolo di oggi vuole essere una guida per spiegarti cos’è questo fenomeno, quali sono le sue cause e cosa puoi fare per limitarne la comparsa.
In questo articolo potrai trovare:
- Debito tecnico, cos’è
- Debito tecnico, origine del termine
- 4 tipologie di debito tecnico
- Quali sono le cause del debito tecnico?
- Come il debito tecnico impatta sul tuo Business
- Come limitare la formazione del debito tecnico
Debito tecnico, cos’è
Il debito tecnico è il risultato di un processo non adatto dello sviluppo di un software.
Descrive una carenza nella progettazione di un prodotto che dovrà essere colmata successivamente per permettere un funzionamento armonico dello stesso o delle sue dipendenze.
Nel pratico, il debito tecnico riguarda tutti quegli errori, sia intenzionali che non, e quelle carenze nel codice che derivano da una serie di problematiche a monte (come la scarsa comunicazione all’interno del team di sviluppo o il rilascio frettoloso di prodotti). In questo scenario, il debito è portato a crescere finché non si esegue un’operazione di refactoring, quell’attività di miglioramento della struttura interna o del funzionamento di un codice o componente senza modificarne il comportamento esterno.
Quindi, il debito tecnico è un concetto strettamente collegato alla metodologia Agile. Se vuoi saperne di più riguardo al mindset Agile, in questo articolo ne parliamo esaustivamente.
Ma torniamo a noi.
Debito tecnico, origine del termine
Il concetto è legato al mindest Agile, non a caso infatti la definizione è stata coniata da Ward Cunningham, uno dei creatori del manifesto Agile.
Per spiegare il concetto, ha preso come riferimento il campo semantico finanziario: Cunningham spiega che se prendiamo in prestito risorse finanziare, prima o poi dovremo ripagare questo debito con gli interessi. Analogamente, se sviluppiamo un software frettolosamente (risparmiando sulle risorse utilizzate) prima o poi dovremo fare i conti con tutte le problematiche che emergono, “pagando” anche un effort aggiuntivo.
Con questa metafora voleva fare leva sul concetto di refactoring, spronando i team a correggere il codice frequentemente per evitare il debito.
4 tipologie di debito tecnico
Cunningham, quando ha coniato il termine, ha disegnato anche 4 tipologie diverse in base a due categorie dicotomiche, illustrandole in un quadrante:
La prima dicotomia si basa sulla contrapposizione tra debito tecnico “Reckless” (avventato) e “Prudent” (prudente). La seconda categoria, invece, è tra debito “Deliberate” (volontario) e “Inadvertent” (involontario).
Volontario imprudente: si verifica quando la mancanza di tempo/ di budget porta a delle azioni non ottimali o quando viene trascurata la fase di refactoring volontariamente;
Volontario prudente: in questo caso il team è consapevole che dando priorità alla consegna rapida del software dovrà spendere energie nel refactoring per gestire le conseguenze;
Involontario imprudente: si verifica quando mancano le qualifiche adeguate, quando la documentazione è insufficiente, quando si presenta un overengineering ecc. Quindi quando in maniera imprudente il team non investe energie per svolgere un lavoro efficiente;
Involontario prudente: in questo caso il debito tecnico si verifica involontariamente ma il team è consapevole che può recuperare svolgendo refactoring costante imparando dai propri errori.
Quali sono le cause del debito tecnico?
È bene sapere che il debito si forma anche quando si lavora seguendo le “regole”. Anche Cunningham lo diceva: il debito tecnico è la conseguenza naturale di scrivere codice su qualcosa di cui non si hanno le conoscenze adeguate. Non riguarda solo il codice scritto in modo scadente.
Se vogliamo individuare dei “colpevoli” potremmo dire che il tutto è causato da:
- Design sbagliato (“Wrong Design”): quando la soluzione trovata non si adatta ai requisiti richiesti dal business. Può verificarsi quando il team di sviluppo ha scarse capacità nell’ambito oppure quando non ha compreso in modo chiaro cosa bisogna fare.
- Evoluzione rapida (“Rapid evolution”): quando il panorama cambia velocemente e non si riesce a stare al passo con questa evoluzione. Al giorno d’oggi gli scenari cambiano velocemente, il rischio che il lavoro che si sta svolgendo diventi obsoleto è molto alto e frequente. Per questa ragione è molto importante l’attività di refactoring.
Quindi, il debito tecnico è sostanzialmente causato da una mancanza di comprensione, un gap tra le esigenze di business e il software sviluppato.
Come il debito tecnico impatta sul tuo business
Il debito tecnico può avere dei risvolti finanziari negativi per il tuo business in diversi modi:
- Calo nelle vendite: un cliente insoddisfatto a causa di un software mal funzionante può portare la perdita di quello e di altri clienti a causa di un passaparola negativo;
- Aumento dei costi di manutenzione: i clienti che decidono di restare richiederanno maggiori attenzioni;
- Aumento del carico di lavoro: che come conseguenza vede un aumento dei costi della manodopera, perché per gestire un debito tecnico si richiedono più developer per rimediare al software “difettoso”;
- Minore produttività: gli sviluppatori saranno impegnati con la sistemazione degli errori e non avranno tempo a disposizione per occuparsi dello sviluppo di feature che possano aggiungere valore al software. Questo ridurrà la produttività e ostacolerà gli obiettivi del business.
Ma non preoccuparti, c’è sempre un modo per recuperare e per limitarne il rischio di comparsa.
Vediamo insieme come:
Come limitare la formazione di debito tecnico
Per spiegarti come fare, dobbiamo parlare dei concetti chiave per la creazione e per lo sviluppo efficiente di un software:
- Scrivere un codice di qualità: sembrerà scontato ma non lo è. Per limitare la comparsa del debito bisogna innanzitutto investire tempo per definire un flusso di lavoro logico e sostenibile per i developer, con la definizione di metodo chiaro per favorire la scrittura di un codice di qualità;
- Definire i ruoli e le responsabilità in modo chiaro: questo per rendere il processo di lavoro lineare dove ogni parte coinvolta ha il proprio compito e i propri obiettivi;
- Utilizzare strumenti sempre aggiornati: questo serve per garantire qualità al software;
- Prevedere una formazione tecnica costante: è importante mantenere tutto il team di lavoro aggiornato sulle tecnologie attuali in modo da garantire un software il più all’avanguardia possibile;
- Chiedere al cliente obiettivi chiari: questo è molto importante per evitare fraintendimenti e il rischio di dover mettere mano sul software una volta che entra in fase di rilascio e produzione;
- Pensare in modo strategico: è importante saper guardare al futuro e avere uno sguardo previdente riguardo alle possibili evoluzioni del software.
To sum up
Al termine di questo articolo, dovremmo essere riusciti a trasmetterti cosa è il debito tecnico, le sue possibili cause e cosa fare per mitigare la sua comparsa.
Abbiamo citato diverse volte il termine Agile, se vuoi saperne di più a riguardo in questo articolo cerchiamo di spiegartelo nel modo più chiaro possibile.