Les bugs font-ils partie de la dette technique?

44

Notre Scrum Master continue à parler des bugs comme une dette technique. A-t-il raison, les bugs sont-ils considérés comme une dette technique dans le monde Agile?

agile technical-debt

— utilisateur86834
source

Pourquoi est-il important de décider s’il s’agit ou non d’une dette technique? Cela affectera-t-il la façon dont vous représentez les bugs sur votre panneau de mêlée ou la manière dont vous envisagez de les résoudre?

— Bryan Oakley

@ BryanOakley Certains bugs peuvent vous bloquer de manière à vous obliger à les contourner, en introduisant une dette encore plus technique. Ces bugs peuvent être trop coûteux à résoudre

— lundi

4

@BryanOkley - J'ai toujours pensé que la dette technique était une conception ou un refactoring nécessaire pour améliorer la mise en œuvre mais qui n'était pas possible à l'heure actuelle en raison de contraintes de temps / budget. Je pense qu'il est important d'utiliser la terminologie correcte. J'ai peut-être tort ou il a peut-être tort, c'est pourquoi j'ai posé la question.

— user86834

Je comprends que. Pourquoi est-il important de les appeler dette technique? Voulez-vous dire que si vous les classifiez comme "dette technique", vous traiterez ces bogues différemment des autres?

— Bryan Oakley

1

Vous pouvez avoir une énorme quantité de service technique et ne pas avoir un seul bug. Le département technique est le contraire d'un code bien écrit et bien conçu. Un code bien écrit est facile à gérer, à tester et à ajouter. Le service technique ralentit le développement, rend difficile la traçabilité des bogues et augmente les chances que le nouveau code introduise des bogues.

— Luis Perez

35

Je pense que la réponse est assez simple: la principale caractéristique de la dette technique est qu’elle est encouragée par choix.

Nous choisissons de prendre des décisions d’architecture, de conception ou d’implémentation qui devraient nous poser des problèmes plus tard afin d’atteindre des objectifs spécifiques plus rapidement.

Nous choisissons d’avoir un bogue dans notre code. C’est donc de facto que ce n’est pas une dette technique.

Bien sûr, on peut faire toutes sortes d’arguments intéressants (et éventuellement valables) sur les choix faits après la découverte, mais fondamentalement (et en particulier dans le contexte de la question), non, les bugs ne sont pas une dette technique.

En post-scriptum, je ne souscris pas à l’affirmation selon laquelle il va de soi que la dette technique entraînera des bugs en soi, car cela jette de nombreuses hypothèses sur la nature des choix faits. Par exemple, vous pouvez avoir un code bien écrit, bien structuré, couvert de tests, qui fait encore - disons - des compromis architecturaux pour une livraison rapide. De même, vous pouvez choisir de ne pas automatiser vos processus de déploiement, ce qui ne provoquera pas de bugs, mais entraînera probablement beaucoup de stress et de douleur. Bien sûr, si la dette est que vous avez écrit un code qui n'est pas SOLIDE (ou autre), alors oui ... mais ce n'est pas toujours le cas.

— Murph
source

1

+1 Je pense que la réponse de BЈовић est à peu près juste, mais votre réponse frappe vraiment le clou. ( Cependant, je suis un peu déconcerté par votre utilisation du terme de facto . Je ne pense pas que vous puissiez dire que de jure , un bogue est une dette technique?)

— ruakh

L'utilisation de la langue est tellement amusante ... essayez ceci: fr.wikipedia.org/wiki/De_facto - lisez-le comme "à toutes fins pratiques", ce qui est assez proche de mon intention

— Murph

"Je pense que la réponse est assez simple. La dette technique a pour caractéristique essentielle de nous engager par choix." Où avez-vous tiré cette définition? Je ne pense pas que c'est juste. C'est une partie de la dette technique, l'autre est implicite et est généralement due à l'ignorance et aux mauvaises pratiques.

— gphilip

de jure du jure. Demain de facto. QED.

— radarbob

1

Selon le Quadrant de la dette technique de Martin Fowler, vous pouvez identifier les bogues et les codes défectueux comme une dette "imprudente par inadvertance": martinfowler.com/bliki/TechnicalDebtQuadrant.html . Je pense que le fait est que si vous marquez des bogues sensibles comme des dettes, vous pourrez alors comprendre combien ils vous coûtent et si vous devez ou non les éliminer. Par exemple, si vous avez un module écrit superficiel qui n'est modifié qu'une fois par an et qu'il faudrait des semaines pour le réécrire - vous devriez probablement le conserver tel quel car les paiements d'intérêts sur cette dette sont très minimes

— shershen

20

Oui.

La dette technique (également appelée dette de conception ou dette de code) est une métaphore néologiste faisant référence aux conséquences éventuelles d'une architecture de logiciel médiocre ou en évolution et du développement de logiciels au sein d'une base de code.

Source: Wikipedia

Lisez la dette technique comme une chose que vous auriez pu éviter en améliorant le flux de travail (par exemple, en effectuant une architecture correcte avant de passer au codage, en effectuant une TDD, etc.), en améliorant les pratiques de codage, etc.

La plupart des bogues auraient pu être évités grâce à une révision supplémentaire ou à l'utilisation de méthodes plus formelles. En ne faisant pas tout ce que vous pouvez pour ne pas avoir de bugs, vous réduisez le coût immédiat / à court terme du projet, mais vous augmentez la dette technique.

Après avoir lu la réponse de BЈовић , je constate que ce n'est peut-être pas aussi facile que je le pensais.

Par exemple, les bogues font-ils partie de la dette technique? Cet article affirme que seuls les bogues que vous connaissez mais que vous avez décidé de ne pas corriger font partie de la dette technique.
Un autre exemple, les réflexions de Christopher sur la dette technique qualifie les bogues comme résultant d’une dette technique et n’en font pas partie. Ceci étant dit, nombre des résultats listés, tels que "le coût d'implémentation d'une nouvelle fonctionnalité", sont influencés par le nombre de bogues.
Enfin, lors de la création du modèle de dette technique ABCDE-T , j’ai inclus les bogues parmi les six facteurs, mais ils sont considérés différemment. L'accent n'est pas mis sur les bugs eux-mêmes, mais sur la manière dont ils sont collectés, hiérarchisés et résolus. Les bugs eux-mêmes apparaissent comme le résultat d'une dette technique (comme dans l'exemple précédent), mais ne se présentent jamais eux-mêmes comme un facteur de dette technique.

Ceci étant dit, je suis toujours enclin à répondre que les bogues - tout bogue - font partie de la dette technique.

Premier argument:

À la lecture de la citation de Jeff Atwood, la plupart des bogues pourraient être qualifiés de:

l'effort supplémentaire que nous devons faire dans le développement futur en raison du choix de conception rapide et sale

Dans les applications métier, presque tous les bogues proviennent de choix de conception rapides et compliqués, ou de mauvaises pratiques (manque de tests, utilisation de technologies que les développeurs ne connaissent pas suffisamment, manque de communication, manque de compréhension du domaine, etc.). etc.) Cela signifie que "en transformant la conception rapide en une meilleure conception" et en adaptant de meilleures pratiques, les entreprises pourraient résoudre la plupart de leurs problèmes.

Deuxième argument:

Si nous établissons un parallèle entre la dette ordinaire d’une entreprise qu’il est important de prendre en compte lorsqu’une entreprise est vendue à une autre, et la dette technique, qu’il est tout aussi important de prendre en compte lorsqu’un projet est vendu à une autre entreprise ou donné. pour une autre équipe, nous pouvons facilement voir que les bogues font partie de la dette technique, puisque la nouvelle équipe:

Soit vous devez traiter ces bugs avant de créer de nouvelles fonctionnalités (point 5 de Joel Test: corrigez-vous les bugs avant d'écrire du nouveau code?)
Ou garder les bugs, en préservant / augmentant ainsi la dette technique.

— Arseni Mourzenko
source

1

Personnellement, je ne considère pas les défauts comme une dette technique, même si l'argument présenté dans cette réponse est valable, mais a) peu importe comment nous définissons la dette technique de l'OMI, et b) il s'agit d'une réponse si bien écrite. m voter quand même. +1!

— Bryan Oakley

13

Jeff Atwood dans son article Rembourser sa dette technique donne une assez bonne réponse sur ce qu'est la dette technique:

la dette technique implique des paiements d’intérêts, qui se traduisent par l’effort supplémentaire que nous devons faire dans le développement futur en raison du choix de conception rapide et délicat. Nous pouvons choisir de continuer à payer les intérêts, ou nous pouvons rembourser le capital en transformant la conception rapide en une conception optimisée. Bien que le remboursement du capital coûte cher, nous gagnons à l'avenir en réduisant les paiements d'intérêts.

Strictement parlant, les bugs ne font pas partie de la dette technique s'ils ne ralentissent pas le développement ultérieur du logiciel (modification des éléments, ajout de nouvelles fonctionnalités, etc.). Ce sont des défauts logiciels.

Cependant, quand il est trop coûteux de réparer un bogue ou que cela vous oblige à le contourner (et à introduire encore plus de dette technique), cela devient alors une partie de la dette technique.

— BЈовић
source

1

En fait, ils le font, car les bogues peuvent entraîner des travaux supplémentaires sur les nouvelles fonctionnalités qui ne seraient pas nécessaires sans les bogues. J'ai même vu le code évoluer dans un mauvais sens (augmentation de la dette technique) à cause d'un bogue qui s'est transformé en "ce n'est pas un bogue, c'est une fonctionnalité" parce que les clients ont écrit des scripts ou quoi que ce soit qui repose sur le comportement du buggy.

— Marjan Venema

@MarjanVenema Bon point. Je n'ai pas pensé à ça.

— Bonjour

Notez que cette citation ne provient pas de Jeff Atwood, elle est tirée d’ un message de Martin Fowler . Jeff cite également ceci dans son blog.

— Uooo

6

Un bug n'est pas une dette technique. La dette technique lésine sur la qualité, pas son absence. Les logiciels ne doivent pas être livrés avec des bugs. Vous savez, tout ce logiciel qui fonctionne avec une documentation complète.

Les plus gros coupables de dettes techniques sont des "corrections de bugs temporaires", vous connaissez celles que vous avez utilisées pour réussir le test et faire accepter l'histoire. Celles que vous vous êtes promis de refactoriser plus tard, mais ne faites jamais. Au fur et à mesure que ces correctifs temporaires, correctifs et autres éléments s'accumulent, le code devient inutile, encombré, difficile à mettre à jour et à tester et constitue en général un cauchemar, mais il fait toujours son travail.

Pour appuyer cette opinion, je suis allé directement à la source, Ward Cunningham. À propos de cela, Ward a fait une bonne interview il y a quelque temps avec Capers Jones, ça vaut le coup d'œil.

Débat technique sur la dette, avec Ward Cunningham et Capers Jones

Un autre article qui mérite d'être lu est celui de Martin Fowler

Martin Fowler sur la dette technique

Dans l'article de Martin, veuillez trouver le lien vers la mention originale de dette technique de Ward Cunningham, de OOPSLA92:

Le système de gestion de portefeuille WyCash

Une citation de l'article ci-dessus:

Bien qu'un code immature puisse fonctionner correctement et être totalement acceptable pour le client , des quantités excessives rendront un programme incontrôlable, conduisant à une spécialisation extrême des programmeurs et finalement à un produit inflexible. Le premier code de livraison est comme une dette.

En fin de compte, la dette technique en est peut-être venue à inclure des bugs pour certaines personnes, et je suppose que ça va. Je ne pense tout simplement pas que c'était l'intention initiale.

— Classe abstraite
source

"Les logiciels ne doivent pas être livrés avec des bugs en premier lieu." Tous les logiciels, sauf le programme le plus simple, contiennent des bogues. Vous fixez cette barre trop haut.

— bhspencer

2

Strictement parlant, la réponse à votre question est non.

Les dettes techniques peuvent (et vont probablement) conduire à des bugs, mais conclure que tout bug est le résultat d’une dette technique consiste à interpréter deux faits: il existe un bug et il y a une dette technique (en supposant que cela puisse être conclu comme un fait).

Si votre Scrum Master affirme «en tant que théorie» que les bogues sont le résultat d’une dette technique, il prend des raccourcis. S'il dit cela à propos de bugs spécifiques qui réapparaissent sans cesse, il a peut-être raison - nous ne pouvons pas voir la qualité du code à partir d'ici ;-)

Il peut également se plaindre que des personnes ne l'écoutent pas à propos de la dette technique, et donc qualifier chaque bug de dette technique, mais maintenant, je spécule.

— Jan Doggen
source

2

À mon avis, peu importe que vous disiez que les bugs font partie de la dette technique ... ou non.

Le fait est que les bogues existants représentent un travail supplémentaire qui peut être nécessaire à l'avenir, soit pour les corriger, soit pour les contourner.

La dette technique (comme le label est généralement utilisé) représente également un travail supplémentaire qui pourrait devoir être effectué à l'avenir… d'une manière ou d'une autre.

Donc, que vous disiez que les bugs connus (ou inconnus) sont une dette technique ... ou pas ... est vraiment juste une question de définitions. Et comme il n’existe pas de définition ^{1 faisant}autorité de "dette technique", toute la discussion est un peu inutile.

Comme Lewis Carroll a écrit:

«Quand j'utilise un mot, dit Humpty Dumpty d'un ton plutôt méprisant, cela signifie exactement ce que je veux dire, ni plus ni moins. .

Voilà comment fonctionne le langage naturel. Les mots signifient ce que les gens pensent qu'ils veulent dire. Les définitions de dictionnaire, etc., ne font que documenter la manière dont les mots sont utilisés et ne constituent pas nécessairement une documentation exacte. Si votre Scrum Master veut faire référence à des bugs connus en tant que dette technique, qui peut dire qu'il a "tort"?

^{1 - Citer des personnes telles que Ward Cummingham et Caper Jones n’aide pas non plus. Au mieux, cela nous dit ce qu'ils veulent dire (ou voulaient dire) quand ils ont utilisé (utilisé) la phrase. Ils ne "possèdent" pas la phrase. Bien qu'ils soient sans aucun doute les autorités sur ces questions, ce n'est toujours que leur avis.}

— Stephen C
source