Il nostro Scrum Master continua a fare riferimento a bug come debito tecnico. Ha ragione, i bug sono considerati un debito tecnico nel mondo di Agile?
Penso che la risposta qui sia abbastanza semplice - la caratteristica chiave del debito tecnico è che è una cosa che noi sosteniamo per scelta.
Scegliamo di prendere decisioni in materia di architettura, design o implementazione che prevediamo ci causeranno problemi in seguito al fine di raggiungere obiettivi specifici prima.
Un bug non è qualcosa che scegliamo di avere nel nostro codice - quindi di fatto il suo debito non tecnico.
Ovviamente 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 di natura tecnica - sembra più un abuso di buzzword bingo a me.
Come post scriptum - non sono d'accordo con l'affermazione che è un dato di fatto che il debito tecnico porterà a bug in sé e per sé, il che rende molte ipotesi sulla natura delle scelte fatte. Ad esempio, è possibile avere un codice di prova ben scritto, ben strutturato e sottoposto a test che faccia ancora, ad esempio, compromessi architettonici per la consegna anticipata. Allo stesso modo è possibile scegliere di non automatizzare i processi di implementazione che non porteranno a bug ma che probabilmente porteranno a molto stress e dolore. Naturalmente se il debito è che hai scritto un codice che non è SOLIDO (o qualsiasi altra cosa) allora sì ... ma non è sempre il caso.
Sì.
Technical debt (also known as design debt or code debt) is a neologistic metaphor referring to the eventual consequences of poor or evolving software architecture and software development within a codebase.
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 una revisione aggiuntiva o dall'uso di metodi più formali. Non facendo tutto il possibile per non avere bug in primo luogo, abbassi il costo a breve / medio termine del progetto, ma aumenti il debito tecnico.
Dopo aver letto la risposta di BЈовић , vedo che potrebbe non essere facile come pensavo.
Ad esempio I bug sono 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, I pensieri di Christopher sul debito tecnico qualifica bug come risultato di 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, durante la creazione del modello ABCDE-T del debito tecnico , ho incluso bug come uno dei sei fattori, ma sono considerato in modo diverso. L'attenzione non è sugli stessi bug, ma sui modi in cui vengono raccolti, ordinati per priorità e risolti. Gli stessi bugs appaiono come il risultato del debito tecnico (come nell'esempio precedente), ma non appaiono mai come un fattore di debito tecnico.
Detto questo, sono ancora incline 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 qualifica come:
the extra effort that we have to do in future development because of the quick and dirty design choice
Nelle applicazioni aziendali, quasi tutti i bug provengono da scelte progettuali rapide e sporche o da cattive pratiche (sarebbe la mancanza di test, l'uso di tecnologie che gli sviluppatori non conoscono abbastanza, mancanza di comunicazione, mancanza di comprensione di il dominio, ecc.) Ciò significa che "rifattorizzando il design veloce e sporco nel design migliore" e adattando le migliori pratiche, 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 è ugualmente importante prendere in considerazione quando un progetto viene venduto ad un'altra società o data a un'altra squadra, possiamo facilmente vedere che i bug fanno parte del debito tecnico, dal momento che la nuova squadra vorrebbe:
O aver a che fare con questi bug prima di creare nuove funzionalità (punto 5 di Joel Test: correggi bug prima di scrivere un nuovo codice?)
O mantieni i bug, preservando / aumentando in questo modo il debito tecnico.
Jeff Atwood nel suo articolo pagare il debito tecnico dà una bella risposta su quale sia il debito tecnico:
the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.
In senso stretto, i bug non fanno parte del debito tecnico, se non rallentano ulteriormente lo sviluppo del software (cambiando le cose, aggiungendo nuove funzionalità, ecc.). Sono difetti del software.
Tuttavia, quando è troppo costoso correggere un bug, o ti costringe a aggirare il problema (e introdurre un debito tecnico ancora maggiore), allora diventa parte di un debito tecnico.
Un bug non è un debito tecnico. Il debito tecnico è lesivo della qualità, non l'assenza di esso. Il software non dovrebbe essere fornito con bug in esso in primo luogo. Sai, tutto il software funzionante su una documentazione completa.
I più grandi trasgressori del debito tecnico sono "correzioni di bug temporanee", sai quelli che hai messo per superare il test e far accettare la storia. Quelli che hai promesso a te stesso ti rifatteranno in seguito, ma poi non lo faranno mai. Poiché queste correzioni temporanee, le patch e altre cose si accumulano, il codice diventa inutile ingombrante, difficile da aggiornare e testare e in generale è un incubo, ma continua a funzionare.
Per sostenere questa opinione, sono andato direttamente alla fonte, Ward Cunningham. Riguardo a questo, Ward ha fatto una buona intervista qualche tempo fa con Capers Jones, vale la pena dare un'occhiata.
dibattito sul debito tecnico, con Ward Cunningham & Capers Jones
Un altro articolo che vale la pena leggere è di Martin Fowler
Martin Fowler sul debito tecnico
Nell'articolo di Martin, ti preghiamo di trovare il link alla menzione originale del debito tecnico di Ward Cunningham, da OOPSLA92:
Il sistema di gestione del portfolio di WyCash
Una citazione dall'articolo precedente:
Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. Shipping first time code is like going into debt.
Alla fine, il debito tecnico potrebbe essere arrivato a includere bug per alcune persone, e suppongo che vada bene. Non penso che sia stata l'intenzione originale.
A mio parere, non importa se dici che i bug fanno parte del debito tecnico ... o no.
Il semplice fatto è che i bug esistenti rappresentano un lavoro extra che potrebbe devono essere eseguiti in futuro, sia per risolverli sia per aggirarli.
Il debito tecnico (in genere viene utilizzato l'etichetta) rappresenta anche un lavoro extra che potrebbe deve essere eseguito in futuro ... in un modo o nell'altro.
Quindi, se affermi che i bug conosciuti (o sconosciuti) sono un debito tecnico ... o no ... è solo questione di definizioni. E poiché non esiste una autorevole definizione 1 di "debito tecnico", l'intera discussione è in qualche modo priva di senso.
Come ha scritto Lewis Carroll:
'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it means just what I choose it to mean — neither more nor less.'.
In realtà è così che funziona la lingua naturale. Le parole significano ciò che le persone pensano che significano. Definizioni di dizionario e così via semplicemente document il modo in cui vengono utilizzate le parole e non sono necessariamente una documentazione accurata. Se il tuo Scrum Master vuole fare riferimento a bug noti come debito tecnico, chi vuol dire che è "sbagliato"?
1 - Non è d'aiuto nemmeno la citazione di persone come Ward Cummingham e Caper Jones. Nel migliore dei casi ci dice cosa intendono (o intendono) quando usano (usata) la frase. Non "possiedono" la frase. Mentre sono indubbiamente le autorità su questi temi, questa è ancora solo la loro opinione.
In senso stretto, la risposta alla tua domanda è No.
Il debito tecnico può (e probabilmente lo farà) portare a bug, ma concludere che ogni errore è il risultato del debito tecnico sta mettendo un'interpretazione tra due fatti: c'è un bug e c'è un problema tecnico debito (supponendo che possa essere concluso come fatto).
Se il tuo Scrum Master sta affermando "come una teoria" che i bug sono il risultato di un debito tecnico, sta facendo tagli. Se sta dicendo questo su bug specifici che continuano a riapparire potrebbe 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 etichettare ogni errore come debito tecnico, ma ora sto speculando.
Leggi altre domande sui tag agile technical-debt