Attribution du temps de correction des bogues

Question

Un client nous a demandé de nous donner une estimation de temps pour chaque bogue que nous avons.

Bien que nous ayons un calendrier défini pour la correction des bogues et que nous en ayons attribué le temps, nous n’avons pas de temps alloué pour chacun des bogues que nous avons. Nous avons simplement classé nos bogues par ordre de priorité et nous nous sommes assurés que les bogues les plus prioritaires soient corrigés dans le temps imparti.

Je ne suis pas fan de l'attribution de temps aux bugs, simplement parce que:

1. C'est généralement inexact. Il est très difficile de savoir combien de temps il faudra pour réparer.
2. Perte de temps.
3. affecte la qualité du code
4. Crée plus de bugs sur le long terme (nous pourrions rater certaines choses dans notre tentative de les achever avant la date limite).

Comment devrions-nous résoudre ce problème où nous ne voulons pas fournir le nombre d'heures par bogue, mais simplement un délai pour déterminer quels bugs seront corrigés?

Comment allouez-vous du temps à vos bugs? Est-ce efficace? Vaut le temps et les efforts?

Answer 1

La seule réponse que je puisse donner est d'être extrêmement conservateur. Devinez combien de temps cela prendra, et multipliez votre estimation par quatre. Utilisez cela comme votre estimation. Comme vous l'avez dit, il est très difficile de déterminer le temps qu'il faudra pour régler le problème, et il est préférable de dire que cela prendra plus de temps que cela ne le sera réellement pour ne pas être pris au dépourvu. parce que vous n'étiez pas assez conservateur.

Answer 2

L'entreprise pour laquelle je travaille reçoit souvent des demandes déraisonnables de nos clients. Il est important de rappeler que les clients veulent être bien informés. Nous avons trouvé que le meilleur moyen de le faire est de générer des rapports de statut.

Donc, nous faisons d’abord un très bon travail pour expliquer notre position. Dans votre exemple, cela ressemblerait à ceci:

  

Nous avons un calendrier fixe pour la correction des bugs de notre projet, qui a toujours fait ses preuves. Cependant, le processus de définition détaillée de la durée de résolution de chaque bogue est sujet à des erreurs. Nous serions heureux de vous fournir des mises à jour hebdomadaires (ou deux fois par semaine ou tous les jours, en fonction du client) sur les bugs corrigés et les correctifs testés.

Cependant, j'estime qu'il est bon d'essayer d'estimer le temps qu'il faudra à chaque bogue pour le réparer. La raison en est que vous devez comprendre le temps total nécessaire pour résoudre tous les bugs. Vous ne pourrez pas obtenir une estimation précise si vous ne disposez pas d'une estimation du temps que chaque pièce prendra à réparer. Ces estimations peuvent bien sûr être approximatives (ne pas consacrer plus d'une heure à la recherche du problème) - vous ne voulez pas perdre trop de temps à estimer. Ensuite, je prend généralement en compte 20% supplémentaires. Donc, supposons que les estimations pour les bugs soient de 3 jours, 5 jours et 2 jours. Ensuite, je ferais savoir au client que nous devrions être en mesure de résoudre le problème en 12 jours. Ensuite, vous aurez peut-être besoin de plus de temps pour tester et réemballer votre produit avant de pouvoir lui fournir un produit livrable.

Answer 3

Ne pensez pas à cela en termes d'estimation de la durée de correction des bugs, car vous ne pouvez pas estimer cela correctement.

Pensez à cela en termes de gestion de la rage des clients . Si vous leur dites que les bugs ne prendront pas du tout de temps à corriger et qu’ils dureront 3 mois, votre client sera heureux avec vous maintenant et furieux contre vous à l’avenir.

Si vous leur dites que les bugs prendront 3 mois à corriger et qu’ils le feront effectivement (ce qu’ils feront), votre client sera furieux maintenant et heureux avec vous à l’avenir.

Je dis habituellement que les insectes ne prendront pas de temps (2-3 jours semblent être un bon nombre de pacificateurs).

Answer 4

Cela devrait être identique à l’estimation de toute autre tâche que vous avez. Divisez-le en tâches les plus petites possibles et estimez-les aussi précisément que possible avec un rembourrage pour les imprévus. Puis, donnez-leur une plage pour que vous ne soyez pas figé sur une date précise pour des tâches qui ne sont pas bien définies. Il n'y a pas de différence entre l'estimation du temps nécessaire pour réparer un bogue et l'estimation du temps nécessaire pour implémenter une fonctionnalité avec des exigences nébuleuses.

Answer 5

Vous avez raison, les estimations sont généralement inexactes.

Peut-être voudriez-vous leur demander combien chaque bogue leur coûte s'ils ne sont pas corrigés. Vous pouvez ensuite effectuer le calcul approprié pour déterminer s’ils doivent être corrigés et combien de temps vous (ou de façon réaliste, ils peuvent) se permettre de consacrer à chaque bogue.

Answer 6

Pourquoi ne pas simplement choisir plusieurs bandes pour la gravité des bogues, par exemple. 1 heure, 1/2 journée, 1 journée, 1 semaine et assigner contre eux. Généralement, vous aurez un sentiment pour un bug - ceux pour lesquels vous n'avez aucune idée, mettez le chiffre le plus défavorable!

Je ne pense pas que vous souhaitiez estimer à un niveau plus fin que celui-là, pour les raisons que vous avez citées (prendre trop de temps à enquêter, etc.)

Je ne pense pas que ce soit une perte de temps. Votre client veut en savoir plus que le nombre de bugs et leur priorité - ils veulent avoir une idée du temps qu'il reste à travailler.

Cela ne doit en aucun cas vous amener à générer plus de bugs. Vous ne devriez pas vous presser contre la montre pour résoudre ces problèmes. Si vous avez estimé 1 jour et qu'il a fallu 10 heures, c'est bon. Si vous avez estimé 1 semaine et que cela a pris 2 heures, bon résultat!

Ceci est simplement un exercice d'estimation!

Answer 7

Généralement, nous convenons des bogues à corriger pour une version donnée, puis nous définissons un délai pour la résolution de tous les bogues. Pour chaque bogue, il y a beaucoup d'incertitude / de variabilité dans le temps qu'il faut prendre pour résoudre le problème, mais cela a tendance à être moyen avec un plus grand nombre de bogues. Pour certains bugs qui dureront plus longtemps, il est possible de donner des estimations, par exemple. si vous devez écrire un simulateur ou un framework de test pour cela.

Answer 8

S'il s'agit de bogues détectés et signalés, vous devriez être en mesure de développer une estimation du temps nécessaire pour le corriger (et le temps nécessaire pour refaire le test). La confiance de l'estimation sera probablement proportionnelle au temps passé sur l'estimation. Expliquez peut-être ce coût au client.

S'il existe un certain nombre de petits rapports de bogues connexes, vous pouvez peut-être les réduire en un seul rapport omnibus. Cela évitera peut-être au client d'essayer de choisir les bogues à corriger uniquement sur la base d'estimations individuelles.