Valutazione del debito tecnico per team di engineering

Valutate dove il debito tecnico rallenta il team e se lo state ripagando.

Provi questo controllo dello stato di salute in tempo reale

Cosa misura una valutazione del debito tecnico?

Ward Cunningham ha coniato la metafora del debito tecnico nel suo experience report presentato a OOPSLA nel 1992, scrivendo che "rilasciare codice alla prima stesura è come indebitarsi". Un po' di debito può farvi andare più veloci. I problemi iniziano quando non viene ripagato e ogni ora passata ad aggirare codice non del tutto corretto diventa interesse. Gli scanner misurano il codice. Questa valutazione misura ciò con cui il team convive ogni giorno: se il debito è visibile, quanto rallenta i rilasci, quanto codice e sistemi vi sembrano in salute e se lo state ripagando. Ognuno valuta ogni affermazione in privato, poi portate i punteggi più bassi in una retrospettiva e decidete insieme cosa sistemare per primo.

Dimensioni

Visibilità

Se il team sa dove si trova il proprio debito e lo tratta come lavoro vero e proprio.

  • Punti critici noti

    Sappiamo quali parti del nostro sistema hanno più debito.

  • Tracciato insieme al resto del lavoro

    Il debito è tracciato nello stesso backlog di funzionalità e bug.

  • Costo noto

    Sappiamo spiegare quanto ci costano i debiti più grandi in termini di tempo o di rischio.

Impatto sui rilasci

Quanto il debito rallenta il lavoro che il team cerca di rilasciare.

  • Velocità sulle funzionalità

    Il debito rallenta raramente le funzionalità che stiamo sviluppando.

  • Modifiche sicure

    Modificare una parte del nostro sistema raramente rompe una parte non correlata.

  • Build veloci e affidabili

    Le nostre build e i nostri test sono veloci e affidabili.

Salute del codice e dei sistemi

Quanto è facile oggi lavorare con codice, sistemi e dipendenze.

  • Facile da modificare

    La maggior parte del nostro codice è facile da capire e da modificare.

  • Dipendenze aggiornate

    Le nostre dipendenze e piattaforme sono ragionevolmente aggiornate.

  • Test a supporto del refactoring

    I nostri test ci danno la sicurezza necessaria per fare refactoring.

Ripagare il debito

Se il team fa progressi costanti e condivisi nella riduzione del debito.

  • Tempo dedicato

    Dedichiamo regolarmente del tempo a ripagare il debito.

  • Debito intenzionale registrato

    Quando ci indebitiamo di proposito, lo registriamo insieme a un piano per ripagarlo.

  • Priorità condivise

    Product ed engineering sono d'accordo su come dividere il tempo tra funzionalità e debito.

Quando utilizzare questo controllo dello stato di salute

  • Quando le funzionalità richiedono più tempo del dovuto e il team continua a dare la colpa al codice.
  • Prima della pianificazione trimestrale o della roadmap, per decidere insieme quanto tempo dedicare a ripagare il debito.
  • Dopo un grosso sforzo o una scadenza difficile, per registrare le scorciatoie prese prima che vengano dimenticate.

Consigli e suggerimenti

  • Leggete per primo il gruppo con il punteggio più basso. Una visibilità bassa significa che prima di tutto vi serve un elenco dei debiti. Una visibilità alta con una riduzione del debito bassa indica un problema di pianificazione, non di codice.
  • Coinvolgete il product manager nella discussione, anche se a valutare sono solo gli sviluppatori. Come dividere il tempo tra funzionalità e debito è una decisione condivisa.
  • Affiancate ai punteggi i dati che avete già, come i tempi di build, il numero di test instabili o le cause degli incidenti. La valutazione mostra dove fa male; i dati mostrano quanto.
  • Usatela insieme all'autovalutazione delle metriche DORA, alla valutazione della maturità DevOps o al modello di maturità dell'eccellenza ingegneristica per capire come il debito si collega ai rilasci e alle pratiche di engineering.
  • Ripetetela ogni trimestre. Un punteggio in crescita sulle affermazioni del gruppo Ripagare il debito è il primo segnale che il vostro piano sta funzionando.

Domande frequenti

Come si misura il debito tecnico?
Non esiste un numero unico. I team combinano metriche del codice come complessità, churn e copertura dei test con indicatori di delivery come i tempi di build, le modifiche fallite e il tempo necessario per completare le funzionalità. Una valutazione di team come questa aggiunge ciò che gli strumenti non vedono: dove il debito rallenta davvero le persone. Monitorate le stesse misure nel tempo invece di inseguire un valore perfetto.
Quali sono i quattro tipi di debito tecnico?
La classificazione più nota è il quadrante del debito tecnico di Martin Fowler. Classifica il debito in base a due domande: è stato contratto deliberatamente o involontariamente, e la scelta è stata prudente o sconsiderata? Il debito prudente e deliberato è un compromesso consapevole con un piano per ripagarlo, mentre quello sconsiderato tende ad accumularsi senza che nessuno se ne accorga.
Quanto tempo dovremmo dedicare al debito tecnico?
Non c'è una risposta standard. Alcuni team riservano una quota fissa di ogni sprint, altri pianificano interventi di pulizia regolari, altri ancora sistemano il debito nel codice che stanno già modificando. Scegliete una quantità, rendetela visibile nella pianificazione ed eseguite questa valutazione ogni trimestre per verificare se è sufficiente.
Come si spiega il debito tecnico ai product manager?
Parlate degli interessi, non del codice. Mostrate come il debito rallenta funzionalità specifiche, causa incidenti o rende le stime meno affidabili, e cosa si libererebbe sistemandolo. Eseguire questa valutazione con il product presente aiuta, perché entrambe le parti vedono gli stessi punteggi e possono decidere insieme cosa sistemare per primo.
Qual è un esempio di debito tecnico?
Un team copia un modulo per rispettare una scadenza e pensa di unire le copie in seguito. Mesi dopo, ogni correzione va fatta due volte e le copie sono ormai diverse tra loro. Altri esempi comuni sono dipendenze obsolete, test mancanti sul codice critico e una build lenta che tutti cercano di aggirare.
Chi ha coniato il termine debito tecnico?
Ward Cunningham ha introdotto la metafora nel 1992, in un experience report presentato a OOPSLA sul sistema di gestione di portafogli WyCash. Scrisse che "rilasciare codice alla prima stesura è come indebitarsi" e che il pericolo nasce quando il debito non viene ripagato. TeamRetro non è affiliata a Ward Cunningham.

Based on Ward Cunningham, 'The WyCash Portfolio Management System,' OOPSLA '92 Experience Report (1992).

Controlli sanitari correlati