Comment affecter les priorités des bugs aux développeurs et les traiter en conséquence?

Nous avons un processus de bogue en cours de traitement.

Nous avons 3 niveaux de bug:

Bogue P1: bogues qui empêchent les utilisateurs de travailler. Ils doivent être résolus sur place.
Bogue P2: bogues qui ont un impact mais les utilisateurs peuvent travailler
Bogue P3: bogues sans impact et où les utilisateurs peuvent travailler.

P1 est obligatoire et doit être traité sur place. Mais pour P2 et P3, nous jugeons au cas par cas.

Avec les 3 niveaux que nous avons, l'équipe a tendance à travailler sur de nouveaux développements plus pressants demandés par les clients, au lieu de traiter P2 et P3, ce qui est presque comme non urgent.

Les questions sont les suivantes:

Dois-je ajouter un autre niveau de priorité, comme avoir un P4?

Dois-je également leur assigner des cibles pour traiter les tickets non urgents comme cette semaine, lorsque vous n'assignez pas de tâche de codage, vous devez traiter au moins 1 P2?

Actuellement, nous n'avons pas d'objectifs comme je l'ai mentionné plus haut, mais je crains que leur donner de tels objectifs puisse être brutal. Ce qui est sûr, c'est que je dois leur parler des objectifs, l'équipe aime être impliquée dans la discussion surtout lorsque nous fixons des objectifs.

Mise à jour:

On m'a proposé cette question en terme de similitude. Cependant, ce n'est pas du tout similaire.

Ma question est de savoir comment faire en sorte que les gens traitent les bogues, sans imposer un ordre du jour strict tout en le résolvant. Alors non, la question implicite ne m'aide pas. Encore merci.

agile debugging issue-tracking

— Andy K
source

Double possible de Comment puis - je convaincre la direction de faire face à la dette technique?

— moucher

le niveau de priorité n'est généralement pas aussi utile que l'ordre de priorité ... "bug X" est plus important que "bug Y". si vous ajoutez p4 finalement, vous voudrez p5 et p3.5

— sudo rm -rf slash

Si vous avez tellement de bogues P1 que tous vos développeurs sont toujours occupés à les corriger au lieu de travailler sur P2 / P3, vous faites quelque chose de très mal. N'ajoutez plus de fonctionnalités pendant un certain temps. Concentrez-vous sur l'exploration et la résolution des problèmes architecturaux (ou personnels) qui sont presque certainement à l'origine de bon nombre de ces bogues. Si vous codez en C ++, par exemple, assurez-vous que vous utilisez RAII partout où vous le pouvez, donc n'oubliez pas de le faire manuellement .release().

— Fund Monica's Lawsuit

Quel est ton but? Voulez-vous que les développeurs travaillent davantage sur les corrections de bogues et moins sur les nouvelles fonctionnalités? Veuillez modifier votre question pour clarifier. Veuillez également décrire comment les développeurs reçoivent ou prennent en charge le travail actuellement. Qu'est-ce qui est utilisé pour décider sur quoi travailler?

— sleske

fonctionnalité, bug, changez ce que vous l'appelez, le logiciel ne fait pas ce qu'il faut. La seule différence entre un bug et une fonctionnalité est de savoir qui le paie.

— mattnz

Réponses:

Généralement, vous avez deux axes pour les bugs: la gravité et la fréquence.

Il est donc évident que quelque chose de grave et fréquent est de la plus haute priorité. Cependant, quelque chose qui est grave mais qui se produit rarement doit être pesé à peu près de la même manière que quelque chose qui n'est pas grave mais qui arrive souvent. Donc, en supposant que vous évaluez la gravité de 1 à 3 et la fréquence de 1 à 3, les types de bogues que vous devriez probablement corriger sont ceux qui traversent la diagonale définie par la gravité 1, fréquence 3 et la gravité 3, fréquence 1.

Une erreur de blocage ou une erreur qui pourrait créer des dommages potentiels aux informations client serait toujours une gravité 3. De même, une erreur avec la gravité 1 ne sera probablement pas remarquée par l'utilisateur ou a une faible priorité. Si vous n'êtes pas sûr ici, 2 est probablement un numéro sûr à attribuer.

Une erreur que l'utilisateur voit à chaque fois que le programme est lancé va avoir une fréquence de 3. Une erreur avec la fréquence 1 va être quelque chose qui se produit rarement, voire pas du tout. Encore une fois, si vous n'êtes pas sûr, 2 est probablement un numéro sûr à attribuer.

C'est surtout subjectif sur ce qui constitue un bug de gravité 3 ou un bug de fréquence 3, mais utilisez votre bon sens. Un bug de gravité 1, fréquence 2 est peut-être une étiquette mal orthographiée. Un bogue avec gravité 2, fréquence 1, peut être une gestion correcte des erreurs lorsque la connexion à la base de données est interrompue.

Encore une fois, ce n'est qu'une idée approximative, mais l'idée est de mettre l'accent sur ce qui devrait être l'objectif de la correction des bogues comme une sorte de triage. De toute évidence, il n'est pas possible d'éliminer tous les bogues, bloquants ou autres, bien qu'au moins avec cette méthodologie, vous pouvez dire en toute sécurité que les bogues ne sont pas trop pressants ou trop fréquents. Si vous bugs corrigés uniquement qui sont des erreurs de blocage, puis les erreurs à haute fréquence seront ignorées et les utilisateurs auront remarqué que vous ne l' avez pas corriger ces bugs.

De plus, pour plus de commodité, vous pouvez trouver que vous préférez fournir des notes alphabétiques pour la gravité ou la fréquence, vous pouvez donc dire qu'un bug est une erreur B3, et il est clair à la fois la gravité et la fréquence.

Bonne chance!

— Neil
source

En réalité, il n'y a qu'une seule mesure pour les bogues - le retour sur investissement - combien cela coûtera-t-il pour corriger par rapport à ce que l'entreprise perd pour ne pas le corriger. Comparez cela aux fonctionnalités. Bien sûr, comment vous calculez cette métrique implique la gravité, la fréquence, etc.

— corsiKa

@corsiKa, oui le ROI est une métrique composite: "retour" et "investissement". Et pour les bogues, le retour peut être modélisé comme un composite de «gravité» et de «fréquence».

— Paul Draper

@corsiKa, ce genre d'analyse égoïste de sang-froid des décisions de qualité est en fait extrêmement irresponsable. C'est la même logique qui conduit les sociétés pharmaceutiques à contourner les lois sur les tests d'efficacité si elles peuvent «s'en tirer» ou à garder des médicaments rentables sur le marché malgré la gravité et la fréquence des effets indésirables. C'est la même irresponsabilité qui conduit à de vastes réseaux de zombies composés de routeurs de consommateurs non sécurisés et d'appareils «intelligents», car le fabricant ne pouvait voir aucune valeur monétaire en toute sécurité. La gravité et la fréquence sont BEAUCOUP de meilleures mesures que «l'impact net».

— Wildcard

@Wildcard Je suis littéralement communiste, donc je suis à 100% d'accord avec vous que ce sont mieux. Cela ne change pas le fait que c'est ainsi que les entreprises de logiciels sont gérées, et aller à contre-courant, à moins que vous ne dirigiez l'entreprise, vous noiera. Même si cela vaut la peine d'être noté, ce n'est pas égoïste. C'est une portion individuelle, mais ce single n'est pas le soi, c'est l'entreprise. Juste, jetant ça là-bas.

— corsiKa

@Wildcard et corsiKa, la société n'est pas une grande entreprise et nous ne pouvons pas nous permettre de dire "oh nous allons perdre de l'argent, alors faisons quelque chose sinon gardons-le immobile". Dans le grand schéma des choses, cependant, je ne pense pas que l'approche que vous avez mentionnée soit durable à long terme. People - Les clients sont loin d'être stupides. Les entreprises qui ont prêché ce genre d'évangile, Sun, pour n'en nommer qu'un, ne sont plus là. Je travaille dans la gestion de compte depuis assez longtemps pour que l'argent ne soit pas gagné de cette façon. À tout le monde, si vous travaillez pour une telle entreprise où la société manque de fidélité 1 / n

— Andy K

Cela se résume vraiment à ce que vous considérez comme plus important. Le bug P2 ou la nouvelle fonctionnalité?

Habituellement, un système de gestion de projet agile comprend une sorte de réunion de priorisation où les tâches sont ordonnées par priorité et travaillées dans cet ordre.

Les développeurs ne sont pas autorisés à choisir les tâches sur lesquelles ils travaillent. C'est le travail du chef de projet. Qui doit s'assurer que le projet comporte le plus grand nombre possible de fonctionnalités importantes incluses avant la fin du budget.

C'est vraiment la chose la plus importante. Des règles simples comme «fixer au moins 1 P2 par semaine» n'aident pas vraiment cet objectif.

— Ewan
source

Le problème avec l'attribution des priorités est que, quelle que soit la granularité du compartiment que vous choisissez, vous vous retrouvez toujours avec plus d'un par compartiment. Vous devez mettre les choses en ordre, pas seulement dire "tout cela est TOP PRIORITY!"

— Ewan

@Ewan Il y a aussi la possibilité d'une inflation prioritaire là où votre compartiment le plus élevé a plus de problèmes que vous ne pouvez jamais espérer résoudre, et de nouveaux niveaux de priorités sont inventés en dehors du système de suivi des bogues. J'ai entendu des gens parler des problèmes de P moins 2.

— kasperd

Dire aux développeurs qu'ils ne sont pas autorisés à choisir les tâches sur lesquelles ils travaillent nuira à votre productivité. Si un développeur est bloqué sur le problème le plus prioritaire sur lequel il travaillait, il est préférable qu'il puisse travailler sur un autre problème en attendant qu'il ne fasse rien pendant que son premier problème est bloqué sur quelque chose. De plus, les problèmes qui ne nuisent pas aux utilisateurs mais nuisent à la productivité des développeurs ne sont souvent pas priorisés aussi haut qu'ils devraient l'être. Enfin, dire aux développeurs qu'ils ne sont pas autorisés à prendre leurs propres décisions est un moyen sûr de détruire la motivation.

— kasperd

@kasperd Je pense que la plupart des développeurs acceptent qu'ils soient à la fois des employés et des super génies techniques et que leur employeur décide des tâches à effectuer en premier. Évidemment, si l'un est bloqué, vous passerez au suivant le plus important, mais vous ne sautez pas 10 tâches importantes pour travailler sur la plus cool.

— Ewan

J'ai trouvé que si le travail est terminé ou bloqué, au lieu de tirer une autre tâche de développement dans le sprint (faire de la mêlée), un bug devrait plutôt avoir la priorité. MS a donné à tous les bogues la priorité la plus élevée sur toutes les tâches de développement lorsqu'ils travaillaient sur Windows 2000 - ils ont constaté que c'était la meilleure façon de produire des logiciels non bogués (l'une des raisons pour lesquelles 2000 était en fait bien aimé) comme s'ils ne le faisaient pas. , les bogues avaient tendance à être éliminés car il y avait généralement un nouveau développement à travailler à la place.

— Baldrickk

C'est un cycle assez courant pour qu'un logiciel accumule des bogues non critiques jusqu'à ce que quelque chose se produise, puis un grand événement se produit et beaucoup d'entre eux sont corrigés à la fois; peut-être en consacrant un sprint ou deux à seulement des corrections de bugs avant une grosse nouvelle version, ou par le logiciel étant EOL et ayant survécu aux heap-o-bugs.

Vous êtes donc en bonne compagnie si vos développeurs les laissent simplement glisser. Bien sûr, vous pouvez jongler avec des "règles" comme vous l'avez mentionné ("si vous ne travaillez pas sur une nouvelle fonctionnalité, vous devez travailler sur au moins un P2 par semaine"), mais cela vous rendra probablement impopulaire.

Ma question est de savoir comment faire en sorte que les gens traitent les bogues, sans imposer un ordre du jour strict tout en le résolvant.

Au lieu de cela, je suggérerais de changer un peu l'état d'esprit général et de rendre les bogues plus comme des fonctionnalités dans le sens où ils sont des citoyens de première classe dans votre arriéré. Oui, les nouvelles fonctionnalités sont géniales; oui, la gestion et les ventes mettent très dur sur les nouvelles fonctionnalités. Mais il est également important d'avoir une application stable et fonctionnant bien au lieu d'une énorme pile de bogues en désordre.

Ne dites pas à vos développeurs qu'ils doivent faire un travail qu'ils n'aiment pas; mais essayez de changer l'atmosphère afin qu'ils aiment travailler sur les bugs. Essayez d'insuffler un sentiment de fierté dans une application sans bug. Faites en sorte qu'il soit plus amusant (sic) de travailler sur un bogue en leur permettant spécifiquement de corriger la raison sous-jacente qui a rendu ce bogue manifeste (c'est-à-dire, pas seulement des solutions rapides / hacks), le cas échéant. Déchirer une structure de classe cassée et la remplacer par quelque chose de plus adapté peut être très amusant pour les développeurs. Si vous avez une pièce centrale cassée qui fait régulièrement apparaître des bogues ailleurs, corrigez la pièce centrale.

La façon dont vous atteignez votre objectif dépend fortement de votre propre caractère et de celui de vos équipes - n'essayez pas de les tromper dans ce que vous voulez réaliser, mais ayez des discussions ouvertes, essayez de faire fonctionner un effet de pairs, laissez-les trouver un processus de travail eux-mêmes, etc.

— AnoE
source