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
la source
la source
Réponses:
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.
la source
Oui.
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:
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.
la source
Jeff Atwood dans son article Rembourser sa dette technique donne une assez bonne réponse sur ce qu'est la dette technique:
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.
la source
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:
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.
la source
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.
la source
À 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:
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.
la source