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

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.

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 .

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.

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.

À 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

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?».

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

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.