Debito Tecnico in Scrum: Come Gestirlo Senza Bloccare la Velocity

In questo articolo:

• La tensione tra debito tecnico e velocity in Scrum
• Backlog del debito tecnico: come strutturarlo
• Sprint planning con il debito tecnico
• La regola del 20% e altri modelli di allocazione
• Quando fermare le funzionalità e concentrarsi sul debito
• Conclusione

La tensione tra debito tecnico e velocity in Scrum

Il debito tecnico in Scrum crea una tensione specifica. Il framework Scrum premia la consegna di valore ogni sprint. La remediation del debito tecnico, tuttavia, spesso non produce output di funzionalità immediatamente visibile. Riduce la frizione futura piuttosto che aggiungere capacità presente. Questo la rende strutturalmente svantaggiata in qualsiasi conversazione di prioritizzazione in cui prodotto e engineering competono per la capacità degli sprint.

Il risultato è un pattern che la maggior parte dei responsabili tecnici riconosce: il debito si accumula mentre la velocity sembra stabile, fino a quando non viene superata una soglia e la velocity crolla. Il crollo è visibile a tutti. L’accumulo lento che lo ha causato era invisibile. Quando il team lo affronta in modo reattivo, il costo di remediation è da tre a cinque volte quello che sarebbe stato se affrontato in modo incrementale.

Gestire il debito tecnico in Scrum non richiede di abbandonare la velocity come metrica o di depriorizzare le funzionalità a tempo indeterminato. Richiede un approccio strutturato a come il lavoro sul debito viene rappresentato, stimato, prioritizzato e revisionato insieme al lavoro sulle funzionalità.

Backlog del debito tecnico: come strutturarlo

Un backlog del debito tecnico non è lo stesso di un backlog tecnico generico. La distinzione è importante. Un backlog del debito tecnico contiene lavoro necessario per mantenere o migliorare la salute del sistema esistente.

Ogni item nel backlog del debito tecnico dovrebbe avere quattro campi. Primo, una descrizione del problema: cosa sta facendo il codice che non dovrebbe, o cosa non riesce a fare che dovrebbe? Secondo, una valutazione dell’impatto: quali risultati di business sta influenzando questo debito e di quanto? Terzo, una stima di remediation: quanti story point o ore ci vorrebbero per affrontarlo? Quarto, un punteggio di priorità: una combinazione di impatto e urgenza.

Il punteggio di priorità collega il debito ai risultati di delivery. Il debito che causa tre incidenti al mese ha priorità più alta del debito che rende semplicemente il codice difficile da leggere. Il debito in un modulo programmato per un’importante aggiunta di funzionalità nel prossimo trimestre ha priorità più alta del debito in un modulo stabile e raramente modificato.

Sprint planning con il debito tecnico

Il modo più affidabile per includere il debito tecnico nello sprint planning è allocare una percentuale fissa della capacità dello sprint prima che la sessione di planning inizi. Ciò impedisce alla conversazione di planning di depriorizzare sempre il debito a favore delle funzionalità.

La percentuale dovrebbe riflettere il livello attuale del debito e il contesto di business. Un team in sviluppo attivo di funzionalità con metriche sane potrebbe allocare dal 10% al 15%. Un team con un rapporto di debito tecnico superiore al 10% e metriche di delivery in declino dovrebbe allocare dal 25% al 30%.

Durante lo sprint planning, gli item di debito dovrebbero essere presentati con lo stesso livello di contesto degli item di funzionalità. L’impatto sul business dovrebbe essere esplicito. “Refactoring del modulo di autenticazione” è un item di sprint scadente. “Ridurre la complessità del modulo di autenticazione per bloccare il bug di timeout della sessione settimanale e sbloccare la funzionalità SSO per il Q2” è un item di sprint che si collega ai risultati.

La regola del 20% e altri modelli di allocazione

Il modello di allocazione del 20% è l’approccio più citato: riservare il 20% della capacità degli sprint per il lavoro sul debito tecnico e sulla qualità del codice. È un buon punto di partenza ma non una regola universale.

L’allocazione corretta dipende da tre variabili. Primo, il livello attuale del debito: un codebase fortemente indebitato ha bisogno di più del 20% per fare progressi significativi. Secondo, il tasso di crescita del nuovo debito: se il team sta accumulando nuovo debito con la stessa velocità con cui ne affronta uno vecchio, l’allocazione è insufficiente. Terzo, il contesto di business.

Un approccio migliore rispetto a una percentuale fissa è un budget di debito. All’inizio di ogni trimestre, il team concorda un budget di debito: il totale degli story point che dedicherà al lavoro sul debito nel trimestre. Questo budget viene impostato in base al livello attuale del debito, alla tendenza e alle priorità di business per quel trimestre.

Il budget di debito crea responsabilità esplicita. Alla fine del trimestre, il team verifica se il budget è stato speso, cosa è stato realizzato e se le metriche pertinenti sono migliorate.

Quando fermare le funzionalità e concentrarsi sul debito

Ci sono tre condizioni che giustificano la pausa dello sviluppo di funzionalità per concentrarsi sulla remediation del debito.

Prima: quando il tasso di fallimento dei cambiamenti supera il 20% per tre sprint consecutivi. A quel punto, il team sta spendendo più tempo a correggere deployment rotti che a consegnare funzionalità.

Seconda: quando un modulo critico raggiunge una complessità ciclomatica superiore a 25 e sta bloccando un item chiave della roadmap. In questo caso, la remediation del debito è prerequisito al lavoro sulle funzionalità.

Terza: quando il tempo di onboarding per i nuovi ingegneri supera le quattro settimane e il team ha piani di crescita. Se il codebase è così complesso che i nuovi membri del team non riescono a contribuire per un mese, l’accumulo di quel costo nell’arco di un anno di assunzioni supera qualsiasi lavoro sulle funzionalità che avrebbe potuto essere fatto nel frattempo.

In tutti e tre i casi, la decisione di sospendere le funzionalità non è una preferenza tecnica. È una decisione di business che dovrebbe essere presa dal responsabile tecnico con una spiegazione chiara agli stakeholder.

Il nostro processo di tech debt solution include una valutazione rapida che può identificare se una di queste condizioni è presente.

Conclusione

Il debito tecnico in Scrum è gestibile con la struttura giusta. Un backlog dedicato del debito tecnico con item prioritizzati e collegati all’impatto di business, un’allocazione fissa di capacità rivista trimestralmente e criteri chiari su quando escalare danno ai team di engineering gli strumenti per affrontare il debito senza sacrificare la delivery.

L’alternativa, trattare il debito come lavoro opzionale che viene rimandato quando c’è capacità libera, produce il pattern di crollo della velocity che i responsabili tecnici conoscono bene dall’esperienza.

Eden Technologies ha supportato oltre 200 team di engineering nell’integrare la gestione del debito nel loro processo di delivery.

Hai un codebase con questi problemi? Parliamo del tuo sistema