Valeurs de priorité discrètes au lieu de valeurs continues dans les outils de suivi des bogues
Dans les outils de suivi des bogues (et probablement d'autres applications similaires), les tickets sont hiérarchisés en fonction de catégories discrètes plutôt qu'en fonction de valeurs continues.
Cela peut produire des situations étranges et contre-intuitives. Par exemple, si le même développeur se voit attribuer vingt tickets et que trois d'entre eux ont la priorité immédiate, qu'est-ce que cela signifie? Lequel, parmi trois, est plus immédiat que les autres? Lesquels sont les plus résolus en premier, considérant que tous nécessitent beaucoup de travail? Ou le développeur doit-il être un dragon à trois têtes pour résoudre ces trois tickets en parallèle?
Au lieu de cela, la priorité continue indique que le troisième ticket doit être résolu avant le quatrième mais après le second qui est lui-même moins urgent que le premier. Tout devient facile: vous commencez par le haut et vous descendez jusqu'à la résolution du dernier ticket, ces tickets étant commandés par glisser-déposer par le chef de projet.
Y a-t-il donc une raison expliquant pourquoi les outils de suivi des bogues utilisent des catégories discrètes, ou est-ce simplement parce que cela a toujours été fait comme ça, pour toujours?
Quelques raisons.
Tout d'abord, comme l'a noté @Chase, les valeurs discrètes ont plus de sens car il est relativement facile de déterminer l'importance du bogue, mais il est souvent inutile de le prioriser par rapport à d'autres bogues de même importance. Cela demandera aux gars de l'AQ de consacrer beaucoup de temps à réfléchir à la priorité de chaque bogue, à la comparer à d'autres bogues et éventuellement à consulter les membres de l'équipe. La décision, en ce qui les concerne, est en fait arbitraire, et lorsque vous les forcez à prendre de telles décisions, cela demande beaucoup d'efforts. C'est juste beaucoup de temps perdu. D'un autre côté, cela peut ne pas être arbitraire pour le développeur, qui peut voir qu'un bogue spécifique du même groupe doit être traité en premier, et qui pourrait prendre en charge d'autres bogues. Cette méthode permet donc à la bonne partie d'exercer son jugement et de soulager la "mauvaise" partie de la lutte pour des décisions inutiles.
La deuxième chose est que, dans la plupart des cas, de nombreuses personnes soumettent des bogues. Comment hiérarchiseraient-ils les bogues des autres, qu'ils ne connaissent pas? Et vous ne pouvez pas simplement laisser chaque personne hiérarchiser ses propres bogues, puis les fusionner dans une grande liste de priorités, car quelqu'un doit prendre ces décisions.
Un développeur préférerait avoir 3 bogues prioritaires "immédiats" et conserver la flexibilité de choisir celui qu'il veut corriger en premier, je pense.
Seul le codeur devrait savoir quel bogue est plus facile à corriger que l'autre et le résoudre en premier, "le travail le plus court d'abord". Si tout semble le même ou ne peut pas être estimé de manière résonnable, clouez d'abord le plus ancien.
Je suis d'accord avec Chase Seibert, si c'est un spectacle, alors quelqu'un vous le dira probablement.
J'utilise à la fois FogBugz et Pivotal Tracker . FogBugz est basé sur des catégories et Pivotal est basé sur une échelle continue.
Développement agile/Pivotal préconise que le propriétaire du produit ou le scrum master décide de la priorité . Et puis, d'après mon expérience, la priorité n'est plus strictement liée à un bug. La priorité devient un mix des effets du bug corrigé et de la direction vers laquelle l'entreprise se dirige en ce moment. Cela changera constamment, et souvent ne devrait pas être défini par le demandeur du bogue, ou à la création du bogue non plus.
C'est vraiment ainsi que Pivotal Tracker fonctionne. Lors de la soumission d'un bug atterrit dans un pool général de bugs. Et ce n'est que lorsque vous sortez de là que vous lui donnez une priorité, ce qui est généralement fait par le propriétaire du produit ou lors des réunions d'équipe.
Comme d'autres l'ont également remarqué, les gens ont du mal - et abusent - de la différence entre la priorité et la gravité. La gravité d'un bogue peut être estimée par le demandeur et probablement confirmée ou modifiée par le programmeur ou le propriétaire du produit. La priorité devrait être entre les mains des personnes qui prennent les décisions, pas des personnes qui trouvent ou corrigent les bugs.
Mais il se peut que vous n'ayez pas d'organisation dans laquelle un responsable de produit donne la priorité et la direction au développement qui soit étroitement . Ensuite, il peut être très pratique que les personnes qui travaillent avec les bogues individuels (soumetteur et réparateur) définissent une priorité en fonction de leur propre expérience des bogues précédents.
Mais aussi dans ces situations, je trouve souvent que les soumissionnaires ne peuvent pas définir la priorité d'un bogue aussi librement. Ou uniquement aux valeurs 2 à 4 (sur une échelle de 1 à 5) par exemple. Seules les autres personnes utilisant le système - peut-être les programmeurs ou les propriétaires de produits) peuvent définir la priorité.
Parler en tant qu'utilisateur potentiel d'un système de suivi des bogues, avoir des valeurs discrètes est plus logique pour moi. Certains bogues sont prioritaires, certains sont faibles, etc. Qui peut dire si un bogue élevé est plus critique qu'un autre? En outre, les bogues ne prennent généralement que quelques minutes à corriger, vous fermerez donc probablement un groupe à la fois, ou du moins tous dans la même version/déploiement.
Si un bug est VRAIMENT critique, vous pouvez parier qu'une personne importante viendra et exigera que vous arrêtiez tout le reste et que vous le répariez. Dans ce cas, un système de suivi des bogues n'est pas vraiment nécessaire.
D'un autre côté, les valeurs continues ont plus de sens pour moi pour un NOUVEAU travail, comme le suivi de nouvelles histoires. Pour Agile en particulier, il est essentiel de pouvoir sélectionner les "prochaines" unités de travail X dans le plus grand espace de tout le travail qui pourrait être effectué. Le fait d'avoir plus de X unités de travail dans le même compartiment "haute priorité" ne vous mène pas là où vous devez être.