Les bugs font-ils partie de la dette technique?
Notre Scrum Master continue de désigner les bogues comme une dette technique. A-t-il raison, les bugs sont-ils considérés comme des dettes techniques dans le monde d'Agile?
Je pense que la réponse ici est assez simple - la caractéristique clé de la dette technique est que c'est quelque chose que nous contractons par choix.
Nous choisissons de prendre des décisions d'architecture, de conception ou de mise en œuvre qui, selon nous, nous poseront des problèmes plus tard afin d'atteindre des objectifs spécifiques plus tôt.
Un bug n'est pas quelque chose que nous choisissons d'avoir dans notre code - donc de facto ce n'est pas une dette technique.
Bien sûr, on peut faire toutes sortes d'arguments intéressants (et peut-être valides) sur les choix effectués après la découverte, mais fondamentalement (et en particulier dans le contexte de la question) non, les bugs ne sont pas des dettes techniques - cela ressemble plus à un abus de mot à la mode bingo pour moi.
En tant que post-scriptum - je ne suis pas d'accord avec l'affirmation selon laquelle il est évident que la dette technique entraînera des bogues en soi, car cela fait beaucoup d'hypothèses sur la nature des choix effectués. Par exemple, vous pouvez avoir un code couvert de test bien écrit et bien structuré qui fait, par exemple, des compromis architecturaux pour une livraison précoce. De même, vous pouvez choisir de ne pas automatiser vos processus de déploiement, ce qui n'entraînera pas de bugs mais entraînera probablement beaucoup de stress et de douleur. Bien sûr, si la dette est que vous avez écrit du code qui n'est pas SOLID (ou autre)) alors oui ... mais ce n'est en aucun cas toujours le cas.
Oui.
La dette technique (également connue sous le nom de dette de conception ou de code) est une métaphore néologiste faisant référence aux conséquences éventuelles d'une architecture logicielle et d'un développement logiciel médiocres ou évolutifs au sein d'une base de code.
Source: Wikipedia
Lisez la dette technique comme quelque chose que vous auriez pu éviter en ayant un meilleur flux de travail (par exemple en faisant correctement l'architecture avant de passer au codage, en faisant TDD, etc.), de meilleures pratiques de codage, etc.
La plupart des bogues auraient pu être évités par un examen supplémentaire ou l'utilisation de méthodes plus formelles. En ne faisant pas tout ce que vous pouvez pour ne pas avoir de bogues en premier lieu, vous réduisez le coût immédiat/à court terme du projet, mais augmentez la dette technique.
Après avoir lu la réponse de BЈовић , je vois que ce n'est peut-être pas aussi facile que je le pensais.
Par exemple Les bogues font-ils partie de la dette technique? l'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, Réflexions de Christopher sur la dette technique qualifie les bogues comme résultat de dette technique, ne faisant pas partie de celle-ci. Cela étant dit, bon nombre des résultats répertoriés, comme "le coût de mise en œuvre d'une nouvelle fonctionnalité", sont influencés par le nombre de bogues.
Enfin, lors de la création modèle ABCDE-T de la dette technique , j'ai inclus les bogues comme l'un des six facteurs, mais ils sont considérés différemment. L'accent n'est pas mis sur les bogues eux-mêmes, mais sur les façons dont ils sont collectés, hiérarchisés et résolus. Les bogues 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 comme un facteur de dette technique.
Cela étant dit, je suis toujours enclin à répondre que les bogues - tous les bogues - font partie de la dette technique.
Premier argument:
En lisant la citation de Jeff Atwood, la plupart des bogues seraient 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 d'entreprise, presque tous les bogues proviennent d'un choix de conception rapide et sale ou de mauvaises pratiques (serait-ce le manque de tests, l'utilisation de technologies que les développeurs ne connaissent pas suffisamment, le manque de communication, le manque de compréhension du domaine, etc.) Cela signifie que "en refactorisant la conception rapide et sale dans la meilleure conception" et en adaptant les meilleures pratiques, les entreprises pourraient résoudre la plupart de leurs bogues.
Deuxième argument:
Si l'on fait 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, qui est tout aussi importante à prendre en compte lorsqu'un projet est vendu à une autre entreprise ou donné pour une autre équipe, nous pouvons facilement voir que les bugs font partie de la dette technique, car la nouvelle équipe:
Soit vous devez gérer ces bogues avant de créer de nouvelles fonctionnalités (point 5 du test Joel: Corrigez-vous les bogues avant d'écrire un nouveau code?)
Ou gardez les bugs, en préservant/augmentant ainsi la dette technique.
Jeff Atwood dans son article Paying Down Your Technical Debt donne une réponse assez agréable sur ce qu'est la dette technique:
la dette technique entraîne des paiements d'intérêts, qui prennent la forme d'efforts supplémentaires que nous devons faire dans le développement futur en raison du choix de conception rapide et sale. Nous pouvons choisir de continuer à payer les intérêts, ou nous pouvons rembourser le principal en refactorisant la conception rapide et sale dans la meilleure conception. Bien qu'il en coûte pour rembourser le capital, nous gagnons par la baisse des paiements d'intérêts à l'avenir.
À strictement parler, les bogues ne font pas partie de la dette technique, s'ils ne ralentissent pas le développement de logiciels (changement de choses, ajout de nouvelles fonctionnalités, etc.). Ce sont des défauts logiciels.
Cependant, lorsqu'il est trop coûteux de corriger un bogue, ou qu'il vous oblige à contourner ce problème (et à introduire encore plus de dette technique), il fait alors partie d'une dette technique.
Un bug n'est pas une dette technique. La dette technique lésine sur la qualité et non sur son absence. Le logiciel ne doit pas être livré avec des bogues en premier lieu. Vous savez, tout ce logiciel de travail sur une documentation complète.
Les plus grands contrevenants à l'endettement technique sont les "corrections de bugs temporaires", vous connaissez ceux que vous mettez en place pour réussir le test et faire accepter l'histoire. Ceux que vous vous êtes promis vous refactoriseront plus tard, mais ne le feront jamais. Au fur et à mesure que ces correctifs temporaires, correctifs et autres choses s'accumulent, le code devient inutile encombré, difficile à mettre à jour et à tester et en général est un cauchemar, mais il fait toujours son travail.
Pour étayer cette opinion, je suis allé directement à la source, Ward Cunningham. À ce sujet, Ward a fait une bonne interview il y a quelque temps avec Capers Jones, ça vaut le coup d'oeil.
Débat sur la dette technique, avec Ward Cunningham et Capers Jones
Un autre article mérite d'être lu par Martin Fowler
Martin Fowler sur la dette technique
Dans l'article de Martin, veuillez trouver le lien vers la mention originale de la dette technique par Ward Cunningham, de OOPSLA92:
Le système de gestion de portefeuille WyCash
Une citation de l'article ci-dessus:
Bien que du code immature puisse fonctionner correctement et être complètement acceptable pour le client , des quantités excessives rendront un programme impossible à maîtriser, conduisant à une spécialisation extrême des programmeurs et enfin à un manque de flexibilité produit. L'expédition du premier code, c'est comme s'endetter.
En fin de compte, la dette technique a peut-être fini par inclure des bugs pour certaines personnes, et je suppose que ça va. Je ne pense tout simplement pas que c'était l'intention initiale.
À mon avis, peu importe que vous disiez que les bogues font partie de la dette technique ... ou non.
Le fait est que les bogues existants représentent un travail supplémentaire qui peut devra être effectué à l'avenir, soit pour les corriger, soit pour les contourner.
La dette technique (comme l'étiquette est généralement utilisée) représente également un travail supplémentaire qui peut doit être effectué à l'avenir ... d'une manière ou d'une autre.
Donc, que vous disiez que les bogues connus (ou inconnus) sont une dette technique ... ou non ... n'est vraiment qu'une question de définitions. Et puisqu'il n'y a pas de définition faisant autorité1 de "dette technique", toute la discussion est un peu inutile.
Comme l'a écrit Lewis Carroll:
"Quand j'utilise un mot", a déclaré Humpty Dumpty, d'un ton plutôt méprisant, "cela signifie exactement ce que je veux dire - ni plus ni moins.".
C'est en fait ainsi que fonctionne le langage naturel. Les mots signifient ce que les gens pensent qu'ils veulent dire. Définitions de dictionnaire et ainsi de suite simplement document la façon dont les mots sont utilisés, et ils ne sont pas nécessairement une documentation exacte. Si votre Scrum Master veut qualifier les bogues connus de dette technique, qui doit dire qu'il a "tort"?
1 - Citer des gens comme Ward Cummingham et Caper Jones n'aide pas non plus. Au mieux, cela nous dit ce qu'ils veulent dire (ou ce qu'ils voulaient dire) lorsqu'ils utilisent (utilisent) l'expression. Ils ne "possèdent" pas l'expression. Bien qu'ils soient sans aucun doute des autorités sur ces questions, ce n'est que leur opinion.
À strictement parler, la réponse à votre question est non.
La dette technique peut (et entraînera probablement) des bogues, mais conclure que tout bogue est le résultat d'une dette technique met une interprétation entre deux faits: il y a un bogue et il y a une dette technique (en supposant que cela peut être conclu comme un fait).
Si votre Scrum Master affirme "en théorie" que les bogues sont le résultat d'une dette technique, il coupe les coins ronds. S'il dit cela à propos de bogues spécifiques qui réapparaissent, il a peut-être raison - nous ne pouvons pas voir la qualité du code d'ici ;-)
Il peut également avoir une plainte en cours concernant les gens qui ne l'écoutent pas au sujet de la dette technique, et donc étiqueter chaque bug comme dette technique, mais maintenant je spécule.