L'amélioration de la productivité à 1 Correction d'un bug par homme / jour [fermé]

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 bug par homme / jour. Cela a été un véritable défi, et je voudrais savoir ce que les autres développeurs / gestionnaires ont pu faire pour améliorer les taux de correction de bugs.

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

• L'équipe est géographiquement distribuée (Europe, Asie, Australie), 10-20 développeurs dans chaque domaine
• grande base de code que je ne suis pas familier avec tout comme je l'ai été avec la compagnie pour seulement 9 mois
• que les moins expérimentés développeurs 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, base de données de bogues, le projet a le calendrier et les spécifications de nouveaux travaux, nous avons des testeurs et faire des tests d'utilisabilité
• notre code dépend beaucoup dans la maison et des composants tiers / bibliothèques
• gestionnaire de programme a des anciens paramètres de correction de bug, montrant 0,7 correction de bug par homme / jour. Mon souci est que cela a été basé sur une équipe de développeurs expérimentés qui travaillent sur un prototype, la correction des bugs dans le code qu'ils s'écrivaient. Maintenant, je suis la coordination d'une équipe de développeurs qui ne connaissent pas le code, et les bugs sont issus 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 des bogues corrigés métriques de productivité, ne pas trop loin avec cette approche
• tous les bugs sont prioritaires (1-5), inclure une gravité (1-5) et étiquetés avec des informations complémentaires (par exemple. Bloquée par un autre bug, CRASH, NOT-REPRODUCTIBLE, etc.)
• la plupart des bugs ont un cas de test unitaire écrite quand ils sont corrigés
• bugs dans la zone de code particulier sont attribués aux personnes familières avec cette région, si possible
• bug taux de correction sont suivis sur une base par équipe, et l'histoire de correction est maintenue
• en stand ups tous les jours que j'essaie de faire bouger les gens en demandant de bloquer les problèmes et les résoudre
• tout le nouveau code est écrit avec des tests unitaires
• Oui, je l'ai fait de mon mieux pour améliorer la mesure de la productivité par divers moyens - fermeture des anciens bugs non pertinents, la création et la correction des bugs pour les problèmes qui seraient autrement résolus sans un rapport de bogue

• i ai développé des scripts python qui ont accès à la base de données de bogue directement pour automatiser certains aspects de la gestion des banales 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 bug. Si vous allez à <1 bug / jour Je présume que votre base de code est grande, et ces bugs sont difficiles à trouver / reproduis. 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 (il est ici un motif)

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

5) Avez-vous révisez individuel et par équipe où les bugs se produisent

Un couple de semaines à faire qui vous donnera une base vraiment bon pour l'orientation future. Il sera également une approche professionnelle que votre gestionnaire doit 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 difficile à résoudre que d'autres.

idées que vous pouvez essayer inclure trier vos bogues dans différentes catégories. Base du tri sur des paramètres tels que la difficulté à fixer, l'importance pour le client, ou la complexité.

Dans un environnement agile vous êtes principalement focalisés sur le code de test d'écriture. Pensez à lui 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 en êtes à la fixation d'un bug si vous pouvez écrire un test contre elle. Faire juste cela permettra d'améliorer les taux de correction de bugs.

Answer 3

Il serait utile de couper entre les développeurs expérimentés et corriger les bugs aux développeurs juniors en créant des améliorations, mais cela ne semble pas possible avec votre situation.

Essayez de ne pas laisser les gens se coincent. Si quelqu'un a un problème et devient nulle part, les encourager à obtenir de l'aide et se concentrer sur la bonne voie.

Selon l'affiche ci-dessus, font les développeurs expérimentés écrivent des cas de test pour leurs améliorations. (Bien sûr, ce qui rend la fixation de bug plus difficile)

Vous pouvez toujours ajouter intentionnellement des bugs et de les corriger.

Answer 4

Vous pouvez demander aux développeurs quelle est leur opinion est la plus longue partie du cycle de correction des bogues et pensez comment vous pouvez utiliser ces informations.

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