I bug fanno parte del debito tecnico?

Il nostro Scrum Master continua a riferirsi ai bug come debito tecnico. Ha ragione, i bug sono considerati debiti tecnici nel mondo di Agile?

Penso che la risposta qui sia abbastanza semplice: la caratteristica chiave del debito tecnico è che è qualcosa che sosteniamo per scelta.

Scegliamo di prendere decisioni sull'architettura, sul design o sull'implementazione che ci aspettiamo che ci causino problemi in seguito al fine di raggiungere obiettivi specifici prima.

Un bug non è qualcosa che scegliamo di avere nel nostro codice, quindi di fatto non è un debito tecnico.

Naturalmente si possono fare tutti i tipi di argomenti interessanti (e possibilmente validi) sulle scelte fatte dopo la scoperta, ma fondamentalmente (e in particolare nel contesto della domanda) no, i bug non sono debiti tecnici - mi sembra più un abuso del bingo di parole d'ordine.

Come poscritto - Non sono d'accordo con l'affermazione che è un dato di fatto che il debito tecnico porterà a bug in sé e per sé, poiché ciò porta a molte ipotesi sulla natura delle scelte fatte. Ad esempio, puoi avere un codice di prova ben scritto, ben strutturato, che fa ancora - diciamo - compromessi architetturali per la consegna anticipata. Allo stesso modo potresti scegliere di non automatizzare i tuoi processi di implementazione che non porteranno a bug ma probabilmente porteranno molto stress e dolore. Ovviamente se il debito è che hai scritto un codice che non è SOLIDO (o qualsiasi altra cosa) allora sì ... ma non è affatto sempre così.

Sì.

Il debito tecnico (noto anche come debito di progettazione o debito di codice) è una metafora neologica che si riferisce alle eventuali conseguenze di un'architettura software scadente o in evoluzione e allo sviluppo di software all'interno di una base di codice.

Fonte: Wikipedia

Leggi il debito tecnico come qualcosa che avresti potuto evitare avendo un flusso di lavoro migliore (ad esempio facendo correttamente l'architettura prima di saltare alla codifica, facendo TDD, ecc.), Migliori pratiche di codifica, ecc.

La maggior parte dei bug avrebbe potuto essere evitata da un'ulteriore revisione o dall'uso di metodi più formali. Non facendo tutto il possibile per non avere bug in primo luogo, si riduce il costo immediato / a breve termine del progetto, ma aumentando il debito tecnico.

Dopo aver letto la risposta di BЈовић , vedo che potrebbe non essere facile come pensavo.

• Ad esempio I bug fanno parte del debito tecnico? l'articolo afferma che solo i bug che conosci ma che hai deciso di non risolvere fanno parte del debito tecnico.

• Un altro esempio, Christopher's Thoughts on Technical Debt qualifica i bug come risultato del debito tecnico, non parte di esso. Detto questo, molti dei risultati elencati, come "costo per implementare nuove funzionalità", sono influenzati dal numero di bug.

• Infine, quando ho creato il modello di debito tecnico ABCDE-T , ho incluso i bug come uno dei sei fattori, ma sono considerati in modo diverso. L'attenzione non si concentra sugli stessi bug, ma sui modi in cui vengono raccolti, ordinati per priorità e risolti. Gli stessi bug appaiono come il risultato del debito tecnico (come nell'esempio precedente), ma non si presentano mai come un fattore del debito tecnico.

Detto questo, sono ancora propenso a rispondere che i bug, tutti i bug, fanno parte del debito tecnico.

Primo argomento:

Leggendo la citazione di Jeff Atwood, la maggior parte dei bug si qualificherebbe come:

lo sforzo extra che dobbiamo fare nello sviluppo futuro a causa della scelta del design veloce e sporca

Nelle applicazioni aziendali, quasi tutti i bug provengono da una scelta di progettazione rapida e sporca o da cattive pratiche (sarebbe la mancanza di test, l'uso di tecnologie che gli sviluppatori non conoscono abbastanza, la mancanza di comunicazione, la mancanza di comprensione del dominio, ecc.) Ciò significa che "rifattorizzando il design rapido e sporco in un design migliore" e adattando le pratiche migliori, le aziende potrebbero risolvere la maggior parte dei loro bug.

Secondo argomento:

Se facciamo un parallelo tra il debito ordinario di una società che è importante prendere in considerazione quando una società viene venduta a un'altra, e il debito tecnico, che è altrettanto importante tenere in considerazione quando un progetto viene venduto a un'altra società o dato per un altro team, possiamo facilmente vedere che i bug fanno parte del debito tecnico, dal momento che il nuovo team dovrebbe:

• O devi affrontare questi bug prima di creare nuove funzionalità (punto 5 di Joel Test: correggi i bug prima di scrivere un nuovo codice?)

• Oppure mantieni i bug, preservando / aumentando in questo modo il debito tecnico.

Jeff Atwood nel suo articolo Paying Down Your Technical Debt dà una bella risposta su cosa sia il debito tecnico:

il debito tecnico comporta pagamenti di interessi, che si presentano sotto forma di uno sforzo supplementare che dobbiamo compiere nello sviluppo futuro a causa della scelta del progetto rapida e sporca. Possiamo scegliere di continuare a pagare gli interessi, oppure possiamo rimborsare il capitale modificando il design rapido e sporco in un design migliore. Anche se costa pagare il capitale, guadagniamo riducendo i pagamenti di interessi in futuro.

A rigor di termini, i bug non fanno parte del debito tecnico, se non rallentano l'ulteriore sviluppo del software (modifica delle cose, aggiunta di nuove funzionalità, ecc.). Sono difetti del software.

Tuttavia, quando è troppo costoso riparare un bug o ti costringe a aggirarlo (e introdurre un debito ancora più tecnico), allora diventa parte di un debito tecnico.

Un bug non è un debito tecnico. Il debito tecnico sta risparmiando sulla qualità, non sulla sua assenza. Il software non dovrebbe essere consegnato con bug in primo luogo. Sai, tutto quel software funzionante su una documentazione completa.

I più grandi trasgressori del debito tecnico sono le "correzioni temporanee di errori", sai quelli che hai messo per superare il test e far accettare la storia. Man mano che si accumulano correzioni temporanee, patch e altre cose, il codice diventa inutile, ingombrante, difficile da aggiornare e testare e in generale è un incubo, ma fa ancora il suo lavoro.

A sostegno di questa opinione, sono andato direttamente alla fonte, Ward Cunningham. A proposito di ciò, Ward ha fatto una buona intervista qualche tempo fa con Capers Jones, vale la pena dare un'occhiata.

Dibattito tecnico sul debito, con Ward Cunningham e Capers Jones

Un altro articolo che merita una lettura è di Martin Fowler

Martin Fowler sul debito tecnico

Nell'articolo di Martin, si trova il link alla menzione originale del debito tecnico di Ward Cunningham, da OOPSLA92:

Il sistema di gestione del portafoglio WyCash

Una citazione dall'articolo sopra:

Sebbene il codice immaturo possa funzionare bene ed essere completamente accettabile per il cliente , le quantità in eccesso renderanno un programma impercettibile, portando a un'estrema specializzazione dei programmatori e infine a un prodotto non flessibile. La spedizione del primo time code è come indebitarsi.

Alla fine, il debito tecnico potrebbe essere arrivato a includere bug per alcune persone, e immagino che vada bene. Solo non penso che fosse l'intenzione originale.

A rigor di termini, la risposta alla tua domanda è No.

Il debito tecnico può (e probabilmente porterà) a dei bug, ma concludere che qualsiasi errore è il risultato del debito tecnico sta mettendo un'interpretazione tra due fatti: c'è un errore e c'è debito tecnico (supponendo che possa essere concluso come un fatto).

Se il tuo Scrum Master sta affermando "come teoria" che i bug sono il risultato di un debito tecnico, sta tagliando gli angoli. Se lo dice su bug specifici che continuano a riapparire, potrebbe anche avere ragione - non possiamo vedere la qualità del codice da qui ;-)

Potrebbe anche avere un reclamo in corso su persone che non lo ascoltano sul debito tecnico e quindi etichettano ogni bug come debito tecnico, ma ora sto speculando.

Secondo me, non importa se dici che i bug fanno parte del debito tecnico ... oppure no.

Il fatto evidente è che i bug esistenti rappresentano un lavoro extra che potrebbe essere necessario eseguire in futuro, per risolverli o aggirarli.

Il debito tecnico (dato che l'etichetta viene generalmente utilizzata) rappresenta anche un lavoro extra che potrebbe essere necessario eseguire in futuro ... in un modo o nell'altro.

Quindi, sia che tu dica che i bug noti (o sconosciuti) siano debiti tecnici ... o no ... è davvero solo una questione di definizioni. E poiché non esiste una definizione autorevole ¹ di "debito tecnico", l'intera discussione è in qualche modo inutile.

Come scrisse Lewis Carroll:

"Quando uso una parola," disse Humpty Dumpty, in tono piuttosto sprezzante, "significa esattamente ciò che scelgo che significhi, né più né meno." .

Ecco come funziona il linguaggio naturale. Le parole significano ciò che la gente pensa di voler dire. Le definizioni del dizionario e così via documentano semplicemente il modo in cui le parole vengono utilizzate e non sono necessariamente una documentazione accurata. Se il tuo Scrum Master vuole riferirsi a bug noti come debito tecnico, chi può dire che ha "torto"?

^{1 - Citare persone come Ward Cummingham e Caper Jones non aiuta neanche. Nella migliore delle ipotesi ci dice cosa significano (o significano) quando usano (usano) la frase. Non "possiedono" la frase. Sebbene siano senza dubbio autorità su questi temi, questa è ancora solo la loro opinione.}