Presque tous les bogues signalés sont des bogues de haute priorité
J'ai remarqué une tendance en travaillant sur plusieurs projets logiciels: la grande majorité des bugs signalés avaient une priorité élevée/très élevée. J'ai demandé à certains collègues pourquoi cela pouvait se produire, et ils ont mentionné que si un bogue n'a pas ce niveau de priorité, il est très rare que le bogue attire l'attention des développeurs, ce qui est effectivement logique.
Donc, je voulais savoir si ce problème est courant ou si je n'ai pas eu de chance. J'ai fait une recherche rapide sur Google et j'ai constaté que certaines équipes appliquent des directives de rapport de bogues ou ont une équipe distincte de "triage des bogues". Si vous avez fait face et résolu ce problème, quelle a été l'approche qui a fonctionné pour vous?
Cette question concerne spécifiquement le problème de "l'inflation prioritaire": si vous faites face au scénario et quelles mesures résultent efficaces contre ce problème.
J'ai demandé à certains collègues ce que cela pouvait se produire et ils ont mentionné que si un bogue n'a pas ce niveau de priorité, il est très rare que le bogue attire l'attention des développeurs, ce qui est en effet logique
En fait, si vous me le demandez, ce n'est pas le cas. Plus il y a de niveaux de priorité (utilisés), plus vous disposez d'informations. Si vous n'avez effectivement qu'une seule priorité, c'est la même chose que de n'avoir aucune priorité.
Et puisque vous avez toujours le même nombre de bogues à résoudre et le même nombre d'heures de travail pour le faire, il s'ensuit qu'une autre heuristique sera utilisée, peut-être la nulle - "premier arrivé, premier servi". Et donc vous avez maintenant une métrique de priorité de bogue, sauf que c'est l'heure d'arrivée et que vous n'êtes plus sous votre contrôle.
Cela peut être un symptôme de manque de ressources allouées à la correction de bogues (il existe certaines politiques telles que " Aucune nouvelle fonctionnalité tant que les bogues ne sont pas corrigés " qui peuvent vous aider. Joel approuve ; la compréhension des limites et des conséquences est une décision commerciale ).
Dans un projet sur lequel j'ai travaillé, les bogues entrants étaient accumulés dans un "tampon sans priorité" et tous les lundis, nous révisions la liste des bogues, estimions la difficulté (une estimation très approximative; le plus souvent, nous venons juste de la mettre, "Moyenne") et les trier par temps disponible. Cela a eu tendance à réduire la liste des bogues ennuyeux, inintéressants ou pensés pour être durs; pour compenser cela, les superviseurs et le marketing avaient un certain nombre de crédits par semaine qu'ils pouvaient dépenser pour contourner la priorité des bogues préférés, et étaient remboursés pour les bogues non résolus (cela fixait une limite sur le retard d'un bogue méprisé par les développeurs) .
Il était également possible de fusionner, d'annuler et de diviser les bogues; Je me souviens d'un module qui était si désespérément imparfait que nous avons coulé une vingtaine ou une trentaine de rapports de bogues en un seul "réécriture de cette chose à partir de zéro", qui a ensuite été divisé en "énoncez clairement les entrées et sorties de la chose misérable", "écrivez des tests pour garantir que les entrées et sorties correspondent aux spécifications ", etc. Le dernier élément était "imprimer l'ancien code sur du papier recyclé, le faire sortir sur la pelouse et le mettre en feu" (nous l'avons fait aussi. Je me souviens à quel point c'était bon. Nous nous sommes relayés sur l'éloge; c'était assez hilarant ).
Après quelques marchandages, nous avions la liste des choses à faire de la semaine, qui était divisée en "va faire", "pourrait faire" et "ne peut pas faire" qui ont été reportées à la semaine prochaine. C'est là que des marchandages supplémentaires sont intervenus: nous avions dit cinquante heures à allouer aux bogues, et nous étions sûrs à 95% de corriger les vingt premiers. La direction souhaitait vivement la correction d'un vingt et unième bug et n'avait plus de crédits; nous proposerions alors d'échanger ce bogue avec un sur la liste "Will do", ou quelqu'un dirait "Sortez-moi de la sous-équipe FooBazFeature pendant quelques jours et je le ferai", ou nous dirions "Nous avons besoin de plus main-d’œuvre ".
Le système ne satisfaisait personne, vraiment, mais cela était considéré (au moins parmi les développeurs) comme un bon signe.
Certains schémas négatifs supplémentaires qui se sont révélés étaient la "Pensée pieuse" de la part des gestionnaires ("Vous avez déclaré que le bogue 57212 nécessite huit heures. C'est inacceptable. Faites-en quatre") et le "Débogage par Fiat" ("Faites ce que vous voulez" mais ces quarante bugs doivent être corrigés avant la grande démo de la semaine prochaine. Vous ne pouvez pas avoir plus de temps, vous ne pouvez pas avoir plus de monde "). Aussi le syndrome du boxeur ("je travaillerai plus dur"), qui a eu tendance à très bien fonctionner pendant une courte période , mais conduit généralement un développeur à paniquer ou à partir pour des pâturages plus verts.
Si vous rencontrez ce problème lorsque les utilisateurs attribuent des bogues de priorité toujours plus élevée, la seule solution réaliste est un mécanisme de triage. Tous les bogues sont signalés avec la priorité qu'ils souhaitent, mais un mauvais gestionnaire devra passer par chaque bogue nouvellement signalé et réinitialiser sa priorité à un niveau raisonnable.
Après un certain temps, vos utilisateurs recevront le message ou vous pourrez modifier le système de rapport afin que chaque bogue ait une priorité par défaut. S'ils veulent qu'il s'aggrave, ils devront contacter quelqu'un pour le heurter, ce qui nécessitera une justification. Ce fait à lui seul entraînera la non escalade de 99% de tous les bogues par l'utilisateur.
De toute évidence, vous avez plus de bogues que vous ne pouvez en traiter, alors vous devrez peut-être vous lancer dans une rafle de correction de bogues pour effacer le retard. Cela montrera aux utilisateurs que leurs bugs seront corrigés sans qu'ils soient marqués comme super-super-dooper-vraiment-pas-honnête-cette-fois-important.
AVERTISSEMENT: je n'ai pas encore d'expérience avec les manigances de priorité de bogue signalées par l'utilisateur. Je sais que la question le demande, mais cela pourrait aider à avoir le point de vue d'un étranger.
Votre problème n'est pas que vous avez trop de bogues de haute priorité. Votre problème est que vous avez trop de personnes qui contrôlent directement la priorité des bogues. Si chaque utilisateur peut attribuer directement une priorité à son bogue, il signalera presque automatiquement son problème comme prioritaire.
Vous pouvez faire en sorte que la priorité des bogues soit configurée par un gestionnaire ou un drone d'assistance, mais cela pourrait conduire au favoritisme et à l'ingénierie sociale, où un client obtient une priorité artificiellement plus élevée en raison de son statut ou parce qu'il sait comment créer ses messages pour les faire paraître plus importants. C'est aussi beaucoup plus de main-d'œuvre.
Il existe un terrain d'entente, où vos utilisateurs ont un certain contrôle sur la priorité, mais d'une manière qui rend plus difficile l'exploitation du système. Essentiellement, vous forcez vos utilisateurs à utiliser un modèle pour signaler des bogues. Ils sélectionnent d'abord une catégorie:
- Le programme devient inutilisable ou se bloque lorsque je fais quelque chose.
- Le programme a un défaut graphique qui affecte la fonctionnalité.
- Le programme ne me permet pas de faire quelque chose que je devrais être capable de faire.
Le programme me permet de faire quelque chose que je ne devrais pas être capable de faire. - Le programme donne le mauvais résultat quand je fais quelque chose.
- Le programme prend trop de temps pour faire quelque chose.
- Le programme a un défaut graphique qui n'affecte pas la fonctionnalité.
- Le programme présente un défaut qui ne rentre pas dans l'une des catégories ci-dessus.
Pour donner des exemples:
- Mon iPhone se bloque lorsque je reçois un message contenant des symboles hébreux.
- Mon écran de verrouillage Android est pivoté de telle sorte que la moitié de celui-ci tombe de l'écran.
- Mon Android n'accepte parfois pas mon code d'écran de verrouillage, même si j'ai entré le bon code.
- Lorsque j'essaie de naviguer sur PhoneHub.net, mon téléphone me redirige vers un site pour adultes.
- Lorsque j'ouvre l'application Facebook, l'ouverture de l'application prend une minute, même sur des connexions rapides et sans aucune autre application en cours d'exécution.
- Votre application a une faute d'orthographe.
- J'ai trouvé un défaut de sécurité dans votre programme et je voudrais le signaler.
Comme vous pouvez le voir, chacune de ces erreurs a un degré de gravité différent et les catégories sont grossièrement ordonnées en fonction de cette gravité. Vous pouvez ensuite attribuer à chaque bogue une priorité en fonction de la catégorie, qui le signale et des mots clés qui apparaissent dans la description. Les bogues de la catégorie 7 devraient voir leur priorité attribuée manuellement.
Notez que cela peut se produire de manière entièrement automatique et que vous devez laisser cela se produire automatiquement; en fait, l'automatisation est la clé ici. Les utilisateurs ont tendance à surestimer leur propre importance pour l'entreprise, de sorte qu'ils ne voient pas de problème de rapporter leurs bogues comme une priorité plus élevée qu'ils ne le devraient. ils sont moins enclins à placer délibérément leur bogue dans une catégorie différente, car cela les oblige à mentir sur le bogue.
Bien sûr, les utilisateurs peuvent toujours entrer leurs bogues dans la mauvaise catégorie. La première chose que vous devez faire est, à partir de la version 1.0, afficher un message convivial encourageant les utilisateurs à fournir des informations précises sur le bogue pour aider les développeurs à le trouver et à le corriger plus rapidement. La plupart des utilisateurs comprendront et arrêteront de signaler mal les bogues. Certains utilisateurs peuvent continuer à fournir des informations erronées. Lorsque cela se produit, envoyez à ces utilisateurs un doux rappel par courrier électronique que des informations précises sont importantes et pour ne pas abuser du système. S'ils continuent de falsifier des enregistrements, vous leur donnez un avertissement qu'ils abusent délibérément du système et que l'abus continu se traduira automatiquement par une catégorie inférieure pour leurs bogues. S'ils persistent, vous pouvez ajuster leur multiplicateur de bogues.
Vous pouvez voir des parties de ce système en place dans des situations de support à haut débit: des sociétés technologiques géantes comme Microsoft, Facebook, Google, des sociétés de jeux avec beaucoup d'utilisateurs comme Valve et Blizzard, certains gouvernements, ... Bien que je ne sois pas sûr du fonctionnement derrière la scène, vous remarquez que leur système de support utilisateur a une interface similaire à ce que je suggère ici, avec un système de catégorie strict.
Comme les gens l'ont dit, c'est pourquoi les personnes signalant des bogues ne peuvent pas attribuer de priorité. Votre équipe de développement doit contrôler sa propre affectation de tâches (dans les limites définies par la direction). Donc, quelqu'un plus haut dit "travaillez sur cette application, corrigez cette , améliorez la façon de faire ceci ", et l'équipe décide de la marche à suivre, car ce sont eux qui ont l'expertise technique nécessaire pour évaluer la meilleure façon de réaliser ce que la direction veut.
Les personnes signalant les bogues doivent attribuer l'impact ou les niveaux de gravité , qui ont défini la portée. Vous pouvez facilement appeler les gens à ne pas respecter les niveaux de gravité convenus, car vous avez des preuves matérielles de ces niveaux. Par exemple:
- Perte complète de fonctionnalités
- Perte partielle de fonctionnalité
- Réduction généralisée de l'efficacité
- Réduction d'efficacité localisée
- Agacement ou obstacle (solution de contournement existe)
- Cosmétique
- Personne n'a vraiment remarqué, a été trouvé lors d'un obscur test exploratoire
Pour commencer, vous pouvez utiliser ces niveaux comme un instrument contondant pour souligner qu'un désalignement d'un texte de titre n'est pas un bogue de niveau 1 car il ne rend pas l'application entière inutilisable. Une fois qu'ils ont l'idée, vous pouvez la rendre plus fine et commencer à débattre si le problème dans la mise à jour de cette zone de texte est un niveau 5, car vous pouvez le corriger en cliquant avec le bouton droit plusieurs fois dans la zone de texte ou un niveau 4 car cela ralentit tout le monde dans la comptabilité, ce qui réduit le nombre de formulaires traités par heure.
Une fois que vous avez obtenu des informations mesurables sur la gravité du bug pour votre organisation , l'attribution de priorité devient évidente. Tout ce qui cause actuellement le plus gros problème pour l'organisation - perte de profits, atteinte à l'image publique, mécontentement des employés, peu importe - va être une priorité élevée, et vous travaillez à partir de là.
Cela ressemble un peu à ceci:
Mgr: sur quoi travaillez-vous? Dev: ces tâches de faible priorité Mgr: ne devriez-vous pas travailler sur des tâches de haute priorité?
Client: quand mon bug sera-t-il corrigé? Dev: c'est une priorité faible, nous avons des tâches hautement prioritaires. Client: oh, alors définissez mon statut de bogue sur une priorité élevée.
Cela conduira à une escalade des niveaux de priorité. Je vois que vous êtes déjà allé au-delà de la priorité élevée à la priorité très élevée. Ce qui sera ensuite:
- Super haute priorité
- Ultra haute priorité
- Très super ultra haute priorité.
- Très super ultra méga haute priorité.
etc.
Oui, c'est un processus normal. Tant qu'il n'y a aucun coût lié à l'attribution de la priorité et que l'appelant a une influence, il essaiera bien sûr de résoudre le problème le plus rapidement possible et de définir la priorité la plus élevée.
Il existe essentiellement 2 façons de contrer cela:
- Prenez le contrôle du client sur les niveaux de priorité.
- Associez un coût au client pour des niveaux de priorité élevés.
On peut ajouter des niveaux de priorité de plus en plus élevés au système, surtout s'il s'agit de Jira. Donner des nouvelles priorités élevées de plus en plus stupides mais des noms désastreux peut augmenter le effet Hawthorne dans la qualité des choix prioritaires effectués par toutes les parties. Si la priorité la plus élevée a un nom vraiment bizarre, l'effet pourrait être permanent. Finalement, lorsque quelqu'un choisit une priorité, il doit peser les conséquences sociales du choix de la priorité "bug de la mort" par rapport à son attention. Ainsi, la plus haute priorité est de facto réservée à quelque chose qui est arrivé au CTO chez lui devant ses invités, ou à d'autres incidents de visibilité équivalente.
Introduire un coût pour soutenir les demandes. Vous pouvez uniquement autoriser un utilisateur à signaler X nombre d'éléments de priorité élevée dans une période de temps donnée, Y nombre d'éléments de priorité moyenne et Z de faible priorité.
Bien sûr, cela signifie également que l'équipe de développement et la direction devront ensuite garantir qu'un certain nombre d'entre eux seront effectivement corrigés - tous les éléments de haute priorité, la plupart des éléments de priorité moyenne et (peut-être) certains des articles de faible priorité dans un certain délai.
Mais si cela fonctionne, la direction devra en fait y adhérer, sinon tout l'exercice est une perte de temps.
À la fin de la journée cependant, votre situation particulière semble être un symptôme d'un problème que votre direction n'alloue pas suffisamment de ressources pour traiter les problèmes de support. Si les problèmes étaient traités en temps opportun, je ne pense pas que cela se produirait.
Quelque chose comme ça a été mis en œuvre dans la première entreprise pour laquelle j'ai travaillé car le processus de support était dysfonctionnel et a conduit à une situation où si tout est une urgence, rien ne l'est. Dans notre cas, après avoir maîtrisé la situation en interne, le nouveau responsable du développement logiciel a fixé une limite stricte sur le nombre de problèmes hautement prioritaires qu'un client pouvait résoudre en fonction du montant qu'il avait payé dans les contrats de support. S'ils dépassaient la limite, soit ils crachaient plus d'argent, soit le problème du support était réduit en priorité.
Il est fort possible que tous les bugs mentionnés soient de haute priorité. J'ai été sur des projets qui étaient à la fois sous-financés et sous-spécifiés, et lorsque les tests ont commencé l'AQ et les utilisateurs ont simplement renoncé à signaler les éléments de faible priorité, car ils savaient que les fautes d'orthographe ou les problèmes d'utilisation étaient une perte de temps si la fonctionnalité principale du projet a été complètement arrosé. Si votre le système de bagages automatisé fait s'écraser les chariots ensemble et détruit les bagages , qui s'en soucie si la police sur les étiquettes est 2pt trop petite?
Dans une situation comme celle-ci, le projet échoue. Si vous pensez que c'est même une possibilité, vous avez besoin d'un cœur à cœur avec les personnes signalant des défauts pour le découvrir. Si les gens gonflent les rapports de bogues, les autres réponses vous aideront. Si les bogues sont aussi mauvais que ceux signalés, alors vous devez prendre des mesures extrêmes .
Cela se produit très souvent dans les grandes entreprises où l'informatique est considérée comme accessoire et/ou est externalisée. Les gens d'affaires ne comprennent pas les logiciels et s'en moquent, tout ce qui les intéresse, c'est que "leur" bogue soit corrigé hier, peu importe à quel point il n'est pas critique. Ils ne réalisent pas, ou ne se soucient pas, qu'il y a une centaine d'autres utilisateurs qui signalent également des bogues, et une équipe de peut-être 5 développeurs disponibles pour corriger les choses.
Ceci est exacerbé par une mauvaise gestion, en particulier les gestionnaires non informatiques qui ne peuvent pas dire "non" ou qui laissent simplement les gens d'affaires définir la priorité des bogues. (Dans les deux cas, ledit manager ne fait pas son travail.) La plupart des managers hiérarchiseront le bug pour lequel ils ont été contactés pour la dernière fois car "c'est urgent"; le résultat net est que les développeurs finissent par sauter d'un bogue à l'autre, donc la correction d'un seul bogue prend plus de temps (changement de contexte), et à la fin de la journée, tout le monde est mécontent. "Lorsque chaque bogue est un bogue de haute priorité, aucun bogue n'est de haute priorité."
J'ai été dans cette situation, et en général, la seule façon d'y échapper est de sortir. Les directives de rapport de bogue sont toujours ignorées car les utilisateurs ne donnent pas de s ** t. Tenter d'introduire le triage des bogues sera soit résisté, soit implémenté puis ignoré la prochaine fois qu'un utilisateur appellera votre responsable pour se plaindre de "leur" bogue.
Fondamentalement, si les développeurs n'ont aucun contrôle sur la priorité, vous avez déjà perdu.
En tant qu'entreprise, vous souhaitez résoudre les problèmes avec le rapport importance/coût le plus élevé. L'utilisateur décide de l'importance, l'ingénierie décide du coût. Si les utilisateurs accordent la même importance à tous les bogues, alors le coût seul compte.
Concrètement, cela signifie que vous définissez la priorité comme importance/coût et que vous ne permettez pas aux utilisateurs ou aux développeurs de définir cette priorité directement. Aucun des deux côtés n'a l'image complète.
Si les utilisateurs décident de noter tous les problèmes de la même manière, ce n'est pas grave - mais cela signifie que l'ingénierie (le coût) décide de ce qui est fait. Expliquez-leur que l'importance est le seul moyen par lequel ils peuvent influencer (mais pas décider) la priorité.
Quelques facteurs ...
- Souvent, la personne signale que le bogue ne connaît pas la situation dans son ensemble et n'est pas en mesure de décider de son importance.
- Souvent, les bogues de faible priorité ne sont jamais triés ou pris en compte, il est donc préférable de donner une priorité trop élevée et de laisser la personne qui effectue le triage la réduire.
- En tant que développeur, j'ai souvent examiné le rapport de bogue et constaté qu'il y avait un problème de très haute priorité derrière le bogue, mais le chef de produit effectuant le triage ne se souciait pas du bogue.
Je pense donc que tous les rapports de bogues doivent être examinés RAPIDEMENT par un à deux développeurs expérimentés, en ajoutant leurs réflexions au rapport de bogue, puis le bogue doit être trié. S'attendre à ce que la personne qui trouve le bogue puisse définir une priorité utile au moment où il le trouve, c'est tout simplement trop demander.
La plupart a déjà été dit, mais je distillerais la liste des "bogues du zoo" jusqu'à quelque chose d'un peu moins granulaire:
A: Le bug arrête l'utilisateur mort sur ses traces, donne une sortie erronée, rend généralement le système/fonctionnalité/fonction inutilisable. C'est un bug "de haute priorité".
B: Tout le reste. Ce sont des bogues "négociables".
Les bugs NÉGOCIABLES relèvent d'une variété de préoccupations (que vous mettriez dans votre propre ordre particulier):
1: Bogues qui affectent la sécurité;
2: Bogues qui affectent la convivialité (adéquation à l'usage prévu);
3: Bugs qui ont un impact sur l'esthétique;
4: Bogues qui affectent les performances (un sous-ensemble de convivialité peut-être?);
5: Bugs qui offensent vos sensibilités en tant que programmeur professionnel;
6: Bogues qui diminuent la CONFIANCE DE L'UTILISATEUR;
Voilà donc le monde utopique dans lequel aucun de nous ne vit réellement. soupir Pour compléter ma réponse à la question posée par le PO, dans toute l'industrie du logiciel, c'est Il est tout à fait courant que les efforts de développement soient dans un état où chaque bogue est prioritaire, un super-banger spécial. Et vous savez ce qu'ils disent de "spécial": quand tout le monde est spécial, personne n'est spécial.
Fondamentalement, ce problème est enraciné dans le problème de la décentralisation des priorités. Il devrait toujours y avoir un nombre impair de personnes capables de hiérarchiser la charge de travail d'une équipe, et 3, c'est trop. Pour qu'une seule personne soit responsable du tri effectif. Et ce devrait être un gestionnaire/analyste, en consultation avec un chef de file/architecte de développement. Et le processus est assez simple et peut également être appliqué aux demandes de fonctionnalités. Quel est le coût du développement? Quelle est la valeur du résultat attendu pour l'entreprise. La sortie de cette fonction est la priorité assignée.
Bien sûr, chaque utilisateur souhaite que son problème soit résolu en premier. Et dès que vous le permettez, le chaos. Vous n'avez aucune priorité valide. Vous avez besoin que cela soit fait par une seule personne autorisée (consultant d'autres personnes si nécessaire), qui a une VISIBILITÉ sur TOUS les problèmes et besoins commerciaux, et suffisamment compétente pour rassembler les conseils d'experts commerciaux et informatiques requis et ainsi générer des estimations raisonnablement précises des mesures. au dessus de.
Au risque d'indiquer l'évidence, je vais supposer qu'il n'y a pas de logiciel de suivi des bogues qui définit les bogues à haute priorité par défaut (ou qui a été défini sur ce paramètre).
Je crains qu'en l'absence de contrôles, il s'agit du scénario par défaut pour plusieurs équipes, clients, etc. qui signalent. Si le statu quo est abusé, une sorte de processus de triage est définitivement en ordre.
Un gain rapide que j'ai vu très bien fonctionner dans le passé est que P1 (bogues de priorité absolue) génère une pléthore d'alertes de gestion. Si le système a été maltraité, il est immédiatement détruit. Ou si cela est vraiment urgent, une conférence téléphonique ou une réunion physique arrive pour résoudre le problème dès que possible.
Je suppose ici que vous parlez de tous bugs et pas seulement ceux du développement initial. Si vous êtes généralement un pistolet de développement de terrain vert à louer, il n'est certainement pas inhabituel que la plupart des bogues soient prioritaires après la version alpha initiale.
Vous ne pouvez pas simplement avoir une priorité et vous attendre à ce que tout fonctionne comme par magie. Parfois, les gens le découvrent d'eux-mêmes, mais pas toujours.
Pour attribuer correctement les priorités, il doit y avoir une définition exacte de ce qui constitue chaque priorité. Ces critères doivent être objectifs, pour éviter le favoritisme des bogues et la priorisation politique. Si les critères objectifs ne sont pas respectés, vous devez obliger l'équipe à le suivre.
Il n'y a vraiment aucun moyen de contourner cela - si vous ne pouvez pas avoir de critères objectifs pour savoir quel bug va où, et si les gens refusent volontairement d'honorer ces critères, vous pourriez tout aussi bien ne pas avoir de priorités assignées par le demandeur - soit vous passer de priorités, soit un tiers attribue la priorité comme d'autres l'ont suggéré. Les données externalisées ne fonctionnent que si les auteurs sont coopératifs et ne sabotent pas activement la collecte de données.
Si la difficulté vient de l'impossibilité de créer des critères objectifs, vous pouvez utiliser des critères relatifs:
- Avoir une simple file d'attente de tous les bugs. Les utilisateurs peuvent insérer des bogues n'importe où dans la file d'attente. Ils ne doivent s'insérer à une position donnée que s'ils estiment que leur bug est plus important que tout ce qui se trouve en dessous. Les correctifs de bogues commencent par le haut de la file d'attente.
- En supposant que vous avez déjà un ensemble de bogues bien classés, dites à tout le monde que la condition pour mettre un bogue en priorité
Xest qu'il doit être plus important que tous les bogues en prioritéX-1. - Dites aux auteurs qu'à aucun moment le nombre de bogues avec priorité
Xne peut dépasser le nombre de bogues avec prioritéX-1.
Mais il semble que votre problème ne soit pas la définition, mais la conviction parmi les auteurs que les bogues de faible priorité ne sont pas corrigés. Vraisemblablement, vous ne pouvez pas les persuader autrement, puisque (d'après ce que vous dites) leur croyance est en fait fondée. Alors, pourquoi leur faites-vous soumettre ces bogues? Cela finit par n'être rien d'autre qu'un travail intense. Vous pourriez, par exemple, après avoir atteint un certain nombre de bogues actifs, dire à tout le monde de ne pas prendre la peine de faire des rapports à moins qu'il ne trouve qu'ils ont trouvé quelque chose de plus important que la plupart des bogues en suspens. Certes, ce n'est que la solution de file d'attente avec une limite supérieure sur la longueur de la file d'attente.