Presque chaque bogue signalé est un bogue de haute priorité [fermé]

J'ai remarqué une tendance lorsque je travaillais sur plusieurs projets logiciels: la grande majorité des bogues signalés avaient une priorité haute / très haute. J'ai demandé à certains collègues pourquoi cela se produisait et ils ont mentionné que si un bogue n'a pas ce niveau de priorité, il est très rare qu'il attire l'attention des développeurs, ce qui est logique.

Je voulais donc savoir si ce problème est commun ou si je n’ai que de la malchance. J'ai effectué une recherche rapide sur Google et j'ai constaté que certaines équipes appliquaient les directives de rapport de bogue ou avaient une équipe distincte de "triage des bogues". Si vous avez résolu et résolu ce problème, quelle a été l'approche qui a fonctionné pour vous?

Cette question concerne spécifiquement le problème "Inflation prioritaire": Si vous êtes confronté au scénario et quelles mesures sont efficaces contre ce problème.

J'ai demandé à certains collègues ce qui se passait et ils ont mentionné que si un bogue n'a pas ce niveau de priorité, il est très rare qu'il attire l'attention des développeurs, ce qui est logique.

En fait, si vous me demandez, ce n’est pas le cas. Plus vous avez de niveaux de priorité (utilisés), plus vous avez d'informations. Si vous n’avez qu’une seule priorité, c’est la même chose que de ne pas avoir de priorité du tout.

Et comme vous avez toujours le même nombre de bugs à traiter et le même nombre d'heures de travail, il s'ensuit que d'autres heuristiques seront utilisées, éventuellement la valeur 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 qu'elle n'est plus sous votre contrôle.

Cela peut être le symptôme d’une insuffisance de ressources allouées à la résolution des bogues (certaines règles, telles que « Aucune nouvelle fonctionnalité tant que les bogues n’ont pas été corrigés », peuvent y contribuer. Joel approuve ; comprendre les limites et les conséquences est une décision de gestion ).

Dans un projet où j'ai travaillé, les bogues entrants étaient accumulés dans un "tampon sans priorité" et chaque lundi, nous examinions la liste des bogues, estimions la difficulté (une estimation très approximative; le plus souvent, nous ajoutions simplement "Moyenne") et triez-les par temps disponible. Cela a eu tendance à faire tomber la liste des bugs ennuyeux, sans intérêt ou pensant être durs; pour compenser cela, les superviseurs et le marketing disposaient d'un certain nombre de crédits par semaine qu'ils pouvaient dépenser pour dépasser la priorité des bogues préférés et étaient remboursés pour les bogues non résolus (ce qui limitait le délai de traitement d'un bogue méprisé par les développeurs). .

Il était également possible de fusionner, d’annuler et de scinder des bugs; Je me souviens d'un module qui était si imparfaitement défectueux que nous avons glissé quelque vingt ou trente rapports de bogues dans un seul "réécrire cette chose à partir de zéro", qui a ensuite été scindé en "indiquer clairement les entrées et les sorties de la chose misérable", "écrire des tests faire en sorte que les entrées et les sorties correspondent aux spécifications ", etc. Le dernier article était "imprimer l'ancien code sur du papier recyclé, le faire ressortir sur le gazon et le mettre au feu" (nous l'avons fait aussi. Je me souviens à quel point c'était agréable. Nous avons joué à tour de rôle à l'éloge funèbre; c'était assez hilarant )

Après un peu de marchandage, nous avions la liste des tâches de la semaine, divisée en "va faire", "pourrait faire" et "ne peut pas faire" à laquelle nous avons été renvoyés la semaine prochaine. C'est là qu'intervenait un marchandage supplémentaire: nous avions cinquante heures à consacrer aux bogues et nous étions sûrs à 95% de corriger les vingt premières heures. La direction souhaitait vivement que le 21ème bogue soit corrigé et qu'il ne reste plus de crédits; nous proposerions alors d'échanger ce bogue avec un de la liste "À faire", ou quelqu'un dirait "Lâchez-moi de la sous-équipe FooBazFeature pendant quelques jours et je le ferai", ou nous dirions "Nous avons besoin de plus main d'oeuvre ".

Le système ne satisfait vraiment personne, mais on croit que cela (du moins parmi les développeurs) est un bon signe.

Parmi les autres tendances négatives apparues, citons la "pensée imaginaire" de la part des responsables ("Vous avez déclaré que le bogue 57212 nécessite huit heures. C’est inacceptable. Choisissez quatre") et le "Debug by Fiat" ("Faites ce que vous voulez mais ces quarante bogues 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 personnes "). De plus, le syndrome de Boxer ("je travaillerai plus dur"), qui avait tendance à très bien fonctionner pendant un court laps de temps , mais conduisait généralement un développeur à paniquer ou à partir pour des pâturages plus verts.

Si vous rencontrez le problème suivant: les utilisateurs attribuent des bogues de plus en plus prioritaires, la seule solution réaliste est un mécanisme de triage. Tous les bogues sont signalés avec la priorité de leur choix, mais un mauvais gestionnaire devra passer en revue chaque bogue récemment 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 génération de rapports afin que chaque bogue ait une priorité par défaut. S'ils le souhaitent, ils devront contacter quelqu'un pour le supprimer, ce qui nécessitera une justification. Ce seul fait fera que 99% de tous les bogues ne seront pas escaladés par l'utilisateur.

De toute évidence, vous avez plus de bogues que vous ne pouvez en traiter, vous devez donc peut-être vous lancer dans une rafle de corrections de bogues pour éliminer l'arriéré. Cela montrera aux utilisateurs que leurs bugs seront corrigés sans qu'il soit nécessaire qu'ils soient marqués comme super-super-exploitants-vraiment-non-honnêtes-ce-temps-importants.

AVERTISSEMENT: Je n'ai pas encore eu l'expérience des manigances de priorité de bogues signalées par les utilisateurs. Je sais que la question le demande, mais cela peut aider d’avoir la perspective d’un étranger.

Votre problème n'est pas que vous avez trop de bogues hautement prioritaires. Votre problème est que trop de personnes contrôlent directement la priorité des bogues. Si chaque utilisateur peut attribuer directement une priorité à son bogue, il signalera presque automatiquement que son problème est hautement prioritaire.

Vous pouvez faire en sorte que la priorité des bogues soit configurée par un responsable ou un drone de support technique, mais cela peut conduire à du favoritisme et à une ingénierie sociale, dans laquelle un client obtient artificiellement une priorité plus élevée en raison de son statut ou parce qu'il sait comment élaborer ses messages. leur donner l'air plus important. C'est également beaucoup plus laborieux.

Il existe un terrain d'entente dans lequel 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 obligez vos utilisateurs à utiliser un modèle pour signaler les bogues. Ils sélectionnent d'abord une catégorie:

1. Le programme devient inutilisable ou se bloque lorsque je fais quelque chose.
2. Le programme a un défaut graphique qui affecte la fonctionnalité.
3. 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.
4. Le programme donne un résultat erroné lorsque je fais quelque chose.
5. Le programme prend trop de temps pour faire quelque chose.
6. Le programme a un défaut graphique qui n’affecte pas la fonctionnalité.
7. Le programme a un défaut qui ne rentre pas dans l’une des catégories ci-dessus.

Pour donner des exemples:

1. Mon iPhone se bloque lorsque je reçois un message contenant des symboles hébreux.
2. Mon écran de verrouillage Android est pivoté de telle manière que la moitié de celui-ci tombe de l'écran.
3. Parfois, mon téléphone Android n'accepte pas mon code lockscreen, même si j'ai saisi le bon code.
4. Lorsque j'essaie d'accéder à PhoneHub.net, mon téléphone me redirige vers un site pour adultes.
5. Lorsque j'ouvre l'application Facebook, cela prend une minute, même avec des connexions rapides et sans aucune autre application en cours d'exécution.
6. Votre application a une faute d'orthographe.
7. J'ai trouvé un problème de sécurité dans votre programme et je voudrais le signaler.

Comme vous pouvez le constater, chacune de ces erreurs a un niveau de gravité différent et les catégories sont ordonnées en gros en fonction de cette gravité. Vous pouvez ensuite attribuer à chaque bogue une priorité en fonction de la catégorie, de son rapport et des mots-clés qui apparaissent dans la description. Les bogues de la catégorie 7 devraient avoir leur priorité assignée manuellement.

Notez que cela peut se produire de manière entièrement automatique et vous devriez laisser cela se faire 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 d'inconvénient à signaler 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 à propos du bogue.

Les utilisateurs peuvent toujours entrer leurs bogues dans la mauvaise catégorie bien sûr. La première chose que vous devriez faire est, à partir de la version 1.0, d'afficher un message amical encourageant les utilisateurs à fournir des informations précises sur le bogue afin d'aider les développeurs à le trouver et à le résoudre plus rapidement. La plupart des utilisateurs comprendront et arrêteront les erreurs de déclaration erronées. Certains utilisateurs peuvent toujours continuer à fournir des informations erronées. Lorsque cela se produit, envoyez à ces utilisateurs un léger rappel par courrier électronique leur indiquant qu'il est important de disposer d'informations précises et d'éviter d'abuser du système. S'ils continuent à falsifier des enregistrements, vous les avertissez qu'ils abusent délibérément du système. Si vous continuez à les utiliser, leurs bogues se verront automatiquement attribuer une catégorie inférieure. S'ils persistent, vous pouvez ajuster leur multiplicateur de bogues.

Vous pouvez voir certaines parties de ce système en place dans des situations de prise en charge à haut débit: sociétés technologiques géantes telles que Microsoft, Facebook, Google, sociétés de jeux avec beaucoup d'utilisateurs tels que Valve et Blizzard, certains gouvernements, ... Bien que je ne sois pas sûr Parmi les travaux en coulisse, vous remarquerez que leur système de support pour les utilisateurs a une interface similaire à celle que je suggère ici, avec un système de catégorie strict.

Comme les gens l’ont dit, c’est la raison pour laquelle les personnes qui signalent des bogues ne peuvent pas attribuer une priorité. Votre équipe de développement doit maîtriser sa propre tâche (dans les limites définies par la direction). Alors, quelqu'un dit plus haut « travailler sur cette application, fixer cette fonction, faire mieux à faire ce », et l'équipe obtient de décider comment aller à ce sujet, parce qu'ils sont ceux qui possèdent les compétences nécessaires pour évaluer la mieux pour réaliser ce que la direction veut.

Les personnes qui rapportent les bogues doivent attribuer des niveaux d’ impact ou de gravité , qui ont une portée définie. Vous pouvez facilement interpeller des personnes qui ne respectent pas les niveaux de gravité convenus, car vous disposez de preuves matérielles de ces niveaux. Par exemple:

1. Perte complète de fonctionnalité
2. Perte partielle de fonctionnalité
3. Réduction généralisée de l'efficacité
4. Réduction localisée de l'efficacité
5. Gêne ou obstacle (solution possible)
6. Cosmétique
7. Personne n'a réellement remarqué, a été trouvé lors d'un test exploratoire obscur

Pour commencer, vous pouvez utiliser ces niveaux en tant qu'instrument contondant pour signaler qu'un désalignement d'un texte de titre n'est pas un bogue de niveau 1, car il ne rend pas l'ensemble de l'application inutilisable. Une fois qu’ils ont eu l’idée, vous pouvez le rendre plus précis et commencer à débattre de la question de savoir si le problème de la mise à jour de cette zone de texte est de niveau 5, car vous pouvez le corriger en cliquant avec le bouton droit de la souris à quelques reprises ou de niveau 4. parce que cela ralentit tout le monde en comptabilité, ce qui réduit le nombre de formulaires traités par heure.

Une fois que vous avez obtenu des informations utiles et mesurables sur la gravité du bogue pour votre organisation , l'attribution d'une priorité devient évidente. Tout ce qui cause actuellement le plus gros problème à l'entreprise - perte de profits, atteinte à l'image du public, malheur des employés, etc. - va devenir une priorité élevée et vous travaillez à partir de là.

Ça va un peu comme ça:

Mgr: sur quoi travaillez-vous? Dev: cette tâche 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é basse, nous avons des tâches hautement prioritaires. Client: oh, eh bien, réglez mon statut de bogue sur une priorité élevée.

Cela conduira à des niveaux de priorité toujours plus élevés. Je vois que vous êtes déjà passé de la haute priorité à la très haute priorité. Quelles seront les prochaines sont:

1. Super Haute Priorité
2. Ultra haute priorité
3. Très Super Ultra Haute Priorité.
4. Très Super Ultra Mega Haute Priorité.

etc.

Oui, c'est un processus normal. Dans la mesure où l'attribution de la priorité est gratuite et que l'appelant a une influence, il va de soi qu'il essaiera de résoudre son problème de la manière la plus rapide et qu'il définira la priorité la plus élevée.

Il y a fondamentalement 2 façons de contrer cela:

1. Prenez le contrôle du client en ce qui concerne les niveaux de priorité.
2. Associez un coût au client pour les 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 aux nouvelles hautes priorités des noms de plus en plus bêtes mais terribles peut accroître l' effet Hawthorne sur la qualité des choix prioritaires faits par toutes les parties. Si la priorité la plus haute porte un nom vraiment bizarre, l’effet pourrait être permanent. En fin de compte, lorsque quelqu'un choisit une priorité, il doit peser les conséquences sociales du choix de la priorité "insecte de la mort" par rapport à l'attention qu'il mérite. Ainsi, la priorité la plus élevée est de facto réservée à quelque chose qui est arrivé à l'OTC chez lui devant ses invités, ou à d'autres incidents de visibilité équivalente.

Introduire un coût pour supporter les demandes. Vous pouvez uniquement autoriser un utilisateur à signaler un nombre X d'éléments de priorité élevée sur une période donnée, un nombre Y d'éléments de priorité moyenne et une priorité faible Z.

Bien entendu, cela signifie également que l'équipe de développement et la direction vont devoir ensuite garantir qu'un certain nombre de ces problèmes seront effectivement résolus - tous les éléments de priorité élevée, la plupart des éléments de priorité moyenne et (peut-être) certains articles de faible priorité dans un certain délai.

Mais si cela doit fonctionner, la direction devra en réalité y adhérer, sinon tout l'exercice est une perte de temps.

En fin de compte, toutefois, votre situation particulière semble être le symptôme d'un problème lié au fait que votre direction n'alloue pas suffisamment de ressources pour traiter les problèmes de support. Si les problèmes étaient réglés rapidement, je ne pense pas que cela se produirait.

Quelque chose comme cela a été mis en œuvre dans la première entreprise pour laquelle je travaillais car le processus de support était dysfonctionnel et conduisait à une situation où, si tout est une urgence, rien ne l'est. Dans notre cas, après avoir maîtrisé la situation interne, le nouveau responsable du développement logiciel a imposé une limite stricte au nombre de problèmes hautement prioritaires qu'un client pouvait créer en fonction du montant payé en contrats de support. S'ils dépassaient la limite, ils touchaient plus d'argent ou la question du soutien était réduite en priorité.

Cela se produit extrêmement souvent dans les grandes entreprises où l'informatique est considérée comme une activité auxiliaire ou externalisée. Les gens d’affaires ne comprennent pas les logiciels et ne s’y intéressent pas. Tout ce qui les intéresse, c’est que "leur" bogue soit corrigé hier, quelle que soit sa gravité. Ils ne réalisent pas, ou se moquent, qu'il y a une centaine d'autres utilisateurs qui déposent également des bogues, et une équipe d'environ 5 développeurs disponibles pour résoudre le problème.

Cela est aggravé par une gestion médiocre, en particulier par les non-responsables informatiques qui ne peuvent pas dire "non" ou qui permettent simplement aux gens d'affaires de définir la priorité des bogues. (Dans les deux cas, ledit responsable ne fait pas son travail.) La plupart des responsables hiérarchiseront le bogue pour lequel ils ont été contactés en dernier parce que "c'est urgent"; Le résultat net est que les développeurs sautent de bogue en bogue, ce qui prend plus de temps pour corriger un bogue (changement de contexte) et à la fin de la journée, tout le monde est malheureux. "Lorsque chaque bogue est un bogue de haute priorité, aucun bogue n’est de haute priorité."

Je suis dans cette situation et, généralement, le seul moyen de s’échapper est de sortir. Les instructions de rapport de bogue sont toujours ignorées car les utilisateurs ne donnent pas ** **. Si vous tentez d’introduire un triage des bogues, on résoudra ou on le mettra en œuvre, puis il sera 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 que société, vous souhaitez résoudre les problèmes avec le rapport coûts / importance le plus élevé. Les utilisateurs décident de l'importance, l'ingénierie détermine les coûts. Si les utilisateurs attribuent la même importance à tous les bogues, le coût seul est important.

Concrètement, cela signifie que vous définissez la priorité en tant qu'importance / coût et que vous n'autorisez pas les utilisateurs ou les développeurs à définir directement cette priorité. Aucune des deux parties n'a une image complète.

Si les utilisateurs décident d’accorder une importance égale à tous les problèmes, c’est acceptable, mais cela signifie que l’ingénierie (le coût) décide 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 qui signale le bogue ne connaît pas la situation dans son ensemble et est incapable de décider de son importance.
• Souvent, les bogues de faible priorité ne sont jamais triés ou considérés, il est donc préférable de donner une priorité trop élevée et de laisser la personne qui effectue le triage l’abaisser.
• En tant que développeur, j’ai souvent consulté le rapport de bogue et constaté qu’il existait un problème de très haute priorité derrière le bogue, mais le chef de produit qui effectue le triage ne se préoccupe pas du bogue.

Donc, je pense 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 bogues, puis le bogue doit être trié. Demander à la personne qui trouve le bogue de pouvoir définir une priorité utile au moment où il le trouve, c'est trop demander.

Il est fort possible que tous les bogues mentionnés soient hautement prioritaires. J'ai participé à des projets sous-financés et sous-spécifiés, et lorsque les tests ont commencé, le contrôle qualité et les utilisateurs ont tout simplement renoncé à signaler les éléments non prioritaires, car ils savaient que les erreurs d'orthographe ou les problèmes d'utilisation étaient une perte de temps si les fonctionnalités essentielles du projet était complètement arrosé. Si votre système de bagages automatisé écrase des chariots et détruit des bagages , peu importe si la police de caractères sur les étiquettes est trop petite.

Dans une situation comme celle-ci, le projet échoue. Si vous pensez que cela est même une possibilité, vous avez besoin d'un coeur à coeur avec les personnes signalant des défauts pour le savoir. Si les gens gonflent les rapports de bogues, les autres réponses seront utiles. Si les bogues sont aussi graves qu’il a été signalé, vous devez prendre des mesures extrêmes .

La plupart ont déjà été dites, mais je vais résumer la liste des "bogues du zoo" en quelque chose de moins granulaire:

R: Le bogue bloque l'utilisateur dans ses traces, donne un résultat incorrect, 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 bogues NÉGOCIABLES relèvent de diverses préoccupations (que vous placeriez dans votre propre ordre):

1: Bugs ayant un impact sur la sécurité;

2: Bugs qui ont un impact sur la facilité d'utilisation (aptitude à l'usage prévu);

3: les insectes qui ont un impact sur l'esthétique;

4: Bugs qui ont un impact sur les performances (un sous-ensemble d’utilisabilité peut-être?);

5: des bugs qui heurtent votre sensibilité en tant que programmeur professionnel;

6: Bugs qui diminuent la confiance de l'utilisateur;

Voilà donc le monde utopique dans lequel aucun d'entre nous ne vit réellement. Soupir Pour compléter ma réponse à la question posée par le PO, dans l'ensemble de l'industrie du logiciel, il est tout à fait courant que les efforts de développement se trouvent dans un état où chaque bogue est une priorité- un-super-banger-special. Et vous savez ce qu’ils disent de «spécial»: lorsque tout le monde est spécial, personne n’est spécial.

Fondamentalement, cette question est enracinée dans le problème de la décentralisation de la priorisation. 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. Donc, cette personne est responsable du tri efficace. Et ce devrait être un gestionnaire / analyste, en consultation avec un chef de projet / architecte. Et le processus est assez simple et peut également être appliqué aux demandes de fonctionnalités. Quel est le coût de développement? Quelle est la valeur du résultat attendu pour l'entreprise? La sortie de cette fonction est la priorité attribuée.

Bien entendu, chaque utilisateur souhaite que son problème soit résolu en premier. Et dès que vous le permettez, le chaos. Vous n'avez pas de priorité valide. Cette opération doit être effectuée par une SEULE personne disposant d'autorité (qui consulte éventuellement d'autres personnes), qui a une visibilité sur tous les problèmes et tous les besoins de l'entreprise et qui est suffisamment compétente pour recueillir les conseils d'experts en affaires et en informatique nécessaires pour générer des estimations assez précises des métriques. au dessus de.

Au risque d’énoncer une évidence, je suppose qu’il n’existe aucun logiciel de suivi des bogues qui attribue une priorité élevée aux bogues (ou qui a été défini sur ce paramètre).

Je crains que, en l’absence de contrôles, il s’agisse du scénario par défaut pour plusieurs équipes, clients, etc., qui font rapport. Si le statu quo est abusé, une procédure de triage est absolument nécessaire.

Une victoire rapide, que j’ai très bien vue par le passé, est que P1 (bogues prioritaires) génère une multitude d’alertes de gestion. Si le système a été maltraité, il est immédiatement écrasé. Ou, si cela est vraiment urgent, une téléconférence ou une réunion physique se produit pour résoudre le problème dès que possible.

Je suppose ici que vous parlez de tous les bugs, pas seulement ceux du développement initial. Si vous êtes généralement un pistolet pour le développement de champs verts à la location, il n’est certainement pas inhabituel que la plupart des bogues soient hautement prioritaires après la publication initiale de l’alpha.

Vous ne pouvez pas simplement avoir une priorité et vous attendre à ce que tout se passe comme par magie. Parfois, les gens s'en sortent seuls, mais pas toujours.

Pour attribuer correctement les priorités, il faut définir exactement ce qui constitue chaque priorité. Ces critères doivent être objectifs pour éviter le favoritisme et les priorités politiques. Si les critères objectifs ne sont pas suivis, vous devez le faire suivre à l'équipe.

Il n’ya vraiment aucun moyen de contourner cela - si vous ne pouvez pas avoir de critères objectifs pour indiquer le bogue, et si des personnes refusent volontairement de respecter ces critères, vous pourriez aussi bien ne pas avoir de priorités assignées à l’émetteur - vous pouvez soit vous passer de priorités, soit vous devez: une tierce partie attribue une priorité comme d'autres l'ont suggéré. Les données externalisées ne fonctionnent que si les émetteurs coopèrent et ne sabotent pas activement la collecte de données.

Si la difficulté provient 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 bogue est plus important que tout ce qui se trouve en dessous. Les correcteurs de bogues commencent au début de la file d'attente.
• En supposant que vous ayez déjà un ensemble de bogues bien classés, dites à tout le monde que la condition pour placer un bogue en priorité Xest qu’il soit plus important que tous les bogues en priorité X-1.
• Dites aux soumissionnaires qu’à aucun moment le nombre de bogues avec priorité ne peut Xdépasser le nombre de bogues avec priorité X-1.

Mais il semble que votre problème ne relève pas de la définition, mais de la conviction des émetteurs que les bogues de faible priorité ne sont pas corrigés. Vraisemblablement, vous ne pouvez pas les convaincre du contraire, car (d'après ce que vous dites), leur croyance est fondée sur des faits. Alors, pourquoi leur faites-vous soumettre ces bugs? Cela finit par n'être que du travail occupé. Vous pouvez par exemple, après avoir atteint un certain nombre de bogues actifs, dire à tout le monde de ne pas déranger de faire des rapports, sauf s’ils ont le sentiment d’avoir trouvé quelque chose de plus important que la plupart des bogues en suspens. Bien entendu, il ne s'agit que de la solution de file d'attente avec une limite supérieure de longueur.