Les cas doivent-ils être rouverts pour les bogues, ou les bogues doivent-ils être ouverts comme un nouveau cas?

Actuellement sur mon lieu de travail, nous utilisons FogBugz pour gérer toutes nos fonctionnalités et bugs pour nos différentes applications web.

Lorsqu'une nouvelle fonctionnalité doit être ajoutée à l'une de nos applications Web, un nouveau boîtier est créé. Par exemple, "Créer un formulaire de téléchargement CSV".

Je travaille ensuite sur le boîtier en enregistrant le temps que j'ai passé dessus. Une fois ce dossier terminé, je le résous et il est attribué à l'ouvreur de dossier (généralement le chef de projet), qui ferme ensuite le dossier.

S'il y a des bogues avec la fonctionnalité, mon chef de projet rouvre ensuite le cas et me le réattribue avec une liste à puces de bogues.

À mon avis, je crois que ces bogues pointus devraient être ouverts en tant que cas de bogues individuels, afin qu'ils puissent être suivis plus facilement et ne pas être encombrés par les notes de cas de fonctionnalité d'origine.

Mes gestionnaires ne sont pas d'accord avec moi, déclarant qu'il est plus facile de calculer le temps total passé sur la fonctionnalité si c'est tout dans un cas.

De plus, ils croient que c'est moins déroutant pour nos clients car ils n'ont qu'une seule référence de numéro de cas pour la fonctionnalité. Cependant, je tiens à souligner que les bogues doivent être traités comme des cas distincts, car il s'agit de l'achèvement du cas d'origine.

Ai-je raison de dire que les bogues doivent être rouverts comme un nouveau cas? Et quels sont les avantages / inconvénients de chaque façon de gérer cela?

Vous et votre manager avez tous les deux de bonnes raisons de traiter comme chacun d'entre vous préfère, et il n'y a pas vraiment besoin de faire de compromis. Il existe une solution qui fonctionne pour moi et répond aux deux préoccupations.

Pour des cas comme le vôtre, j'utilise l'approche de tâches de haut niveau / sous-tâches de bas niveau (concept que j'ai choisi de JIRA , je ne peux pas dire si FogBugz le prend en charge, il ^ressemble explicitement ^{à ce qu'il fait} ). De cette façon, les listes à puces "orientées client" vont aux tâches de haut niveau tandis que les "itérations de développeur" qui sont importantes pour moi se reflètent dans les sous-tâches.

Lorsque la tâche de haut niveau est "rouverte", je crée une nouvelle sous-tâche pour suivre l'effort supplémentaire pour soi .

De cette façon, le développeur peut refléter clairement toutes les permutations, perversions et rebondissements traversés par la spécification des fonctionnalités, tout en laissant le gestionnaire le présenter aux clients comme s'il était parfait. Soit dit en passant, une présentation comme si elle avait une valeur pour moi en tant que développeur, car le fait de la rendre plus facile à lire pour les clients permet d'obtenir des ajustements plus précis.

Cela permet également naturellement d'avoir une justification claire dans les cas où la mise en œuvre des fonctionnalités prend beaucoup plus de temps que prévu à l'origine.

_{En ce qui concerne le suivi du temps par tâche ou sous-tâche - puisque JIRA permet d'inclure le suivi des sous-tâches dans un résumé de niveau supérieur, il est acceptable pour le gestionnaire que je suive le temps dans les sous-tâches. Cependant, même si ce n'était pas le cas, je pourrais vivre avec le suivi formel du temps dans la tâche "parent" - dans ce cas, j'utiliserais simplement des commentaires de sous-tâches pour indiquer combien de temps a été consacré à une itération particulière.}

Si tout cela se produit avant que la fonctionnalité ne soit publiée pour le client, alors ne disposez que d'un cas. L'argument ici est que l'affaire n'est vraiment complète que lorsqu'elle a été approuvée et prête à être publiée. Les autres avantages - un numéro de dossier unique pour la facturation et les utilisateurs finaux à référencer sont valides et importants.

Une fois que la fonctionnalité a été publiée et que des bogues ont été détectés, ceux-ci doivent être signalés comme de nouveaux problèmes dans votre logiciel de suivi des problèmes.

Je suis entièrement d'accord avec vous, tout comme FogBugz - c'est pourquoi il définit différentes catégories de bogues et de fonctionnalités. FogBugz n'a pas été conçu pour être un outil de suivi de l'utilisation du temps; il s'agit d'un sous-produit accidentel de l'introduction d'une planification basée sur des preuves.

Les bogues d'une fonctionnalité terminée peuvent être liés au cas principal de la fonctionnalité (dans FogBugz, en utilisant un nom de balise ou une référence croisée, ou en en faisant des sous-cas). Je peux voir que c'est un peu plus de travail pour votre PM pour consolider les informations dans plusieurs cas, mais il est également souvent logique de pouvoir séparer le temps consacré au développement original et le temps consacré à la maintenance, en particulier pour les contrats à prix fixe, et vous perdez la possibilité de le faire si vous mettez tout dans un seul cas.

C'est mon avis qu'une fois un ticket fermé, il doit rester fermé, votre tracker de bug devrait être capable de se lier à d'autres cas de toute façon. J'essaierais de souligner que la création de nouveaux bogues et leur liaison au cas d'origine offre de meilleurs avantages que la méthode que vous décrivez.

• les clients peuvent toujours avoir un numéro de référence contenant des liens vers chaque bogue.
• l'état de chaque bogue peut être suivi individuellement, ce qui permet une meilleure hiérarchisation et un meilleur rapport d'état.
• avoir des bogues distincts vous permettra de réduire le temps passé sur les bogues par rapport au temps passé à développer de nouvelles fonctionnalités, et ne devrait être qu'un effort supplémentaire minimal pour obtenir un nombre total pour tous les bogues liés à un changement et au développement de ce changement.
• la séparation des bogues permet à votre gestionnaire de rassembler beaucoup plus facilement d'autres mesures telles que le nombre total de bogues, le temps moyen par correction de bogue, les ratios de bogues fermés / en cours / fixes.
• des cas distincts par bogue permettent de mieux répartir les tâches entre tous les développeurs et de tenir chacun responsable de son propre travail, ou autorise cette possibilité si plus de développeurs étaient embauchés à une date ultérieure.

Le seul avantage de votre configuration actuelle est que c'est extrêmement simple pour les personnes qui ne sont pas les principaux utilisateurs du système. Le but d'un outil de suivi des bogues est que le développeur ait un endroit pour tout rapporter sur un bogue dans un seul endroit qui se trouve également être assez convivial pour que les autres puissent voir les progrès, votre système actuel semble saper presque toutes les parties de cela.

Les bogues sont-ils détectés avant ou après que le produit a été «expédié / publié» aux clients?

Si c'est avant une version, les bogues doivent être suivis par rapport au ticket d'origine.

Si c'est après une version, chaque bug devrait être son propre ticket.

Là où je travaille, seules les personnes chargées de l'assurance qualité peuvent clore un dossier. Nous avons des cases à cocher pour le code révisé, testé par l'ingénieur et la démo pour les parties prenantes (dans votre cas, chef de projet). Si l'équipe QA voit un cas marqué comme "Terminé" qui n'a pas tous ces champs marqués, elle le marquera comme annulé et nous le renverra.

Une fois qu'un cas a franchi toutes ces phases et que le contrôle qualité le ferme, tous les nouveaux problèmes qu'ils trouvent sont enregistrés comme bogues.

Ce système semble bien fonctionner pour nous.

Je pense que vous pouvez présenter un argument dans les deux sens. J'essaierais de m'asseoir avec le PM et d'expliquer pourquoi vous pensez qu'avoir des problèmes discrets vous aidera. Personnellement, je veux que chaque tâche soit son propre ticket, mais je peux voir pourquoi il le veut ainsi.