Dicono che il lento e costante vinca la gara, ma nel frenetico mondo dello sviluppo del software – posticipi, perdi.
Le aziende che non portano i prodotti fuori dalla porta o non colgono le opportunità emergenti con entrambe le mani spesso cadono nel dimenticatoio. Ma come completare funzionalità e prodotti più velocemente con risorse limitate? La risposta: prendi una scorciatoia.
Può sembrare una cattiva pratica tagliare gli angoli quando si tratta di codifica, ma quando la velocità produce rendimenti maggiori della perfezione, è l’unica strada da percorrere. Naturalmente, le scorciatoie non sono gratuite e lo stesso vale per lo sviluppo del software. Ha anche un nome: debito tecnico.
Come il debito finanziario, può essere sia positivo che negativo, a seconda di come lo gestisci. Rimani aggiornato e potrebbe essere il percorso della tua azienda verso una rapida crescita. Ignoralo e finirai in un buco nero che potrebbe affondare l’intera operazione. Continua a leggere per definizioni, esempi e suggerimenti!
#1 – Cos'è il debito tecnico?
Il debito tecnico (noto anche come “debito tecnologico”, “debito di progettazione” o “debito di codice”) è ciò che accade quando gli sviluppatori prendono scorciatoie per completare un prodotto o funzionare più velocemente. Di conseguenza, dovrai rivisitare e migliorare le funzionalità in futuro, che si tratti di correggere bug, completare la documentazione mancante o rivisitare il codice legacy. Altri tipi di debiti tecnici includono la conoscenza che il team di sviluppo non condivide con l’organizzazione e il codice troppo complesso per essere modificato rapidamente.
Originariamente coniato dallo sviluppatore di software Ward Cunningham (il tizio a cui è stato attribuito il merito di aver inventato la wiki), il debito tecnico era una metafora chiara che usava per spiegare agli stakeholder non tecnologici perché è importante budget per il refactoring (il processo di ristrutturazione del codice esistente).
La frase utile ha preso piede. Anni dopo, quando gli è stato chiesto come è arrivato alla metafora tecnica del debito, ha detto quanto segue: “Con il denaro preso in prestito, puoi fare qualcosa prima di quanto potresti, ma finché non ripagherai quei soldi, pagherai gli interessi. Pensavo che prendere in prestito denaro fosse una buona idea. Pensavo che portare il software fuori dalla porta per fare un po’ di esperienza con esso fosse una buona idea, ma che ovviamente alla fine saresti tornato indietro e, man mano che avresti imparato cose su quel software, avresti ripagato quel prestito refactoring il programma per riflettere la tua esperienza così come l’hai acquisita.”
Quindi, quando scegli la velocità rispetto alla perfezione, a un certo punto, dovrai tornare indietro e affrontare quel “debito”.
Come continua Ward Cunningham, “Il pericolo si verifica quando il debito non viene ripagato. Ogni minuto speso su un codice non corretto conta come interesse su quel debito. Intere organizzazioni di ingegneria possono essere fermate sotto il carico del debito di un’implementazione non consolidata, orientata agli oggetti o altro.
#2 – Quali sono i vantaggi del debito tecnico?
Non tutti i debiti sono negativi. Gestirlo bene può portare enormi vantaggi, incluso aiutare te o la tua azienda a raggiungere i tuoi obiettivi più velocemente. Ciò è particolarmente vero per le aziende che hanno bisogno di cogliere opportunità emergenti e/o testare il prodotto o l’adattamento al mercato. Ma come per il debito finanziario, devi rimborsare il debito tecnico. Il debito accumulato può rallentarti, causare la rottura dei tuoi prodotti, sopraffare i tuoi sviluppatori o persino far affondare la tua azienda.
“Il costo di non pagare mai questo debito tecnico è chiaro; alla fine il costo per fornire funzionalità diventerà così lento che è facile per un prodotto software competitivo ben progettato superare il software mal progettato in termini di funzionalità”.
“Nella mia esperienza, un software mal progettato può anche portare a una forza lavoro di ingegneria più stressata, portando a sua volta a una maggiore abbandono del personale (che a sua volta influisce sui costi e sulla produttività durante la distribuzione delle funzionalità). Inoltre, a causa della complessità di una determinata base di codice, scomparirà anche la capacità di stimare accuratamente il lavoro. Nei casi in cui le agenzie di sviluppo addebitano in base alla funzionalità, il margine di profitto per la distribuzione del codice alla fine si deteriorerà”, aggiunge.
#3 – Tre tipi spiegati
In Essential Scrum. Una guida pratica al processo agile più diffuso, l’autore Ken Ruben utilizza le seguenti tre categorie per definire il debito tecnico:
- Debito tecnico verificatosi: questo è un debito che il team di sviluppo non sapeva esistesse fino a quando non è stato esposto durante l’uso o la manutenzione di routine del prodotto. Ad esempio, il team sta aggiungendo una nuova funzionalità e ha notato che una soluzione è stata aggiunta al codice anni fa e lasciata invariata. Può anche essere causato da “bit rot”, che si verifica quando il codice si deteriora nel tempo, alterandone la funzione e l’usabilità.
- Debito tecnico noto: questo è il debito di cui gli sviluppatori sono a conoscenza ed è visibile.
- Debito tecnico mirato: questo è un debito noto che il team di sviluppo rinnoverà.
Questo è stato ulteriormente suddiviso in una moltitudine di sottocategorie, la più popolare delle quali è il debito tecnico intenzionale e non intenzionale. Entriamo in quelli in modo un po ‘più dettagliato. - Il debito tecnologico intenzionale (noto anche come “debito deliberato”) si verifica quando le organizzazioni lasciano spazio a miglioramenti nel loro codice per motivi di velocità.
- Il debito tecnologico non intenzionale (chiamato anche debito accidentale, passivo, obsoleto o involontario) si verifica quando il codice necessita di miglioramenti per una serie di motivi non intenzionali. Ad esempio, lavoro scadente la prima volta o codice semplicemente obsoleto e che necessita di un aggiornamento.
#4 Il quadrante del debito tecnico
Al di là di quanto abbiamo già spiegato, Martin Fowler (che, insieme a Ward Cunningham, è stato uno dei 17 autori del Manifesto per lo sviluppo software agile), ha creato qualcosa che chiama il “Quadrante del debito tecnico”.
Fowler ha preso la definizione in due parti e ha aggiunto più sfumature con l’obiettivo di scavare domande più rilevanti.
Piuttosto che chiedere se qualcosa fosse o meno un debito tecnico, ha pensato che fosse più utile chiedersi se il debito fosse “sconsiderato” o “prudente”. Da lì, guarda le categorie “deliberato” o “involontario”.
Il quadrante crea quattro nuove categorie di debito tecnico:
- Spericolato e involontario
- Spericolato e deliberato
- Prudente e deliberato
- Prudente e involontario
Deliberato e involontario è lo stesso di intenzionale e non intenzionale, mentre prudente e sconsiderato sono completamente diversi da qualsiasi altra categoria.
La prudenza si verifica quando il team ha preso decisioni attente, informate e mirate. Reckless accade quando la squadra matura un debito senza discrezione.
Rispondere se la causa del debito fosse un comportamento prudente o sconsiderato non è una domanda facile da affrontare. Il team deve essere abbastanza consapevole di sé da sapere quando sta facendo un buon lavoro (o meno), e questo si riduce a coltivare una cultura di responsabilità del team, qualcosa di cui parleremo un po’ più in dettaglio più avanti.
#5 –Come gestire il debito tecnico
Come per i debiti finanziari, nascondere la testa sotto la sabbia non è una buona strategia. Gestirlo richiede consapevolezza, monitoraggio e impegno a tenerlo sotto controllo.
Questo non è facile. Spesso sembra meno importante ripassare il vecchio lavoro che lavorare per ottenere qualcosa di nuovo fuori dalla porta. Team e project manager sono impegnati e spesso sotto pressione per continuare a rilasciare aggiornamenti e nuovi prodotti. È importante che i manager imparino a stabilire le priorità. Parte di questo sta nel vedere l’importanza del recupero tecnico dei crediti.
Ecco una statistica che apre gli occhi: Stripe stima che il “cattivo codice” costi alle aziende a livello globale quasi $ 85 miliardi.
Nel frattempo, Research di Gartner afferma che le aziende che hanno una strategia per il debito tecnico spediranno il 50% più velocemente. Quindi come tenerlo sotto controllo? Ecco alcuni suggerimenti.
Investire nella cultura aziendale: è fondamentale far lavorare tutti dallo stesso libro. Ciò significa mettere in atto procedure che tengono le persone responsabili (e assicurano che tutti seguano le stesse istruzioni).
Segui le pratiche DevOps: avere team isolati non è ottimo per la collaborazione o la comunicazione. Segui le pratiche DevOps (o DevSecOps) per far lavorare insieme le persone in modo coeso.
Investi nella tua base di codice: esegui test QA approfonditi e valuta la possibilità di automatizzare la tua pipeline di distribuzione continua.
Investi in uno strumento di gestione dei progetti per gli sviluppatori, come Backlog: questo rende più facile per gli sviluppatori identificare, segnalare, tracciare e dare priorità ai rapporti sui debiti senza apportare grandi modifiche al loro flusso di lavoro. Inoltre, poiché le informazioni vengono archiviate in un archivio centrale, non esistono fili incrociati o lavori duplicati.
#6 - In conclusione
Proprio come nel mondo reale, il debito è sia buono che cattivo. Se lo gestisci bene, può aiutarti a crescere e prosperare in un mercato in rapida evoluzione, ma ignoralo a tuo rischio e pericolo.
La gestione efficiente del debito tecnico inizia con la cultura aziendale. Se metti in atto procedure che garantiscono il refactoring del codice come una questione di routine, dai ai team di sviluppo tempo e spazio per lavorare sul miglioramento del codice e investi in strumenti di gestione dei progetti che rendano più facile monitorare e gestire i miglioramenti, allora un po’ di il debito non deve essere motivo di preoccupazione. Potrebbe anche essere la cosa che aiuta la tua azienda a superare il gruppo.