Debito Tecnico: cos’è, come si evita

Una variabile in ogni progetto IT che può portare a problemi strutturali cronici.

Cosa è il Debito Tecnico e come possiamo mitigarlo?

Il Debito Tecnico descrive un disavanzo in termini di funzioni, architettura o integrazione, che successivamente dovrà essere colmato per permettere un funzionamento omogeneo del prodotto stesso o delle sue dipendenze. È prevalentemente causato dal perseguire uno sviluppo rapido rispetto al perseguire una procedura di sviluppo corretta. Il Debito Tecnico è quindi il risultante di un processo di sviluppo software non ottimale.

Il concetto di Debito Tecnico è strettamente correlato al mindset Agile. Non ci stupiamo se la definizione stessa è stata coniata per la prima volta da Ward Cunningham, uno dei creatori dell’Agile Manifesto (qui un po’ di storia) e del concetto e applicazione Wiki. Suggerisco questo video dove Ward spiega proprio la storia del termine.

“Con il denaro preso in prestito, puoi fare qualcosa prima di quanto potresti fare altrimenti. Pensavo che prendere in prestito del denaro fosse una buona idea, così come pensavo che affrettare l’uscita di un software per fare un po’ di esperienza fosse buono. Ma che, naturalmente, alla fine sarei tornato indietro e man mano che imparavo cose su quel software avrei ripagato quel prestito rifacendo il programma per riflettere la mia esperienza come l’avevi acquisita”.

Ward ha brillantemente colto un’analogia tra il prendere a prestito denaro e il prendere a prestito tempo e risorse nei processi di sviluppo software.

Così se prendiamo a prestito risorse finanziarie, dovremmo poi ripianare questo debito, corrispondendo un interesse aggiuntivo. Se sviluppiamo un applicativo in fretta, risparmiando su documentazione, su test, su processi di QA, dovremmo poi in futuro saldare questo debito con un extra effort.

Un esempio

Il concetto di Debito Tecnico è quindi intuitivamente abbastanza semplice: devo fare qualcosa rapidamente o con risorse scarse. Lo porto a termine comunque, ottenendo l’output desiderato. Ma so che in futuro dovendo tornare su quel tema, dovrò recuperare quel tempo e quelle risorse, con gli interessi.

Una metafora per chiarire definitivamente: devo prendere un aereo tra 1 ora. So che impiegherei 2 ore per fare la valigia. Decido allora di preparare uno zaino alla bell’e meglio e partire.

Risultato: prendo l’aereo e mi imbarco con successo. Ma a destinazione dovrò sicuramente reintegrare il mio bagaglio con scorte prese in loco, perdendo ben più del tempo che avrei dedicato fermandomi a fare le valigie alla partenza, pur rischiando di perdere il volo.

Tipologie di Debito Tecnico

A livello teorico il Debito Tecnico si divide in quattro quadranti, di cui generalmente si pone enfasi maggiormente negativa sui quadranti “Reckless” a dispetto dei quadranti “Prudent”, considerati spesso insiti nella stessa creazione di un prodotto tecnologico con risorse finite.

L’elaborazione che forniamo sotto è stata ispirata da uno studio di Martin Fowler, un altro luminare dell’Agile Manifesto e uno tra i massimi esperti di programmazione a oggetti.

Il Debito Tecnico è un male?

Giusta domanda. È utile notare che il Debito Tecnico non è considerato come qualcosa da evitare sempre e a ogni costo.

Il Debito Tecnico non è qualcosa di negativo a priori, così come non lo è prendere denaro in prestito (questo assunto è stato anche ben chiarito dall’Agile Alliance).

È importante però ricordare che il debito va saldato prima o poi e dobbiamo essere pronti a quell’evenienza. Insomma, d’accordo generare debito per centrare un obiettivo importante, purché non implichi divenire debitori cronici.

Esistono anche pareri più radicali addirittura contrari al concetto stesso di Debito Tecnico, che personalmente trovo ragionevoli. Un’eccessiva teorizzazione di un fenomeno pratico rischia di diventare a sua volta una sovrastruttura, come in parte è avvenuto con il mindset Agile. Se ti interessa scoprire di più su questo approccio, qui una bella lettura.

Genesi del Debito Tecnico

La genesi del Debito Tecnico può avere diversa natura.

• Vincoli temporali troppo stringenti: il go-to-market implica una delivery dell’applicativo a discapito dei necessari test di qualità, meccanismi di controllo, processi di review del codice.
• Processi di sviluppo mancanti: il prodotto viene sviluppato da una bozza di requisiti incompleti, soggetta a continui cambiamenti, che obbliga a frequenti cambi di direzione.
• Risorse scarse: troppi progetti in parallelo, poche risorse disponibili, mancanza di strumenti adeguati.
• Sovrastrutture e inefficienze: codice troppo complesso, illogico, non commentato, incomprensibile da altri che non ne siano artefici.
• Black Box: si interviene su prodotti e applicativi acquistati dall’esterno, sui quali è oneroso o molto complesso mettere mano in modo proficuo.
• Competenze e professionalità: il team di sviluppo non ha le competenze adeguate per lavorare sul progetto in oggetto, generando materiale sub-ottimale.
• Debito Tecnico: si, esatto. Così come una persona indebitata avrà più facilità a contrarre debiti rispetto a una in una situazione economica florida, un contesto di Debito Tecnico latente generare facilmente un aggravarsi della situazione.

Si intuisce che la lista potrebbe protrarsi fino a raggiungere una discreta lunghezza. Possiamo riassumere dicendo che le cause del Debito Tecnico siano:

• Risorse inadeguate
• Competenze inadeguate
• Processi inadeguati

Come mitigare la formazione di Debito Tecnico

Se parliamo della mitigazione del Debito Tecnico dobbiamo addentrarci in quelli che sono i paradigmi di un processo di sviluppo software.

• Incentiviamo la scrittura di codice di qualità con definizione di variabili parlanti, suddivisioni in funzioni e classi, metodi chiari, e un flusso logico che lo renda digeribile a sviluppatori, programmatori e tester esterni.
• Definiamo responsabilità chiare all’interno del progetto e del tavolo di sviluppo, affinché non sia una corsa disordinata verso la meta ma una marcia precisa dove ciascuno risponde di precisi compiti e ne garantisce i risultati in modo comprovabile.
• Utilizziamo strumenti aggiornati per il monitoraggio della qualità, refactoring, e introduzione di nuove funzionalità.
• Promuoviamo formazione tecnica costante e sempre aggiornata da parte di tutto il team di lavoro, sia sviluppatori ma anche PM, tester, product managers, ecc.
• Richiediamo requisiti chiari e univoci evitando le frasi killer “lo davo per scontato”, “poi ci penso”, “lo risolviamo in produzione”, “non è necessario fare test” ecc. Un problema di valore 1 in fase di sviluppo acquista un moltiplicatore x10 o più in fase di rilascio e produzione.
• Evitiamo un approccio a toppe ossia non costruiamo su qualcosa di instabile o posticcio, ma prendiamoci del tempo per appianare il pregresso completamente prima di aggiungere nuove funzionalità.
• Pensiamo in modo strategico e non tattico ossia guardiamo al futuro e alle evoluzioni possibili dell’applicativo, sapendo che sopravvivrà probabilmente alla contingenza che stiamo affrontando.

Gestire il Debito Tecnico per non sviluppatori

Tutto facile (quasi) quando facciamo parte del team di sviluppo e abbiamo voce in capitolo e gli strumenti per analizzare a fondo l’andamento di un progetto. Ma nella realtà, nelle aziende, ci troviamo spesso nel contesto in cui un’entità esterna (agenzia, consulenti, provider, vendor) si cura dello sviluppo, consegna il prodotto, e all’imprenditore non resta che incrociare le dita.

Ecco quello che sembra un decente piano di azione:

• Raggiungi il livello di competenze minime: dialogare con un team di sviluppo può essere intimidatorio le prime volte. Assicurati di avere un bagaglio tecnico che ti permetta di esprimerti e comprendere almeno un ad un livello base.
• Chiedi di essere allineato periodicamente: non aspettare che il processo di sviluppo sia fatto e finito per metterci le mani. Chiedi di essere coinvolto nel processo di test, nelle iterazioni, nelle fasi intermedie. Anche ogni settimana se ti è possibile, o almeno ogni quindici giorni.
• Chiedi un manuale utente o una documentazione: oggi lavori con un team, domani potresti lavorare con tutt’altre persone. E non vorrai dover spiegare a parole le funzionalità del tuo applicativo o consegnare al team una pila di email stampate.
• Crea un team che possa darti supporto: anche i migliori non possono fare tutto da soli. Crea all’interno della tua azienda o del tuo team delle figure tecniche che possano seguire da vicino le fasi di sviluppo e possano esaminare con spirito critico o per lo meno seguire il lavoro degli sviluppatori.

Il Debito Tecnico nella vita reale

Nella nostra vita e nei ruoli più diversi ci siamo costantemente trovati a fronteggiare situazioni dove il Debito Tecnico era stato trascurato per anni. Un effetto Jenga dove apportare la più piccola modifica richiedeva revisionare enormi porzioni di codice o ricostruire a ritroso un intero applicativo.

Possiamo proprio dire, Debito Tecnico, se lo conosci, lo eviti :)

Letture e approfondimenti

L’argomento, sia per via della sua genesi in capo a menti luminari dello sviluppo del software, sia per la sua esaustiva trattazione nel corso degli anni, è vastissimo.

Per approfondire, ecco la nostra lista di lettura consigliata:

• Le basi – il Debito Tecnico spiegato con la riparazione di un tetto (Scrum.org).
• Il paper originale del 1992 (WyCash).
• Uno dei tanti articoli di Martin Fowler sul tema (Fowler).
• TD & Scrum (Medium).
• La bella definizione di Wiki inglese (Wikipedia).
• Un case study molto puntuale (ResearchGate).

Scarica l’ebook gratuito “La guida definitiva alla comprensione del debito tecnico”

E per concludere, ti consiglio la lettura della guida esclusiva prodotta da Aziona, “La guida definitiva alla comprensione del debito tecnico”.

Oltre 40 pagine di contenuti originali, riferimenti, approfondimenti, per comprendere genesi, rimedi, soluzioni e significato del debito tecnico.