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

50

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.

Carlos Gavidia-Calderon
la source
9
C'est pourquoi la priorité est stupide. Est-ce que X une priorité 2 n'a pas de sens, est-ce que X est plus important que Y est responsable et utile. La seule chose qui compte, c'est l'ordre.
Nathan Cooper
7
@NathanCooper Oui, mais vous voyez, si nous avons un bogue qui est vraiment important, et nous devons vraiment lui donner un petit coup de pouce supplémentaire pour que vous sachiez ce que nous faisons? C'est vrai - nous avons fixé sa priorité à 11.
gbjbaanb
6
@CarlosGavidia vous devez donc prendre le contrôle de la priorité de la personne qui soumet le bogue et trouver un autre moyen objectif de déterminer le retour sur investissement pour le réparer.
2
@ JuliaHayward personnellement, j'aime bien pef / rev, bien que je regarde spécifiquement la métrique «douleur» pour les bogues: Améliorer le triage des bogues avec l'utilisateur La douleur est également très bonne. Aucune de ces méthodes ne permet à la personne qui a signalé le bogue de définir la priorité globale du bogue (la "priorité" dans la métrique de la douleur du bogue concerne son blocage - et non l'importance de le corriger).
16
Histoire vraie: j'ai déjà résolu ce problème d'inflation prioritaire en appelant mes clients et en menaçant de renommer les différentes priorités en "orange", "kumquat" et "orangutang" s'ils ne faisaient pas un meilleur travail de différenciation. suffisamment de serveur pour que le champ reste significatif. Cela a fonctionné (ce qui était regrettable, car j'avais les privilèges d'administrateur pour créer un niveau de gravité "kumquat" et je l'attendais avec impatience)
Cort Ammon

Réponses:

42

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.

LSerni
la source
J'adore la partie "incendier". Nous avons prévu quelque chose de similaire pour l'un de nos modules :)
Roman Reiner
1
Je suis impressionné par votre système organisé / négocié et par votre capacité à épuiser les développeurs. Ce devait être un projet intense!
thanby
En fait, nous avons eu des managers intenses, et pas toujours avec une bonne dynamique humaine. Donc, de temps en temps, il y avait ... des problèmes. Certains s'en sont sortis, d'autres non.
LSerni
La question initiale est "(comment éviter) chaque bogue est hautement prioritaire". Techniquement parlant, cette réponse (acceptée!) N'y répond pas vraiment. Il se contente de mentionner "les bogues entrants ont été accumulés dans un tampon sans priorité et chaque lundi, nous examinions la liste des bogues, estimions (approximativement) la difficulté et les trier par temps disponible". Mais cette réponse donne beaucoup de bonnes observations, de bonnes pistes de réflexion.
RayLuo
@RayLuo Non, c'est une réponse. Plutôt que de demander aux journalistes d'évaluer la priorité, les développeurs attribuent cette priorité.
JAB
47

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.

gbjbaanb
la source
8
Non attends. Vous semblez prétendre ... Mais cela ne peut pas être ... Il y a en fait des développeurs qui n'ont pas plus de bogues qu'ils ne peuvent en traiter? Sérieusement? :-D
Martin Ba
49
@MartinBa YMMV, mais j’ai travaillé dans des endroits où nous avons pris notre temps pour concevoir et développer notre produit avec soin, et bien que des bugs aient été trouvés, ils étaient relativement rares. Vous, les enfants d'aujourd'hui, écrivez du code sans trop de conception au départ, il n'est donc pas étonnant que vous passiez tout votre temps à tester et à refactoriser:
)
5
En fait, si l’on passe suffisamment de temps à tester l’unité, les bugs disparaîtront rapidement. Dans une équipe Scrum, le propriétaire du produit serait celui qui réaffirmerait l'importance des bogues et ceux-ci sont censés avoir suffisamment de connaissances dans le domaine métier pour évaluer la véritable importance des bogues. Si les bogues ne se retrouvent jamais dans le carnet de commandes de sprint, le responsable du produit ne fait pas suffisamment son travail.
Cronax
14
@Cronax Si vous passez suffisamment de temps à tester vos unités de calcul, vous constaterez qu'il ne vous reste plus de temps pour écrire aucune fonctionnalité. Donc, je suppose que cela empêche les bugs d'apparaître :-)
gbjbaanb
4
@gbjbaanb tant que vous vous en tenez aux tests unitaires et que vous n'allez pas trop loin, la métrique agile / scrum habituelle consistant à dépenser 10 à 20% de ses tests unitaires à temps de développement me semble exacte. Vous ne pouvez pas tout tester, mais c'est la même chose, peu importe le type de test que vous faites et ce n'est pas le but du test. Vous vous assurez simplement que votre code fait ce qu'il est censé faire, le testeur évaluera s'il est adapté à l'usage auquel il est destiné.
Cronax
14

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.

Nzall
la source
Très bonne réponse. Les utilisateurs ne devraient même jamais être autorisés à définir eux-mêmes une priorité quelconque dans un rapport de bogue. Les catégories sont un très bon conseil. Tout réglage manuel des priorités doit être effectué par un produit propriétaire ou similaire. Dans nos projets de développement, le propriétaire du produit donne la priorité aux problèmes rencontrés lors des tests lors de réunions de discussion avec le scrum master.
Crainte
11

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à.

anaximandre
la source
Cette. Et la version courte à des fins de relations publiques est que la priorité est toujours relative à d’autres choses et ne peut donc être décidée que par comparaison avec d’autres choses dans la file d’attente. Ce n’est pas parce que votre chose doit apparemment être faite que sa priorité est prioritaire.
Steve Jessop
1
Eh bien, il ne faut pas oublier que le problème à fort impact peut être beaucoup plus difficile à traiter qu'un problème à impact légèrement inférieur. Je veux dire, sur quoi travailleriez-vous si vous pouviez soit corriger deux bugs coûtant chacun 100 € par jour, soit un coûtant 200 $, pour le même effort?
Déduplicateur
1
C'est un bon point; les estimations de l'effort y entreront également.
Anaximandre
@DuDuplicator Sorry n'a pas tout à fait obtenu votre 100 € et 200 $ analogique. Avez-vous essayé de suggérer un problème légèrement moins grave mais beaucoup plus facile à résoudre avant le problème le plus puissant mais beaucoup plus difficile? En d'autres termes, vous parliez du concept de retour sur investissement (ROI)?
RayLuo
10

Ç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.
Pieter B
la source
7
Ce n'est pas un processus normal. Les clients n’ont pas d’interaction avec les développeurs à ce niveau. Si cela se produit, la direction a complètement et complètement échoué à faire son travail.
Davor Ždralo
@ DavorŽdralo peut-être que processus n'est pas le bon mot utilisé ici. Je voulais dire que c'est la chose normale qui se produit.
Pieter B
3
C'est un processus normal dans la mesure où le client aura toujours le sentiment que le bogue qu'il rencontre est plus important qu'il ne l'est probablement. Dans le même temps, les développeurs sont connus pour sous-estimer l’importance des bugs. C’est la raison pour laquelle Scrum a un propriétaire de produit qui se situe entre les deux avec une connaissance du domaine métier associée à une vue de haut niveau de l’endroit où va l’application. Ils sont particulièrement bien adaptés pour évaluer correctement la priorité d’une histoire ou d’un bogue.
Cronax
5

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.

homme de l'espace cardiff
la source
4

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é.

utilisateur1666620
la source
1
J'ai peut-être mal compris votre idée, mais si le logiciel est généralement de mauvaise qualité, pourquoi le client devrait-il être pénalisé pour avoir généré une série de bogues hautement prioritaires?
Robbie Dee
@RobbieDee qui dit que le logiciel est de mauvaise qualité? Il ne s'agit pas d'une question sur la façon de corriger la pratique du code malveillant, mais sur la façon d'empêcher les clients d'escalader chaque problème de support en priorité élevée.
user1666620
Donc, vous parlez d'un coût théorique ou d'un quota?
Robbie Dee
@RobbieDee - Cela dépend. 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 a imposé une limite stricte au nombre de problèmes hautement prioritaires qu'un client pouvait créer en fonction du montant de ses contrats d'assistance. S'ils dépassaient la limite, ils touchaient plus d'argent ou la question du soutien était réduite en priorité.
user1666620
Ah, d'accord - c'est logique.
Robbie Dee
3

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.

Ian Kemp
la source
Les développeurs ayant le contrôle des priorités peuvent être tout aussi problématiques. Ils peuvent sauter sur des victoires rapides ou ne sélectionner que des bugs dans des domaines qu'ils connaissent bien.
Robbie Dee
@RobbieDee Je ne vois rien de mal à aller dans le sens d'une politique simple et judicieuse.
Pieter B
1
Une politique anti-bugs est un objectif admirable, mais l’OMI est tout à fait irréaliste: les bugs sont un artefact du développement logiciel car les utilisateurs ne sont pas parfaits. C'est pourquoi vous avez besoin d'un triage - pour déterminer ce qui doit être corrigé maintenant , ce qui peut être corrigé si / quand vous en avez le temps et ce qui n'a peut-être pas besoin d'être corrigé. De cette façon, vous pourrez vous débarrasser des problèmes les plus graves tout en proposant des fonctionnalités.
Ian Kemp
1
@RobbieDee J'ai été à la fois développeur de fonctionnalités et correcteur de bugs, et le problème est que les gars de la fonctionnalité et les fixateurs finissent par se regrouper dans leur propre mini-équipe, car ils ne travaillent pas sur le même code et donc pas besoin d'interagir. Cela crée toutes sortes de problèmes pour la cohésion et le moral des équipes, en particulier si les acteurs et les réparateurs ne font jamais la rotation de leurs rôles.
Ian Kemp
1
@RobbieDee Et c'est encore pire si les rôles sont inversés - si vous le faites selon un calendrier fixe, les gens seront arrêtés au milieu du travail et les "nouveaux" personnes devront reprendre leur activité; si vous le faites en fonction du moment où le travail est terminé, il y aura malheur, car invariablement quelqu'un se sentira lésé ("Pourquoi est-ce que je finis toujours par passer plus de temps sur les insectes"). D'après mon expérience, la seule façon de fonctionner est de garantir le fonctionnement et la correction des bogues de tous les développeurs - par exemple, le développement de fonctionnalités pour 4 jours de la semaine et de bogues pour un jour.
Ian Kemp
3

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é.

MSalters
la source
1
Ça marche. Tant que tous les problèmes ont un impact égal sur tous les utilisateurs. Sinon, souvenez-vous que mes insectes ont toujours la priorité.
Déduplicateur
Cela fonctionne, en théorie. Mais cela ne résout pas vraiment le problème initial de "presque chaque bogue signalé est un bogue de priorité élevée", l'utilisateur peut toujours signaler chaque bogue comme "de haute importance" à la place, et finalement, il devient "bogue facile en premier".
RayLuo
3

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.

Ian
la source
3

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 .

Alan Shutko
la source
2

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.

Dwoz
la source
2

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.

Brad Thomas
la source
1

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.

Robbie Dee
la source
Dans JIRA, la priorité par défaut pour les émissions est Majeur ("Principale perte de fonction")
Carlos Gavidia-Calderon
1
@ CarlosGavidia Ensuite, la faute semble être avec la mise en place. Les systèmes de bogues sont généralement configurés pour que tout se passe comme une priorité moyenne.
Robbie Dee
0

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.

Superbest
la source