Il debito tecnico dove nasce
Il debito tecnico è una metafora che è stata utilizzata per la prima volta da Ward Cunningham, uno degli autori dell’Agile Manifesto, per spiegare ai non tecnici l’importanza di fare refactoring, ovvero la riorganizzazione del codice per mantenerlo semplice, ordinato, e predisposto alle successive modifiche, senza cambiare il comportamento stesso del codice.
Il termine, dato la sua semplicità, riesce a spiegare in maniera intuitiva tramite un’analogia ad un concetto ben noto come quello del debito, quindi da subito fa immaginare ad un qualcosa che, se non restituito in tempo, può accumularsi e dare una conseguenza negativa.
Analogamente al termine economico, in realtà il debito tecnico non ha un’accezione negativa, infatti può anche essere creato volontariamente, come quando si chiede un finanziamento per ottenere subito un bene.
Il caso in cui si accetta deliberatamente di avere il debito tecnico è per esigenze esterne allo sviluppo, per la necessità di business di andare sul mercato il più velocemente possibile, oppure per tagliare il budget sullo sviluppo. In questo caso viene richiesto esplicitamente al team di sviluppo di concentrarsi sull’implementazione delle funzionalità richieste, a discapito di un codice flessibile che possa far fronte alle future esigenze.
Essendo un atto volontario, gli stakeholder devono essere coscienti delle conseguenze, ed il team di sviluppo segnare le parti di codice che hanno bisogno di refactoring, per poter ripagare il debito non appena sia possibile. Talvolta può anche capitare che il debito non venga mai restituita, e l’effort ricadrà direttamente sulla successiva modifica che il progetto incontrerà.
Molto spesso il debito tecnico si genera involontariamente. In questo caso è dovuto a discrepanza tra le funzionalità prodotte e quelle delle aspettative del committente.
Il design di un prodotto digitale è un processo complesso, e lo è ancor di più condividere un’idea in maniera concreta al di fuori della propria mente. Dietro alla semplicità dei siti e delle app che utilizziamo tutti i giorni c’è un’analisi, uno studio ed una profonda comprensione del prodotto, che deriva da una lunga sequenza di ragionamenti e considerazioni. Spesso capita che l’idea iniziale sia prematura e che man mano che prende forma il prodotto si evolvi e che si trasformi.
L’ingegneria del software ha molte analogie con le altre ingegnerie, fa uso di buone pratiche comuni e fattorizza i problemi ricorrenti con le soluzioni ottimali finora scoperte, ma a differenza delle altre il prodotto è virtuale, ed è questa peculiarità che permette e necessita un approccio che tiene conto del cambiamento durante il ciclo di vita del prodotto, che può essere un continuo mutamento.
Per questo motivo il metodo di sviluppo negli anni è passato da un approccio a cascata, nel quale le varie fasi di analisi, progettazione, sviluppo e test avvengono in un unico flusso sequenziale, ad un approccio ciclico, iterativo e incrementale, in cui le fasi vengono svolte ripetutamente a produrre parti del progetto isolati e funzionanti.
Questa metodologia dà anche la possibilità di uno scambio più frequente con gli stakeholder, e permette ad ogni iterazione di validare il prodotto e di correggere il tiro qualora ci fossero discrepanze o criticità emerse. Pertanto è fondamentale che ad ogni iterazione ci sia un momento di scambio attivo con tutti gli stakeholder, per poter fare il punto della situazione e verificare che la direzione che sta prendendo il prodotto sia quella giusta.
Cos’è quindi il debito tecnico?
Il debito tecnico è quindi un termine che indica la quantità di effort necessaria per rendere il codice pronto ai cambiamenti, ed aumenta con il crescere della complessità del software. La complessità del software dipende dalla complessità del prodotto, dalle sue funzionalità e dalle sue logiche di business, ma anche dall’organizzazione del software.
Sulle funzionalità bisogna limare il prodotto fino ad ottenere un insieme minimo che possa essere l’essenziale di valore che si vuole offrire agli utenti, mentre il codice va strutturato in modo tale da essere facilmente comprensibile, ma soprattutto le specifiche devono essere chiare affinché le scelte progettuali possano essere le più adatte per i problemi che andrà ad affrontare. Un’architettura sbagliata può portare anche al rifacimento dell’intero progetto, con un debito tecnico tale da non convenire più modificare quello che si è realizzato fino a quel momento.
Per mantenere basso il debito tecnico è importante che venga dedicato il giusto tempo di manutenzione affinché il codice sia predisposto al cambiamento, ma soprattutto che le specifiche siano chiare a tutti, sia agli sviluppatori che agli stakeholder, e quindi un coinvolgimento attivo durante tutte le fasi del progetto, di modo che ogni dettaglio possa essere implementato e corretto al più presto ed arrivare realizzare un prodotto di qualità che risponde alle esigenze e alle aspettative dei committenti.
Ultimi progetti
