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.