La correction de bugs créés par d'autres personnes est-elle une bonne approche?

Supposons la situation où une équipe de quatre développeurs crée une application. Pendant la phase de test, les bugs sont signalés par les utilisateurs. Qui devrait les réparer? La personne qui a commis le code erroné, ou toute personne libre?

Quelle est l'approche préférée dans le développement agile (Scrum)?

L'approche privilégiée dans le développement agile serait de les corriger le plus rapidement possible, par qui que ce soit. C'est simplement parce que la propriété du code n'appartient pas à une seule personne, mais à l'ensemble du groupe de développeurs. Si une personne provoque régulièrement des bogues, c'est un autre problème qui doit être traité séparément.

Par défaut, la personne. La raison est assez simple: le feedback. Les bogues offrent une excellente opportunité pour des commentaires personnels et professionnels. Si quelqu'un d'autre corrigeait mes bugs, je referais la même erreur, car je n'en tirerais aucune leçon.

Si cette personne n'est pas disponible, quelqu'un d'autre peut le réparer, mais la personne doit suivre le cycle de vie des bogues.

En tant que PM, j'éviterais de lier des bogues à des développeurs spécifiques. Si cela doit être fait, laissez le responsable fonctionnel / développement le faire. Concentrez-vous avec l'équipe. Il y a un bug que l'équipe doit corriger.

Je ne sais pas comment Scrum gère ce scénario, mais dans mon équipe, nous avons quelque chose comme un test croisé / revue de code. De cette façon, en cas de détection d'un bogue, le développeur et le réviseur discutent de la meilleure approche pour le corriger.

Je crois que, tant que la solution convient, peu importe si le développeur ou le réviseur l'applique. Il est cependant important d'éviter tout type de conflit entre développeur et testeur.

Rgds

Edit: Je ne sais pas si je me suis bien fait comprendre, mais il est important de souligner que le réviseur est un autre développeur de l'équipe.

1. Évaluer le bug
2. Si ce sera plus rapide / plus logique pour le développeur d'origine de le réparer, donnez-le lui
3. Si cela peut être corrigé par n'importe qui dans l'équipe, laissez-le faire.

Je suis totalement d'accord avec Steven sur le fait que le code appartient à toute l'équipe; et il y a d'autres raisons pour lesquelles vous ne devriez pas donner le bug à leurs créateurs:

Comme je le sais, dans de nombreux cas, il est difficile d'identifier la cause du bogue. Même si vous utilisez un système de gestion de documents comme SVN, la recherche du code d'erreur peut prendre beaucoup de temps. Donc, à mon avis, donnez simplement le bogue à tous ceux qui sont gratuits.

Si vous souhaitez suivre la façon dont le bug s'est produit, pendant les loisirs, vous pouvez interroger le réparateur sur l'affaire (avant toute l'équipe). Comme votre équipe est petite, je pense que cela partagerait l'expérience sur les éventuels bugs, et ne mettrait personne dans l'embarras.

Il n'y a que trois raisons de se soucier de qui corrige un bug: le coût, la vitesse et le développement professionnel.

Et il y a des avantages et des inconvénients pour les trois. Par exemple, le développement professionnel, d'une part, c'est l'occasion d'en savoir plus sur le code, d'autre part, c'est une opportunité de reconnaître le type d'erreurs que vous faites et d'éviter certaines à l'avenir. Ou prendre des coûts, vraisemblablement celui qui a fait l'erreur serait en mesure de la réparer plus rapidement et probablement moins cher, d'autre part, il y a un coût pour le temps passé à identifier qui a fait l'erreur et à l'attribuer à la personne appropriée - le temps qui dans de nombreux cas dépasse celui de la correction du bug.

L'approche agile consiste à laisser les développeurs auto-attribuer le problème, je ne remplacerais cela que pour une bonne raison.

Dans mon équipe, nous décidons toujours par priorité. si la personne qui a soumis le code est disponible, il / elle corrige le code. Si cette personne travaille sur une histoire de priorité plus élevée, toute personne disponible et capable de corriger le code dès que possible le corrigera. Si tout le monde est occupé à travailler sur des tâches de priorité plus élevée dans l'itération en cours, le correctif est planifié dans l'itération suivante en fonction de sa priorité par rapport aux autres histoires et défauts.

Pensez à: Qui a le plus d'informations sur le bogue? L'équipe de développement.

Laissez-les donc décider quoi faire avec le bogue. Ils sont propriétaires du code, ils en sont donc responsables.

Vous pouvez les aider en gérant le projet, en allouant du temps sur la portée du projet pour les corrections de bogues et en les laissant seuls faire le travail.

Évitez de prendre de nombreuses décisions lorsque vous (en tant que rôle PM) avez moins d'informations que l'équipe.

Voir la question sur: Comment éviter la microgestion d'une équipe de développement logiciel?

Je dis, vous avez besoin d'un système de suivi des bogues pour enregistrer les bogues causés par quoi, signalés par, puis attribuer les bogues à différentes personnes en fonction de leur charge de travail. Indique également le code à l'origine du bogue, puis un rapport indiquant le nombre de codeurs et les applications qui ont causé x nombre de bogues au cours de la semaine.

Ensuite, vous pouvez montrer cela aux codeurs, pour montrer comment ils causent des bugs.

Et la meilleure façon de prévenir les bugs, est d'impliquer tout le monde dans leur correction. Je veux dire attribuer une correction de bogue à différentes personnes, pour donner une expérience complète de ce qui cause les bogues et de ce qui les corrige.

Ensuite, peut-être après un mois ou deux de correction de bogues par tout le monde, révisez ou créez votre ligne directrice de style de codage pour aider à prévenir de futurs bogues, à l'échelle du système, en ayant des normes écrites / documentées pour la façon dont vous programmez.

Lorsqu'un bogue est détecté, il est de la responsabilité de toute l'équipe de développement de le corriger.

Si les gens croient qu'un bug devrait être corrigé par son auteur, c'est comme dire "Je ne résout pas le problème, le trou n'est pas de mon côté du bateau". Mais le bateau coulera toujours si le trou n'est pas fixé, et vous êtes sur ce bateau avec tout le monde.

Les individus doivent se rendre compte qu'ils font partie d'une équipe et comprendre que le code, ainsi que ses responsabilités, leur appartient à tous. Le succès d'un projet repose sur tous les membres de l'équipe.