LinkedIn est un service en ligne vaste et complexe, qui regroupe toute une série de fonctionnalités sous l’apparence d’une application web. Celle-ci inclut la plateforme communautaire qui attire les utilisateurs, mais aussi les produits de formation et de recrutement qui génèrent des bénéfices. Tous ces éléments sont importants et doivent fonctionner ensemble pour fournir le service attendu par les utilisateurs et ses clients. Proposer ces prestations demande beaucoup d'efforts de la part des développeurs, de l'infrastructure, pour soutenir la myriade de services et de microservices qui s'assemblent pour composer un réseau social moderne.

Pur produit de ses développeurs, LinkedIn doit faire en sorte qu’ils restent productifs et heureux. Elle doit donc comprendre ce que ces deux exigences clés signifient pour elle en tant qu'entreprise. S'appuyant sur ses propres expériences et sur celles d'autres entreprises dont Mozilla, le réseau social a élaboré, mis en œuvre et partagé un framework de productivité et de bonheur au travail des développeurs, le Developer Productivity and Happiness Framework ou DPH, qui fournit des lignes directrices pour mesurer ses propres processus de développement. Ces lignes directrices se sont avérées utiles et elles ont été récemment livrées en open source afin que d'autres entreprises puissent tirer les mêmes leçons et améliorer leurs propres processus de développement, en comprenant ce qui marche dans leur fonctionnement et là où se situent les goulets d'étranglement et les frustrations.

L'évolution des méthodes de développement appelle à une évolution du management

Un aspect important du Developer Productivity and Happiness Framework (DPH) annoncé par LinkedIn, est sa capacité à comprendre la façon dont le développement logiciel a évolué. On sait depuis longtemps que dans toute mesure de la productivité, il faut prendre en compte les délais de construction, mais le passage de la méthode traditionnelle en cascade à la méthode agile et au CI/CD (intégration continue/livraison continue) a changé la donne. Désormais, chaque poussée de code peut donner lieu à une compilation, en incluant les tests automatisés qui font partie du processus. Il faut également prendre en compte les revues de code, le temps passé à tester et à traiter les requêtes pull avant l’acceptation des changements. La plupart des mesures utilisées par LinkedIn proviennent des outils eux-mêmes, qu'il s'agisse des performances d'une chaîne d'outils locale sur le PC d’un développeur ou d'une plateforme CI/CD hébergée dans le cloud. L'objectif est d’identifier les freins et les goulots d'étranglement qui entravent la livraison du code et de s'assurer que les utilisateurs ont la meilleure expérience possible.

Ce nouveau modèle exige de nouvelles méthodes de travail. Les développeurs ne peuvent plus livrer d'énormes blocs de code, car ils seraient obligés d’attendre la fin de la révision. Quant aux réviseurs de code, ils ne peuvent pas laisser s’accumuler des arriérés de code. En utilisant les métriques DPH, on peut déterminer ce qui facilite le travail des deux parties. Cela peut se traduire par des soumissions plus fréquentes, mais plus petites, plus faciles à comprendre, plus faciles à tester et plus rapides à approuver, ce qui rend le code plus facile à maintenir et à comprendre. Les avantages qui en découlent sont évidents : les développeurs, qu'ils soient débutants ou confirmés, peuvent rester concentrés sur leur code, en évitant les sources de perturbations dont la résolution prend du temps.

Des chiffres aux résultats

Certes, c’est une bonne chose d'avoir un framework pour déterminer la productivité des développeurs et définir les indicateurs utilisés, mais comment transformer ces données en action ? L'un des éléments clés est de disposer d'un tableau de bord ou d'un portail où l’on peut afficher les données et mettre en pratique la pertinence statistique. Le réseau LinkedIn a créé ce qu'il appelle un Developer Insights Hub autour de DPH, lequel facilite la visualisation des données clés, comme le temps d'attente moyen pour l'achèvement d'une construction, ainsi que les éventuelles valeurs aberrantes. Ces informations encouragent les changements. Par exemple, si le temps moyen de construction est trop élevé, l'équipe interne chargée des outils de développement cherchera à améliorer les performances du compilateur et de l'éditeur de liens. Ou encore, si l'approbation d'une demande de téléchargement prend trop de temps, les développeurs pourront essayer de modifier la manière dont ils construisent et soumettent les livraisons. Les possibilités sont nombreuses, car les mesures permettent de comprendre non seulement ce qui se passe au présent, mais aussi ce qui s'est passé dans le passé.

Livrer en open source un framework comme le DPH est une étape importante pour LinkedIn. Grâce à lui, les entreprises pourront déterminer les indicateurs et les mesures qui leur conviennent et partager leurs idées et leurs enseignements avec une communauté plus large. Une chose manque cependant à l'appel : l’annonce d’une communauté DPH formelle. Le travail sur les indicateurs DPH par une communauté interprofessionnelle est important, car il permet aux entreprises de comparer les mesures et de disposer d’un forum pour discuter du lien entre productivité et bonheur des développeurs. Les entreprises ne sont jamais identiques, et la façon dont elles mesurent et ce qu'elles mesurent est différent. Mais elles peuvent utiliser des tableaux de bord similaires en ayant une compréhension commune de la nature statistique de leurs mesures. A voir maintenant si cette communauté se développera - ou pas - dans les prochains mois.