Come definire il Technical Debt?

E’ la differenza che rileviamo tra ciò che è stato effettivamente realizzato e ciò che è idealmente necessario per considerare conclusa un’attività.

Viene percepito come “debito” proprio perché si tratta di una mancanza rispetto a quanto atteso. Inoltre, come molti debiti, se lasciato indietro può dare origine a interessi che, accumulandosi, potrebbero compromettere il progetto generale.

Facciamo un esempio nell’abito dello sviluppo software con la classica funzionalità di “procedura di log in”. Immaginiamo che la User Story prenda in considerazione la possibilità di log in nativa, tramite Facebook e Twitter. Ipotizziamo invece che nell’arco della iterazione venga sviluppata solo la versione nativa. Il nostro debito tecnico consiste quindi nell’assenza delle altre due metodologie di log in. Se non correttamente recuperato, questo debito potrebbe portare a problemi nelle successive User Story dove, magari, è richiesta la connessione con un social network per poter usufruire di determinate sezioni dell’applicazione.

Sono disponibili diversi metodi per recuperare il debito tecnico, ne parlerò in dettaglio in un prossimo post. Vorrei comunque anticipare uno spunto più Agile: il technical debt potrebbe essere il punto di partenza per la gestione del continuos improvement!