Gennaio 24, 2022 - di Luca Rossi
“Conosci il tuo nemico, conosci te stesso, e in cento battaglie non sarai mai sconfitto”Sun Tzu
La settimana scorsa mi sono imbattuto in questo vecchio articolo di Rands sul managementese. È un grande saggio sulla comunicazione – e come nella vita, quanto sul posto di lavoro – più la comunicazione è chiara, più diventa veloce, in maniera assolutamente naturale.
Frasi strane su cui spesso ridiamo su, come “action item”, o “circling back”, sono in realtà espressioni capaci di esprimere concetti complessi in pochissime parole e di essere compresi veramente da tutti.
Una di queste espressioni è la grande metafora del debito tecnico.
Il debito tecnico è ampiamente usato e discusso all’interno dei team di sviluppo per un paio di ragioni che vi elenco di seguito:
Questi elementi lo rendono una leva perfetta quando si negoziano priorità, scadenze e risorse.
Tuttavia, è davvero così chiaro come sembra?
È un dato di fatto che, con il tempo, tutti i team di sviluppo vengono rallentati dalla code base esistente. Ma perché?
È perché la manutenzione è inevitabile? Oppure perché potremmo fare qualcosa di meglio in primo luogo? O entrambe le cose?
Se provate a cercare “Technical Debt” su Google e provate a guardare ai primi risultati, troverete una sorta di consenso tra i vari siti o articoli che trattano il tema. Sembra che si tratti di qualcosa che si accumula a causa di alcune “dirty practice”.
Se ciò è vero, potremmo dedurre che se scrivessimo un codice pulito fin dall’inizio (elaborando una perfetta documentazione, facendo test puntuali, ecc.), il debito non si accumulerebbe mai o, quantomeno, ciò succederebbe in maniera ridotta.
Naturalmente, se avete qualche esperienza di lavoro in un team di sviluppatori, sapete che non è vero. Il debito tecnico si insinua anche quando si lavora con le migliori intenzioni e si seguono le migliori pratiche. Ma perché?
Provate a dare un’occhiata a questo breve video di Ward Cunnigham.
Ward è l’inventore originale del termine “Debito Tecnico”, ed è interessante sentire la frase in cui questa metafora è stata usata per la prima volta (i grassetti sono miei):
If we fail to make the program aligned with what we understand to be the proper way to think about our […] objects, then we are going to continuously stumble into disagreement, and that would slow us down like paying interest on a loan.
Ward descrive il debito come il risultato naturale dello scrivere codice su qualcosa di cui non abbiamo una comprensione adeguata. Non parla di codice scadente che – secondo lui – rappresenta una parte molto piccola del debito. Parla, invece, di disagreement tra i bisogni del business e il modo in cui il software è stato scritto.
Ma come si arriva a questo disagreement? Nella mia esperienza, ci sono due colpevoli da individuare:
Vediamoli nel dettaglio 👇
Può capitare che il team progetti una soluzione che non si adatti alla perfezione ai requisiti di business. I requisiti possono anche essere soddisfatti in superficie, ma qualcosa è sbagliato alla radice (un’astrazione imprecisa, qualche duplicazione, problemi di scalabilità, e così via).
Certamente, questo genere di cose possono verificarsi quando il team ha scarse skill di sviluppo. Ma nella mia esperienza, la maggior parte delle volte ciò accade perché gli sviluppatori non hanno ben capito cosa dovesse essere fatto.
Se questo si verifica regolarmente, la risposta naturale è quella di investire di più nella fase di progettazione.
Questo significa, ovviamente, un’analisi più approfondita da parte degli sviluppatori, ma anche più momenti di confronto con gli stakeholder. Dovreste discutere sia il qui e ora, sia l’evoluzione futura del progetto.
Soffermarsi di più sulla fase di Design può, nel tempo, indebolire i risultati. Dunque, sta a te trovare lo “sweet spot” giusto, che si baserà su quanto è solida la pianificazione della tua azienda rispetto a quanti cambiamenti puoi aspettarti in futuro.
Il secondo scenario è quando le cose cambiano così rapidamente che non ci si può fidare dei requisiti di oggi. In altre parole: anche se lavoriamo per costruire la cosa giusta, quest’ultima rischia di diventare obsoleta velocemente a causa del panorama aziendale in continua evoluzione.
Una fase di progettazione troppo approfondita fornisce una protezione limitata contro i cambiamenti futuri. Dunque, un ciclo più snello potrebbe funzionare meglio:
Prendiamo, fondamentalmente, un pezzo dello sforzo di progettazione e lo spostiamo in avanti, in una fase di refactoring che avviene ogni volta che alcuni pezzi si sono consolidati e sono pronti per “essere messi al sicuro”.
In questo scenario, stiamo accettando la creazione di un debito, confidando nella nostra capacità di ripagarlo nel breve termine.
Tutto si può riassumere in tre elementi:
Come sempre, provo a riassumere i punti principali dell’articolo in questa sezione finale. Un modo utile a voi lettori, ma anche un controllo per me e per capire se quello che ho scritto ha senso da cima a fondo:
Dunque, se avete fretta, questo è ciò che dovreste ricordare:
Alcune risorse che mi hanno aiutato a scrivere questo articolo, e che possono essere utili per scavare più a fondo:
– Debt Metaphor: un breve video di Ward Cunningham che spiega la relazione tra debito e comprensione.
– Technical Debt as a Lack of Understanding: un recente articolo di Dave Rupert che riflette sulla definizione di Ward e aggiunge una preziosa esperienza del mondo reale.
– Technical Debt Quadrant: un saggio di Martin Fowler su cosa sia realmente il debito tecnico e i sulle diverse tipologie.
– Managementese: un grande articolo di Rands sul linguaggio del management e la comunicazione in ufficio.
Qual è la vostra esperienza con il debito tecnico? Fatemelo sapere nei commenti!
Se ti è piaciuto quello che ho scritto e vuoi saperne di più su di me vai su Refactoring.fm e iscriviti alla Newsletter! Questo invece l’articolo in inglese: The True Meaning of Technical Debt.
Le slide sono disponibili per studenti ed ex studenti del Master in Product Management
2 replies on “Cos’è il debito tecnico e come affrontarlo in modo Agile”
Davide Alaimo
Ciao,
ci sono dei metodi per stimare in qualche modo il debito tecnico atteso?
Luca Rossi
Ciao Davide, assolutamente!
Mi piace molto la tecnica di Riot Games, che considera tre caratteristiche: impatto, costo e contagio. Ti giro il link all’articolo: https://technology.riotgames.com/news/taxonomy-tech-debt