Y a-t-il un avantage marginal à corriger les bogues [fermé]


27

Un ancien collègue m'a dit que tous les bogues n'avaient pas besoin d'être corrigés, car au fur et à mesure que vous descendez dans la liste des bogues prioritaires, le cas d'utilisation qui provoque ce bogue devient plus obscur ou la satisfaction client acquise diminue. Mais vous devez encore passer beaucoup de temps à corriger ce bogue.

Dans un effort pour convaincre notre propriétaire de produit de ce concept, je n'ai pas pu trouver de bonnes ressources. Tout ce que j'ai pu trouver, c'est des discussions sur la question de savoir s'il y a un coût marginal dans le développement de logiciels ou non.

Y a-t-il un avantage vraiment marginal à corriger les bogues? Y a-t-il un terme différent qui explique ce concept?



2
Votre question n'est pas très claire. « Tous les bogues sont nécessaires pour être fixes » il y a certains qui ne valent pas être fixés. "Y a-t-il un avantage vraiment marginal à corriger les bogues", me dit-on, vous voulez dire quelque chose de différent. Pouvez-vous s'il vous plaît expliquer?
Doc Brown

2
N'est-ce pas au propriétaire du produit de comprendre? Pourquoi pensez-vous que vous devez les en convaincre?
Arrêtez de nuire à Monica le

@Goyo Je ne pose pas cette question spécifiquement pour les convaincre. C'est un concept que j'ai rencontré il y a quelque temps mais qui ne trouve plus de ressources. De plus, il n'est pas rare qu'un développeur de logiciel soit en position de gestion. Donc, moi-même, je pourrais avoir besoin de ces informations à l'avenir.
Gökhan Kurt

2
@ GökhanKurt: Il ne résulte pas de "Tous les bugs doivent être corrigés" qu'ils sont tous également importants. Certains peuvent être plus perturbateurs que d'autres et ont donc une priorité plus élevée.
JacquesB

Réponses:


66

D'un point de vue commercial, une correction de bogue n'est pas différente d'une demande de fonctionnalité. Il a un certain coût en temps de développement, et il a une certaine valeur pour les clients. Si un bogue n'est pas critique, il peut être tout à fait judicieux sur le plan commercial de prioriser une fonctionnalité précieuse au-dessus du correctif de bogue.

Mais d'un point de vue technique, les bogues peuvent être plus critiques, car ils indiquent une erreur dans une fondation sur laquelle un autre code pourrait utiliser / s'appuyer, auquel cas l'erreur est "contagieuse" et augmente les coûts de maintenance future. Donc , pas la fixation d' un bug est une dette technique qui exige que la direction, tout en ne mettant en œuvre une fonction n'a pas vraiment un coût permanent. Mais le niveau de dette technique encourue par un bug dépend beaucoup de la nature du bug.

Tous ces facteurs doivent être pris en considération lors de l'établissement des priorités.

Quant à savoir s'il y a un avantage marginal à corriger les bogues: c'est une donnée. Étant donné que tous les bogues n'ont pas la même gravité, vous priorisez naturellement les bogues les plus importants en premier. Donc, plus vous corrigez de bogues, plus la valeur marginale de la correction du suivant est faible. Mais s'il atteint le niveau de correction du bug ne vaut pas la peine, c'est une décision commerciale plutôt qu'une décision technique.


J'aime cette réponse, mais je n'irais pas jusqu'à dire qu'une nouvelle fonctionnalité n'a pas de coût permanent. Cela nécessite généralement de rendre le code plus général pour accueillir les nouvelles fonctionnalités, et vous devrez vivre avec le niveau d'abstraction le plus élevé, quelle que soit la valeur réelle de la fonctionnalité.
Doval

25
@Doval Vous vous méprenez. Ce que Jacques a dit, c'est qu'une fonctionnalité qui n'a pas encore été écrite n'a pas de coût de fonctionnement. Ou en d'autres termes, ne pas avoir de fonctionnalité ne rend pas plus difficile l'implémentation d'une fonctionnalité différente (sauf si cette dernière dépend de la première, bien sûr). Un bug, d'autre part, rend plus difficile de faire autre chose que de le corriger. En tant que tels, les «fonctionnalités non écrites» et les «bogues non corrigés» sont différents, en ce que le premier n'a pas d'impact sur votre base de code, tandis que le second le fait.
Sebastian Redl

3
J'ajouterais qu'un bug peut aussi avoir un gros impact sur l'image du programme (et donc du produit dans son ensemble, et de l'entreprise qui l'a produit) ... Il faut en tenir compte: est-ce qu'on veut laisser un bug lorsque, s'il est trouvé, peut coûter à l'entreprise des clients et / ou des affaires?
Olivier Dulac

2
À titre d'exemple de bogues contagieux: dans l'un de mes projets, tout fonctionnait bien, sauf que la mémoire était libérée dans un morceau de code qui ne fonctionnait pas toujours. En l'occurrence, dans tout le code que j'avais écrit jusqu'alors, c'était toujours le cas; Je n'ai eu ni fuite de mémoire ni double libération, juste quelques journaux de débogage qui semblaient hors service. Depuis que les choses fonctionnaient, je ne l'ai pas réparé. Ensuite, j'ai ajouté du code, ceux qui ne sont plus alignés, et j'ai commencé à avoir des fuites de mémoire. De tels bugs sont mineurs, mais méritent d'être corrigés; malheureusement, ils sont également difficiles à distinguer des bogues réellement mineurs.
Fund Monica's Lawsuit

5
Juste pour développer le point de @ OlivierDulac, un bogue peut faire penser à un utilisateur final "Je ne peux pas faire confiance à ce logiciel pour être fiable" et l'abandonner, malgré ses fonctionnalités. Je suis sûr que nous avons tous installé des logiciels qui semblaient vraiment utiles seulement pour le désinstaller quelques minutes plus tard, car cela semblait glitch. Alors qu'une fonctionnalité manquante peut être remarquée, mais laissez l'utilisateur final penser "je vais continuer à l'utiliser parce que j'aime les fonctionnalités qu'il possède". Je ne pense pas que les bogues et les fonctionnalités devraient être considérés comme équivalents d'un point de vue commercial.
Jon Bentley

12

Voici une bonne référence

http://www.joelonsoftware.com/articles/fog0000000043.html

Corrigez-vous les bugs avant d'écrire un nouveau code? La toute première version de Microsoft Word pour Windows était considérée comme un projet de «marche vers la mort». [...] parce que la phase de correction de bugs ne faisait pas partie du planning formel [...]

Microsoft a adopté universellement quelque chose de [...] la plus haute priorité est d'éliminer les bogues avant d'écrire tout nouveau code [...] En général, plus vous attendez avant de corriger un bogue, plus il est coûteux (en temps et en argent) de corriger .

Vous pouvez être sûr que plus ces bogues resteront longtemps, plus il faudra de temps pour les corriger une fois qu'ils deviendront prioritaires. Ainsi, au lieu d'avoir un avantage brut en ce moment, vous évitez une perte plus coûteuse à l'avenir.

Une bonne façon de gérer cela serait de définir une quantité de temps allouée pour traiter les problèmes de backlog. Cela ne pousserait pas aussi fort que Microsoft, mais cela garantira une quantité de résolution de problèmes futurs, s'ils ne sont pas déjà votre problème même si le client ne s'en soucie pas vraiment.


3

Dans un effort pour convaincre notre propriétaire de produit de ce concept, je n'ai pas pu trouver de bonnes ressources.

En supposant que vous travaillez pour une organisation commerciale, il y aura sûrement quelqu'un là-bas qui est au courant de l' analyse coûts-avantages .

Votre organisation dispose d'une quantité limitée de ressources pour les développeurs et d'une liste infinie de choses bénéfiques à faire. Ces avantages sont à la fois l'ajout de nouvelles fonctionnalités et la suppression de bogues existants - la suppression d'un bogue améliore le logiciel, tout comme l'ajout d'une nouvelle fonctionnalité.

Donc, évidemment, il y a des décisions à prendre sur la façon d'allouer cette ressource finie à cette liste infinie, et il n'est pas particulièrement surprenant que le résultat soit que certains bogues ne soient pas corrigés en ce moment, ou la semaine prochaine, ou l'année prochaine, ou dans fait jamais.

Si vous recherchez une approche plus structurée ici, vous pouvez essayer le système PEF / REV qui attribue des numéros aux vues Utilisateur et Programmeur d'un bogue, comme point de départ pour décider de ce qui sera corrigé - et de ce qui ne le sera pas.

Voir également ces deux articles ici sur le génie logiciel:

Résoudre les bogues les plus rentables

Presque tous les bogues signalés sont des bogues de haute priorité


2

Tous les aspects involontaires ou indésirables du comportement du logiciel ne sont pas tous des bogues. Ce qui est important, c'est de s'assurer que le logiciel dispose d'une gamme de conditions utiles et documentées dans lesquelles il peut être utilisé pour fonctionner de manière utile. Considérons, par exemple, un programme qui est censé accepter deux nombres, les multiplier et produire les résultats, et qui génère un faux numéro si le résultat est supérieur à 9,95 mais inférieur à 10,00, supérieur à 99,95 mais inférieur à 100,00, etc. Si le programme a été écrit dans le but de traiter des numéros dont le produit est compris entre 3 et 7, et ne sera jamais appelé à en traiter d'autres, la correction de son comportement avec 9,95 ne le rendrait pas plus utile pour son objectif. Cela pourrait cependant rendre le programme plus adapté à d'autres fins.

Dans une situation comme celle ci-dessus, il y aurait deux solutions raisonnables:

  1. Résolvez le problème, si cela est possible.

  2. Spécifiez les plages dans lesquelles la sortie du programme serait fiable et indiquez que le programme ne peut être utilisé que sur des données connues pour produire des valeurs dans des plages valides.

L'approche n ° 1 éliminerait le bogue. L'approche n ° 2 pourrait rendre la progression moins appropriée à certaines fins qu'elle ne le serait autrement, mais s'il n'y a pas besoin de programmes pour gérer les valeurs problématiques, cela pourrait ne pas être un problème.

Même si l'incapacité à gérer correctement les valeurs 99,95 à 100,0 est le résultat d'une erreur de programmation [par exemple, décider de sortir deux chiffres à gauche de la virgule décimale avant d'arrondir à un endroit après, ce qui donne donc 00,00], cela ne doit être considéré que comme un bug si le programme était spécifié autrement comme produisant une sortie significative dans de tels cas. [Par ailleurs, le problème susmentionné s'est produit dans le code d'impression Turbo C 2.00; dans ce contexte, c'est clairement un bogue, mais le code qui appelle le printf défectueux ne serait bogué que s'il pouvait produire des sorties dans les plages problématiques].


0

Dans un sens large, oui, tous les bogues n'ont pas besoin d'être corrigés. Il s'agit d'analyser le rapport bénéfice / risque.

Ce qui se passe généralement, c'est que l'entreprise organisera une réunion avec les responsables techniques et les parties prenantes pour discuter des bogues qui ne sont manifestement pas dans le besoin de corriger. Ils décideront si le temps (= argent) investi dans la correction du bug en vaudra la peine pour l'entreprise.

Par exemple, un «bug mineur» pourrait être une légère erreur d'orthographe / grammaire dans la section Conditions générales d'un site Web. La personne qui a soulevé cette question peut penser qu'il est trop mineur pour changer, mais l'entreprise reconnaîtrait le préjudice potentiel qu'elle pourrait causer à la marque et la facilité relative de fixer quelques caractères.

D'un autre côté, vous pourriez avoir un bogue qui semble important, mais qui est difficile à corriger et n'affecte qu'un nombre négligeable d'utilisateurs. Par exemple, un lien de bouton mineur est rompu pour les utilisateurs utilisant une ancienne version de Google Chrome et Javascript est également désactivé.

D'autres raisons pour lesquelles l'entreprise ne résout PAS un bogue pourraient être que le temps investi repousserait le projet un temps inattendu, ou que le temps du développeur serait mieux utilisé pour travailler sur d'autres correctifs / codages. Il se peut également que le bogue soit suffisamment mineur pour pouvoir être mis en ligne, puis corrigé à une date ultérieure.

J'espère que cela explique un peu mieux le concept! Je voudrais certainement éviter de penser à cela en termes généraux - chaque bug est unique et doit être traité comme tel.


-4

Car au fur et à mesure que vous progressez sur la liste des bogues prioritaires, le cas d'utilisation qui provoque ce bogue devient plus obscur, ou la satisfaction client acquise diminue.

Donc, leur «argument» est en fait

Si vous ignorez le bogue assez longtemps, l'utilisateur oubliera quel était le problème ou trouvera un moyen de le contourner.

Les bogues doivent être classés par ordre de priorité et traités "dans l'ordre", tout comme les nouvelles demandes de fonctionnalités (mais, sans doute, en plus de ces dernières).


3
Non, son argument est que les bogues de priorité inférieure ne peuvent se produire que rarement, et peuvent ne pas vraiment ajouter beaucoup de valeur à la correction (par exemple, si vous avez une horloge sur votre site Web qui est à une demi-minute ou si vous êtes un site Web erreurs à minuit le 1er janvier pour les utilisateurs en Moldavie)
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.