Amélioration de la productivité à 1 Correction de bugs par homme/jour

Question

Je suis un ingénieur logiciel senior, et il y a quelques mois, on m'a demandé d'aider à la coordination des corrections de bugs. Le chef de projet (non technique) m'a donné un objectif d'amélioration de la productivité à 1 correction de bogue par homme/jour. Cela a été un réel défi, et j'aimerais savoir ce que d'autres développeurs/gestionnaires ont pu faire pour améliorer les taux de correction des bogues.

Certains facteurs qui jouent un rôle dans cette situation:

équipe
• est réparti géographiquement (Europe, Asie, Australie), 10-20 développeurs dans chaque zone
• grande base de code que je ne suis pas tout familier avec comme je l'ai été avec la compagnie pour seulement 9 mois
• seulement les moins de développeurs expérimentés sont affectés à des corrections de bugs, les développeurs les plus capables travaillent sur les améliorations
• nous suivons agile, nous utilisons donc le contrôle source, intégration continue , punaise base de données, projet a calendrier et spécifications pour le nouveau travail, nous avons des testeurs et faire des tests d'utilisabilité
• notre code dépend de nombreux composants/bibliothèques de la maison et de tiers
• le gestionnaire de programme a quelques anciennes mesures de correction de bugs, montrant 0,7 bug correction par homme/jour. Mon inquiétude est que cela était basé sur une équipe de développeurs expérimentés travaillant sur un prototype, corrigeant les bogues dans le code qu'ils ont eux-mêmes écrit. Maintenant, je coordonne une équipe de développeurs qui ne connaissent pas le code, et les bogues proviennent de l'équipe de validation.

Quelques informations supplémentaires après avoir lu quelques premières réponses:

• J'ai essayé d'argumenter contre l'utilisation de la correction des bugs productivité métrique, ne pas aller trop loin avec cette approche
• tous les bugs sont priorisés (1-5), inclure une sévérité (1-5) et étiqueté avec des informations supplémentaires (par exemple BLOQUÉ par un autre bug, CRASH, NOT-REPRODUCIBLE, etc)
• la plupart des bogues ont un cas de test unitaire écrit quand ils sont corrigés
• bugs dans un domaine particulier de code sont attribués aux personnes familières avec cette zone, si possible
• les taux de correction de bugs sont suivis par équipe, et l'historique de correction est conservé
• dans les lève-personnes quotidiens J'essaie de faire bouger les gens en demandant de bloquer les problèmes et de les résoudre
• tout le nouveau code est écrit avec des tests unitaires
• oui, j'ai fait de mon mieux pour améliorer la métrique de productivité par divers moyens - fermeture des anciens bogues non pertinents, création et correction de bugs pour les problèmes qui seraient autrement résolus sans rapport de bogue

• J'ai développé un script python s que l'accès à la base de données de bogue directement à automatiser certains aspects mondains de la gestion des bogues et pour la création de rapports

-

Answer 1

Je pense qu'un bon point de départ est de systématiser le processus de correction de bogue. Si vous allez à < 1 bug/jour, je suppose que votre base de code est grande, et ces bogues sont difficiles à trouver/reproduire. Je commencerai par une analyse

1) Combien de temps pour comprendre le bug

2) Combien de temps pour trouver/reproduire

3) Quel code est fixe (est-il un modèle ici)

4) lorsque vous fixez, vous ajoutez un autre test unitaire

5) Donnez votre avis avez-vous individuel et par équipe où les bugs se produisent

quelques Des semaines à faire cela vous donneront une très bonne base pour la direction future. Ce sera également une approche professionnelle que votre gestionnaire devrait acheter.

Answer 2

Alors que les taux de correction de bug sont une mesure valable dans certaines circonstances, ils peuvent être misguiding dans d'autres. Certains bugs sont évidemment beaucoup plus difficiles à résoudre que d'autres.

Les idées que vous pouvez essayer incluent le tri de vos bugs dans différentes catégories.Basez le tri sur les métriques telles que la difficulté à corriger, l'importance pour le client ou la complexité.

Dans un environnement agile, vous vous concentrez principalement sur l'écriture de code de test. Pensez au cycle de vie d'un bug. L'une des premières choses que vous essayez de faire est de le reproduire. Vous pouvez mesurer jusqu'à quel point vous êtes en train de corriger un bogue si vous pouvez écrire un cas de test par rapport à celui-ci. Ce faisant, cela améliorera les taux de correction des bogues.

Answer 3

Il serait utile de désactiver entre les développeurs expérimentés corrigeant les bogues et les développeurs juniors créant des améliorations, mais cela ne semble pas possible dans votre situation. Essayez de ne pas laisser les gens se coincer. Si quelqu'un a un problème et ne va nulle part, encouragez-le à obtenir de l'aide et à prendre la bonne voie.

Conformément à l'affiche ci-dessus, demandez aux développeurs expérimentés d'écrire des cas de test pour leurs améliorations. (Bien sûr, cela rend la correction des bogues plus difficile)

Vous pouvez toujours ajouter des bogues intentionnellement et les corriger.

Answer 4

Vous pourriez demander aux développeurs quelle est leur opinion la partie la plus longue du cycle de correction d'erreur et pensez comment vous pouvez utiliser cette information.

Ils font un travail réel et il est raisonnable qu'ils aient le plus d'informations sur ce que sont les goulots d'étranglement.