Guida Scrum · Artefatti e pratiche
Debito tecnico in Scrum: come individuarlo e gestirlo
Il debito tecnico è il costo futuro delle scorciatoie prese oggi: codice scritto in fretta, test mancanti, strumenti obsoleti. Come il debito finanziario, un po' può essere utile, ma se non gestito rallenta ogni Sprint.
Punti chiave
- Il debito tecnico è il costo futuro delle scorciatoie di oggi.
- Rendetelo visibile nel Product Backlog.
- Prevenite nuovo debito con una Definition of Done rigorosa.
Da dove nasce
- Pressione delle scadenze che porta a prendere scorciatoie.
- Una Definition of Done debole.
- Test automatizzati mancanti.
- Librerie e infrastruttura obsolete.
- Conoscenze detenute da una sola persona.
- Requisiti cambiati dopo che la progettazione era già stata realizzata.
Segnali di debito in crescita
- In calo o irregolare velocity.
- Più difetti che sfuggono fino agli utenti.
- Le modifiche semplici richiedono più tempo.
- Developer restii a mettere mano a certe aree.
Gestirlo in Scrum
- Rendetelo visibile: aggiungete al Product Backlog gli elementi di debito con una descrizione chiara del loro costo.
- Rafforzate la Definition of Done così non si crea nuovo debito.
- Riservate capacità in ogni Sprint, ad esempio una quota del lavoro del team, per ridurre il debito.
- Fate refactoring in modo continuo come parte del lavoro normale.
- Discutetene durante la Sprint Review così gli stakeholder comprendono il compromesso.
Spiegare il debito agli stakeholder
Presentate il debito in termini di business: "Quest'area richiede il triplo del tempo per essere modificata e causa la maggior parte dei nostri incidenti in produzione. Investire due Sprint accelererebbe tutto il lavoro futuro qui."
Modelli gratuiti per questo argomento
Domande frequenti
Chi decide quando ripagare il debito tecnico?
Il Product Owner ordina il backlog, informato dai Developer che spiegano il costo del debito.
Tutto il debito tecnico è negativo?
No. Un debito deliberato e a breve termine per imparare rapidamente può essere una scelta saggia, purché venga tracciato e ripagato.
Che cos'è il debito tecnico?
Il costo futuro della scelta di una soluzione rapida o facile oggi invece di una migliore. Si manifesta con modifiche più lente, più difetti e rilasci più rischiosi.
Chi ha coniato il termine debito tecnico?
Ward Cunningham introdusse la metafora del debito nel 1992 per spiegare agli stakeholder di business perché il refactoring era necessario.
Come si misura il debito tecnico?
Non esiste un'unica misura. I team usano segnali come il tempo necessario per apportare modifiche semplici, i tassi di difetti, gli strumenti di analisi del codice e la dimensione degli elementi di debito nel Product Backlog.
Il debito tecnico va inserito nel Product Backlog?
Sì. Rendere visibile il debito come elementi del Product Backlog permette al Product Owner di soppesarlo rispetto alle nuove funzionalità.
Quanto tempo dovrebbe dedicare un team Scrum al debito tecnico?
Non esiste una regola. Molti team riservano una parte della capacità di ogni Sprint, adeguandola in base a quanto il debito li sta rallentando.
In che modo la Definition of Done previene il debito tecnico?
Una Definition of Done rigorosa, che includa test, code review e documentazione, impedisce che le scorciatoie entrino a far parte dell'Increment.
In che modo il refactoring riduce il debito tecnico?
Il refactoring migliora la struttura interna del codice senza modificarne il comportamento. Farlo regolarmente impedisce l'accumulo di debito tecnico.
Il debito tecnico è solo un problema del software?
Il termine nasce nel software, ma un debito simile esiste anche altrove, come processi obsoleti, conoscenze non documentate o soluzioni rapide in contenuti e dati.
Come si convincono gli stakeholder a ripagare il debito tecnico?
Spiegatelo in termini di business, ad esempio quanto rallenta le modifiche o quanti incidenti causa, e mostrate il beneficio atteso dalla sua correzione durante la Sprint Review.