Retrospettiva sul debito tecnico

Individua, ordina e pianifica la riduzione del debito tecnico

Provi questa esibizione dal vivo in chiave retrospettiva

Fonti del debito

Quali aree del codice hanno accumulato debito tecnico?

Il modulo di autenticazione utenti è troppo complesso e difficile da mantenere per via dei tanti hack e workaround aggiunti nel tempo.
Abbiamo parecchio codice duplicato tra componenti diversi che andrebbe rifattorizzato in utility condivise.
Molti dei nostri modelli dati principali sono fortemente accoppiati, quindi estendere o modificare le funzionalità rischia di causare regressioni.
Impatto e rischi

Che effetto ha questo debito tecnico sul team e sul prodotto?

Inserire nuovi sviluppatori è difficilissimo per la complessità e la mancanza di documentazione in alcune aree.
Passiamo il tempo a spegnere incendi e non riusciamo a consegnare nuove funzionalità a un ritmo ragionevole per l'instabilità causata dal debito.
Il nostro processo di deploy è fragile e soggetto a errori, con frequenti problemi e interruzioni in produzione.
Prioritizzazione

Da quali aree di debito dovremmo partire?

Dovremmo partire dal modulo di autenticazione, visto che è una dipendenza centrale che tocca diverse parti dell'applicazione.
Aumentare la copertura di test sui componenti più instabili darebbe una base solida per i refactoring futuri.
Aggiornare il frontend all'ultima versione di React dovrebbe essere una priorità assoluta, così da sfruttare i miglioramenti di prestazioni e le nuove funzionalità.
Piano d'azione

Come possiamo affrontare in modo sistematico il debito prioritario?

Dedicheremo il 20% di ogni sprint alle voci di debito ad alta priorità, partendo dal refactoring del modulo di autenticazione.
Una settimana sì e una no avremo una giornata dedicata al 'pagamento della rata del debito', con miglioramenti graduali in base alle priorità.
Per il prossimo trimestre uno sviluppatore senior si dedicherà a tempo pieno a guidare la riduzione del debito tecnico.

Che cos'è la retrospettiva sul debito tecnico?

La retrospettiva sul debito tecnico è una sessione mirata in cui il team mappa il debito presente nel codice o nel sistema, si mette d'accordo su quanto sta costando e decide da cosa partire per ripagarlo. Alla fine si esce con un piano che ha responsabili e scadenze. Il debito tecnico è l'insieme di scorciatoie e soluzioni non ottimali che si accumulano in un codebase. In parte nasce dalla scelta di privilegiare la consegna a breve termine rispetto alla qualità a lungo termine, in parte da lacune di conoscenza e in parte da refactoring rimandati di continuo. Se lo si ignora, ogni modifica diventa più lenta e più rischiosa. La board ha quattro colonne. In Fonti del debito le persone indicano le aree problematiche specifiche: moduli aggrovigliati, codice duplicato, test mancanti, framework obsoleti. Impatto e rischi raccoglie gli effetti del debito su consegne, qualità, inserimento dei nuovi arrivati e morale. Prioritizzazione ordina le voci per impatto, sforzo e importanza. Piano d'azione trasforma le voci principali in attività con responsabili, tempistiche e verifiche periodiche, ad esempio una quota fissa di ogni sprint dedicata alla riduzione del debito. Conviene farla più o meno ogni trimestre, o ogni volta che il team sente che il debito lo sta rallentando, così il debito resta visibile e contenuto.

Formato della retrospettiva sul debito tecnico

Fonti del debito

Quali aree del codice hanno accumulato debito tecnico?

Chiedi alle persone di essere precise sul tipo di debito e su dove si trova: code smell, problemi architetturali, test mancanti, dipendenze obsolete.

Impatto e rischi

Che effetto ha questo debito tecnico sul team e sul prodotto?

Parlate di quanto il debito costa davvero: consegne più lente, bug visibili ai clienti, inserimento faticoso dei nuovi arrivati, sviluppatori frustrati. I costi concreti rendono più forte la richiesta di ripagarlo.

Prioritizzazione

Da quali aree di debito dovremmo partire?

Ordinate le voci di debito per impatto, sforzo e quanto bloccano altro lavoro. Una rapida matrice impatto/sforzo aiuta il team a trovare un accordo.

Piano d'azione

Come possiamo affrontare in modo sistematico il debito prioritario?

Costruite un piano concreto: chi fa cosa, entro quando e quando verificherete i progressi. Decidete quanta capacità di ogni sprint va alla riduzione del debito.

Quando utilizzare questa analisi retrospettiva

  • Quando il codebase diventa più difficile da mantenere ed estendere a ogni modifica.
  • Quando il team passa il tempo a spegnere incendi e le nuove funzionalità continuano a slittare per colpa dell'instabilità.
  • Quando l'inserimento di nuovi sviluppatori è lento perché alcune aree sono contorte o non documentate.
  • Quando manutenzione e correzione di bug occupano più tempo del lavoro nuovo.
  • Quando gli sviluppatori sono frustrati dalle stesse aree problematiche sprint dopo sprint.

Domande suggerite per rompere il ghiaccio

  • Se il nostro codebase fosse un edificio, che aspetto avrebbe e perché?
  • Qual è stato il tuo incontro più buffo o più doloroso con il debito tecnico?

Desiderate un esercizio di riscaldamento che la vostra squadra possa svolgere, anziché limitarsi a rispondere ad alta voce? Sfogliate gli esercizi per rompighiaccio gratuiti →

Idee e consigli per la vostra riunione di retrospettiva

  • Mantenete la discussione libera da colpe. Ogni codebase accumula debito: la domanda è cosa farne adesso.
  • Assicurati che le persone non tecniche presenti capiscano cos'è il debito tecnico e perché conta per le consegne.
  • Ordinate il debito per impatto, sforzo e importanza invece di cercare di sistemare tutto in una volta.
  • Date al piano tempistiche, responsabili e verifiche regolari, così non si arena.
  • Riservate una quota fissa di ogni sprint o ciclo alla riduzione del debito.
  • Automatizzate linting, test e parte della code review, così entra meno debito nuovo.

Domande frequenti

Che cos'è una retrospettiva sul debito tecnico?
È una riunione di team mirata per individuare dove si è accumulato il debito tecnico, discutere quanto sta costando, decidere cosa affrontare per primo e pianificare come ripagarlo.
Quando conviene fare una retrospettiva sul debito tecnico?
Fatela quando notate consegne più lente, bug ricorrenti o un accumulo di scorciatoie dovute a decisioni passate. Molti team la fanno anche a cadenza regolare, ad esempio una volta a trimestre, accanto alle normali retrospettive di sprint.
Come si dà priorità al debito tecnico durante la retrospettiva?
Valutate ogni voce per impatto, sforzo e importanza invece di affrontare tutto insieme. Poi trasformate le voci principali in un piano d'azione con responsabili e tempistiche.
Chi dovrebbe partecipare a una retrospettiva sul debito tecnico?
Gli sviluppatori che lavorano sul codice, più il product owner o chi stabilisce le priorità. Se manca la persona che decide cosa sviluppare, il piano raramente trova spazio nello sprint.
Quanto tempo dovremmo dedicare a ripagare il debito tecnico?
Non esiste un numero giusto in assoluto. Molti team riservano una quota fissa di ogni sprint, così la riduzione del debito procede in modo costante invece di aspettare uno sprint di pulizia dedicato che non arriva mai.

Modelli correlati

Processo di sviluppo prodotto

Allarga lo sguardo oltre gli sprint e rivedi come costruisci i prodotti.

Retrospettiva DevOps

Analizzate deployment, incidenti e passaggi di consegne tra dev e ops.

Retrospettiva Bug Fixing

Scopri perché nascono i bug ed evita che si ripetano

Retrospettiva sulla Code Review

Rendete le code review del team più rapide e utili

È pronto a condurre questa retrospettiva?Provi questa esibizione dal vivo in chiave retrospettiva