Mesurer la productivité des développeurs : mission impossible ?

Un des axes de la plupart des stratégies de transformation numérique réside dans la recherche de nouveaux leviers de productivité. Dans le même temps, les développeurs se font rares alors que la demande de nouveaux applicatifs reste soutenue. Cette situation a suscité un intérêt pour la compréhension et la mesure de la productivité des développeurs, explique Keith Mann, directeur sénior et analyste au sein du cabinet d'études Gartner. « Les entreprises doivent tirer le meilleur parti du nombre limité de développeurs dont elles disposent, explique-t-il. Nos enquêtes et les données recueillies auprès de ses clients confirment que la productivité des développeurs reste une priorité absolue pour les responsables de l'ingénierie logicielle. »

Dominic Titcombe, DSI du réseau américain de compagnies d'assurance dentaire Delta Dental en Californie, ajoute que les récentes avancées en matière d'IA générative ont inspiré de nouvelles méthodes de travail, et que l'application de l'IA pour accélérer la création de logiciels a fait l'objet de nombreuses discussions. « Il existe clairement des outils formidables dans ce domaine, comme GitHub Copilot, que les développeurs peuvent utiliser pour améliorer et accroître leur productivité », dit-il.

Angelic Gibson, DSI du fournisseur de logiciels d'automatisation des comptes fournisseurs et de solutions de paiement AvidXchange, reconnaît que l'élimination des frictions dans le workflow des développeurs peut favoriser l'innovation agile. « Se concentrer sur l'innovation et le déploiement technologique permet d'identifier et d'éliminer les obstacles qui entravent les équipes techniques », dit-elle, ajoutant que si la mesure de la productivité dans le développement logiciel est essentielle pour la numérisation de la DSI, elle nécessite un déploiement prudent pour maintenir une dynamique d'équipe saine. « Les équipes connectées font preuve d'une plus grande appropriation et d'un plus grand engagement, ce qui se traduit par une plus grande efficacité », dit-elle.

Rationaliser le processus pour optimiser la productivité

Le développement agile de logiciels est essentiel pour innover et rester compétitif. C'est pourquoi les responsables de l'ingénierie doivent mesurer la productivité des développeurs de logiciels, explique Keith Mann (Gartner), mais surtout ils doivent appréhender comment le faire efficacement et se méfier des pièges. « Bien menée, la mesure de la productivité permet de savoir comment les équipes de développement peuvent apporter plus de valeur aux utilisateurs et aux clients, et c'est ce qui conduit à des impacts positifs pour l'entreprise », note-t-il.

Dominic Titcombe estime, lui aussi, qu'il est utile d'évaluer l'efficacité des développeurs, car cela permet aux services IT d'atteindre leurs objectifs, à savoir fournir des produits de qualité aux consommateurs finaux. « Il incombe à toute division de l'entreprise de rechercher des améliorations de la productivité et de trouver des moyens de faire davantage avec moins, souligne-t-il. Un élément clé de la création des expériences que nous offrons à nos clients consiste à le faire rapidement et à des coûts acceptables, tout en fournissant un produit de qualité. »

Identifier les goulets d'étranglement

Cependant, livrer des produits numériques de qualité peut s'avérer difficile si les équipes de développement ne sont pas placées dans de bonnes dispositions. Trop souvent, les services IT sont aux prises avec d'importants backlogs de fonctionnalités, ce qui entrave les nouveaux développements, observe Angelic Gibson. Les équipes de développement sont également souvent confrontées à des goulets d'étranglement qui empêchent la fluidité des workflows, ajoute-t-elle. Freins qui peuvent provenir d'un code peu lisible, d'une architecture trop complexe ou d'une automatisation et de tests insuffisants. Étant donné que ces frictions dans le processus de développement diminuent la productivité, il est impératif, selon elle, de comprendre ces blocages afin de les lever. « Tout comme Netflix a innové face à Blockbuster grâce à des développements technologiques efficaces, les entreprises qui rationalisent ce processus peuvent accélérer l'innovation sur le marché, ce qui stimule leur chiffre d'affaires et leur rentabilité », explique la DSI de AvidXchange.

Tous les DSI ne sont d'ailleurs pas convaincus que la mesure de la productivité des développeurs peut produire des résultats exploitables. C'est plutôt l'accent mis sur la rationalisation des processus qui leur semble le plus important. « L'accent mis sur la productivité des développeurs est une course folle », estime même Kyle Campbell, PDG et fondateur de la plateforme de test de code CTO.ai. « Un dirigeant plus expérimenté et plus pragmatique sait que le rendement d'une équipe est directement lié au niveau de soutien dont elle dispose pour se concentrer sur son travail le plus utile. »

Par conséquent, il recommande de responsabiliser les équipes de développement en réfléchissant de manière critique à la façon dont leurs workflows, en particulier ceux de la chaîne CI/CD, peuvent être optimisés, et en mesurant de manière empirique l'expérience des développeurs dans ces domaines.

Mesurer les résultats, ne pas compter les lignes de code

Il existe différents points de mesure tout au long du cycle de vie du développement logiciel (SDLC, pour software development lifecycle), de la naissance des idées aux étapes de production, qui doivent être surveillés pour assurer la fluidité du workflow. « Si les entreprises n'améliorent pas l'efficacité de ces étapes ou le déploiement de la technologie, elles risquent de se laisser distancer par leurs concurrents », dit Angelic Gibson.

La volonté de mesurer la productivité des développeurs de logiciels se heurte toutefois à des obstacles. Bien qu'il existe de nombreuses écoles de pensée sur la manière de procéder en la matière, le sentiment général des décideurs IT est qu'il vaut mieux éviter de mesurer les contributions au niveau microscopique, celui de chaque contributeur. « Compter les lignes de code générées par jour et par développeur peut conduire à des mesures de productivité erronées », estime ainsi Dominic Titcombe. Mieux vaut jauger la vitesse de livraison des nouvelles fonctionnalités. « Une meilleure mesure de l'efficacité des développeurs consiste à savoir si nous pouvons mettre plus rapidement des outils et expériences à la disposition de nos clients, ce qui aura un effet bénéfique global plus important pour l'entreprise » dit le DSI de Delta Dental Californie.

L'une des principales mises en garde concernant certaines mesures de la productivité est qu'elles peuvent donner naissance à des faux positifs ou inciter les ingénieurs à jouer avec le système mis en place. « Dès qu'un développeur se rend compte qu'il fait l'objet d'une certaine mesure, il cherchera à gonfler artificiellement cette mesure, explique ainsi Dominic Titcombe. Il est donc préférable d'utiliser une mesure de la productivité à l'échelle de l'entreprise, qui se concentre sur les résultats obtenus au bénéfice des clients. »

Des frameworks à manipuler avec prudence

Chez Gartner, les clients s'intéressent à la mise en oeuvre de certains frameworks axés sur la productivité des développeurs, explique Keith Mann. L'un d'eux est SPACE. Proposé par les chercheurs de GitHub, SPACE complète le cadre DevOps Research and Assessment (DORA) avec des mesures plus qualitatives basées sur la satisfaction et le bien-être, la performance, l'activité, la communication et la collaboration, ainsi que l'efficacité et le workflow. Un autre framework utilisé par l'analyste se nomme DevEx.

Les attributs de ces frameworks peuvent aider à mesurer la productivité des développeurs, certains de manière plus objective que d'autres, note Keith Mann. Cependant, il encourage les DSI à faire preuve de discernement lors de leur mise en oeuvre. Idéalement, les activités de mesure devraient dévoiler les obstacles qui empêchent d'obtenir des résultats positifs pour l'entreprise et ne pas être utilisées pour placer certains collaborateurs sur un piédestal.

« L'objectif de la mesure n'est pas de déterminer si un développeur est meilleur ou moins bon qu'un autre en comparant leurs indicateurs, tranche Keith Mann. L'objectif est plutôt de diagnostiquer les facteurs susceptibles d'entraîner une hausse ou une baisse de la productivité du développeur en question. » Par exemple, il raconte comment un client utilisant SPACE a pu mettre au jour un problème de communication, qui a été résolu avec succès, ce qui a permis de réduire les problèmes de qualité et les reprises de code.

Ce type de petites corrections, révélées par un contrôle intelligent de la productivité, peut déboucher sur des bénéfices significatifs. « En matière de productivité, il s'agit de savoir à quelle vitesse les entreprises peuvent passer de la conceptualisation d'une idée et de la définition de ses spécifications à la planification de l'architecture, explique Angelic Gibson. Et cette productivité se traduit directement sur le time-to-market et la capacité d'innovation, ce qui se répercute en fin de compte sur les résultats de l'entreprise. »

Le travail d'équipe génère des gains de productivité

Et l'amélioration de la productivité du développement logiciel ne doit pas être encouragée uniquement par des mesures. Un autre facteur contribuant de manière significative à la productivité globale est le sentiment d'appartenance et d'engagement d'un développeur vis-à-vis de son équipe. « Le travail d'équipe est la pierre angulaire de la productivité, juge Angelic Gibson. Pour que les équipes soient très productives, il faut que les gens se sentent connectés les uns aux autres, qu'ils aient un sentiment d'appartenance et de cohésion avec les autres équipes avec lesquelles ils travaillent. »

Mieux appréhender la productivité pourrait également signifier réimaginer le concept dans son intégralité, car la définition industrielle typique de ce que signifie être "productif" ne s'applique tout simplement pas au processus de conception et de développement. Les logiciels ne se comparent pas à la production d'un objet mécanique, dont le processus de fabrication reste identique pour chaque unité produite, explique Keith Mann. Les logiciels, eux, sont en constante évolution, et la valeur finale diffère d'un composant à l'autre, ce qui complique les techniques traditionnelles de mesure de la productivité.

« Chaque logiciel est unique et a une valeur unique, indique l'analyste du Gartner. Cela n'a aucun sens de dire : 'Nous avons produit deux fois plus de logiciels que la semaine dernière, nous avons donc été deux fois plus productifs', car le logiciel livré cette semaine peut très bien avoir une valeur deux fois moindre. » Par conséquent, les mesures de productivité peuvent souvent être des illusions sans réels avantages tangibles. « Ce qu'il faut faire, c'est comprendre la productivité comme la quantité de valeur que nous produisons par unité de temps ou de coût », ajoute Keith Mann.

Se focaliser sur la valeur créée, sans perdre sa lucidité

L'autre implication de la nature même du processus de création du logiciel : les applications ne sont pas créées de manière isolée - il s'agit d'un processus collaboratif avec de nombreuses parties prenantes impliquées dans chaque sprint. « La plupart des logiciels sont produits par des équipes de développeurs, et non par un développeur unique », précise Keith Mann. Par conséquent, les DSI devraient chercher à évaluer la productivité de l'équipe sur des périodes prolongées afin de déterminer réellement si les améliorations apportées sont efficaces.

« Si vous pouvez évaluer la valeur de manière cohérente entre les équipes, vous pouvez même comparer leur productivité », note Keith Mann. Toutefois, s'empresse-t-il d'ajouter, il s'agit là d'un grand "si", car la valeur créée dépend fortement du domaine d'activité en question et varie considérablement d'un cas à l'autre.

Bien entendu, la valeur n'est pas toujours facile à mesurer, ce qui souligne la nécessité d'une approche flexible, en particulier lorsqu'il s'agit de comparer la dynamique d'une équipe. Par conséquent, au lieu de s'appuyer sur une mesure universelle spécifique, il peut être plus avantageux de révéler les tendances relatives aux équipes en question.

« Il est plus intéressant de comparer et de comprendre les tendances et de les utiliser comme base pour des analyses plus approfondies, renchérit Mann. Par exemple, si la productivité d'une équipe a tendance à augmenter alors que celle d'une équipe similaire stagne, nous pourrions nous demander ce que la première équipe fait différemment. » Poser de telles questions amène à partager les connaissances au sein de l'entreprise, ce qui aide les autres équipes à s'améliorer.

Favoriser une culture de l'amélioration continue

Si on se focalise sur l'expérience des développeurs, les domaines clés sur lesquels se concentrer présentent des caractéristiques légèrement différentes. « Il est essentiel d'évaluer les éléments clés de l'expérience d'un développeur à l'aide des feedbacks des équipes », dit Kyle Campbell (CTO.ai). Il regroupe ces éléments en quatre catégories : clarté (comment déployer), facilité d'utilisation (quelles sont les étapes minimales pour déployer), fonctionnalité (existe-t-il un workflow, une API ou un SDK que je peux étendre) et stabilité (puis-je être sûr que l'applicatif ne tombera pas en panne au milieu de la nuit si je le déploie maintenant). A partir des commentaires des ingénieurs dans ces domaines, la DSI peut investir au mieux dans des améliorations qui renforceront la productivité.

Kyle Campbell estime même que mesurer uniquement la productivité des développeurs peut être un leurre. Il préconise plutôt d'encourager une culture de l'amélioration continue et de découvrir des stratégies pour mieux instrumenter les workflows des développeurs et, à partir de là, de mesurer cette chaîne d'outils pour obtenir des informations exploitables sur le développement. « Tout comme nous mesurons l'impact de nos logiciels sur les utilisateurs finaux qui tentent d'atteindre un objectif, nous pouvons également mesurer l'impact de nos outils internes sur notre objectif », dit-il.

A lire également :
- Peut-on mesurer la productivité des développeurs (sans effet pervers) ?