IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Est-il possible de mesurer la productivité des développeurs ? Oui, selon McKinsey,
Qui suggère une approche adaptée au contexte et aux objectifs

Le , par Stéphane le calme

20PARTAGES

12  0 
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

Et vous ?

Cette étude de McKinsey est-elle crédible ou pertinente ?
Quelle est selon vous la définition de la productivité des développeurs logiciels ? Est-il possible de la mesurer ?
Sinon, pourquoi ? Si oui, quelles sont les méthodes que vous utilisez ou que vous connaissez pour mesurer la productivité des développeurs logiciels ?
Quels sont les avantages et les inconvénients de ces méthodes ?
Quels sont les facteurs qui influencent positivement ou négativement la productivité des développeurs logiciels ?
Comment améliorer la productivité des développeurs logiciels dans votre entreprise ou votre équipe ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de AaâÂäÄàAaâÂäÄàAaâÂäÄ
Membre éprouvé https://www.developpez.com
Le 21/08/2023 à 14:53
J'ai connu un dev qui était très bien vu parce qu'il était vraiment rapide.
Étonnamment, quand arrivait les tests de validation, on passait du temps majoritairement à débugger son code
Et curieusement son aura de kador auprès des boss ne ternissait pas malgré ce fait assez incriminant.
13  0 
Avatar de pboulanger
Membre éclairé https://www.developpez.com
Le 21/08/2023 à 16:17
Avant de vouloir mesurer la productivité des développeurs, ils devraient commencer par mesurer la productivité de leurs consultants... Lorsque l'on voit le prix facturé à l'état français et les effets délétères de leurs rapports sur l'économie et l'infrastructure française je m'interroge sur la pertinence de leur réflexion.
Pour faire simple: avant de vouloir l'aiguille dans l'oeil de ton voisin, enlève la poutre dans le tien.
10  0 
Avatar de Fagus
Membre expert https://www.developpez.com
Le 22/08/2023 à 13:45
Je travaille dans le public.

Une fois, la direction a voulu payer un cabinet de conseil pour optimiser le service.

Déjà, j'ai jamais compris l'intérêt d'être audité par des juniors, qui ne sont même pas du métier et comprennent péniblement la nature de notre travail. Logiquement, on devrait apporter des conseils quand on a une grande expérience du sujet...

Finalement, on a obtenu un rapport en français de consultant, qui une fois traduit en français normal était assez creux et éludait les problèmes réels... qui en fait sont bien connus du service (mais la direction a des objectifs... bien différents)

À savoir, les objectifs du gouvernement sont d'économiser de l'argent, donc tous les indicateurs visent l'économie (mais pas intelligemment comme en supprimant les redondances, plutôt par rabot global en amputant autant le critique que l'inutile).

Donc, on a du matériel tout le temps en semi-panne, à la fois par économie matérielle et du personnel de la maintenance.
Comme le but c'est d'économiser autant que possible sur les salaires, plus de la moitié du personnel a démissionné et il y a plus de candidats. C'est d'ailleurs dommage, car on avait essayé d'expliquer à la direction que pas de personnel = 2 mois d'arrêt d'une partie de la production en été et qu'un seul jour de cette prod paye les salaires (sans compter que le travail non fait doit être externalisé au privé à grand frais)

Sans compter les problèmes "normaux" du public (par ex, que le personnel toxique et improductif doit être gardé, et que le seul moyen de diminuer la contagion c'est de les concentrer dans un service... le notre), ou que du personnel diplômé (ex secrétaire) est remplacé par des "agents sachant relativement lire et écrire" parce que c'est le minimum de la grille salariale (mais ça produit peu et le personnel très qualifié se retrouve à abandonner son travail pour faire du secrétariat)

Rien de tout ça dans le rapport des consultants. Vivent les consultants.
8  0 
Avatar de GLDavid
Expert confirmé https://www.developpez.com
Le 22/08/2023 à 14:25
McInsey... je reviendrais pas sur notre bon président et sa lubie avec ces gens-là.
Moi, la boîte pour laquelle je travaille avait demandé à McInsey comment réorganiser la boîte pour qu'elle fonctionne en 'meilleure synergie' (mais si, ce terme de manager...)
De l'argent a été dépensé, des cadres auditionnés par McInsey (pas votre serviteur) et finalement, on a abouti à une idée lumineuse: "Tous ensemble pour demain" !
Wouah, la com' ! Et ca a été le maître mot pendant 1 an et puis... plus rien, les objectifs avaient changé, la boîte avait d'autres orientations et toutes ces belles paroles envolées.

De l'argent jeté par les fenêtres avez-vous dit ? Allons, qu'est-ce qui a bien pû vous faire penser ça
4  0 
Avatar de escartefigue
Modérateur https://www.developpez.com
Le 22/08/2023 à 13:59
Citation Envoyé par Fagus Voir le message
Rien de tout ça dans le rapport des consultants. Vivent les consultants.
Parfois, les consultants travaillent en toute autonomie, parfois, il ne font qu'écrire sur ordre, ce qu'on attend d'eux, ce qui permet de légitimer des actions (tant qu'à faire un plan social) sous le couvert d'un avis réputé extérieur et donc, à priori, impartial...
3  0 
Avatar de totozor
Membre expert https://www.developpez.com
Le 23/08/2023 à 8:47
Citation Envoyé par Fagus Voir le message
Déjà, j'ai jamais compris l'intérêt d'être audité par des juniors, qui ne sont même pas du métier et comprennent péniblement la nature de notre travail. Logiquement, on devrait apporter des conseils quand on a une grande expérience du sujet...
Mon expérience me dit que le problème ne vient ni de l'âge ni de la connaissance du métier mais de la capacité de l'auditeur à apprendre et de sa volonté d'apprendre.

J'ai un exemple vécu : Je me retrouve chef d'équipe il y a bien longtemps et au bout de quelques semaines je découvre un problème simple : on recoit chaque semaine 50 plans, on en sort que 30. Après moultes efforts non concluant je demande du support à mes managers parce que la situation semble insolvable. Comme ils ne veulent pas renforcer l'équipe ils nous envoient le cador de la qualité de l'entreprise, un gars de 50 piges, 15 ans d'expérience pro en gestion de projet et en gestion qualité. On parle pendant 4h (le temps qu'il me fallait pour sortir 3 plans) pour lui présenter la situation : on rentre 50 plans, on a une capacité théorique d'en sortir 55 mais on dépasse rarement les 30, on ne sait pas exactement combien de plans sont dans notre backog mais on dépasse largement les 200. Sa solution : vous ne produisez rien pendant une semaine et toute l'équipe se concentre sur l'enregistrement de ce qui a été fait, sur l'historisation des versions des outils utilisés. Quand je lui répond que ça ne répond en rien à mes problèmes de productivité il me répond que si à la fin de la semaine suivante on a pas fait le boulot je vais me retrouver en commission devant la direction pour expliquer pourquoi je ne suit pas les consignes du responsable qualité de la boite. Conclusion : vendredi de la semaine suivante, alors qu'on a rien sorti de la semaine, le client me convoque avec mes managers : on a 360 plans de retard en backlog, il exige de nous un plan de rattrapage pour revenuir à la normale dans 3 mois, en attendant le projet est remis en cause chaque semaine : si on atteint pas les objectifs hebdo personne ne revient lundi matin.
Pendant ce plan de rattrapage un jeune sorti d'école d'ingé qualité arrive dans l'équipe, il ne sait pas lire un plan mais est capable de suivre la procédure de controle. Depuis le premier jour il pose des questions sur l'organisation et propose des solutions. Les premières ne sont pas applicables mais il comprend petit à petit le contexte et on lance quelques améliorations d'organisation. En quelques semaines on gagne clairement en productivité. On finira le plan de rattrage avec une semaine d'avance.

Bref un gamin qui s'y interresse peut etre bien plus efficace qu'un "vieux briscard" donneur de lecon.
3  0 
Avatar de solstyce39
Membre confirmé https://www.developpez.com
Le 22/08/2023 à 8:23
Citation Envoyé par pboulanger Voir le message
Avant de vouloir mesurer la productivité des développeurs, ils devraient commencer par mesurer la productivité de leurs consultants... Lorsque l'on voit le prix facturé à l'état français et les effets délétères de leurs rapports sur l'économie et l'infrastructure française je m'interroge sur la pertinence de leur réflexion.
Pour faire simple: avant de vouloir l'aiguille dans l'oeil de ton voisin, enlève la poutre dans le tien.
haha oui, j'ai vu McKinsey, jme suis dis direct la même chose
1  0 
Avatar de totozor
Membre expert https://www.developpez.com
Le 22/08/2023 à 8:34
Citation Envoyé par Stéphane le calme Voir le message
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.
Je ne suis pas développeur et je travaille pas dans une entreprise dont le développement est le coeur de métier mais je bosse beaucoup avec nos developpeurs internes. Et ma première conclusion est simple : la valeur des développeurs interne ne vient pas de leur productivité mais de leur capacité à s'adapter à un evironnement qui n'est pas forcément son environement de travail naturel, à un client qui ne sait pas ce qu'il veut ou qui ne sait pas l'expliquer clairement etc.
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
Bonne idée ça, changeons les méthodes de travail pour pouvoir faire un suivi et constater que les dev ne sont pas perfomants, étrangement les clients étaient satisfaits avant et ne le sont plus.
On prétextera à la fin une résistance au changement pour justifier la non adoption des nouvelles méthodes.
Je passe une grande partie des mes journées à faire des indicateurs, ma première ligne de conduite est qu'on ne doit pas dégrader le travail pour réussir à le mesurer. Il faut mieux bien bosser sans être capable de le prouver que d'être capable de prouver qu'on bosse mal.
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*?
C'est là que je vois l'écart de philosophie entre un cabinet de conseil et une entreprise industrielle. Avant de parler de productivité, ils pensent déjà aux questions que la non performance implique. ils sont déjà en train d'essayer de justifier la non performance.
1 on mesure la performance
2 Si elle est bonne et que personne se plaint on passe à la suite, si elle n'est pas bonne on cherche les sources
3 On arrete de justifier la non performance passé et on commence à agir pour attaindre l'objectif dans l'avenir

Qu'une entreprise ne soit pas capable d'identifier les compétences nécessaire chez un dev est un problème en soit. Les matrices de compétences existent depuis la nuit des temps, à 26 ans j'ai réinventer le truc (pas si bien que ça) pour montrer à mes managers pourquoi je voulais faire monter en compétence les membres de mon équipe. J'étais un gamin, je n'envisage même pas que les RH d'une boite un minimum grande ne s'en charge pas.

Pour la suite je ne comprends pas:
Ils disent que le développement est essentiellement un travail collectif donc que la performance passe par la synchronisation des personnes pourtant aucune des mesures qu'ils proposent de traitent de ce sujet...
Ils parlent de productivité individuelle mais 2/3 des indicateurs proposés ne concernent même pas la productivité. ("la performance de compétence" de ton personnel est avant tout de ta responsabilité, s'il est là depuis longtemps mais qu'il est à la traine c'est probablement parce que tu ne lui a pas donné les formations nécessaire. Je ne parles que de compétence, pas de poil dans la main, ça c'est de la performance)

Je pensais honetement que McKinsey étaient des cadors de l'optimisation et qu'ils étaient donc capables de proposer des vrais indicateurs pertinents ou de dire pourquoi on ne peut pas en avoir facilement, mais en fait ils sont pas si malin que ça...
Je soupçonne que la meilleure conclusion est plutôt qu'on ne sait pas mesurer la productivité individuelle d'un dev de façon précise et réactive et qu'il faut donc soit allonger la période de mesure soit abandonner l'individualisation pour une mesure collective.
Et je penses que dans le dévelopement interne d'une entreprise industrielle quand on mesure la performance de l'équipe on doit intégrer le client (et là je parle de moi et mes confrères) dans "l'équipe" parce qu'il est un des facteur premier de la non performance.
1  0 
Avatar de ParseCoder
Membre averti https://www.developpez.com
Le 22/08/2023 à 14:15
Donc en gros pas grand chose de nouveau. On s'en serait douté. Mais ils font parler d'eux et c'est sans doute le plus important.
1  0 
Avatar de stardeath
Expert confirmé https://www.developpez.com
Le 22/08/2023 à 21:14
Citation Envoyé par Stéphane le calme Voir le message
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.
donc la mesure est possible ... MAIS elle dépend de tellement de choses et doit être utilisée avec discernement [...]

de là à dire que la mesure est donc soit ni possible soit ni exploitable, il n'y a donc qu'un pas?
1  0