Mesure permettant de tenir les développeurs responsables
J'ai posé une question sur les lignes de code par heure et j'en ai déchiré une nouvelle. Donc, ma question de suivi mûri est la suivante:
S'il ne s'agit pas de lignes de code, alors quelle est une bonne mesure permettant de mesurer (par heure/jour/unité de temps) l'efficacité des programmeurs distants?
En 16 ans, je n'ai jamais trouvé de métrique exploitable du type que vous recherchez.
Essentiellement, pour être utile, tout ce qui doit être mesurable, représentatif et inamovible (c'est-à-dire que le système ne peut pas être joué par des développeurs intelligents). Il y a tout simplement trop de variables dans le développement logiciel pour le rendre mesurable comme travail à la pièce de cette façon.
Le plus proche est la progression par rapport aux estimations - c'est-à-dire le nombre de tâches accomplies dans les estimations convenues. L'astuce ici est (a) d'obtenir de bonnes et justes estimations et (b) de comprendre où les estimations ont été dépassées pour de bonnes raisons pour lesquelles le développeur ne peut pas/ne devrait pas être blâmé (c'est quelque chose qui était vraiment plus complexe que prévu). En fin de compte, si vous poussez les développeurs trop fort, vous trouverez probablement des estimations qui grimpent progressivement jusqu'à un niveau où elles sont toujours respectées non pas en raison d'une productivité accrue mais en raison de délais raccourcis.
Allez trop dans le sens des estimations (en les réduisant pour créer une pression à livrer) et vous créez des délais bidons dont les études ont montré qu'ils n'augmentent pas la productivité et sont susceptibles d'avoir un impact sur le moral de l'équipe (voir Peopleware pour plus d'informations ).
Mais je me demande essentiellement si vous cherchez un problème légèrement faux. Pourquoi les programmeurs distants sont-ils différents des autres programmeurs lorsqu'il s'agit de mesurer la productivité? Comment mesurez-vous la productivité des programmeurs non distants?
S'il s'agit de ne pas leur faire confiance pour travailler à distance, c'est essentiellement un problème de confiance plus large. Si vous ne leur faites pas confiance pour travailler à domicile, vous devez soit établir cette confiance, ne pas les laisser travailler à domicile, soit trouver un moyen de vous assurer qu'ils travaillent effectivement quand ils sont censés l'être.
Les métriques fonctionnent mieux dans les usines et les programmeurs ne fonctionnent pas sur une ligne d'assemblage.
Je comprends parfaitement le désir de mesurer la productivité.
Mais utiliseriez-vous la même métrique pour un médecin de famille et un chirurgien cardiaque? Que diriez-vous de Michel-Ange peignant la chapelle Sixtine, et un gars du Mexique qui lance des peintures d'Elvis en velours noir?
Louis de Broglie a rédigé une thèse de doctorat qui était si courte que les examinateurs allaient la rejeter - sauf que de Broglie était un aristocrate de haut rang et qu'ils avaient besoin d'une bonne excuse. Les examinateurs l'ont donc envoyé à Einstein, qui non seulement ne l'a pas rejeté, il l'a renvoyé au comité Nobel, et de Broglie a obtenu le prix Nobel de physique cinq ans plus tard.
Les mesures numériques fonctionnent mieux sur les travaux répétitifs, comme la fonte ou le vissage des boulons sur les portes des voitures. Mais si vous répétez du code qui a été fait auparavant, vous n'avez pas besoin d'un programmeur, vous avez juste besoin d'un copier-coller. La programmation est fondamentalement une discipline créative et la productivité dépend entièrement de ce que vous faites.
Certains jours, je lance 1000 lignes de code. Aujourd'hui, je vais corriger des bogues de géométrie de coordonnées, et le code pourrait rétrécir. Si je devais corriger un bogue dans un pilote de noyau Linux, je passerais peut-être toute la journée à déboguer et à ne pas écrire de ligne de nouveau code.
La mesure de la productivité d'un programmeur est très, très, très subjective.
Si vous voulez savoir si Joe est productif, trouvez Sally et Ralph, qui savent ce que fait Joe et qui sont compétents dans les mêmes domaines, et demandez-leur.
Le meilleur système numérique que j'ai jamais vu a été la planification des points de poker d'Agile. C'est juste une façon élégante de demander à Joe, Sally et Ralph à quel point ils pensent que le prochain travail de Joe sera difficile. Ensuite, vous pouvez mesurer la productivité en points par semaine pour chaque membre de l'équipe. Mais même dans ce cas, il faut un certain temps pour calibrer les estimations d'une équipe, et les chiffres sont flous et facilement rejetés.
Beaucoup de gens veulent des estimations de productivité afin de pouvoir planifier le calendrier. C'est un peu la théorie du "brancher sur MS Project, regardez le chemin critique, et il y a la date de votre bateau". Je n'ai jamais, jamais vu ce travail - il y a juste trop d'inconnues. Si vous le souhaitez, utilisez Waterfall, concevez tout à l'avance, n'autorisez aucun ordre de modification et soyez prêt à être déçu de toute façon.
La seule métrique que j'utilise est la quantité de logiciel qui fonctionne qu'il produit pour un montant d'argent que j'ai investi.
Quel que soit son horaire, qu'il travaille à distance ou non, le nombre de pauses qu'il prend, les méthodologies qu'il utilise ou le nombre d'heures de travail.
Par logiciel fonctionnel je veux dire:
Liste des fonctionnalités définies par l'utilisateur/client qui répondent au niveau de qualité requis
Par montant d'argent:
Combien l'utilisateur/client a payé pour les fonctionnalités définies + les coûts de maintenance
Il a donc un lien direct avec la façon dont il est construit et la qualité du travail produit, mais n'est lié à aucune métrique de ligne de code source.
Vous avez besoin d'un développeur ou d'un chef d'équipe expérimenté (qui n'est pas associé à ces programmeurs distants) pour estimer la durée d'une tâche et l'efficacité est mesurée en comparant le temps requis par rapport aux estimations. Pour être sûr que les estimations sont bonnes, vous pouvez choisir au hasard quelques tâches et les faire exécuter par une équipe interne que vous avez sous contrôle.
Une autre façon intéressante de mesurer la productivité serait de compter les tests automatisables revus par un manager par jour. Le développeur obtient:
- un point pour écrire un test automatisable (et passer un examen) et l'ajouter à la suite de tests de régression,
- un point pour les faire passer, sans provoquer d'autres échecs de test de régression.
Le développeur et le gestionnaire peuvent améliorer conjointement le système en:
- convenir conjointement des domaines importants de développement et de test
- examiner et exécuter indépendamment la suite de tests.
- décider de ne pas créer une fonctionnalité qui présente des avantages commerciaux limités mais qui nécessite beaucoup de développement et de tests pour fournir cette fonctionnalité. (La ligne de code la plus productive est celle que vous avez décidé de ne pas écrire car elle n'apporte aucun avantage commercial).
- partitionner le système en une architecture (telle que model-view-controller) qui facilite le développement de fonctionnalités incrémentielles sans casser tout le système.
Le développeur ne peut pas jouer la métrique car:
- les tests redondants seront bloqués par l'examen du responsable.
- les tests à grain fin peuvent être bloqués par l'examen du responsable.
- des tests à grains fins amélioreront la qualité du système.
Le gestionnaire ne peut pas jouer la métrique car:
- le rejet d'un trop grand nombre de tests entraînera l'attrition des développeurs.
- demander trop de tests, il sera difficile de refuser une date limite ultérieure.
Le développeur ne peut pas visser le gestionnaire car
- Chaque unité de fonctionnalité livrée avec des tests doit également passer la suite de régression. c'est-à-dire que cela oblige le développeur à développer soigneusement sans casser d'autre code.
- Toute réclamation de travail doit être prouvable en passant de nouveaux tests et tests de régression.
Le gestionnaire ne peut pas visser le développeur car.
- Chaque unité de fonctionnalité demandée doit comprendre des cas de test clés et une estimation du nombre de cas de test nécessaires pour terminer le travail.
- Il est difficile de demander un horaire agressif et/ou des heures supplémentaires gratuites lorsque vous demandez évidemment beaucoup de travail.
Un autre gros avantage pour le gestionnaire est qu'il peut faire appel à de nouveaux développeurs et savoir qu'ils ne seront pas en mesure de fournir du code qui casse le système en silence (car la suite de tests de régression le détecte).
Le gros inconvénient du gestionnaire est qu'il l'oblige à admettre que son système est plus complexe qu'il n'y paraît sur la description d'une page de la fonctionnalité. L'autre inconvénient est que la transparence de cette méthode rendra difficile de blâmer les développeurs pour l'échec de l'entreprise.
Il est certainement possible de concevoir toutes sortes de métriques complexes pour évaluer les performances, mais au bout du compte, une partie importante de votre jugement doit s'appuyer sur la subjectivité et la contribution de personnes proches de la base de code.
Par exemple, il est tout à fait possible pour certaines équipes de lancer une pente interne hideuse et honteuse à un rythme très rapide, et cela pourrait même respecter le délai et les spécifications requis. Mais la dette technique générée par ce type de style de travail est-elle pire que si l'équipe avait produit quelque chose de robuste et de maintenable mais avait retardé le délai de quelques semaines? Ça dépend.
Si le but de la question est de résoudre un certain type de problème de productivité, je dirais que ce que le gestionnaire fait réellement pour faciliter le travail de l'équipe est aussi ou plus important que toute technique de mesure utilisée pour évaluer l'équipe. C'est une rue à double sens. En d'autres termes, je dis que les mesures sont correctes mais si vous voulez plus de n'importe quelle équipe, la question ultime est de savoir si le manager fait tout son possible pour s'assurer que l'équipe peut être productive.
Cela va bien au-delà de la rédaction d'une spécification, de la recherche d'une équipe, du lancement de la spécification "par-dessus le mur" et du clic sur un chronomètre.
Quelques idées:
- fonctionnalités implémentées
- bogues corrigés (tiennent également compte des bogues rouverts plus tard par le contrôle qualité)
- les plaintes des utilisateurs ont été résolues (notez que ce n'est pas la même chose que 2 - un bug grave peut être une douleur dans le cou tandis que 100 fautes de frappe peuvent ne pas être si importantes)
Vous pouvez également vouloir suivre:
- Couverture du code par des tests
- Couverture du code par la documentation interne
- Couverture des fonctionnalités par une documentation externe (utilisateur)
Mesurez de la même manière que vous êtes mesuré par le client. En termes de code fonctionnel, mais à plus petite échelle.
Faites des objectifs courts - une semaine ou deux - et voyez si les programmeurs atteignent les objectifs, et faites-le de manière satisfaisante.
Je recommanderais fortement la révision par les pairs du code, car cela vous permet de détecter le mauvais code à l'avance.
Que diriez-vous du taux de ventes du produit/service.
Parfois, j'ai entendu que cela s'appelait une commission/pourcentage du brut
Les gens achètent de bons produits, non?
L'entreprise veut vendre le produit (ou peut-être le service, même différence pour cela)
Donc, si c'est ce que vous voulez, mesurez-le.
Un peu comme dire que les gens qui conçoivent une voiture qui obtient de bonnes critiques et se vend bien ont vraiment fait du bon travail.
Maintenant, adoptez cette équipe de métrique et de programmation qui voudra interagir avec le vendeur pour deux raisons.
Promising underliverable
Ne pas vendre efficacement le produit aux clients
Écrire du code/programmer, ce n'est pas comme mettre un marteau sur un clou. Tout comme "l'écriture" en général, ce n'est pas quelque chose que vous pouvez également appliquer des mesures - à mon avis.
Ne pourriez-vous pas simplement regarder leurs enregistrements, ou ce qu'ils ont fait par le biais de l'examen par les pairs, de l'examen du code?
Ou vous savez, s'ils produisent réellement du code de travail et des solutions qui résolvent les problèmes?