Oui, selon McKinsey, Qui suggère une approche adaptée au contexte et aux objectifs
La productivité des développeurs logiciels est un sujet qui suscite beaucoup de débats et de controverses dans l’industrie du logiciel. Comment mesurer l’efficacité et la performance des développeurs qui travaillent sur des projets complexes, créatifs et collaboratifs ? Est-il possible de trouver des indicateurs objectifs et fiables qui reflètent la qualité et la valeur du travail accompli ? Quels sont les facteurs qui influencent la productivité des développeurs et comment les optimiser ?
Comparé à d’autres fonctions commerciales critiques telles que les ventes ou les opérations client, le développement de logiciels est constamment sous-évalué. La croyance de longue date de nombreux techniciens est qu’il n’est pas possible de l’évaluer correctement et que, dans tous les cas, seuls les ingénieurs formés sont suffisamment informés pour évaluer les performances de leurs pairs. Pourtant, ce statu quo n’est plus tenable. Maintenant que la plupart des entreprises deviennent (à un degré ou à un autre) des éditeurs de logiciels, quel que soit leur secteur d’activité, les dirigeants doivent savoir qu’ils déploient leurs talents les plus précieux avec le plus de succès possible.
Il est indéniable qu’il est difficile de mesurer la productivité des développeurs. D’autres fonctions peuvent être raisonnablement bien mesurées, certaines même avec une seule métrique ; alors que dans le développement de logiciels, le lien entre les entrées et les sorties est beaucoup moins clair. Le développement de logiciels est également un travail hautement collaboratif, complexe et créatif et nécessite différentes métriques pour différents niveaux (tels que les systèmes, les équipes et les individus). De plus, même s’il existe un véritable engagement à suivre correctement la productivité, les mesures traditionnelles peuvent nécessiter des systèmes et des logiciels configurés pour permettre une mesure plus nuancée et complète. Pour certaines métriques standard, des piles technologiques entières et des pipelines de développement doivent être reconfigurés pour permettre le suivi, et la mise en place des instruments et outils nécessaires pour obtenir des informations significatives peut nécessiter des investissements importants à long terme. De plus, le paysage du développement de logiciels évolue rapidement, car les outils d’IA générative tels que CopilotX et ChatGPT ont le potentiel de permettre aux développeurs d’effectuer des tâches jusqu’à deux fois plus rapidement.
McKinsey estime qu’il est possible de mesurer la productivité des développeurs logiciels
Cependant, le cabinet précise que cela nécessite une approche adaptée au contexte et aux objectifs de chaque entreprise.
Tirer parti des informations sur la productivité
Avec un accès à des données et des informations sur la productivité plus riches, les dirigeants peuvent commencer à répondre à des questions urgentes sur les talents en génie logiciel qu’ils se sont tant battus pour attirer et retenir, telles que les suivantes :
- Quels sont les obstacles qui empêchent les ingénieurs de travailler à leur meilleur niveau ?
- Dans quelle mesure la culture et l’organisation affectent-elles leur capacité à produire leur meilleur travail ?
- Comment savoir si nous utilisons leur temps sur des activités qui génèrent vraiment de la valeur ?
- Comment pouvons-nous savoir si nous avons tous les talents en génie logiciel dont nous avons besoin ?
Comprendre les fondements
Pour utiliser un système suffisamment nuancé de mesure de la productivité des développeurs, il est essentiel de comprendre les trois types de mesures qui doivent être suivies : celles au niveau du système, au niveau de l’équipe et au niveau individuel. Contrairement à une fonction telle que les ventes, où une mesure au niveau du système des dollars gagnés ou des transactions conclues pourrait être utilisée pour mesurer le travail des équipes et des individus, le développement de logiciels est collaboratif d’une manière distincte qui nécessite des lentilles différentes. Par exemple, bien que la fréquence de déploiement soit une mesure parfaitement adaptée pour évaluer les systèmes ou les équipes, elle dépend du fait que tous les membres de l’équipe effectuent leurs tâches respectives et n’est donc pas un moyen utile de suivre les performances individuelles.
Une autre dimension critique à reconnaître est ce que les différentes mesures font et ne vous disent pas. Par exemple, mesurer la fréquence de déploiement ou le délai d’exécution des changements peut vous donner une vision claire de certains résultats, mais pas de savoir si une organisation d’ingénierie est optimisée. Et bien que des métriques telles que les points d’histoire terminés ou les interruptions puissent aider à déterminer l’optimisation, elles nécessitent une enquête plus approfondie pour identifier les améliorations qui pourraient être bénéfiques.
En construisant notre ensemble de métriques, nous avons cherché à développer les deux ensembles de métriques déjà développés par l’industrie du logiciel. Le premier est la métrique DORA, du nom de l’équipe de recherche et d’évaluation DevOps de Google. Ce sont les normes les plus proches du secteur technologique et elles sont excellentes pour mesurer les résultats. Lorsqu’une métrique DORA renvoie un résultat inférieur à la moyenne, c’est un signal pour enquêter sur ce qui s’est mal passé, ce qui peut souvent impliquer une recherche prolongée. Par exemple, si une métrique telle que la fréquence de déploiement augmente ou diminue, il peut y avoir plusieurs causes. Déterminer ce qu’ils sont et comment les résoudre n’est souvent pas simple.
Le deuxième ensemble de mesures développées par l’industrie est constitué des métriques SPACE (satisfaction et bien-être, performance, activité, communication et collaboration, et efficacité et flux), que GitHub et Microsoft Research ont développées pour augmenter les métriques DORA. En adoptant un objectif individuel, en particulier autour du bien-être des développeurs, les métriques SPACE sont très utiles pour clarifier si une organisation d’ingénierie est optimisée. Par exemple, une augmentation des interruptions subies par les développeurs indique un besoin d’optimisation.
En plus de ces mesures déjà puissantes, notre approche cherche à identifier ce qui peut être fait pour améliorer la façon dont les produits sont livrés et ce que valent ces améliorations, sans avoir besoin d’une instrumentation lourde. Compléter les métriques DORA et SPACE avec des métriques axées sur les opportunités peut créer une vue de bout en bout de la productivité des développeurs de logiciels.
Les métriques utilisées par McKinsey
McKinsey s’intéresse à l’optimisation du temps passé par les développeurs de logiciels dans les activités de création de produits (boucle interne) et les tâches nécessaires pour mettre le code en production (boucle externe). Le cabinet a présenté quatre méthodes pour identifier les domaines d’amélioration potentiels :
- analyse du temps passé dans la boucle interne/externe : il s’agit de mesurer la répartition du temps entre les activités de codage, de construction et de test unitaire (boucle interne) et les activités d’intégration, de test d’intégration, de publication et de déploiement (boucle externe). L’objectif est de maximiser le temps passé dans la boucle interne, qui génère de la valeur et motive les développeurs, en automatisant et en améliorant les outils pour la boucle externe ;
- benchmark de l’indice de vélocité des développeurs : il s’agit d’un sondage qui mesure la technologie, les pratiques de travail et l’habilitation organisationnelle d’une entreprise et les compare à celles de ses pairs. Cette comparaison permet de mettre en évidence des opportunités spécifiques, que ce soit dans la gestion du backlog, les tests ou la sécurité et la conformité ;
- analyse des contributions : il s’agit d’évaluer les contributions individuelles au backlog d’une équipe (à partir des données des outils de gestion du backlog tels que Jira) et de normaliser les données pour tenir compte des nuances. Cette analyse peut aider à identifier les tendances qui entravent l’optimisation de la capacité de l’équipe. Elle peut également aider à définir des opportunités de formation ou d’amélioration des compétences individuelles et à repenser la distribution des rôles au sein d’une équipe ;
- score de capacité des talents : Il s’agit d’un résumé des connaissances, des compétences et des aptitudes individuelles d’une organisation, basé sur des cartes de capacité standard de l’industrie. Idéalement, les organisations devraient aspirer à une distribution « en diamant » de la compétence, avec la majorité des développeurs dans la plage moyenne de compétence. Ce score peut révéler des opportunités de coaching et d’amélioration des compétences, et dans des cas extrêmes, appeler à une reconsidération de la stratégie de talents.
Les difficultés et les pièges de la mesure de productivité des développeurs logiciels
Un article paru sur Stack Overflow a souligné les difficultés et les pièges de la mesure de la productivité des développeurs logiciels. L’auteur critique notamment l’utilisation des heures travaillées comme proxy de la performance, qui peut conduire à une culture toxique où la présence au bureau prime sur la qualité du travail. Il met également en garde contre le risque d’ignorer le travail négatif, c’est-à-dire le travail qui réduit la valeur du produit ou qui crée des problèmes à résoudre ultérieurement. Il suggère plutôt de se concentrer sur les résultats concrets et mesurables du travail des développeurs, comme le nombre de fonctionnalités livrées, le taux d’erreurs corrigées, le feedback des utilisateurs ou le retour sur investissement.
Un article paru sur Stackify propose une liste de métriques importantes à suivre pour évaluer la productivité des développeurs logiciels. Parmi ces métriques, on trouve le nombre de lignes de code écrites, le nombre de commits effectués, le temps passé à coder, le temps passé à tester, le temps passé à déboguer, le nombre de bugs détectés, le nombre de bugs résolus, le taux de couverture des tests, le taux d’utilisation des ressources ou encore le niveau de satisfaction des clients. L’article précise toutefois que ces métriques doivent être interprétées avec prudence et qu’elles ne doivent pas être utilisées pour comparer les développeurs entre eux ou pour les sanctionner.
Conclusion
Tous ces différents articles indiquent deux choses : la première est que la mesure de la productivité des développeurs logiciels est possible, la seconde est qu’elle n’est pas simple ni universelle. Elle dépend du type de logiciel, de la structure de l’équipe et de l’organisation, ainsi que des objectifs visés. Elle nécessite également une approche holistique qui prend en compte les différents aspects du travail des développeurs, comme le temps, la qualité, l’impact, l’expérience et la culture. Enfin, elle doit être utilisée avec discernement et dans un but d’amélioration continue plutôt que de contrôle ou de jugement.
Source : McKinsey