Mon patron a décidé d'ajouter un champ «personne à blâmer» à chaque rapport de bogue. Comment puis-je le convaincre que c'est une mauvaise idée?

Dans l'un des derniers mouvements "WTF", mon patron a décidé que l'ajout d'un champ "Personne à blâmer" à notre modèle de suivi des bogues augmenterait la responsabilisation (même si nous avons déjà un moyen de lier les bogues aux fonctionnalités / histoires). Mes arguments selon lesquels cela diminuerait le moral, augmenterait l'indication des doigts et ne tiendrait pas compte des fonctionnalités manquantes / incompris rapportées comme des bogues sont passés inaperçus.

Quels autres arguments forts contre cette pratique puis-je utiliser? Y a-t-il une écriture sur ce sujet que je puisse partager avec l'équipe et le patron?

Dites-leur qu'il ne s'agit que d'un nom amateur du champ Cause d'origine utilisé par les professionnels (lorsque le suivi des problèmes n'a pas de champ dédié, on peut utiliser des commentaires pour cela).

Rechercher sur le Web pour quelque chose comme le logiciel bug analyse des causes profondes , il y a beaucoup de ressources pour justifier ce raisonnement ^{1 , 2 , 3 , 4 , ...} .

... une cause fondamentale d'un défaut n'est pas toujours un développeur unique (qui est le point principal de ce champ) ...

C'est exactement pourquoi "la cause fondamentale" est professionnelle alors que "la personne à blâmer" est amateur. La responsabilité personnelle est excellente, mais il y a des cas où elle se situe simplement à l'extérieur de l'équipe de développement.

Dites à votre patron quand il y a un seul développeur à blâmer, le champ de la cause fondamentale couvrira définitivement cela ( "erreur de codage faite par Bob dans le commit 1234, manquée par Jim dans le commentaire 567" ). L'intérêt d'utiliser le terme cause racine est de couvrir de tels cas, ainsi que des cas sortant du cadre de l'équipe de développement.

^{Par exemple, si le bogue a été causé par un matériel défectueux (la personne à blâmer étant une personne extérieure à l'équipe qui l'a acheté et testé), le champ de cause première permet de couvrir ce problème, tandis que "le développeur à blâmer" casserait simplement le flux de suivi des problèmes .}

^{La même chose s'applique aux autres bogues causés par une personne extérieure à l'équipe de développement - erreurs de testeur, modification des exigences et décisions de gestion. Supposons que si la direction décide de ne pas investir dans du matériel de reprise après sinistre, "blâmer un seul développeur" pour une panne d'électricité dans le centre de données n'aurait tout simplement aucun sens.}

Un autre résultat probable pour une telle politique est que les personnes ne signaleront pas de bogue si elles pensent être la "personne à blâmer", ce qui réduira en fait le nombre de bogues signalés par l'équipe.

L'argument principal que j'utiliserais contre cela est de demander quel problème il essaie de résoudre. Il y a presque certainement de meilleurs moyens de résoudre le même problème.

D'une part, n'y a-t-il vraiment qu'une seule personne à blâmer? Si c'est le cas, vous faites autre chose de mal. Un bon processus nécessite un travail effectué par un analyste, un programmeur, un réviseur et un testeur avant sa mise en production. Si vous ne faites pas toutes ces étapes, c'est peut-être la solution au problème que votre patron tente de résoudre. Si vous êtes alors lequel est à blâmer? Ce n'est peut-être aucun d'entre eux, ce pourrait être le code hérité qui est à blâmer.

Il ne sert à rien que les gens piquent et pointent du doigt, essayant d'éviter une marque noire qui ne disparaîtra pas une fois fixée. Cela ne résout rien. Très peu de personnes font preuve de malveillance par négligence. Vous devez faire une rétrospective appropriée , voir ce qui ne va pas et ce que vous pouvez faire pour vous assurer que cela ne se reproduira plus.

À partir de là, vous verrez clairement si une personne est régulièrement en faute et le problème peut être différent.

L'astuce pour empêcher un responsable de créer de la responsabilité est de l' offrir librement , mais d'une manière qui a du sens pour vous.

Il y a au moins trois problèmes dans ce domaine.

La première est que blâmer les gens n'est pas bon pour le moral. D'accord. Mais peut-être ne se soucie-t-il pas du moral et veut-il renvoyer les mauvais développeurs. Difficile de discuter contre.

Deuxièmement, il sera difficile de réussir dans ce domaine et de perdre beaucoup de temps. C'est plus complexe que de trouver qui a écrit le mauvais code. Et toute information potentiellement difficile à comprendre peut faire l’objet d’un sac de sable. Mais peut-être qu'il est prêt à payer ce coût et à vérifier l'information. Bien.

La question la plus fondamentale est que ce domaine ne sera pas un bon indicateur pour prendre des mesures. Bien sûr, il aura un bon classement du code qui cause le plus de défauts. Mais devinez qui sera en tête de cette liste? Probablement le fondateur de la société, ou peut-être un développeur de haut niveau qui a un taux de défauts très bas mais qui est si productif qu'il écrit une partie démesurée du code. Il finira donc par renvoyer son meilleur développeur ou le ralentira tellement qu'il n'est plus son meilleur développeur. Et le gars qui écrit une ligne de code chaque mois - de préférence des commentaires - sera probablement récompensé pour ses faibles nombres de défauts.

Encore un autre échec de métrique de logiciel.

La cause première d'un défaut sur le terrain n'est jamais une seule personne. Des personnes parfaitement consciencieuses commettront des erreurs, et un processus qui les attend infaillibles est déraisonnable. Si vous ne vérifiez pas les modifications apportées aux systèmes de production avant le déploiement, que ce soit manuellement ou via des tests automatisés, les bogues sont inévitables.

Faux:

Bob oublie de vérifier les entrées et le programme a planté en divisant par zéro.

Droite:

Le code vulnérable à une erreur de division par zéro n'a pas été détecté avant le déploiement. De nouveaux cas de test ont été ajoutés pour vérifier le traitement correct des entrées non valides. Le code a été corrigé et tous les nouveaux cas de test réussissent.

Changer "Personne à blâmer" en "Personne à louer"

La personne responsable de la correction des bugs porte son nom.

Réponse simple.

Le champ "Blame" ne sera utilisé que pour les boucs émissaires et les doigtés, le moral va s'effondrer, la confiance de l'équipe sera détruite et tout le monde tentera de trouver le moyen de prouver que quelque chose n'est pas de sa faute au lieu de le réparer. Les gens seront également plus enclins à garder le silence sur les bugs au lieu de les signaler, car ils ne veulent pas que leurs collègues aient des problèmes. C'est complètement contre-productif.

Quoi de plus important, victimiser quelqu'un pour avoir commis une erreur honnête, ou avoir résolu le problème le plus rapidement possible?

Votre patron semble penser que les insectes sont un signe de paresse ou de négligence. Ils ne sont pas. Ils sont une réalité de la vie. Combien de correctifs Microsoft envoie-t-il en un an?

Si vous êtes prêt pour un peu de désobéissance civile, demandez à l'équipe d'accepter de mettre une liste de tous les développeurs dans ce champ pour chaque bogue. Si cela ne vous convient pas, écrivez "Je suis Spartacus!" au lieu. Bien entendu, le fait est que vous êtes tous responsables de tous les bogues et que vous n'êtes pas content de devoir désigner la personne qui a créé un bogue.

Une autre option: jouer le long. Ne faites rien de particulier, faites du bon travail et remplissez le champ aussi précisément que possible pendant quelques mois. Puis expliquez au patron que l’attribution d’une faute à chaque bogue rend tous les membres de l’équipe malheureux et inconfortables. Dites-lui que vous avez tous l'impression qu'il y a peu de corrélation entre les bugs créés et toute autre chose (compétence, effort, santé mentale). (Cela vous aidera si vous pouvez utiliser des chiffres montrant qu'il n'y a pas vraiment de corrélation.)

Désobéissance civile gandhienne: Indiquez votre nom sur tous les domaines (à moins que d'autres développeurs n'interviennent et signalent leurs bogues), et acceptez de blâmer chaque bogue, qu'il soit vôtre ou non. Rien ne rendra ce champ ou l'idée de blâmer quelqu'un plus inutile que cela. Si votre patron vous demande pourquoi vous vous appelez dans tous les domaines, vous pouvez expliquer "parce que je ne pense pas que le développement est un jeu de reproches, si vous avez vraiment besoin que des personnes soient blâmées et crucifiées, alors crucifiez-moi pour tout et laissez mon équipe travailler en paix." . "

Un jour, un patron a mis en place un système très similaire à celui-ci. Bien que ce ne soit pas une programmation (il s’agissait d’une conception imprimée pour un quotidien), le concept et la réponse appropriée sont les mêmes.

Au lieu d'ajouter un champ «personne à blâmer» sur nos documents, elle a remis à chacun des concepteurs un ensemble d'autocollants colorés. Chaque concepteur a reçu un autocollant de couleur différente et a été informé que pour toute conception travaillée ou même touchée, la vignette devait être ajoutée à la documentation de cette conception.

L'objectif déclaré du patron pour "l'initiative des autocollants" était de déterminer la source de toutes les erreurs de notre service (erreurs dans la paperasserie, erreurs de classement, copie incorrecte, essentiellement l'équivalent imprimé de bugs).

Ce que nous avons fait a été de donner à chacun des autres concepteurs un quart de nos autocollants afin que nous puissions chacun avoir toutes les couleurs. Au lieu de simplement mettre notre couleur sur chaque motif, nous avons mis les quatre couleurs des concepteurs.

N'écrivez pas simplement votre nom dans la case [Blame] - indiquez le nom de chacun dans l'équipe / le projet et assurez-vous que toute l'équipe fait de même.

Nous avons travaillé ensemble contre sa chienne orwellienne et, en conséquence, nous avons fini par rattraper les erreurs des uns et des autres et à nous en parler, ce qui a finalement abouti à une réduction significative des erreurs. Cependant, elle était une gestionnaire de bord et, au lieu de reconnaître que son initiative avait fini par nous unir et accroître sa productivité, elle a tout obtenu, a dissous le système de vignettes et l'a déclaré échec. Elle nous a tous officiellement réprimandés.

Cela finira par punir son programmeur le plus prolifique. Les chances sont, une ou deux personnes pourraient être les meilleurs employés qui ont travaillé sur la plupart des projets. Si vous avez, dans un département de 10 personnes, un codeur qui est juste une source de sortie et qu'il a écrit 60% du code d'interface, alors 60% des bogues seront dans son code.

Expliquez que ce système donnerait l’impression que la personne qui écrit le plus de code est le pire programmeur, et la personne qui écrit le moins de code est le meilleur programmeur.

Cela ressemble beaucoup à la situation où Scott Adams avait souligné la sagesse manquée du Bug Bounty lorsque le chef aux cheveux pointus de Dilbert. Wally a annoncé qu'il allait lui écrire une nouvelle mini fourgonnette ".

Bande dessinée Dilbert du 13/11/1995 dans les archives officielles de la bande dessinée Dilbert.

Je me souviens d'une fois, quand Snow Skiing, quelqu'un a fait remarquer que «ne pas tomber» n'était pas le signe d'un bon skieur, mais souvent celui d'une personne qui n'essaie pas (ou ne skie pas du tout).

Des bogues peuvent être introduits dans le code en raison d'une mauvaise programmation et d'une mauvaise conception. mais, ils peuvent aussi être la conséquence de l'écriture de nombreux codes difficiles. Dinger les personnes qui produisent le plus de bugs est tout aussi probable pour les développeurs Ding pauvres que les plus productifs.

Il semble que votre patron soit frustré par le nombre de défauts. Les membres de votre groupe sont-ils passionnés par la qualité? Créer un champ "quoi" pour la cause plutôt qu'un champ "qui" pourrait être plus productif. Ex.: Modification des exigences, défaut de conception, défaut de mise en œuvre, etc. Même si cela échouera, à moins d'un groupe pour améliorer la qualité du produit.

Peut-être devriez-vous le regarder comme "Qui est le mieux placé pour corriger le bogue?" Une partie de moi aussi sent, tu l'as cassé, tu le répares. Il devrait y avoir une certaine responsabilité.

Je ne suis pas d'accord avec garder une sorte de score. Certaines personnes créent plus de bogues car elles travaillent sur des parties plus complexes du code. Si les lignes de code ne sont pas une métrique utile, je doute que les bogues par lignes de code soient meilleurs. Le code ne sera jamais enregistré

À un moment donné, un manager devrait savoir qui fait son travail et qui ne le fait pas, ainsi que qui le fait mieux parce que le reste de l'équipe le fait.

Il est étrange que personne ne l’ait mentionné auparavant: l’ajout d’une telle fonctionnalité au système de suivi des bogues inciterait les employés à essayer de jouer au système .

C'est un problème courant pour des approches telles que celle présentée dans la question, parmi d'autres idées similaires (payer en fonction du nombre de lignes de code, payer en fonction du nombre de bogues). Cela en encouragera beaucoup à se concentrer sur l'obtention d'un bon score, au lieu de résoudre les problèmes liés au logiciel sur lequel ils travaillent.

Par exemple, essayer de soumettre un rapport de bogue avec un libellé pour atténuer son blâme et le renvoyer à quelqu'un d'autre peut amener les développeurs à mal comprendre la cause du problème (ou le travail confié à un autre développeur qui ne connaît pas cette section de un code aussi bon que celui qui y travaillait le plus et qui était la principale cause du bogue) nécessitant plus de temps et d’efforts pour résoudre le problème.

Votre question portait sur la manière de changer la culture avant de quitter l'entreprise, en convaincant votre patron que le fait d'ajouter une personne à blâmer pour les rapports de bogues est une mauvaise idée. Mais bien sûr, pour changer de culture, il doit vraiment comprendre pourquoi c'est une mauvaise idée.

C'est un défi de taille. Outre la question de sauver la face après avoir changé d'avis, il existe un problème fondamental: les personnes qui pensent aux solutions principalement en termes de reproches individuels sont généralement bien ancrées dans cet état d'esprit.

Vous avez demandé à écrire sur ce sujet, et Peopleware vient à l’esprit. Il est hautement considéré et parle en termes généraux de la façon de gérer les personnes qui font un travail créatif lorsque le résultat est difficile à mesurer. Le problème, c'est que si vous le lisez, cela ne vous aidera pas beaucoup, votre patron devrait le lire et en croire au moins une partie.

Bizarrement, étant donné que le problème ici concerne davantage les personnes que les rapports de bogues, il appartient probablement davantage au lieu de travail qu'aux programmeurs. Mais le succès des projets logiciels dépend généralement beaucoup de l’interaction sociale entre l’homme et les vraies réponses portent donc souvent sur des choses qui transcendent les logiciels.

Ma seule autre suggestion, légèrement sérieuse, est de dire (ou de convaincre un collègue de dire, puisque vous envisagez de partir) que vous êtes prêt à assumer l'entière responsabilité de la réussite du projet et que votre nom doit toujours aller sur le terrain. car même si quelqu'un d'autre a commis l'erreur directement, vous avez la responsabilité de vous assurer que tous les membres de l'équipe effectuent un travail de qualité.

C'est absurde, bien sûr, comment pourriez-vous jamais revenir en arrière, mais certaines personnes (surtout les gros coupables) mangent vraiment ce genre de choses. Ronald Reagan avait l'habitude d'assumer publiquement sa responsabilité personnelle chaque fois qu'un membre de son administration était pris dans un scandale (et il y en avait plusieurs) et que tout se passait plutôt bien politiquement. La meilleure partie pour vous est que la responsabilité n'entraîne généralement aucune conséquence réelle, ils pensent simplement que vous êtes un type à prendre pour la responsabilité.

Ou peut-être que ce n'est pas comme ça que ça va aller. Cela n’a aucun sens pour moi, alors il m’est difficile de prédire quand cela fonctionnera, mais j’ai été témoin du fait que cela fonctionnait alors qu’il semblait ne pas y avoir d’affaires (sur le lieu de travail, pas seulement l’exemple de Reagan).

Les gens ne vont pas au travail avec la ferme intention de commettre des erreurs, et toute stratégie mise en place pour imputer de manière spécifique la responsabilité de ce qui peut être ou non une erreur humaine est ridicule - pour ne pas mentionner un manque de professionnalisme extrême.

Au minimum, une "partie responsable" chargée de prendre en charge et de "régler" le problème, ou d'élaborer un plan pour suivre et / ou empêcher que de tels événements se produisent, serait une bonne chose. Parfois, la solution n'est rien de plus qu'une formation supplémentaire. J'ai travaillé pour un certain nombre d'entreprises où cela faisait partie de votre description de travail, pour obtenir une formation "entreprise rémunérée / temps passé en entreprise". Un endroit a même construit tout un "centre de formation", que le collège local "emprunte" à l'occasion, pour ses cours sur les technologies industrielles.

Je travaille dans un environnement manufacturier depuis 20 ans, où les erreurs de programmation ne font pas que causer des erreurs, elles détruisent physiquement des choses et / ou, pire, elles blessent des gens. Cependant, dans tous les domaines de la fabrication, une constante est qu’il n’ya jamais de responsable. Parce que c'est un défaut du système, clair et simple - pas un défaut du personnel. Examinez-le de la manière suivante: l’utilisation du correcteur orthographique - un outil extrêmement efficace, pour les moins fortunés dans le domaine de la virtuosité textuelle, ou peut-être simplement ceux qui sont un peu trop travaillés… mais en aucun cas une méthode de blâme ou de responsabilité.

Un environnement de travail, quel que soit son type ou son objectif, est un système. Un système composé de composants individuels qui, s’ils sont correctement "accordés", fonctionne en totale harmonie - ou un semblant de ce genre.

Suggestions de lecture de la part de votre patron: Les 7 habitudes des personnes extrêmement efficaces

On dirait qu'il pourrait utiliser un peu d'humilité, sinon une vérification de la réalité. Il fait tout autant partie de l'équipe que tout le monde et il doit se rendre compte que cela ne fonctionnera tout simplement pas et qu'en fin de compte, il tiendra le sac malgré tout.

Suggestions de lecture et / ou de recherche de votre part:

Examinez les raisons pour lesquelles l'analyse, l'analyse des causes fondamentales ... tout ce qui vous permet de mieux proposer une solution, pas un problème . Et votre désaccord avec votre patron, c'est juste que, un problème, pas une solution. Offrez-lui quelque chose de mieux, quelque chose qui a du sens, et soyez même prêt à lui permettre de prendre le crédit pour cette idée.

À l'heure actuelle, il ne semble pas qu'il soit prêt à réparer quoi que ce soit, car il ne comprend pas bien ce qui est brisé, s'il y a quelque chose de brisé, à part sa mentalité "je suis le patron".

Bonne chance! J'espère que vous réussirez à vous en sortir, d'une manière qui soit acceptable pour tous, surtout en ces temps difficiles.

EDIT: Personnellement, de ma propre expérience ... "Allez-y, reprenez-moi. Parce que bien sûr, je vais le réparer, et sur la route, quand cela se reproduira, qui sera là pour sauver la journée? Yep, vous deviné ... moi, avec un grand sourire. "

Pour la responsabilité, je ne voudrais pas d'un person to blamechamp, je voudrais un Person who knows the codechamp ou un person who can fixchamp, afin de savoir où envoyer le ticket d'assistance.

Cela accélèrerait le processus de correction du bogue lui-même et donnerait une responsabilité, un peu comme tuer deux oiseaux avec une pierre. Personnellement, je le lui demanderais et le laisserais décider si cela contribuerait à améliorer le moral et la responsabilisation sans que quiconque ait l'impression qu'ils ont échoué. Les tests extrêmes ne détectent pas tous les bogues, sinon il n'y aurait pas de rapport de bogue.

Dites-lui que "le blâme" est négatif. Changez-le en "personne à réparer" alors au moins, il est encadré de manière positive, et le même travail est toujours fait. Comment les gens peuvent-ils travailler s'ils se font "blâmer"?!

Si mon supérieur hiérarchique agissait de la sorte, voici ce qui se passerait dans cet ordre:

1) Je commencerais immédiatement à chercher un nouvel emploi.

2) Chaque fois qu'un bogue est blâmé avec une personne à blâmer, le nom de mon patron y apparaît, et un commentaire expliquant pourquoi un mauvais processus dans l'équipe en est responsable. Et CC ça à son patron (de préférence en lot). Avez-vous des tests unitaires? Sinon, cela signifie que le processus de développement est interrompu, d'où le bogue. Avez-vous des tests d'intégration automatisés constants avec tous les systèmes externes? Ensuite, le processus de développement est interrompu, d'où le bogue. Avez-vous la possibilité de rendre chaque environnement identique dans la production via un script pour éviter toute erreur humaine? Ensuite, le processus de développement est interrompu, d'où le bogue. Un développeur est-il terrible? Ensuite, le critère d’embauche est le badm, donc la faute du patron. Tous les développeurs font-ils des erreurs stupides par manque de repos parce qu’ils travaillent 12 heures par jour? Ensuite, le processus de développement est brisé.

Remarque: chaque bon responsable du développement est conscient de ce que j'ai écrit ci-dessus. Et les stratégies Agiles ont pour but de montrer au patron ou à son supérieur pourquoi le ralentissement du développement ralentit: Regardez, nous passons 50% de notre temps à réparer les bugs. Examinons des stratégies pour les réduire afin que nous puissions passer 40% du temps à réparer les bogues, puis réexaminons ce problème pour le ramener à 30%. etc.

Malheureusement, il semble que vous n’ayez pas un bon manager à cause du terrain. Je suggère donc de faire (1) et de ne pas en parler au responsable (sauf lors de votre entretien de départ)

Il semble que votre patron n’a pas une connaissance approfondie des logiciels et qu’il n’en a peut-être pas l’intention. Donc, il a une langue différente, une culture différente.

Quitter un emploi pour un problème comme celui-ci, avant même d'essayer de trouver une solution, c'est simplement être un lâcheur. Quitter, c'est quitter. N'abandonnez pas avant qu'il ne vous assure que vous ne pourrez jamais vous comprendre. Pour en être sûr, vous devriez d'abord essayer.

Puisqu'il ne connaît pas notre langue et qu'il est le chef, la première étape serait d'essayer de lui parler dans sa langue. Qu'est-ce que je veux dire avec la langue? Pensons ensemble:

Nous, spécialistes des logiciels, la plupart d’entre nous aimons le travail que nous accomplissons, nous avons un lien profond avec ce que nous faisons. Sinon, cela ne fonctionne pas et on ne peut pas continuer longtemps dans cette affaire sans l'aimer ou en être un complet ... vous remplissez les blancs ...

Cependant, il voit les choses très différemment. Avec chaque rapport de bogue, alors que la plupart d’entre nous sont enthousiastes à l’idée de rendre le système plus performant (non, même si c’est parfois très stressant, nous adorons les problèmes, admettez-le juste!), Il le voit comme un échec, une mesure d'être infructueux. La première chose qu’il devrait comprendre, c’est que les bugs sont bons. Les insectes font que les clients aiment l'entreprise. (Maintenant, c'est sa langue) Lorsqu'un client rapporte un bogue, ou lorsque nous en trouvons un nous-mêmes, une fois résolu, le problème est bien meilleur que la situation ne s'est jamais produite. Les bugs créent la fidélité des clients (je suis sérieux!), Les bugs constituent une excellente excuse pour la communication entre le consommateur et le producteur du logiciel.

Pour "augmenter le bénéfice des bogues", vous devez proposer de rendre les rapports de bogues encore plus ouverts. Avec chaque rapport de bogue et sa solution rapide, propre et efficace, les clients ressentent et constatent que "wow, ces gars-là sont géniaux! Ils travaillent très dur. Regardez ce qu'ils sont en train de résoudre. Nous ne savions même pas que le logiciel était si complexe. chose!" bla bla et bla ...

Fais ton geste, parle dans sa langue. Les bugs sont parfaits pour une entreprise de logiciels, pas un problème. Ils nous font vivre.

Pour l’éthique d’équipe, l’efficacité ou tout autre type de discours que vous feriez peut-être fonctionner de la manière opposée. Si vous voulez arrêter de fumer, il va penser "aha, ma solution a commencé à fonctionner dès le premier jour! Les mauvais liens ont déjà commencé à disparaître d'eux-mêmes avant d'être exposés!" Il croit en son idée de trouver les mauvais garçons de la compagnie et il est très difficile de le convaincre du contraire. Surtout quand vous pourriez être l'un de ces mauvais garçons!

Alors, concentrez-vous sur son vrai problème: Bugs. Montrez-lui que les insectes peuvent être très utiles. Sans aucun problème, une relation est ennuyeuse. Tout ce qui ne vous tue pas vous rend plus fort. Chaque bogue est une excellente occasion d’augmenter le bonheur de vos clients.

Ceci est juste une chose que vous pouvez dire. Pensez à ses préoccupations et vous trouverez de nombreux autres éléments à ajouter à votre liste. La clé d'or est d'offrir une alternative au lieu de se battre avec son idée!

Si vous faites de l’agile, cela ressemble à du commentaire sur les caractéristiques / histoires . La personne à blâmer serait la personne d'assurance qualité qui aurait laissé le bogue passer au travers, ou le propriétaire du produit / client qui aurait accepté la fonctionnalité / l'histoire comme complète avec le bogue qu'il contenait.

J'ai fait la composition dans la journée, voici mon point de vue.

Cela revient à blâmer un compositeur pour des fautes d’orthographe et autres choses qu’un correcteur aurait dû trouver mais qu’il aurait manquées. Le dactylographe a mal orthographié, mais le relecteur l'a manquée. C'est donc le relecteur à blâmer pour l'erreur d'impression, et non la personne qui a commis l'erreur au départ.

Dans un environnement agile, il incombe aux personnes responsables de l'assurance qualité de détecter les erreurs (bugs) et aux propriétaires de produits de ne pas accepter des choses qui ne sont pas correctes. Il s’agit de deux niveaux de lecteurs d’épreuves qui doivent isoler les développeurs des éléments publiés, ce qui est la seule façon de classer tout ce qui doit être classé comme un bogue dans un environnement Agile.

Je pense que votre responsable essaie de résoudre un problème avec la mauvaise solution. Je pense que le problème est peut-être que trop de bogues ont été publiés et que votre responsable souhaite que les développeurs prennent davantage en charge le code qu’ils écrivent.

Le développement piloté par les tests et la mise en place d’un serveur d’intégration continue (comme Jenkins ) aideront à résoudre ce problème, sans introduire le "jeu du blâme". Un serveur d'intégration continue est important pour cela, car lorsqu'une personne commet un code qui "rompt la construction", un courrier électronique est envoyé à l'équipe pour lui montrer le responsable. Puisque ce code n'a pas été publié dans un environnement de production, ce type de blâme est plus proactif et encourageant (et amusant!).

Le résultat est que les développeurs vont s'approprier davantage, se sentir plus en confiance et qu'il y aura moins de bugs dans le code de production.

Indiquez que si l'erreur d'une seule personne entraîne la fin d'un bogue dans la production, votre méthodologie ou votre méthode globale de développement de logiciels présente un problème. Indiquez que toute l'équipe est responsable d'empêcher que des bugs n'atteignent la production.

En utilisant l’un ou l’autre de ces arguments, voyez si vous pouvez convaincre votre patron qu’avoir le champ "à blâmer" en tant que champ à sélection unique serait trompeur; et que, par conséquent, il est nécessaire de s’assurer que le champ "à blâmer" est un champ à sélection multiple. Une fois que vous avez réalisé cela, assurez-vous que pour chaque bogue, le nom de tout le monde est sur le terrain. Votre patron finira par se rendre compte que tout compte rendu sur le terrain est inutile.

Pour donner un peu de crédit au patron, le concept d '"attribution de responsabilité" est déjà intégré dans des outils tels que SVN , et une utilisation appropriée des données peut aider les développeurs à "trouver à qui parler" lors du débogage, par exemple: http: / /www.codinghorror.com/blog/2007/11/who-wrote-this-crap.html

Bien que je sois d’accord avec la réponse de gnat ci-dessus selon laquelle un champ de cause principale est une bonne chose, il ne s’agit pas de la même information, et il est parfois "dénormalisant" le champ pour attribuer le ou les noms de développeur précédent (s) à la source affectée. Une description technique (par exemple, "n'a pas évolué jusqu'à 10000 utilisateurs") ne fera que brouiller les pistes. Je préconise de garder une cause fondamentaleIndiquez clairement une description technique (par exemple, même si une erreur de programmation est claire, demandez-lui de saisir des détails tels que "Exception IndexOutOfRange lorsque fooData = 999"). Cela peut potentiellement fournir des informations utiles lorsqu’elles sont examinées en masse et permettre l’adoption de mesures correctives. pour résoudre des classes entières de problèmes avec des modifications d'architecture ou de structure (par exemple, amélioration des classes de conteneur personnalisées, gestion des exceptions de niveau supérieur)

Cela dit, l'ajout d'un champ Personne à blâmer peut clairement envoyer un très mauvais message et un message destructeur à une équipe de logiciels que la direction souhaite identifier et punir les développeurs individuels qui paient le plus souvent le code. Je pense que le responsable pense que cet examen public poussera les développeurs à être plus prudents et à s'autoréglementer pour éviter de se faire nommer sur ce "mur de la honte", et je ne comprends pas pourquoi les développeurs se sentiraient menacés par cette situation, surtout si elle est ajoutée. génériquement à chaque rapport de bogue.

Il est facile de commencer à énumérer les problèmes liés à l'ajout de cela en tant que champ de bogue / métrique potentielle:

1. Les bugs ont des difficultés de résolution très variables, et une simple statistique de nombre de bogues / développeur ne le reflétera pas.
2. Les développeurs ont des capacités très variables "" "" "" "" "" "
3. De nombreux systèmes logiciels comportent des composants nécessitant une refactorisation; toutefois, les composants existants (en particulier si la base existante ne dispose d'aucune installation de test unitaire / limitée) introduiront initialement des bogues. Les développeurs risquent d'être découragés de cette "bonne" activité, s'il existe une stigmatisation / peur associée à la génération de nouveaux bogues (même s'ils sont triviaux à résoudre et que le résultat final est une amélioration majeure du système.)
4. Les testeurs peuvent générer un nombre très variable de bogues liés au même problème, ce qui entraîne un nombre de bogues / développeur très asymétrique, à moins qu'une analyse plus détaillée ne soit effectuée.

Ce n'est que la pointe de l'iceberg. Combinez ces éléments avec l'indication précise du comportement attendu de l'API, des résultats attendus incorrects dans les tests et des problèmes "plus tôt dans la chaîne" avec des exigences incorrectes / manquantes, et il devrait être évident qu'une métrique comme celle-ci est vouée à l'échec le but est d’endommager le moral et de provoquer un exode massif.)

Pour revenir au point de vue du patron, il est normal qu’il / elle cherche à savoir s’il existe des développeurs qui enfreignent le code à plusieurs reprises et essaie de faire quelque chose (de manière constructive, à cet égard). Essayer d'obtenir ces informations en ajoutant un champ aux rapports de bogues ne fournira pas d'informations significatives pour les raisons énumérées ci-dessus. D'après mon expérience, ces informations peuvent être apprises en étant connectées à l'équipe, en participant à la plupart des réunions de l'équipe, en intégrant (avec soin) les informations apprises lors de réunions individuelles avec des membres de l'équipe, et en se familiarisant avec les sous-systèmes de le code (même s'ils ne peuvent pas lire le code.)

Laisser faire. Votre patron découvrira seul que cela cause un problème, si cela se produit.

Soyons francs, vous avez une opinion et lui aussi. Il est votre manager et son opinion est celle qui gagne.

Oui, vous pouvez faire la guerre à ce sujet, mais est-ce que cela en vaut vraiment la peine? Je doute que cela dure plus de 3 mois avant de tomber en désuétude.

Mais saboter activement ou crier dessus utilise simplement un capital politique mieux sauvegardé pour demander un congé supplémentaire, une prochaine augmentation, une promotion ou lorsqu’une décision de conception vraiment critique sera prise.

À ce moment-là, quand cela compte vraiment, vous ne voulez pas que le chef se souvienne que vous êtes la personne qui a activement saboté son idée de "personne à blâmer".

Respectez le bureau même si vous ne respectez pas la décision.

Économisez le stress et battez-vous à la table pour prendre des décisions qui dureront beaucoup plus longtemps.

Dites à votre patron que le développement en équipe nécessite des compétences sociales. Il pourrait même hocher la tête.

Mais le problème, c’est que c’est une chose avec laquelle les développeurs sont extrêmement mauvais. L'ajout d'outils suggérant blâmer est plus important qu'une analyse correcte du problème est contre-productif.

Au lieu de cela, vous avez besoin d'incitations pour améliorer les compétences sociales, et l'infrastructure de communication que vous avez doit le supporter. Par exemple, exprimez-le de façon positive: nommez une personne responsable d’un ticket, qui s’occupe de celui-ci.

Commencez également par des revues de code afin que vous puissiez apprendre les uns des autres. Cela épargne les reproches plus tard.

Envoyez-lui cette question SO. S'il est ouvert à la raison, les commentaires ici fourniront des contrôles de cohérence pour son raisonnement. S'il n'est pas raisonnable, il est peu probable que vous le convainciez avec des raisons sensées. De plus, il sera capable de lire les raisons en dehors d'une conversation (ce qui peut parfois être plus convaincant en raison de la motivation retirée pour "avoir raison" dans le feu de la conversation).

Vous pouvez également essayer de renverser la situation. Ce champ pourrait être "les étapes possibles pour éviter un bogue similaire", ou quelque chose de plus court à cet effet. Vous pourrez ensuite mettre en commun les solutions et voter sur les solutions à mettre en œuvre pour améliorer votre lieu de travail. Une approche axée sur les solutions est peut-être plus productive et probablement mieux accueillie (à condition que les suggestions soient réexaminées).

Je vois deux possibilités ici: il veut pouvoir punir les gens qui font des erreurs, ou il n'y a tout simplement pas réfléchi. Dites-lui que chacun aura l’impression de vouloir punir ceux qui commettent des erreurs. Demandez-lui si c'est la culture qu'il veut encourager.

mon patron a décidé que l'ajout d'un champ "Personne à blâmer" à notre modèle de suivi des bogues augmenterait la responsabilité

Selon mon expérience, lorsque la direction veut «responsabiliser davantage les gens», elle veut simplement pouvoir punir les personnes qui échouent. Qu'il s'agisse de licencier des personnes peu performantes ou simplement de les laisser se perdre dans la révision annuelle des salaires ("Désolé, Bob, vous aviez 17 bogues signalés comme étant votre faute, et c'est au-dessus de la limite de 15"), c'est une punition.

Il dira probablement "Oh, non, nous ne le voulons pas", alors demandez-lui comment ces données seront utilisées. Rappelez-lui que vous n'ajoutez pas de points de données à une base de données à moins que vous ne l'utilisiez. Veut-il sélectionner un critère donné ("Montre-moi tous les bogues non résolus dans le sous-système créateur de rapport"), afin de pouvoir travailler sur des choses ou obtenir des données agrégées ("Quel sous-système a eu le plus de problèmes?"). bugs "), afin que vous puissiez faire une analyse post-mortem. Envisage-t-il une sorte de plateau d'échec où les gens peuvent être humiliés publiquement?

Alors qu'est-ce qu'il a l'intention? Veut-il pouvoir dire "Montre-moi tous les bugs qui sont la faute de Bob?" Pourquoi? Ou veut-il pouvoir dire "Montre-moi qui est en faute la plupart du temps?" Pourquoi? Le premier n'a pas de sens et le second n'est que punitif. Ou la troisième option est qu'il n'a pas de vraie raison.

J'admets qu'il est possible qu'il recherche des programmeurs de l'équipe qui ont besoin d'aide pour améliorer leurs compétences. Si tel est le cas, il existe de meilleurs moyens de capturer ces informations sans créer de culture de pointage du doigt.

Je pense que l'aspect clé à surveiller ici est le degré d'ouverture de la communication dans l'équipe envers le «patron» et vice-versa. Il n'est jamais bon de pointer du doigt du point de vue de la gestion. Si un de vos développeurs tombe plusieurs fois dans le même problème, il peut être temps d'intervenir et de l'aider à surmonter ce problème répétitif (par exemple, John ne teste pas correctement le code: 3 bogues de production au cours des 3 derniers mois, donnons-lui une liste de contrôle afin qu'il se souvienne de la manière dont son code est censé être et comment il devrait le tester).

Du point de vue du développement, "blâmer" est déjà intégré dans un outil grand public tel que SVN, donc je ne vois vraiment pas de mal à dire "John, corrige ce bordel que tu as écrit" et place un nom à côté de il. JIRA incorpore également le nom d’une personne lorsque vous enregistrez un bogue (toutefois, le champ n’est pas vraiment destiné à la personne qui en est responsable, c’est assez bien pour que quelqu'un le répare).

Cependant, comme beaucoup d’entre eux l’ont mentionné plus haut, si un bogue se présentait, c’est une responsabilité partagée: des développeurs aux testeurs, en passant par le contrôle qualité, en passant par les gestionnaires. Si, à un moment donné, votre patron traite un client en colère au téléphone avec des choses telles que " Je suis vraiment désolé, John n'a jamais testé cela correctement ", alors je chercherais certainement un autre emploi. Un bon patron devrait aller "nous nous en occupons". Pas de noms, pas de doigt, juste des solutions.

Encore une fois, je crois que tout est question de communication. Peut-être que la seule chose que votre patron veut faire est de voir qui a des problèmes dans l’équipe de développement, ou quel genre de problèmes l’équipe a (peut-être pour des séances d’entraînement?), Mais je ne pense pas que vous saurez exactement ce qui se cache derrière son décision (ou plutôt, nous affichons / lecteurs) sauf si vous parlez à votre patron et à votre équipe.