Résoudre les bogues les plus rentables [fermé]

Je voulais avoir une idée de la catégorisation des bogues en fonction de sa facilité de résolution et de ses avantages. par exemple, s'il y a un bug qui prendra disons une heure (double fermeture de fichier etc.) à résoudre vs un autre qui prend une journée (défaut de segmentation). Mais si la résolution du premier bogue n'est pas très importante, je travaillerai probablement sur le second.

Existe-t-il des documents de recherche qui catégorisent les bogues en fonction du rapport coût-bénéfice ou d'une mesure similaire?

Disons qu'il est possible de catégoriser les bogues en fonction des caractéristiques des bogues, par exemple vulnérabilité de sécurité, erreur de mémoire, erreur de logique, etc. Dans l'autre dimension, il pourrait y avoir des paramètres comme la difficulté (facile, moyen, difficile). Y a-t-il d'autres dimensions que je devrais rechercher. Pour simplifier les choses, je peux supposer deux choses:

1. Chaque programmeur de l'équipe est également capable de résoudre n'importe quel bug
2. Il n'y a pas de date limite

Le système typique de suivi des bogues comporte deux, voire trois champs identifiant le rapport coûts-avantages des bogues:

1. Priorité (attribuée par le propriétaire de l'entreprise)
2. Gravité (classification du bogue - critique à faible)
3. Heures estimées (une estimation du temps qu'il faudra pour le faire)

Comme vous le constatez, cela identifie le bogue sur lequel il est important de travailler.

Le système mis en avant dans PEF / REV: une métrique de suivi des bogues multidimensionnelle ajoute plus d'informations sur les composants métier et développeur pour réduire les coûts.

Toutes les valeurs sont sur une échelle 1 .. N (même valeur supérieure pour chacune).

Le PEF est identifié par l'entreprise:

• P ain - À quel point le bug est douloureux
• E ffort - Combien d'efforts il faut pour contourner le bogue
• F requency - À quelle fréquence le bogue se produit-il

REV vient du développeur:

• R isk - Quel est le niveau de risque du correctif pour le système
• E ffort - Combien d'efforts y a-t-il pour corriger le bogue
• V erifiabilité - Est-il facile de vérifier la correction de bogue

Si, par exemple, vous avez un crash qui se produit rarement et qui est facile à contourner (activez la sauvegarde automatique), cela pourrait être un PEF de 7,1,1 (score 9). Lors de la correction, cela peut impliquer un changement dans un module de base et avoir un REV de 9,3,2 (score 14).

D'un autre côté, vous pourriez avoir une gêne qui est toujours là (3,3,9 - score 15) qui a un correctif trivial (1,1,3 - score 5).

Dans cet exemple, la gêne semble être un meilleur rapport coût / bénéfice sur lequel travailler.

Le problème que vous décrivez est très courant et la meilleure réponse pourrait être «utilisez votre intuition».

Je divise généralement les bogues en trois catégories: Crashing, Annoying, Cosmetic (ils peuvent être appelés 1, 2, 3 - cela n'a pas vraiment d'importance), puis je mets une estimation globale du temps nécessaire pour corriger chaque bogue (tous les bogues doivent avoir une estimation actualisée approximative à tout moment).

Lors de la résolution des bogues Crashing> Annoying> Cosmetic, puis je fais simplement un "travail le plus court en premier" pour obtenir le plus de débit initial possible.

Je trouve qu'il est TRÈS difficile de calculer tout type d'avantage financier direct lié à la résolution d'un bug - à moins qu'il ne s'agisse d'un travail rémunéré très limité.

Une note dont vous pourriez avoir besoin est que vous devriez vraiment vivre jusqu'au cinquième point du test Joel - cela pourrait être influencé par la taille de l'équipe et la distribution entre divers autres problèmes "locaux" - mais c'est généralement un signe de bonne pratique.

Une autre considération pourrait être le type de test ou l'organisation de test qui découvre le bogue, lorsque vous essayez de déterminer l'impact et le coût du bogue et de le corriger. Les tests unitaires ou fonctionnels peuvent indiquer quelque chose dans la conception qui doit être modifié, et donc une correction précoce serait plus facile et moins coûteuse que plus tard. Les tests de système ou d'intégration peuvent indiquer quelque chose qui affecte une plus grande variété de clients. Et les tests de normes, bien que souvent non critiques pour un grand nombre de clients, peuvent entraîner une perte de certification s'ils ne sont pas corrigés et avoir un impact négatif sur l'entreprise.

Cela dit, ce n'est pas parce qu'une organisation de test particulière a un échec de test que le bogue est «critique» automatiquement. Par exemple, il pourrait être tentant de dire quelque chose comme «tous les tests système doivent réussir avant d'être expédiés, ainsi tout test système qui échoue entraîne automatiquement un bogue critique / de gravité élevée». J'espère qu'aucune organisation ne ferait cette déclaration (de bons critères de sortie de test sont une discussion différente), mais le fait est que la «gravité» du bogue doit être jugée en fonction de son impact sur le client, le produit ou l'image de l'entreprise plutôt que de savoir où et quand il est découvert.

Une façon possible de résoudre ce problème est de faire une distinction entre «gravité» et «urgence». Par exemple, à mesure que la date de sortie approche, il peut y avoir une pression de temps pour déterminer si un bogue apparemment de moindre gravité pourrait affecter un grand sous-ensemble de clients, ce qui donne au bogue une plus grande "urgence" et élève le travail sur ce bogue au-dessus de (certains) autres sur du moins jusqu'à ce que cette décision puisse être prise. Un bon équilibre entre les deux, ainsi que l'expérience et un bon jugement, aideraient à déterminer où le temps et les efforts sont consacrés.

En plus de ce que d'autres ont dit sur la classification des bogues, etc., envisagez également de regarder le couplage afférent (Ca) pour déterminer le niveau de criticité qu'un bogue particulier pourrait représenter. Si vous avez un bogue dans un module avec un nombre élevé de Ca, je pourrais envisager de corriger celui-ci en premier car cela pourrait bénéficier à d'autres composants du système. Ca vous aide à déterminer le niveau de responsabilité, et les modules responsables avec des bugs en eux nuisent à l'ensemble de l'application (en savoir plus sur Ca ici: http://www.ibm.com/developerworks/java/library/j-cq04256/index.html ).

Dans cet esprit, nous avons tendance à classer les bogues et à les placer en priorité en fonction de leur impact sur le client. Votre client variera, mais le fait de les impliquer dans la discussion entraînera en fin de compte les bogues à corriger par rapport aux autres. Ce n'est pas vraiment scientifique, mais dans l'ensemble de l'équipe, nous avons tendance à parvenir à un consensus sur la priorité et la catégorisation des bogues, tout le monde a son mot à dire sur les "gros" (toutes les parties prenantes peuvent donner leur avis), et nous empilons et rackons à partir de là.

Vous ne pouvez pas déterminer le coût réel de tous les bogues. Pour certains, il est très difficile à quantifier pour beaucoup. Par exemple, supposons que vous ayez un bogue qui entraîne un léger désalignement de tout le texte des boutons. Cela rend votre produit 1.0 un peu bâclé. Cela n'entraîne pas le plantage de votre programme ni la perte de données pour vos utilisateurs. Probablement un bug assez bon marché, non?

Et si tous les de vos clients remarque ce problème et que chaque critique le mentionne dans les critiques de votre produit. Et que se passe-t-il si ce bogue persiste de la version 1.0 à 1.1 et 1.2. Votre entreprise peut maintenant avoir la réputation d'être un peu bâclée dans le contrôle de la qualité. Quel est le coût de ce simple bug en termes de pertes potentielles de ventes pour votre entreprise pour les futurs produits? Ou, comment cela pourrait-il affecter une évaluation de votre produit - votre produit peut parfaitement répondre aux besoins de vos clients, mais n'obtient qu'un 9 sur 10 car il semble un peu bâclé.

Donc, vous devez non seulement regarder le coût d'un bug spécifique en termes de coût et de impact direct sur l'utilisateur, mais vous devez le considérer dans le contexte plus large de la façon dont il affecte la perception de votre produit. sur le marché, et comment cette perception affecte les ventes futures.

Cela peut sembler exagéré, mais ce n'est pas le cas. Au moment où j'écris ceci, vous pouvez aller sur un autre site sur le Web qui a un article sur la façon dont Apple a déplacé le "1" sur son icône de calendrier d'un pixel ou deux. Si vous effectuez une recherche, vous verrez plusieurs articles négatifs sur ce minuscule petit bug. Bien sûr, cela n'a pas affecté directement le résultat d'Apple, mais ils se présentent comme le summum du bon design, donc avoir un bug de conception affecte cette perception, même si ce n'est que légèrement.