Je gagne 4 à 5 fois plus de points d'histoire que la moyenne, mais je produis deux fois moins de bugs. Les graphes disent que c'est 2x plus de bugs, comment gérer ça?

43

Il est donc généralement admis que les programmeurs de premier plan peuvent produire un ordre de grandeur supérieur / meilleur que le code de leurs pairs plus ordinaires.

Il est également généralement admis que le taux d’erreurs dans le code est relativement constant pour les programmeurs.

Au lieu de cela, il a tendance à être affecté par les processus utilisés lors de l'écriture du code et après son écriture . (Si je comprends bien), les humains ont tendance à commettre des erreurs à un rythme relativement constant - les meilleurs programmeurs en remarquent simplement plus et sont plus rapides à les réparer.

  • Notez que les deux assertions ci-dessus proviennent de Code Complete de Steve McConnell - il ne s'agit donc pas d'un point de vue différent.

J'ai donc commencé à voir cela récemment dans mon code. Je peux calculer environ 4 à 5 fois plus de code que beaucoup de mes pairs (mesuré en fonction du nombre d'histoires estimées par l'équipe), avec une qualité supérieure (en fonction des indicateurs de performance et du nombre de modifications apportées après l'enregistrement). Mais je fais encore des erreurs. Entre de meilleurs tests unitaires, une meilleure compréhension de ce que fait le code et un œil plus attentif lors de la révision des codes, je ne produis pas 4 à 5 fois plus de bogues.

Mais je produis encore environ deux fois plus de bogues trouvés par le contrôle qualité que les autres développeurs de mon équipe. Comme vous pouvez l’imaginer, cela pose quelques problèmes aux personnes non techniques effectuant des mesures métriques (lisez: mon patron).

J'ai essayé de faire remarquer que je produisais des bogues deux fois moins vite que mes pairs (mais que j'en corrige deux fois plus), mais il est difficile de vendre des graphiques indiquant que je produis deux fois plus de bogues.

Alors, comment gérer le fait qu'une productivité accrue entraînera une augmentation du nombre de bogues?

Telastyn
la source
27
Ou tout simplement ralentir afin que vous puissiez bien faire les choses.
Brandon
29
D'un point de vue pratique, il semblerait que vous évitez davantage les bogues que la génération de code. Passez donc le quart de votre journée à écrire du code pour votre entreprise et passez le reste de la journée à écrire du code pour vos propres projets parallèles. Selon le critère qu'il a défini, votre patron devrait vous aimer.
Rob
14
Je ne comprends pas très bien pourquoi notre communauté semble célébrer la "vitesse" plus que la rectitude. Et j'écris "speed" entre guillemets parce que si vous devez revenir en arrière pour arranger les choses, alors peut-être que ce n'est pas réel. En fin de compte, vous êtes payé pour fournir un logiciel fonctionnel. Si vous écrivez du code plus rapidement que la moyenne, que vous produisiez des bogues, que vous ignoriez les tests ou ne compreniez pas correctement les exigences, prenez du temps que vous "épargnez" et utilisez-le pour améliorer la compréhension de vos tests / exigences (par exemple, faites-vous TDD?). Comme dit Oncle Bob, "si tu veux aller vite, va bien".
MichelHenrich
9
La façon dont vous corrigez cela est en corrigeant les métriques.
Robert Harvey
24
@ MichelHenrich: S'il produit des bogues deux fois moins vite que ses pairs, le problème n'est pas la rapidité. la gestion est le problème. Vous lisez ces statistiques loufoques de la même manière que ses patrons.
Robert Harvey

Réponses:

41

Je pense que vous mélangez vos préoccupations. Et il n'y a rien de votre côté que vous devez changer.

La productivité est un indice de la rapidité avec laquelle un projet sera achevé. Les chefs de projet et tout le monde aiment savoir quand le projet aboutira. Une productivité plus élevée ou plus rapide signifie que le projet sera livré plus rapidement.

Le taux de bogues n'est pas lié à la productivité mais plutôt à la taille du projet. Par exemple, vous pouvez avoir des Nbogues par Ylignes de code. Il n'y a rien dans cette métrique qui indique (ou s'intéresse!) À quelle vitesse ces lignes de code sont écrites.

Pour lier cela ensemble, si vous avez une productivité plus élevée, oui, vous «verrez» les bogues être écrits plus rapidement. Mais de toute façon, vous alliez avoir ce nombre de bugs, car cela est lié à la taille du projet.

Au mieux, une productivité accrue signifie que vous aurez plus de temps à la fin du projet pour chasser ces bogues, sinon le développeur sera plus rapide dans la recherche des bogues créés. 1


Pour aborder les aspects plus personnels de votre question.

Si votre patron examine strictement le nombre de bugs que vous produisez, par opposition au taux de bugs que vous générez, une session éducative est en ordre. Le nombre de bugs créés n'a pas de sens sans taux de sauvegarde.

Pour prendre cet exemple à l'extrême, dites s'il vous plaît à votre patron que je veux doubler votre salaire. Pourquoi? Je n'ai créé absolument aucun bogue sur votre projet et je suis donc un programmeur bien supérieur à vous. Quelle? Il va avoir un problème que je n'ai pas produit une seule ligne de code au profit de votre projet? Ah Nous comprenons maintenant pourquoi le taux est important.

Il semble que votre équipe dispose des mesures nécessaires pour évaluer les bogues par point d’histoire. Si rien d'autre, c'est mieux que d'être mesuré par le nombre brut de bugs créés. Vos meilleurs développeurs devraient créer plus de bogues car ils écrivent plus de code. Demandez à votre patron de jeter ce graphique ou au moins de lancer une autre série derrière celui-ci, indiquant combien de points d'histoire (ou quelle que soit la valeur commerciale que vous mesurez) à côté du nombre de bugs. Ce graphique racontera une histoire plus précise.


1 Ce commentaire en particulier a attiré beaucoup plus d'attention que prévu. Soyons donc un peu pédants (surprise, je sais) et concentrons-nous sur cette question.

La racine de cette question concerne un responsable qui examine les mauvaises choses. Ils examinent les totaux de bogues bruts alors qu’ils devraient examiner le taux de génération par rapport au nombre de tâches accomplies. Ne soyons pas obsédés par la mesure par rapport à des "lignes de code", des points d'histoire, une complexité ou autre. Ce n’est pas la question qui nous occupe et ces inquiétudes nous distraient de la question plus importante.

Comme indiqué dans les liens de l'OP, vous pouvez prédire un certain nombre de bogues dans un projet uniquement par la taille du projet. Oui, vous pouvez réduire ce nombre de bogues grâce à différentes techniques de développement et de test. Encore une fois, ce n'était pas le but de cette question. Pour comprendre cette question, nous devons accepter que, pour un projet de taille donnée et une méthodologie de développement, nous verrons un nombre donné de bogues une fois que le développement sera "terminé".

Revenons donc à ce commentaire que quelques-uns ont complètement mal compris. Si vous attribuez des tâches de taille comparable à deux développeurs, les développeurs avec un taux de productivité plus élevé termineront leur tâche avant l'autre. Le développeur le plus productif disposera donc de plus de temps à la fin de la fenêtre de développement. Ce "temps supplémentaire" (par rapport à l’autre développeur) peut être utilisé pour d’autres tâches, telles que le traitement des défauts qui se répercuteront au cours d’un processus de développement standard.

Nous devons prendre le PO au mot qu'il est plus productif que les autres développeurs. Rien dans ces revendications n'implique que l'OP ou d'autres développeurs plus productifs sont négligés dans leur travail. Soulignant qu'il y aurait moins de bugs s'ils passaient plus de temps sur la fonctionnalité ou suggérant que le débogage ne fait pas partie de ce temps de développement, oublie ce qui a été demandé. Certains développeurs sont plus rapides que d’autres et produisent un travail de qualité comparable ou supérieure. Encore une fois, voir les liens que le PO énonce dans sa question.


la source
43
"Mesurer les progrès de la programmation à l'aide de lignes de code revient à mesurer le progrès de la construction d'un aéronef en termes de poids." -Bill Gates
Neil
40
Les bons programmes peuvent en réalité produire plus d’erreurs que le programmeur moyen, car les bons programmes ont tendance à travailler sur des problèmes plus difficiles.
hlovdal
4
Bugs / K lines ou bugs / storypoint serait un taux juste. Je courrais aussi vite que possible si le patron voulait utiliser un taux de bugs / heure.
Bart van Ingen Schenau
4
"Vos meilleurs développeurs devraient créer plus de bugs parce qu'ils écrivent plus de code." non, ils devraient empêcher les bogues ou en finir avec plus de fonctionnalités. Cela signifie souvent qu'ils écrivent moins de code, ou même enlèvent des pans de code. (vous le savez probablement, vous ne l'avez pas tout à fait écrit ainsi) Certainement, dans certains secteurs d'activité (aérospatial et nucléaire, par exemple), le seul code qui compte est le code dont il a été prouvé qu'il ne présentait aucun défaut. Tout le reste est du bruit.
Pete Kirkham
4
"En fait, une productivité accrue signifie que vous aurez plus de temps à la fin du projet pour chasser ces bogues, sinon le développeur sera plus rapide dans la recherche des bogues créés." - Je pense que ceci est fallacieux et nécessite une analyse plus minutieuse. En d'autres termes: s'il consacrait plus de temps à chaque fonction, il aurait moins de temps pour supprimer les bogues. Mais il y aurait aussi moins de bugs à écraser.
occulus
21

Consacrez une partie de votre temps supplémentaire à nettoyer, polir et tester votre code. Il y aura toujours des erreurs, mais il y en aura moins. Ça prend du temps. Votre débit de sortie de code diminuera, mais votre sortie de code sans bogue augmentera, ce qui entraînera une meilleure productivité. Parce que les insectes sont chers.

Pouvez-vous conserver votre code dans une branche ou un environnement de test jusqu'à ce que vous le récupériez et que vous détectiez davantage de bogues? Les bogues dans une branche provoquent généralement moins de vagues que les bogues dans le code de production.

Mais je ne suis pas en train de creuser vos affirmations, ce qui nous amène à votre question. Et peut-être que votre patron non plus.

Je ne pense pas que tous les codeurs produisent le même taux d'erreur. Votre deuxième lien est en fait entièrement hors sujet, car il compare différentes langues et non pas différents niveaux de compétence de codeur. Code complet mentionne des mesures sur grand échantillon qui portent sur le processus plutôt que sur les compétences des codeurs. Et quand ils disent que les codeurs de haut niveau produisent plus / meilleur code, cela signifie en partie qu'il contient moins de bogues. Dépend de l'application. Donc, oui, je pense que c’EST une question de perspective différente.

En fin de compte, si le patron veut un code plus propre, donnez-lui un code plus propre.

Philippe
la source
4
+1 Je ne sais pas pourquoi l'autre réponse a tant de votes positifs. On dirait que vous avez déjà bien raisonné votre patron et qu'il n'écoute pas. Passez donc plus de temps à tester et moins de temps à "libérer" des lignes de code. Si cela ne vous convient pas, changez de travail.
durron597
21

Je vais sur une branche et être l'avocat du diable. Cela ne veut pas dire que je ne sympathise pas avec votre situation critique, mais bon, ma sympathie ne vous aidera pas. Permettez-moi donc d'ajouter à la perspective de Philip :

Votre patron se préoccupe de la qualité du produit, en partie parce que son nom et sa réputation lui seront liés. Une partie de la qualité est la quantité perçue de bugs . Si vous vendez une perceuse géniale qui fore quatre fois plus rapidement que toutes les foreuses concurrentes, mais se casse deux fois plus souvent, vous aurez une mauvaise réputation. Même s’il est discutable que le foret fonctionne mieux, les gens s’habituent à la vitesse, mais ils se souviendront des pannes.

Avec le recul, la plupart des bugs sont évidemment évitables. Si seulement vous étiez un peu plus prudent, votre patron le sentirait, vous pourriez éviter ces problèmes et tout nettoyage nécessaire. De son point de vue, c'est une chose triviale et sensuelle à poser, et tout argument que vous faites à ce sujet ne fonctionnera pas et vous donnera une mauvaise image.

Il ne peut pas mesurer votre productivité supérieure. Vous revendiquez une productivité plus élevée basée sur une métrique vérifiable. Que pensent donc vos collègues? Sont-ils d'accord, peut-être à contrecœur, que vous êtes un programmeur plus productif, ou êtes-vous seul à votre avis? Vous ferez mieux valoir vos arguments si vous avez d'autres personnes à l'appui de vos affirmations.

C'est pour la perspective. Maintenant, comment allez-vous «réparer» cette situation frustrante dans laquelle vous vous trouvez?

Ralentissez un peu. Mentionnez explicitement à quiconque distribue des tâches que vous allez essayer de réduire le taux de bugs (*), de sorte qu'ils ne soient pas surpris par votre faible consommation. Au contraire, un ralentissement réduira le nombre de bugs qui vous sont attribués par manque d'approvisionnement.

(*) Il y a une différence entre, d'une part, en reconnaissant qu'il ya des bogues à votre nom et que vous allez essayer de réduire ce montant et, d'autre part, en admettant que vous avez trop de bogues à votre nom et devrait passer à l'action.

N'essayez pas de convaincre votre patron, car cela ne fonctionnera pas. Encore une fois, cela ne signifie pas que vous devez concéder votre point de vue; vous pouvez présenter un contrepoint et tenir votre opinion sans rejeter ses préoccupations. Parce que si vous défendez votre argument et ne pouvez pas prouver de manière satisfaisante votre productivité supérieure (et même si vous le pouvez), vous risquez d'insulter vos collègues ou de paraître les ignorer. Tu ne veux pas être ce mec .

JvR
la source
4
Ma réponse préférée, et aussi la plus proche d'un point que j'aimerais ajouter: quelle est la valeur d'un nombre complet de points de scénario et quel est le coût d'un bogue pour l'entreprise? Le PO peut trouver avec ces éléments pondérés par les priorités des patrons qu’il est en fait plus productif de ne créer que deux fois plus de code que les autres développeurs, mais avec beaucoup moins de défauts.
Neil Slater
2
Votre remarque sur l'exercice dépend de beaucoup de choses. En particulier, son cycle de travail. Si une perceuse fonctionne 24 heures sur 24, 7 jours sur 7, quatre fois plus vite et si elle tombe en panne deux fois plus souvent, vous devriez au moins prendre en considération la productivité de la perceuse. Parce que si cela coûte moins de deux fois plus cher qu'un exercice régulier et que vous pouvez le mettre à profit, c'est un meilleur rapport qualité-prix. Vous savez, l'économie. Vous lui dites de considérer la valeur de son travail par rapport à son coût. Son rapport coûts-avantages est deux fois supérieur à celui de ses pairs.
nomen
1
@nomen Oh, mais je suis d'accord: les gens devraient absolument en tenir compte. Mais le font-ils?
JvR
20

En supposant que vous produisez la même "quantité" de code que vos collègues dans 20% de leur temps, vous pourriez dépenser 4 fois plus de temps pour vraiment déboguer le code et le rendre parfait, ce qui réduirait encore plus votre taux de bugs. Ensuite, vous pourriez vous appeler un bon programmeur.

La plus grande question est de savoir pourquoi vous codez 5 fois plus que les autres au lieu de viser la qualité. Est-ce quelque chose que votre ego vous dicte ou votre patron vous force-t-il?

En outre, vous devez tenir compte des coûts liés à la correction d'un bogue. Lorsque vous le trouverez tôt, vous serez peut-être encore "suffisamment" dans le code pour le réparer rapidement. S'il n'apparaît qu'après un autre mois de développement, il peut être difficile de trouver ou même de vous forcer à modifier de grandes parties du code déjà programmé.

Vous semblez avoir les compétences nécessaires pour produire du code et vous pourriez le rendre génial si vous vous concentrez sur la qualité plutôt que sur la vitesse. Essayez un peu de temps, je suppose que vous allez l'aimer.

Le problème suivant est alors d'obtenir la reconnaissance (parler de l'argent) pour votre meilleure performance. Parlez à votre patron et demandez-lui comment procéder. Il s'agit bien de sa société et de son argent. S'il souhaite que vous produisiez moins de bugs, il devrait également décider de quelle manière.

awsm
la source
11
OP fournit 500% des points d’histoire des autres membres de l’équipe, avec 60% de défauts en moins par point d’histoire, et vous souhaitez changer la façon dont il travaille?
Justin
6
" La plus grande question est de savoir pourquoi vous codez 5 fois plus que les autres au lieu de viser la qualité [...] mettez plutôt l'accent sur la qualité que sur la vitesse " - Vous avez fait ma journée, mec. Celui qui a voté pour ça: S'il te plaît, fais tes devoirs de base en mathématiques. Pour le dire franchement: j'engagerais immédiatement le PO et refuserais de vous embaucher.
jeudi
1
Le calcul peut être faux mais je pense que le point est valable. Je préférerais embaucher une personne qui vise une qualité supérieure pour travailler dans mon entreprise actuelle. Les besoins varient cependant, en particulier selon le secteur et la taille de l'entreprise.
Michael Durrant
1
Je préférerais embaucher quelqu'un qui fait ce que son patron lui demande de faire, au lieu de s'en plaindre sur Internet. Parfois, le patron sait mieux.
Dawood dit réintégrer Monica
8

Les développeurs peuvent être brillants, voire géniaux, avec une aptitude à comprendre et à coder en solo, sans être de bons développeurs. Un bon développeur crée un travail de qualité et améliore l'ensemble du projet.

Je ne dis pas que c'est vous, mais l'un des programmeurs les plus frustrants avec lequel j'ai jamais travaillé a écrit plus de code que quiconque dans l'équipe, et nous avions de bonnes personnes dans l'équipe. Nous avons suivi les commits avec un logiciel de classement, donc c’était presque une compétition pour certaines personnes. Il a créé des pans de code, laissant derrière lui une documentation ZÉRO, des forêts impénétrables, et a même rendu difficile la compréhension de mon propre code (je peux le faire moi-même, merci beaucoup!). Finalement, il a failli faire dérailler le projet, car il est devenu un one man show. Les gens ne pouvaient pas le suivre. Nous n'étions pas synchronisés en équipe. Nous avons en fait réécrit certaines de ses caractéristiques des années plus tard, simplement pour retrouver la maintenabilité.

Ce que je voulais de lui, c’était de ralentir et de passer plus de temps: 1) Améliorer la qualité de la base de code 2) Communiquer avec l’équipe 3) Travailler sur des choses qui aidaient les autres et l’aider à finir des articles / récits 4) Réparer bogues

Je ne suis pas d'accord avec la mesure de la productivité par lignes de code, mais c'est une métrique clé. Votre compteur de code inclut-il des commentaires? Si tel est le cas, il existe un moyen simple de maintenir votre sortie ligne tout en réduisant votre "rapport de bogues"; augmentez simplement la qualité et la quantité des commentaires que vous écrivez. Les commentaires ont rarement des bugs (bien qu'ils puissent) et en général, nous n'avons pas assez de commentaires de qualité. Je ne tolère pas l' inflation de code, mais l'acte de commenter s'apparente à un mini-examen de code: il oblige à réfléchir, à refactoriser et à s'améliorer.

Codenheim
la source
1
Un bon point. Je ne suis pas d'accord sur l'ajout de commentaires (car un code plus clair et lisible est préférable) et nous mesurons par point de récit, pas des lignes de code. Je sens que je fais du bon travail avec ça (les critiques de code aident les gens à m'aider à clarifier les choses), mais +1 parce que tout le monde ne le fait certainement pas.
Telastyn
1
Je ne veux pas ajouter de commentaires sur le duvet. Je viens de supposer que vous êtes comme la plupart d'entre nous et que vous ne commentez pas assez. Oui, éloignez-vous des commentaires sans valeur, en particulier des œuvres d'art asiatiques sophistiquées, à moins que ce ne soit de la bonne humeur :)
codenheim
4
D'après mon expérience, les commentaires contiennent souvent des bogues.
Dawood dit réintégrer Monica
Pas le genre fonctionnel, mesurable ...
codenheim
6
@DavidWallace, selon mon expérience, le code contient souvent des bogues. Cela ne signifie pas que vous cessez de l'écrire.
Charles E. Grant
4

Essayer d’éclairer la gestion est un non-débutant. Il y a un vieux cliché, "Vas-tu me croire ou croire tes yeux menteurs?" Ce qui concerne vos patrons, c'est le nombre de bugs. Aucune mesure de rationalisation ne leur dira que c'est acceptable. C'est plus de deux fois plus risqué. De plus, vous n'êtes pas le seul concerné par votre nombre de bogues. L’assurance qualité a deux fois plus de travail pour essayer d’identifier vos bogues; la direction voudra donc que vous en réduisiez moins.

La meilleure solution consiste à réduire le nombre de bugs que vous produisez , tout simplement. La gestion sera non seulement plus heureuse, mais vous le serez aussi. N'est-ce pas? Parce que je suis assez sûr autant que vous aimez vous vanter vos collègues surpasser par un facteur de quatre, tu aimes te dire le faire faire le même nombre, ou encore moins, les bugs qu'ils ne le font.

Comme vous l'avez dit, "… le taux d'erreurs commises dans le code ... a tendance à être affecté par les processus utilisés lors de l'écriture du code et une fois que celui-ci a été écrit." Si vous souhaitez modifier le taux de production de bogues, vous devrez modifier les processus que vous utilisez pour écrire du code.

Les programmeurs utilisent des méthodes de production pour produire du code, un peu comme une chaîne d'assemblage utilise des méthodes pour produire un objet produit en masse. D'accord, les pratiques de l'industrie du logiciel s'apparentent davantage à couper les bibelots aux branches trouvées dans les bois. Mais puisque nous produisons des machines, nous devrions employer la même rigueur et la même discipline que celles utilisées pour les machines à grande vitesse de production en série.

Cela inclut les mêmes techniques que celles utilisées en production de masse pour réduire le taux de défauts: une analyse des causes fondamentales pour déterminer la raison pour laquelle des bogues sont créés et modifier le processus pour qu’ils ne le soient pas. Ou du moins que vous attrapiez avant le contrôle qualité.

  1. Faites une liste de vos bugs. Vous en avez probablement déjà un grâce aux gars de l'assurance qualité. Peut-être classé aussi. Type de bogue, gravité, point auquel le bogue a été injecté dans le code, etc.

  2. Choisissez la plus grande catégorie de bugs. Étant donné que votre volume est si élevé, vous devriez commencer par cibler cette catégorie. Les autres catégories comprennent les plus faciles à trouver et les plus faciles à créer.

  3. En sachant où ces bogues sont introduits dans le code, envisagez de faire des changements à cette phase (et plus tôt) pour éviter ces bogues et aux moyens de les résoudre plus facilement à cette phase.

  4. Assurez-vous d'examiner les incidents non liés à la programmation, car ils pourraient faire une différence dans la qualité de votre travail. Musique de fond, interruptions, repas, travailler trop longtemps sans pause, faim, etc.

Ce que vous trouvez peut vous amener à ralentir. D'autre part, cela peut vous aider à produire encore plus rapidement car vous aurez moins besoin de retravailler ce que vous avez déjà mis derrière vous. Dans l'état actuel des choses, quatre fois plus de code ne représente pas un ordre de grandeur supérieur à celui de vos collègues. Il est donc tout à fait possible de changer de processus.

Huperniketes
la source
3

Changez votre objectif de produire le plus de code possible pour aider l'entreprise à progresser le plus possible.

Comme il semble que vous ayez beaucoup de collègues et que vous disposiez de plus de temps, le meilleur effet que vous pouvez avoir sur une livraison plus rapide de fonctionnalités et de corrections de bugs est d'aider vos collègues.

Aidez vos collègues en

  • utiliser les revues de code pour améliorer la qualité du code et l'éducation.
  • créer des processus automatisés pour rendre leur travail plus rapide et leur vie plus facile.
  • écrire de meilleurs tests avec eux
  • attaquer le code technique pour améliorer la base de code
  • être le gars qui est toujours disponible pour aider les autres.
  • écrire / améliorer des outils qui aident à la productivité des développeurs
  • plaidoyer auprès de la direction pour de meilleurs outils / équipements / conditions de travail pour vos collègues si vous avez plus de poids.
  • préparer et diriger des sessions éducatives sur la rédaction d'un meilleur code.
  • pratiquer l'humilité
Michael Durrant
la source
1

Alors, comment gérer le fait qu'une productivité accrue entraînera une augmentation du nombre de bogues?

Votre patron est la seule personne qui peut répondre à cette question dans votre cas. Parlez-lui, indiquez votre meilleur ratio et laissez-le décider. Si sa décision n’a pas de sens, il est temps de chercher une entreprise avec votre façon de penser.

En tant que professionnel, vous devriez être capable de travailler avec n'importe quelle situation client donnée, assurez-vous simplement qu'ils comprennent les conséquences. Un tableau de bogues / histoires peut aider votre patron à comprendre à quel point votre productivité diminuera si vous prenez le temps de produire moins de bugs.

Vous devez également tenir compte de ces points:

  • la complexité des récits, par exemple les simples encapsuleurs getter / setter par rapport aux calculs statistiques, à la programmation en temps réel ou même aux statistiques en temps réel ...
  • gravité des bogues, est-ce que ce sont de petites fautes de frappe sur les champs de texte ou des résultats de calcul erronés, le programme plante
  • le coût pour corriger les bugs, que ce soit si vous le faites maintenant, plus tard ou si quelqu'un d'autre doit comprendre votre code parce que vous êtes parti
Marten Storm
la source
0

La situation est que vous travaillez quatre fois plus vite qu'un programmeur moyen, mais que vous faites deux fois plus d'erreurs en un laps de temps donné. Par rapport à la quantité de travail que vous faites, vous faites en réalité la moitié d’erreurs «moyennes».

Vous pouvez essayer de souligner votre faible ratio erreurs sur travail, voire même vos erreurs sur le produit fini (que vous pouvez compléter en un quart du temps normal). La plupart des patrons l'accepteront.

Il y a quelques chefs qui ne le feront pas parce qu'ils travaillent avec un état d'esprit "raisonnable" d'erreurs à la fois. Ensuite, vous pouvez ralentir votre rythme de travail en effectuant DEUX fois plus de travail que la moyenne en un temps donné et de faire les mêmes erreurs (voire moins) car vous avez plus de temps pour vérifier votre travail.

Tom Au
la source
0

Si votre responsable souhaite que vous amélioriez la qualité de votre travail, améliorez-la.

Vous devriez viser zéro bogue et ne pas en produire deux fois plus que le prochain meilleur programmeur.

Dawood dit réintégrer Monica
la source
6
Zéro bugs est un objectif en grande partie inaccessible et souvent peu rentable.
Telastyn
7
Ce n'est pas une excuse pour ne pas réduire votre taux d'erreur. Si votre patron veut que vous produisiez un meilleur code, alors il est temps de le produire, et non de vous en excuser.
Dawood dit réintégrer Monica
4
J'ai seulement dit que vous devriez viser zéro bogue, pas que vous devez l'atteindre. Pensez au tir à l'arc. Je ne suis pas bon en tir à l'arc - je n'ai jamais touché le "10" au centre de la cible. Devrais-je viser le cercle "7", parce que "10" serait trop difficile?
Dawood dit réintégrer Monica
6
Oui, mais votre patron dit que votre travail n'est pas "assez bon". En d'autres termes, vous devriez faire mieux. Vous n'avez pas donné une bonne raison pour laquelle vous ne pouvez pas faire mieux. Toute cette discussion me semble être une tentative de trouver des excuses pour produire du code corrigé par des bogues. "Je suis dans une équipe de développeurs très lents et je dois donc faire deux fois plus d'erreurs que tout le monde". S'il vous plaît!
Dawood dit réintégrer Monica
3
Chaque cycle de publication, vous produisez deux fois plus de bugs que vos pairs. Les bugs sont chers à trouver et à réparer. Votre patron doit donc prévoir des ressources pour que vos problèmes soient résolus. et c'est deux fois plus pour vos insectes que pour les insectes du gars suivant. Par conséquent, votre patron souhaite que vous produisiez moins de bogues, quel que soit le travail de votre équipe. Peut-être qu'il sait que vous avez plus d'expérience que le reste de l'équipe et qu'il devrait donc pouvoir produire moins de bugs. En tout cas, je ne vois pas pourquoi vous vous plaindriez d'avoir un chef qui veut que vous produisiez moins de bugs.
Dawood dit réintégrer Monica
0

Vous devriez dire à votre patron que les mesures qu'il utilise sont assez imparfaites. Si vous regardez les chiffres d'affaires des gardes dans la NBA, vous constaterez qu'ils ont tendance à avoir un nombre plus élevé que les attaquants. Mais, c’est parce qu’ils gèrent davantage la balle. Si un garde non partant joue 1/5 de la taille d’un garde au départ et qu’il fait tourner la balle trois fois en moyenne. un gardien partant qui tourne le ballon plus de 7 fois par match - à première vue, on pourrait croire que le garde partant est pire. Mais si vous divisez le nombre de revirements par le nombre de minutes jouées, il est clair que la garde de départ a des chiffres bien meilleurs, basés sur les minutes jouées.

De même, vous avez des chiffres bien meilleurs si le nombre de bugs est divisé par le nombre de points d’histoire terminés. C'est ce que je proposerais à votre responsable. Modifiez la métrique comme étant le nombre de bogues divisé par les points d’histoire terminés ou ajoutez au moins une nouvelle métrique à cet effet si le nombre total de bogues par développeur est requis. Cependant, étant donné que certains points de scénario sont beaucoup plus difficiles et complexes que d’autres, il peut y avoir et il y aura beaucoup de variation, ce qui devra également être pris en compte par le responsable.

Ce que je ne pense pas que vous devriez faire, c'est ralentir.

Bob Bryan
la source
0

Mesurer la valeur ajoutée

Expliquez que ce qui compte vraiment, c'est la valeur que vous ajoutez. Ensuite, présentez une mesure approximative (manuelle):

  • Estimer la valeur de la fonctionnalité que vous produisez
  • Soustrayez votre salaire
  • Soustrayez le coût estimé de vos bugs (au moins le coût pour les corriger)
  • Soustrayez le coût estimé de toutes les autres dettes techniques que vous produisez.

Le reste est votre valeur ajoutée. De même pour tout le monde.

Ces estimations sont difficiles, mais même les plus approximatives peuvent faire la différence. Et le simple processus de discussion de ces estimations est utile pour l’équipe et le projet.

Lutz Prechelt
la source
-1

Les grands programmeurs ont tendance à écrire du code très régulier, facile à déboguer et à comprendre, ils utilisent au maximum les outils disponibles (analyse statique, erreurs de compilation, code de débogage). En outre, les principaux programmeurs ont déjà compris l'intérêt des tests unitaires grâce à leur expérience éprouvée.

Ainsi, bien que le nombre initial de problèmes par ligne soit le même, les problèmes sont éliminés plus rapidement.

zzz777
la source
La question indique que cela n’aide en rien: "J'ai essayé de souligner que je produisais des bogues deux fois moins vite que mes pairs (et en corrige deux fois plus), mais c’est difficile à vendre quand il y a des graphiques deux fois plus de bugs ... "
mord
C'est relatif et plutôt subjectif, n'est-ce pas? Je ne sais pas ce que le code "normal" signifie. Je dirais que les plus grands programmeurs tentent d’utiliser toutes les bibliothèques et les langages dont ils disposent à leur avantage maximal en termes de productivité et d’expressivité, ce qui devrait rendre le code très facile à comprendre pour les autres programmeurs très performants ... Ce programme est extrêmement difficile à comprendre pour les programmeurs
débutants
IMHO, la grandeur est définie par la longue expérience et 90% des ingénieurs en logiciel en vie n'ont jamais eu la chance de rencontrer de grands. J'ai essayé de résumer les impressions de deux grands programmeurs avec lesquels je travaille. Le code "normal" signifie: (a) les mêmes choses sont faites de la même manière dans tous les codes produits, (b) il est facile d'interpréter une modification, et (c) il est nettement opposé à "facile à comprendre par d'autres programmeurs qui fonctionnent ... ".
zzz777