Je fais 4 à 5 fois plus de points d'histoire que la moyenne, mais je produis des bogues à moitié moins. Les graphiques indiquent que c'est 2x plus de bugs, comment y faire face?
Il est donc généralement admis que les programmeurs de haut niveau peuvent produire un ordre de grandeur plus/meilleur code que leurs pairs plus moyens.
Il est également généralement admis que le taux d'erreurs faites 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 l'écriture du code . (Si je comprends bien) Les humains ont tendance à faire des erreurs à un rythme assez constant - les meilleurs programmeurs remarquent simplement plus d'entre eux et sont plus rapides à les corriger.
- Notez que les deux affirmations ci-dessus proviennent de Code Complete par Steve McConnell - il ne s'agit donc pas de perspectives différentes.
J'ai donc commencé à voir cela récemment dans mon code. Je peux marteler environ 4 à 5 fois la quantité de code autant de mes pairs (mesurée par les points d'histoire estimés par l'équipe), avec une qualité supérieure (basée sur les mesures de performances et le 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 meilleur œil pour les problèmes lors des révisions de code, je ne produis pas 4 à 5 fois plus de bogues.
Mais je produis toujours environ deux fois autant de bogues trouvés par QA que les autres développeurs de mon équipe. Comme vous pouvez l'imaginer, cela cause des problèmes aux personnes non techniques qui effectuent des mesures métriques (lire: mon patron).
J'ai essayé de souligner que je produisais des bogues à la moitié du taux de mes pairs (et corrige deux fois plus), mais c'est difficile à vendre quand il y a 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?
Je pense que vous mélangez vos préoccupations. Et il n'y a rien sur 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 nous verrons le projet se réaliser plus rapidement.
Le taux de bogues n'est pas lié à la productivité mais plutôt à la taille du projet. Par exemple, vous pouvez avoir N bogues par Y lignes de code. Il n'y a rien dans cette métrique qui indique (ou se soucie!) À quelle vitesse ces lignes de code sont écrites.
Pour lier cela, si vous avez une productivité plus élevée, oui, vous "verrez" que les bogues sont écrits plus rapidement. Mais vous alliez avoir ce nombre de bogues de toute façon, car il est lié à la taille du projet.
Si quoi que ce soit, une productivité plus élevée signifie que vous aurez plus de temps à la fin du projet pour traquer ces bogues ou que le développeur sera plus rapide à trouver les bogues qu'ils ont créés.1
Pour répondre aux aspects plus personnels de votre question.
Si votre patron regarde strictement le nombre de bugs que vous produisez par rapport au taux de bugs que vous produisez, une session éducative s'impose. Le nombre de bogues créés n'a pas de sens sans taux de sauvegarde.
Pour prendre cet exemple à l'extrême, dites à votre patron que je veux doubler votre salaire. Pourquoi? J'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 possède les mesures pour évaluer les bogues par point d'histoire. Si rien d'autre, c'est mieux que d'être mesuré par le nombre brut de bogues créés. Vos meilleurs développeurs devraient créer plus de bugs car ils écrivent plus de code. Demandez à votre patron de jeter ce graphique ou au moins de lancer une autre série derrière lui montrant le nombre de points d'histoire (ou la valeur commerciale que vous mesurez) avec le nombre de bogues. Ce graphique racontera une histoire plus précise.
1Ce commentaire particulier a attiré beaucoup plus d'attention que prévu. Alors soyons un peu pédants (surprise, je sais) et remettons l'accent sur cette question.
La racine de cette question concerne un gestionnaire qui regarde la ou les mauvaises choses. Ils examinent les totaux bruts des bogues alors qu'ils devraient examiner le taux de génération par rapport au nombre de tâches terminées. Ne soyons pas obsédés par la mesure par rapport aux "lignes de code" ou aux points d'histoire ou à la complexité ou autre. Ce n'est pas la question à portée de main et ces inquiétudes nous distraient de la question la plus importante.
Comme indiqué dans les liens par l'OP, vous pouvez prédire un certain nombre de bogues dans un projet uniquement par la taille du projet seul. 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 et une méthodologie de développement données, nous verrons un nombre donné de bogues une fois le développement "terminé".
Revenons donc enfin à ce commentaire que certains ont complètement mal compris. Si vous attribuez des tâches de taille comparable à deux développeurs, le développeur avec un taux de productivité plus élevé terminera sa 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 travail sur les défauts qui se répercuteront à travers un processus de développement standard.
Nous devons prendre l'OP au mot qu'ils sont plus productifs que les autres développeurs. Rien dans ces affirmations n'implique que l'OP ou d'autres développeurs plus productifs sont en train de faire preuve de lenteur dans leur travail. Soulignant qu'il y aurait moins de bogues 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, il manque ce qui a été demandé. Certains développeurs sont plus rapides que d'autres et produisent un travail comparable ou de meilleure qualité. Encore une fois, voir les liens que le PO établit dans leur question.
Consacrez une partie de ce temps supplémentaire au nettoyage, au polissage et au test de votre code. Il y aura toujours des erreurs, mais il y en aura moins. Cela prend du temps. Votre taux de sortie de code diminuera, mais votre sortie de code sans bogue augmentera, ce qui se traduira par une meilleure productivité. Parce que les bugs sont chers.
Pouvez-vous conserver votre code dans une branche ou un environnement de test jusqu'à ce que vous le fassiez tourner et attrapiez plus de bogues? Les bogues dans une branche génèrent généralement moins de vagues que les bogues dans le code de production.
Mais je ne creuse pas exactement vos affirmations menant à votre question. Et peut-être que votre patron ne l'est pas non plus.
Je ne pense pas que chaque codeur produit le même taux d'erreurs. Votre deuxième lien est en fait entièrement hors sujet car il compare différentes langues, pas différents niveaux de compétence de codeur. Le code complet mentionne certaines mesures à large échantillon qui examinent le processus plutôt que la compétence des codeurs. Et quand ils disent que les codeurs de niveau supérieur produisent un code plus/meilleur, une partie de cela signifie qu'il a moins de bogues. Dépend de l'application. Donc, oui, je pense que c'est IS une question de perspective différente.
En fin de compte, si le patron veut un code plus propre, donnez-lui un code plus propre.
Je vais sortir sur un membre et être l'avocat du diable. Cela ne veut pas dire que je ne sympathise pas avec votre sort mais, bien, ma sympathie ne vous aidera pas. Permettez-moi donc d'ajouter à point de vue de Philip :
Votre patron se soucie de la qualité du produit, en partie parce que son nom et sa réputation y seront liés. Une partie de la qualité est le quantité perçue de bugs. Si vous vendez une perceuse impressionnante qui perce quatre fois plus vite que n'importe quelle perceuse concurrente, mais qui tombe également en panne deux fois plus souvent, vous aurez une mauvaise réputation. Même si l'on peut soutenir que la perceuse fonctionne mieux, les gens s'habituent à la vitesse, mais ils se souviendront des pannes.
Avec le recul, la plupart des bugs sont évitables. Si seulement vous étiez un peu plus prudent, votre patron le ressentirait, vous pourriez éviter ces problèmes et tout nettoyage nécessaire -up. De son point de vue, c'est une question triviale et sensée à poser, et toute argumentation à ce sujet ne fonctionnera pas et vous fera mal paraître.
Il ne peut pas mesurer votre productivité supérieure. Vous prétendez une productivité plus élevée basée sur une métrique vérifiable, alors comment vos collègues s'en sentent-ils? Conviennent-ils, peut-être à contrecœur, que vous êtes un programmeur plus productif, ou êtes-vous seul à votre avis? Vous ferez un argument plus fort si vous avez d'autres personnes pour sauvegarder 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 à celui qui distribue les tâches que vous allez essayer de réduire le taux de bogues (*), afin qu'ils ' ne vous étonnez pas de votre faible apport. Si quoi que ce soit, le ralentissement réduira le nombre de bogues qui vous sont attribués par simple manque d'approvisionnement.
(*) Il y a une différence entre, d'une part, reconnaître qu'il y a sont bogues à votre nom et que vous allez essayer de diminuer ce montant et, d'autre part, admettre que vous avoir trop bugs à votre nom et devrait prendre des mesures.
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; vous pouvez présenter un contrepoint et garder votre opinion sans rejeter ses inquiétudes. Parce que si vous argumentez et ne pouvez pas prouver de manière satisfaisante votre productivité supérieure (et même si vous le pouvez), vous allez risquer d'insulter vos collègues ou de paraître méprisant envers eux. Vous ne voulez pas être ce mec.
En supposant que vous produisiez la même "quantité" de code que vos collègues dans 20% de leur temps, vous pourriez dépenser 4 fois plus pour vraiment déboguer le code et le rendre parfait, ce qui réduirait encore plus votre taux de bogues. 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?
Vous devez également prendre en compte les coûts de correction d'un bogue. Lorsque vous le trouvez tôt, il se peut que vous soyez suffisamment "à l'intérieur" du code pour le corriger rapidement. S'il n'apparaît qu'après un autre mois de développement, il pourrait ê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-le un peu, je suppose que vous l'aimerez.
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, c'est son entreprise et son argent après tout, et s'il veut que vous produisiez moins de bugs, il devrait également décider de quelle manière cela se produit.
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 qui j'ai travaillé a écrit plus de code que quiconque dans l'équipe, et nous avions de bonnes personnes dans l'équipe. Nous avons suivi les engagements avec un logiciel de classement, donc c'était presque une compétition pour certaines personnes. Il a produit des bandes de code, laissant derrière lui une documentation ZÉRO, des forêts impénétrables, et a en fait rendu difficile la compréhension de mon propre code (je peux le faire moi-même, merci beaucoup!). Finalement, il a presque fait 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 fonctionnalités des années plus tard, juste pour retrouver la maintenabilité.
La chose que je voulais de lui é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 ont aidé les autres ainsi que l'aider à terminer les fonctionnalités/histoires 4) Corriger Bugs
Je ne suis pas d'accord avec la mesure de la productivité par des lignes de code, mais c'est une mesure clé. Votre compteur de code inclut-il des commentaires? Si c'est le cas, il existe un moyen simple de maintenir la sortie de votre ligne tout en réduisant votre "rapport de bogues"; augmentez simplement la qualité et la quantité de commentaires que vous écrivez. Les commentaires ont rarement des bugs (bien qu'ils le puissent) et en général, nous n'avons pas assez de commentaires de qualité. Je pas tolérant l'inflation du code, mais l'acte de commenter est comme une mini revue de code, il vous oblige à réfléchir, à refactoriser et à améliorer.
Essayer d'éclairer la gestion est un non-démarreur. Il y a un vieux cliché, "Allez-vous me croire ou vos yeux menteurs?" Ce qui préoccupe vos patrons, c'est le nombre de bogues. Aucune rationalisation ne leur dira que c'est acceptable. C'est plus de deux fois plus risqué. De plus, vous n'êtes pas le seul affecté par votre nombre de bogues. Le contrôle qualité a deux fois plus de travail pour identifier vos bugs, donc la direction va vouloir que vous en fassiez moins.
La meilleure solution est de réduire le nombre de bugs que vous produisez, point. Non seulement la direction sera plus heureuse, mais vous aussi. N'est-ce pas? Parce que je suis presque sûr que vous aimez vous vanter de surclasser vos collègues de travail par un facteur de quatre, vous voudriez aimer dire que vous le faites en faisant le même nombre, voire moins, de bugs que ils 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 après l'écriture du code." Si vous souhaitez modifier la vitesse à laquelle vous produisez des 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, tout 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 ressemblent davantage à des bibelots tailladés à partir de branches trouvées dans les bois. Mais puisque nous produisons des machines, nous devons employer la même rigueur et discipline que celles utilisées pour les machines à grande vitesse de production en série.
Cela inclut les mêmes techniques utilisées dans la production de masse pour réduire le taux de défauts: analyse des causes profondes pour déterminer pourquoi des bogues sont faits et changer le processus pour qu'ils ne le soient pas. Ou du moins que vous attrapez avant le contrôle qualité.
Faites une liste de vos bugs. Vous en avez probablement déjà un grâce aux gars de l'AQ. Peut-être aussi catégorisé. Type de bogue, gravité, point auquel le bogue a été injecté dans le code, etc.
Choisissez la plus grande catégorie de bogues. Étant donné que votre volume est si élevé, vous devez d'abord cibler cette catégorie. Les autres catégories comprennent celles les plus faciles à trouver et celles les plus faciles à créer.
En sachant où ces bogues sont introduits dans le code, cherchez à apporter des modifications à cette phase (et plus tôt) qui empêchent ces bogues de se produire, et des moyens de faciliter leur capture à cette phase.
Assurez-vous de regarder les faux frais non liés à la programmation, car ils peuvent faire une différence dans la qualité de votre travail. Musique d'ambiance, interruptions, heures de repas, travailler trop longtemps sans interruption, faim, etc.
Ce que vous trouverez peut vous conduire à ralentir. D'un autre côté, cela peut vous aider à produire encore plus rapidement car vous aurez moins besoin de retravailler des choses que vous avez déjà mises derrière vous. Dans l'état actuel des choses, quatre fois plus de code n'est pas près d'être un ordre de grandeur meilleur que vos collègues, donc changer votre processus est certainement la voie à suivre.
Faites passer votre objectif de produire le plus de code à aider l'entreprise à progresser le plus.
Puisqu'il semble que vous ayez beaucoup de collègues ainsi que du temps supplémentaire disponible, le plus d'effet que vous pouvez avoir sur une livraison plus rapide des fonctionnalités et des corrections de bugs est d'aider vos collègues.
Aidez vos collègues en
- utiliser des revues de code pour améliorer la qualité et l'éducation du code.
- créer l'automatisation des processus 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 incontournable qui est toujours disponible pour aider les autres.
- écrire/améliorer des outils qui contribuent à la productivité des développeurs
- faire le cas avec la direction pour de meilleurs outils/équipements/conditions de travail pour vos collègues si vous avez plus de poids.
- préparer et animer des sessions éducatives sur l'écriture d'un meilleur code.
- pratiquer l'humilité
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, montrez-lui 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 devez être en mesure de travailler avec toutes les conditions du client, assurez-vous simplement qu'il en comprend les conséquences. Un joli graphique de bogues/histoires peut aider votre patron à comprendre combien votre productivité diminuera si vous prenez le temps de produire moins de bogues.
Vous devez également tenir compte de ces points:
- complexité des histoires, par exemple de simples wrappers getter/setter contre des calculs statistiques ou une programmation en temps réel ou même des statistiques en temps réel ...
- gravité des bogues, est-ce de petites fautes de frappe sur les champs de texte ou de mauvais résultats de calcul, le programme plante
- coût pour corriger les bugs, à la fois si vous le faites maintenant, plus tard ou si quelqu'un d'autre doit comprendre votre code parce que vous avez quitté
La situation est que vous travaillez quatre fois plus vite que le programmeur moyen, mais vous faites deux fois plus d'erreurs dans un laps de temps donné. Par rapport à la quantité de travail que vous faites, vous faites en fait la MOITIÉ autant d'erreurs que la "moyenne".
Vous pourriez essayer de signaler votre faible taux d'erreurs par rapport au travail, ou même des erreurs au produit terminé (que vous pouvez terminer en un quart du temps normal). La plupart des patrons l'accepteront.
Il y a quelques patrons qui ne le feront pas parce qu'ils travaillent avec un état d'esprit "tolérance" d'erreurs à la fois. Ensuite, vous pourriez ralentir votre rythme de travail, faire deux fois plus de travail que la moyenne dans un délai donné, et faire les mêmes (ou moins) erreurs parce que vous avez plus de temps pour vérifier votre travail.
Mesurer la valeur ajoutée
Faites valoir que ce qui compte vraiment, c'est la valeur que vous ajoutez. Ensuite, allez introduire une mesure approximative (manuelle) de cela:
- Estimez la valeur de la fonctionnalité que vous produisez
- Soustrayez votre salaire
- Soustrayez le coût estimé de vos bugs (au moins le coût de leur correction)
- 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 dures, mais même des estimations approximatives peuvent faire le point. Et le simple processus de discussion de ces estimations est utile pour l'équipe et le projet.
Si votre patron veut que vous amélioriez la qualité de votre travail, alors améliorez la qualité de votre travail.
Vous devriez viser à zéro bogue, pas à produire seulement deux fois plus que le prochain meilleur programmeur.
Vous devez dire à votre patron que les mesures qu'il utilise sont assez erronées. Si vous regardez les chiffres d'affaires des gardes de la NBA, vous constaterez qu'ils ont tendance à avoir des chiffres plus élevés que les attaquants. Mais c'est parce qu'ils manipulent davantage le ballon. Si un garde non partant joue 1/5 autant qu'un gardien partant et retourne la balle plus de 3 fois en moyenne .vs. un gardien de départ qui retourne le ballon plus de 7 fois par match - à première vue, il pourrait sembler que le gardien de départ est pire. Mais, si vous divisez le nombre de chiffres d'affaires par le nombre de minutes jouées, le gardien de départ a clairement de bien meilleurs chiffres en fonction des minutes jouées.
De même, vous avez de bien meilleurs chiffres si le nombre de bogues est divisé par le nombre de points d'histoire complétés. C'est donc ce que je proposerais à votre manager. Modifiez la métrique pour être le nombre de bogues divisé par les points d'histoire terminés, ou ajoutez au moins une nouvelle métrique pour cela si le nombre total de bogues par développeur est nécessaire. Mais, comme certains récits sont beaucoup plus difficiles et plus complexes que d'autres récits, il peut y avoir et il y aura un certain écart et cela doit également être pris en compte par le gestionnaire.
Ce que je ne pense pas que vous devriez faire, c'est de ralentir.