Pourquoi avons-nous besoin à la fois de priorité et de gravité?


11

Je comprends ce qu'ils déterminent, mais est-il vraiment utile de les attribuer aux problèmes trouvés? Je veux dire, il est nécessaire de corriger rapidement ou non.

Je sais comment les définir, les classer, etc. Je sais que l'IEEE / ISO a besoin de le faire. Je ne vois tout simplement pas pourquoi.


Hmm, je pense qu'un bug qui endommagerait les données est plus grave que quelque chose qui est juste ennuyeux, comme par exemple certaines fonctionnalités qui prennent trop de temps à charger. Les deux devraient être corrigés mais ceux qui ont un impact négatif plus élevé devraient être corrigés en premier.
thorsten müller

Non, comme je l'ai écrit, je sais ce que c'est et comment les régler. Je ne vois tout simplement pas le bénéfice.
Pietross


Dans la plupart des cas, non. Mais il y a toujours des cas extrêmes où il est logique de séparer les deux. Que la séparation mérite d'être maintenue pour chaque problème uniquement pour répondre à ces rares occasions est une autre question.
biziclop

1
Vous pouvez avoir un bug d'interface utilisateur qui n'affecte pas vraiment la convivialité des applications ( faible gravité ), mais est une priorité élevée car il est moche. Vous pouvez avoir un bug qui bloque l'application complètement ( haute gravité ) , mais est une faible priorité parce que les conditions pour y arriver sont un sur un million et dans tous les termes pratiques ne seront jamais réellement arriver (cela ne tient pas le fait que d' un in- un million de chances se présentent neuf fois sur dix ).
Binary Worrier

Réponses:


24

Il est absolument possible que ces valeurs diffèrent. Si vous avez une vente à faire avec une agence gouvernementale importante qui nécessite des performances élevées mais n'utilisera jamais le module X, il est très judicieux sur le plan commercial de corriger une erreur de disponibilité de base de données mineure plus tôt qu'une erreur grave dans le module X. Fondamentalement, les raisons techniques ne sont pas le seul facteur lorsque vous dirigez une entreprise de logiciels .


Exactement: la priorité indique la valeur commerciale et résulte de la gestion de projet. La gravité indique un impact et est le résultat de bogues. Chaque tâche peut avoir une priorité, mais par exemple les nouvelles fonctionnalités n'ont pas de gravité. Mis à part les bogues de haute gravité critiques pour la sécurité, il serait stupide de laisser la gravité seule dicter les priorités, ou les gens seraient mal incités à surestimer la gravité de leur problème.
amon

5
Je pense que l'important est qu'une seule mesure (la priorité) contrôle directement l'ordre de développement. L'utilité pour une équipe de trouver une «gravité» supplémentaire dans le cadre d'une description de défaut est extrêmement opionnée: certains pourraient la trouver utile, d'autres comme @arnaud pensent que c'est de la «bureaucratie» - les deux points de vue peuvent être raisonnables.
Doc Brown

4
Haute priorité, faible gravité: la page de destination de votre application, vue par des millions d'utilisateurs par mois, comporte une faute de frappe dans le nom de votre entreprise. Priorité faible, gravité élevée: le système se bloque 25% du temps au démarrage pour une application qui est retirée la semaine prochaine.
Gort the Robot

2
La gravité peut généralement être déterminée par des règles par des testeurs automatisés et en direct. La priorité ne peut être évaluée que subjectivement par l'entreprise.
Gort the Robot

3

Bogues de date et d'heure

Bug: le traitement de fin d'année corrompra totalement votre base de données. C'est clairement un bug grave.

Date: 15 décembre. Le bug est de très haute priorité.

Date: 1er février. Le bug est de faible priorité.


Lancement accidentel d'un bug de missile

Bogue: le logiciel de contrôle ICBM vomit lors du passage du 28 février au 1er mars dans les années divisibles par 4. Le résultat est un lancement non commandé.

C'est un bug aussi grave que possible. Priorité très faible, cependant - existe-t-il une chance réaliste que le logiciel soit utilisé lorsque la condition est déclenchée?


«Mauvais» mots par inadvertance à l'écran

Bug: les messages débordant de leur espace à l'écran provoquent l'apparition d'une référence profane par inadvertance à Bob. (Monde réel: nous avions des personnes travaillant dans le département "Final Ass". "Ass" = "Assembly".)

Malheureusement, demain, vous faites une présentation où l'obtention de la vente est une rupture ou une rupture pour l'entreprise. Vous faites la présentation à quelqu'un nommé "Bob". Gravité: très faible. Priorité: très élevée.


Liés aux bogues de débordement et de date et heure que vous mentionnez - vous pouvez apprécier le bug de la phase de la lune

0

Tu as écrit:

Je veux dire, il est nécessaire de corriger rapidement ou non.

C'est exact. Cependant, si vous êtes comme la plupart des entreprises, vos ressources sont limitées. Soit vous n'avez pas suffisamment de personnes pour résoudre tous les problèmes, soit vous n'avez pas assez de temps.

Étant donné qu'un bogue doit être corrigé rapidement ou non, et que vous avez beaucoup de bogues à corriger, "priorité" répond à la question "lequel dois-je corriger en premier"?

La gravité, en revanche, est un indicateur utilisé par la personne qui fixe la priorité. Du point de vue d'un développeur, la gravité est un point discutable. Du point de vue de celui qui attribue le travail, la gravité est un élément d'information important qui aide au processus décisionnel.

Bien sûr, tout cela est une information très générale. Si vous êtes une équipe avec un arriéré de bogues incroyablement long, la priorité et la gravité signifient quelque chose de complètement différent que si vous faites partie d'une équipe qui a une base de données de bogues presque vide.

Si vous faites partie d'une équipe où "gravité élevée == priorité élevée", rien de tout cela n'a d'importance et vous n'avez pas besoin des deux mesures. En fin de compte, ce ne sont que des outils. Votre équipe doit décider comment les utiliser. Pour votre équipe, il peut ne pas être judicieux d'utiliser les deux.


0

À mon humble avis, mettre à la fois la priorité et la gravité n'est que de la bureaucratie.

En pratique, vous n'avez besoin que d'une mesure "d'importance". Souvent, la priorité est utilisée pour cela, et la sévérité est ensuite utilisée comme terme technique comme "high = plante le système ou le rend inutilisable", "medium = comportement buggy, potentiellement dangereux", "low = nuisance, ennuyeux mais inoffensif"

Habituellement, la priorité va de pair avec la gravité. Quelques contre-exemples sont une "nuisance où tout le monde se plaint toujours" ou un "crash ayant eu lieu une fois dans un environnement exotique".

... mais, en fin de compte, en tant que développeur (ou gestionnaire, etc.), il vous suffit de savoir dans quel ordre vous devez corriger / améliorer les choses, c'est tout. Une mesure suffit donc.

Le besoin de priorité est clair: il s'agit de savoir dans quel ordre les rapports de bogues doivent être traités. L'autre, à mon humble avis comme d'habitude, est la bureaucratie. Pourquoi en avez-vous besoin? C'est apparemment inutile pour le tri car c'est la priorité qui fait ça. Et les conséquences (description de la gravité) sont de toute façon décrites dans le rapport de bogue.

Je pense même que c'est nuisible car cela rend moins clair quel bug est le plus important:

  • Certains peuvent penser qu'un bogue "critique" a une priorité plus élevée qu'un bogue "haute priorité".
  • Certains utilisateurs signalant un bogue peuvent confondre gravité et priorité
  • ... dans l'ensemble, cela ajoute plutôt de la confusion quant à l'ordre dans lequel les bogues doivent être traités

1
Et les développeurs sont-ils les seules personnes qui comptent?
biziclop

2
@biziclop Non, vous avez raison, c'était une mauvaise formulation. Cela vaut pour tout le monde: ce qui compte, pour les gestionnaires, etc., c'est ce qui doit être fixé en premier et ce qui est moins important. Pour cela, une mesure suffit.
dagnelies

1
Eh bien, c'est faux du point de vue de la gestion des risques - priorité = gravité * taux d'occurrence. Une faute de frappe sur le frontp age est-elle moins prioritaire qu'un crash serveur fatal qui se produit si le nom de l'utilisateur dépasse 46 caractères?
Pietross

1
@Pietross: eh bien, vous l'avez épinglé: lequel devrait être abordé en premier? Le crash de basse priorité ou la nuisance de haute priorité? Comment priorisez-vous? Qui fait ce jugement? Tout le monde regarde la liste? Lorsque vous utilisez une seule mesure prioritaire, elle a priorisé une fois, puis c'est fait. L'impact et la gravité sont de toute façon décrits dans le rapport de bogue.
dagnelies

La chose au sujet de la "sévérité" est que vous pouvez assez facilement dire "crash = high, typo = low". Il faut penser à réaliser qu'une faute de frappe qui laisse «o» hors du mot «count» sur la page d'accueil est plus prioritaire à corriger que la page qui refuse de se charger du tout.
Gort the Robot

0

En plus des autres réponses, considérez ce scénario: le bogue A prendra 30 minutes à corriger et a une gravité «faible»; le bogue B peut prendre plus de 2 semaines à corriger et avoir une gravité «élevée». De plus, le bug B peut prendre beaucoup de discussions et de coordination dans l'équipe de développement et peut-être en dehors de l'équipe; le bug A peut être corrigé par un seul développeur immédiatement. Il est tout à fait correct de définir une priorité plus élevée sur le bogue A.

Bien entendu, la «gravité» et la «priorité» peuvent être interprétées de différentes manières.

Dans un petit outil de suivi des bogues que j'ai fait pour mon usage personnel, j'ai préféré préférer la `` difficulté '' et la `` priorité '' où les problèmes de gravité élevée auraient toujours la priorité la plus élevée, et je pourrais décider de retarder leur travail en fonction de la difficulté.

Une chose que je n'aime pas à propos de la «gravité» est qu'elle ne s'applique qu'aux bogues et non aux fonctionnalités. Il peut être préférable d'avoir une liste unique de tous les problèmes classés par priorité et par difficulté, car il est plus directement utile de décider «sur quoi dois-je travailler ensuite?».


0

J'ai conçu et implémenté des processus dans une société de logiciels certifiés ISO9001: 2007. Il y a eu des mises à jour de la norme depuis 2007, il peut donc y avoir des exigences supplémentaires que je ne connais pas ... cependant:

La norme ISO9001 vise à garantir que votre entreprise conçoit et implémente des processus dotés de boucles de rétroaction pour améliorer le processus lorsque des défauts de produit et de processus sont identifiés.

Au cours de la phase de conception, les exigences se concentrent sur la question de savoir si la solution proposée, si elle est correctement mise en œuvre, résoudrait réellement le dossier de conception (validation) et vérifierait si la mise en œuvre a effectivement été mise en œuvre sans défaut (vérification).

Sur la boucle de rétroaction, lorsque des défauts sont identifiés, il ne suffit pas qu'ils soient enregistrés. La gravité d'un défaut doit également être évaluée et le remaniement priorisé.

L'élément clé est que la manière dont votre entreprise décide d'évaluer sa gravité et de prendre des décisions sur la priorité n'est pas définie par la norme ISO. C'est une question commerciale et de gouvernance pour l'entreprise de décider et de documenter.

Comme il est écrit dans la norme comme exigence, toute entreprise certifiée aura un processus pour évaluer la gravité d'un défaut et un processus pour déterminer la priorité du travail pour corriger le bogue. Ce sont certainement deux décisions distinctes qui doivent être prises.

La gravité du bogue n'est qu'un point de données. L'impact client est un autre point de données. Il y a aussi des efforts pour corriger, l'âge défectueux, la vie commerciale restante dans le produit et tout autre facteur que l'entreprise décide d'inclure dans sa prise de décision. La seule chose qu'il ne devrait pas être écrit comme «défaut actuel au chef de produit pour décider de la priorité» car cela ne définit que le pouvoir de prendre la décision et ne définit pas le processus qu'ils suivent pour prendre la décision.

J'ai une préférence pour la priorisation qui est biaisée vers la fourniture d'un taux élevé de modifications petites et importantes, car cela semble donner le meilleur coup de fouet à la fiabilité globale du produit. Cela signifie qu'un bogue grave qui nécessitera beaucoup de travail à corriger nécessiterait que son travail soit divisé en morceaux plus petits pour obtenir une priorité suffisante pour être planifié.


-3

Pour des raisons de différer fortement la priorité et la gravité:

Un exemple simple. Imaginez le cas où vous avez un endroit étroit qui empêche la mise à l'échelle de votre système - certains algorithmes ont une complexité O (N ^ 3), où N est le nombre de magasins du client. Le client dit qu'il ouvrira 200 nouveaux magasins l'année prochaine et que les calculs nécessaires (distribution des marchandises, planification des transports, etc.) ne seront pas terminés à temps. Mais, actuellement, ce client ne dispose que de 30 magasins et les ressources sont suffisantes. La tâche d'optimiser cet algorithme (en O (N ^ 2) ou mieux) est certainement importante (vous perdrez le client s'il n'est pas implémenté), mais probablement pas urgente: vous avez quelques mois pour implémenter le nouvel algorithme.

Exemple 2: une application plante systématiquement, mais cette version est hors d'usage en quelques jours en raison d'une mise à niveau ou d'une migration. La correction est urgente car les plantages affectent vraiment l'expérience utilisateur, mais sont de faible importance.

Bien sûr, les deux paramètres sont unifiés à l'aide d'une métrique (formelle ou informelle) pour produire un plan de travail à court terme, car ce dernier est unidimensionnel (séquence de tâches). Mais à long terme, ils ne seront pas unifiés.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.