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 N
bogues par Y
lignes 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.