Si vous allez sur Google et recherchez “mesurer la productivité des développeurs de logiciels” tu ne trouveras rien. Sérieusement — rien.
Nick Hodges, Mesurer la productivité des développeurs

A présent, nous devrions tous savoir que nous ne savons pas comment mesurer la productivité des programmeurs.

Il n'y a pas manière claire de mesurer quels programmeurs font un travail meilleur ou plus rapide, ou pour comparer la productivité entre les équipes. Nous "savons" qui sont les stars d'une équipe, sur qui nous pouvons compter pour livrer, et qui lutte. Et nous savons si une équipe botte des fesses ou se traîne les fesses. Mais comment le prouver? Comment pouvons-nous le quantifier?

Toutes sortes de choses stupides et diaboliques peuvent se produire lorsque vous essayer de mesurer la productivité des programmeurs.

Mais faisons-le quand même.

Nous écrivons plus de code, donc nous devons être plus productifs

Les développeurs sont payés pour écrire du code. Alors pourquoi ne pas mesurer la quantité de code qu'ils écrivent ? combien de lignes de code se faire livrer?

Parce que nous avons connu depuis les années 1980 que c'est une mauvaise façon de mesurer la productivité.

Les lignes de code ne peuvent pas être comparées entre les langues (bien sûr), ou même entre des programmeurs utilisant le même langage travaillant dans des frameworks différents ou suivant des styles différents. C'est pourquoi Points de fonction ont été inventés - une tentative de standardisation et de comparaison de la taille du travail dans différents environnements. Ça a l'air bien, mais les points de fonction je n'ai pas réussi dans le courant dominant, et ne le sera probablement jamais - très peu de gens savoir comment fonctionnent les points de fonction, comment les calculer et comment les utiliser.

Le problème le plus fondamental est que la mesure de la productivité par lignes (ou points de fonction ou autres dérivés) tapé n'a aucun sens. Beaucoup de travail important dans le développement logiciel, le travail le plus important, implique penser et apprendre - pas taper.

Les meilleurs programmeurs passent beaucoup de temps à comprendre et à résoudre des problèmes difficiles, ou aider d'autres personnes à comprendre et à résoudre des problèmes difficiles, au lieu de taper. Ils trouvent des moyens de simplifier le code et d'éliminer les doublons. Et une grande partie du code qu'ils écrivent ne comptera pas de toute façon, au fur et à mesure qu'ils itèrent à travers des expériences et construisent des prototypes et jettent tout cela afin d'arriver à une solution optimale.

Les défauts de ces mesures sont évidents si l'on considère les résultats idéaux: le moins de lignes de code possible pour résoudre un problème, et la création de schémas simplifiés, des processus communs et des interactions avec les clients qui réduisent la complexité des systèmes informatiques. Nos employés les plus productifs sont ceux qui trouvent des moyens ingénieux d'éviter d'écrire le moindre code.
Jez Humble, L'entreprise Lean

C'est clairement l'un de ces cas où la taille n'a pas d'importance.

Faisaient (ou économiser) plus d'argent,
donc on doit mieux travailler

Nous pourrions essayer de mesurer la productivité à un niveau élevé en utilisant la rentabilité ou le rendement financier de ce que chaque équipe fournit, ou une autre mesure commerciale telle que le nombre de clients utilisant le système - si les développeurs gagnent plus d'argent pour l'entreprise (ou économiser plus d'argent), Ils doivent être en train de faire quelque chose de bien.

Utiliser des mesures financières semble être une bonne idée au niveau de la direction, surtout maintenant que "chaque entreprise est une entreprise de logiciels". Ce sont des mesures organisationnelles que les développeurs doivent partager dans. Mais ce ne sont pas des mesures efficaces - ou justes - de la productivité des développeurs. Il y a trop de facteurs commerciaux qui échappent au contrôle de l'équipe de développement. Certains produits ou services réussissent même si les personnes qui les livrent font un travail médiocre, ou échouer même si l'équipe a fait un excellent travail. Se concentrer sur les économies de coûts en particulier conduit de nombreux managers à réduire leurs effectifs et à essayer de « faire plus avec moins » au lieu d'investir dans de véritables améliorations de la productivité..

Et comme Martin Fowler fait remarquer il y a un décalage dans le temps, en particulier dans les grandes organisations - cela peut parfois prendre des mois ou des années pour voir les résultats financiers réels d'un projet informatique, ou des gains de productivité.

Nous devons chercher ailleurs pour trouver des mesures de productivité significatives.

Nous allons plus vite, donc nous devons devenir plus productifs

Mesurer la vitesse de développement – rapidité en Agile - ressemble à une autre façon de mesurer la productivité au niveau de l'équipe. Après tout, le but du développement logiciel est de fournir un logiciel fonctionnel. Plus vite une équipe livre, le meilleur.

Mais rapidité (combien de travail, mesuré en points d'histoire ou en points caractéristiques ou en jours idéaux, que l'équipe livre dans un délai) est vraiment une mesure de prévisibilité, pas la productivité. Velocity est destiné à être utilisé par une équipe pour mesurer la quantité de travail qu'elle peut assumer, pour calibrer leurs estimations et planifier leur travail.

Une fois que la vitesse d'une équipe s'est stabilisée, tu peux mesurer les changements de vitesse au sein de l'équipe comme mesure relative de la productivité. Si la vitesse de l'équipe ralentit, cela pourrait être un indicateur de problèmes dans l'équipe ou le projet ou le système. Ou vous pouvez utiliser la vélocité pour mesurer l'impact des améliorations de processus, pour voir si la formation ou de nouveaux outils ou de nouvelles pratiques rendent réellement le travail de l'équipe sensiblement plus rapide.

Mais vous devrez tenir compte des changements dans l'équipe, au fur et à mesure que les gens rejoignent ou partent. Et vous devrez vous rappeler que la vélocité est une mesure qui n'a de sens qu'au sein d'une équipe - qui vous ne pouvez pas comparer la vitesse entre les équipes.

Bien que cela n'empêche pas les gens d'essayer. Certains ateliers utilisent l'idée d'une histoire de référence bien connue que toutes les équipes d'un programme comprennent et utilisent pour fonder leurs estimations de points d'histoire sur. Tant que les équipes n'ont pas beaucoup de liberté sur la façon dont elles proposent des estimations, et tant que les équipes travaillent sur le même projet ou programme avec les mêmes contraintes et hypothèses, vous pourrez peut-être faire une comparaison approximative de la vitesse entre les équipes. Mais Mike Cohn avertit que

Si les équipes ressentent la moindre indication que les vitesses seront comparées entre les équipes, il y aura une «inflation de points» progressive mais constante.

ThoughtWorks explique que rapidité <> productivité dans leur dernier radar technologique:

Nous continuons à voir des équipes et des organisations assimiler vitesse et productivité. Lorsqu'il est correctement utilisé, la vélocité permet l'incorporation de la « météo d'hier » dans le processus de planification d'itération interne d'une équipe. La clé ici est que la vélocité est une mesure interne pour une équipe, c'est juste une estimation de capacité pour cette équipe donnée à un moment donné. Les organisations et les managers qui assimilent la vélocité interne à la productivité externe commencent à se fixer des objectifs de vélocité, oublier que ce qui compte réellement, c'est le fonctionnement du logiciel en production. Traiter la vélocité comme de la productivité conduit à des comportements d'équipe improductifs qui optimisent cette métrique au détriment du logiciel de travail réel.

Reste juste occupé

Un gestionnaire que je connais dit qu'au lieu d'essayer de mesurer la productivité

"Nous restons occupés. Si nous sommes occupés à travailler comme des maniaques, nous pouvons rechercher les problèmes et les goulots d'étranglement, les résoudre et continuer ».

Dans ce cas, vous mesureriez – et optimiseriez – temps d'un cycle, comme dans le Lean manufacturing.

Temps de cycle - délai d'exécution ou délai de modification, du moment où l'entreprise demande quelque chose jusqu'au moment où elle l'obtient et le voit fonctionner - c'est quelque chose dont l'entreprise se soucie, et quelque chose qui tout le monde peut voir et mesurer. Et une fois que vous commencez à regarder de près, le gaspillage et les retards apparaîtront lorsque vous mesurerez le temps d'attente/d'inactivité, valeur ajoutée vs. travail sans valeur ajoutée, et efficacité du cycle de processus (temps total de valeur ajoutée / temps de cycle total).

"Ce n'est pas important de définir la productivité, ou pour le mesurer. Il est beaucoup plus important d'identifier les activités non productives et de les réduire à zéro.
Erik Simmons, Intel

Les équipes peuvent utiliser Kanban pour surveiller – et limiter – les travaux en cours et identifier les retards et les goulots d'étranglement. Et Cartographie des flux pour comprendre les étapes, queues, des délais et des flux d'informations à optimiser. Pour être efficace, vous devez examiner le processus de bout en bout depuis le moment où les demandes sont faites pour la première fois jusqu'au moment où elles sont livrées et exécutées, et optimiser tout au long du parcours, pas seulement le travail de développement. Cela peut signifier changer la façon dont l'entreprise priorise, comment les décisions sont prises et qui prend les décisions.

Dans presque tous les cas, nous avons vu, rendre un bloc de processus plus efficace aura un effet minimal sur le flux de valeur global. Étant donné que les temps de reprise et d'attente sont parmi les principaux contributeurs au délai de livraison global, adopter des processus « agiles » au sein d'une même fonction (comme le développement) a généralement peu d'impact sur le flux de valeur global, et donc sur les résultats clients.
Jezz Humble, L'entreprise Lean

L'inconvénient d'assimiler la vitesse de livraison à la productivité? L'optimisation du temps de cycle / de la vitesse de livraison en elle-même pourrait entraîner des problèmes à long terme, parce que cela incite les gens à penser à court terme, et pour arrondir les angles et s'endetter techniquement.

Nous écrivons de meilleurs logiciels, donc nous devons être plus productifs

« Le paradoxe est que lorsque les managers se focalisent sur la productivité, des améliorations à long terme sont rarement apportées. D'autre part, quand les managers misent sur la qualité, la productivité s'améliore continuellement.
Jean Seddon, cité dans L'entreprise Lean

Nous savons que corriger les bugs plus tard coûte plus cher. Que ce soit 10x ou 100+x, ça n'a pas vraiment d'importance. Et cela les projets avec moins de bugs sont livrés plus rapidement – au moins jusqu'à un point de rendements décroissants pour les systèmes critiques pour la sécurité et vitaux.

Et nous savons que les coûts des bogues et des erreurs dans les logiciels pour l'entreprise peuvent être importants. Pas seulement les coûts de refonte du développement et les coûts de maintenance et de support. Mais les coûts directs pour l'entreprise. Temps d'arrêt. Failles de sécurité. IP perdue. Clients perdus. Amendes. Poursuites. Échec de l'entreprise.

C'est facile à mesurer que vous écrivez un bon – ou un mauvais – logiciel. Densité des défauts. Taux d'échappement des défauts (en particulier les défauts - y compris les vulnérabilités de sécurité - qui échappent à la production). Métriques d'analyse statique sur la base de code, utiliser des outils comme SonarQube.

Et nous savons écrire de bons logiciels – ou nous devrions savoir maintenant. Mais la qualité du logiciel est-elle suffisante pour définir la productivité?

Devops – Mesurer et améliorer les performances informatiques

Les équipes Devops qui construisent/maintiennent et exploitent/supportent les systèmes étendent la productivité du développement à l'exploitation. Ils mesurent la productivité à travers deux dimensions que nous avons déjà examinées: rapidité de livraison, et qualité.

Mais devops ne se limite pas à la création et à la livraison de code. Il examine plutôt les mesures de performance pour la prestation de services informatiques de bout en bout.:

1. Débit de livraison: fréquence et délai de déploiement, maximiser le flux de travail vers la production
2. Qualité du service: modifier le taux d'échec et MTTR

Il ne s'agit pas simplement de fournir des logiciels plus rapidement ou mieux. C'est le développement et les opérations qui travaillent ensemble pour fournir des services meilleurs et plus rapides, trouver un équilibre entre aller trop vite ou essayer d'en faire trop à la fois, et une bureaucratie excessive et une prudence excessive entraînant des gaspillages et des retards. Dev et ops doivent partager la responsabilité et la responsabilité du résultat, et pour mesurer et améliorer la productivité et la qualité.

Comme je l'ai souligné dans un post précédent cela fait métriques opérationnelles plus important que les métriques des développeurs. Selon des études récentes, le succès dans la réalisation de ces objectifs conduit à des améliorations dans la réussite de l'entreprise: pas seulement la productivité, mais part de marché et rentabilité.

Mesurer les résultats, pas de sortie

Dans L'entreprise Lean (que vous pouvez dire que je viens de finir de lire), Jez Jumble parle de l'importance de mesurer la productivité par le résultat - mesurer les choses qui comptent pour l'organisation - et non la production.

"Peu importe le nombre d'histoires que nous terminons si nous n'atteignons pas les résultats commerciaux que nous nous sommes fixés sous la forme de conditions cibles au niveau du programme".

Arrêtez d'essayer de mesurer productivité des développeurs individuels. C'est une perte de temps.

• Tout le monde sait qui sont les plus performants. Orientez-les dans la bonne direction, et gardez-les heureux.
• Tout le monde connaît les gens qui luttent. Offrez-leur l'aide dont ils ont besoin pour réussir.
• Tout le monde sait qui ne rentre pas. Sortez-les.

Mesurer et améliorer la productivité de l'équipe ou (mieux) le niveau de l'organisation vous donnera des rendements beaucoup plus significatifs.

Quand il s'agit de productivité:

1. Mesure les choses qui comptent – des choses qui feront la différence pour l'équipe ou pour l'organisation. Des mesures claires, important, et ce n'est pas facile à jouer.
2. Utiliser les métriques pour le bien, pas pour le mal - pour favoriser l'apprentissage et l'amélioration, ne pas comparer les résultats entre les équipes ou classer les personnes.

Je comprends pourquoi la mesure de la productivité est si séduisante. Si nous pouvions le faire, nous pourrions évaluer les logiciels beaucoup plus facilement et objectivement que nous ne le pouvons actuellement. Mais les fausses mesures ne font qu'empirer les choses.
Martin Fowler, Impossible de mesurer la productivité

A propos de l'auteur

Jim Bird est un responsable du développement logiciel expérimenté, chef de projet et actuellement CTO dans une société de services financiers. Il se concentre sur les problèmes difficiles de développement et de maintenance de logiciels, qualité et sécurité des logiciels. Pour le dernier 15 ans, il a dirigé des équipes construisant et exploitant des systèmes financiers performants. Son intérêt particulier est de savoir comment les petites équipes peuvent être plus efficaces dans la création de vrais logiciels: haute qualité, des systèmes sécurisés aux limites extrêmes de la fiabilité, performance, et adaptabilité. Un logiciel qui doit fonctionner, c'est bien construit, et construit pour durer. Cet article a été initialement publié sur son propre blog Construire un vrai logiciel.

Un article de blog représente l'opinion personnelle de l'auteur
et ne coïncide pas nécessairement avec les politiques officielles de Nesma.