4 ressources sur la productivité des équipes logicielles que tout le monde devrait connaître

Tout au long de ma carrière technologique, j’ai rencontré une multitude de personnes idéalistes qui croient que suivre l’idée X ou la méthodologie Y transformera d’une manière ou d’une autre comme par magie une équipe ou une organisation. En réalité, si vous voulez rendre les équipes logicielles plus productives, il n’y a pas de solution miracle.

Chaque organisation logicielle est différente. Les gens viennent de cultures et de circonstances différentes. Ils ont des niveaux d’expérience, des motivations et des personnalités différents.

La seule véritable voie à suivre est un processus incessant d’amélioration progressive :

1. Identifier les goulots d’étranglement
2. Expérimenter avec une solution possible
3. Mesure
4. Analyser
5. Répéter

C’est un conseil simple, mais difficile à mettre en pratique. L’un des plus grands défis de ce processus d’amélioration continue est d’identifier ce que vous devez mesurer et quel type de comportement vous devez favoriser.

Les quatre ressources de cet article vous donneront des conseils fiables qui vous aideront à apporter des améliorations significatives à votre organisation.

Projet Aristote : Comprendre l’efficacité d’une équipe

Si vous avez entendu dire que la « sécurité psychologique » est le facteur le plus important pour créer des équipes productives, vous avez entendu parler du projet Aristote. Le projet Aristote est la recherche de Google la plus connue et la plus citée sur ce qui rend une équipe efficace.

La principale conclusion de cette recherche : la façon dont les équipes travaillent ensemble est plus importante que qui fait partie de l’équipe.

Les cinq dynamiques clés qui affectent l’efficacité de l’équipe, par ordre de priorité, sont :

• Sécurité psychologique : Les membres de l’équipe se sentent en sécurité pour prendre des risques et être vulnérables les uns devant les autres.
• Fiabilité: Les membres de l’équipe font les choses à temps avec le niveau de qualité attendu.
• Structure et clarté : Les membres de l’équipe ont des rôles, des plans et des objectifs clairs.
• Sens: Le travail est personnellement important pour les membres de l’équipe.
• Impacter: Les membres de l’équipe pensent que leur travail est important et crée des changements.

Les chercheurs ont également fourni une liste d’indicateurs d’amélioration pour chaque dynamique clé. Ce sont des signes que votre équipe a besoin d’améliorer une dynamique particulière :

• Sécurité psychologique : Peur de demander ou de donner des commentaires constructifs. Hésitation à exprimer des idées divergentes et à poser des questions « idiotes ».
• Fiabilité: L’équipe a une mauvaise visibilité sur les priorités ou les progrès du projet. Diffusion des responsabilités et pas de propriétaires clairs pour les tâches ou les problèmes.
• Structure et clarté : Manque de clarté sur qui est responsable de quoi. Processus de prise de décision, propriétaires ou justification peu clairs.
• Sens: Affectations de travail basées uniquement sur la capacité, l’expertise et la charge de travail. Il y a peu de considération pour les besoins et les intérêts de développement individuel. Manque de reconnaissance régulière des réalisations ou des jalons.
• Impacter: Encadrer le travail comme « l’eau foulée ». Trop d’objectifs, limitant la capacité de faire des progrès significatifs.

Pour comprendre ce que votre équipe pense de cette dynamique, vous pouvez utiliser cet outil. Il vous donne des questions dont vous pouvez discuter ensemble, ce qui aidera votre équipe à déterminer ses propres besoins et à s’engager à apporter des améliorations.

DORA : quatre indicateurs de performance clés

L’équipe DevOps Research and Assessment (DORA) est un groupe de recherche qui a démarré de manière indépendante en 2014 et fait partie de Google depuis 2019. Ils sont connus pour les rapports annuels « State of DevOps ».

L’équipe DORA a mené sept enquêtes mondiales annuelles entre 2014 et 2021 qui ont collecté des données auprès de plus de 32 000 professionnels du logiciel. À partir de cette recherche, l’équipe DORA a identifié quatre indicateurs de performance clés qui indiquent les performances d’une équipe de développement de logiciels et leur capacité à fournir de meilleurs résultats commerciaux.

Ces quatre « métriques DORA » sont :

• Fréquence de déploiement : La fréquence à laquelle une organisation se déploie en production.
• Délai d’exécution du changement : Le temps nécessaire pour que le code validé s’exécute en production.
• Modifier le taux d’échec : Le pourcentage de déploiements de production entraînant une dégradation du service et de la correction (par exemple, une restauration).
• Temps de restauration du service : Combien de temps faut-il pour corriger une défaillance de production

Les deux premières métriques, la fréquence de déploiement et le délai de changement, mesurent la vélocité de vos équipes d’ingénierie. Les deux secondes, le temps moyen de récupération et de modification du taux de défaillance, indiquent la stabilité. L’un des principaux points de la recherche DORA est que les équipes performantes peuvent améliorer leur vitesse tout en atteignant une grande stabilité.

Les quatre mesures DORA sont la partie la plus populaire et la plus connue de cette recherche. Cependant, il comprend de nombreuses autres informations importantes dont vous devez être conscient lors de l’application des métriques. Par exemple, l’étude répertorie 24 capacités clés en corrélation avec les performances de l’équipe.

La méthodologie de recherche et les résultats du State of DevOps sont expliqués en détail dans le livre Accelerate. C’est une lecture incontournable pour toute personne intéressée à améliorer la productivité de l’équipe d’ingénierie.

Bien que les métriques DORA soient très utiles, vous ne devez pas les considérer comme la seule et unique mesure d’amélioration de l’ingénierie. La recherche est davantage axée sur l’identification des éléments en corrélation avec les performances financières d’une entreprise plutôt que sur une feuille de route pour améliorer l’ingénierie.

SPACE : un cadre pour la productivité des développeurs

SPACE est un framework pour la productivité des développeurs. Il examine la productivité des développeurs du point de vue de différents niveaux organisationnels (individus, équipes/groupes et systèmes) et de différentes dimensions (Ssatisfaction & Bien-être, Pperformance, UNEactivité, Ccommunication et collaboration, et Eefficacité et débit).

Un membre de l’équipe DORA et auteur du livre Accelerate, Nicole Forsgren, a dirigé cette étude. L’objectif de SPACE est de donner une image plus complète et nuancée de la productivité des développeurs au-delà des métriques spécifiques incluses dans DORA.

Le cadre SPACE vise à surmonter les défauts des tentatives antérieures de mesurer la productivité des développeurs. Ces « mythes et idées fausses sur la productivité des développeurs » incluent :

• La productivité dépend de l’activité des développeurs.
• La productivité n’est qu’une question de performance individuelle.
• Une seule mesure de productivité peut tout nous dire.
• Les mesures de productivité ne sont utiles que pour les gestionnaires.
• La productivité ne concerne que les systèmes d’ingénierie et les outils de développement.

Pour contrer ces mythes, le cadre SPACE « fournit un moyen de penser rationnellement à la productivité dans un espace beaucoup plus grand ». Il répertorie cinq dimensions différentes de la productivité des développeurs que vous devriez plutôt mesurer :

• Satisfaction et bien-être : « La satisfaction est la façon dont les développeurs se sentent satisfaits de leur travail, de leur équipe, de leurs outils ou de leur culture ; le bien-être est à quel point ils sont en bonne santé et heureux, et comment leur travail l’impacte. » Des exemples de mesures incluent la satisfaction des employés, l’efficacité des développeurs et l’épuisement professionnel.
• Performance: Essayer de mesurer les performances à travers les résultats conduit souvent à des résultats commerciaux sous-optimaux. Par conséquent, pour le développement de logiciels, les performances sont mieux évaluées en tant que résultats que comme produits. Les exemples de métriques incluent la fiabilité, l’absence de bogues et l’adoption par les clients.
• Activité: Les activités dénombrables qui se produisent lors de l’exécution du travail, telles que les documents de conception, les validations et l’atténuation des incidents, sont presque impossibles à mesurer de manière exhaustive. Par conséquent, vous ne devez jamais les utiliser isolément et les équilibrer plutôt avec des métriques d’autres dimensions.
• Communication et collaboration : Dans quelle mesure les équipes communiquent-elles et travaillent-elles ensemble ? Des exemples de mesures incluent la découvrabilité de la documentation, la qualité des examens et les délais d’intégration pour les nouveaux membres de l’équipe.
• Efficacité et débit : Ceux-ci « capturent la capacité d’achever le travail ou de progresser avec un minimum d’interruptions ou de retards ». Les exemples de métriques incluent le nombre de transferts dans un processus, la capacité perçue à rester dans le flux et les mesures de temps à travers le système (temps total, temps à valeur ajoutée et temps d’attente).

Pour une image plus complète de ce qui se passe dans votre organisation, le cadre SPACE suggère que vous disposiez de métriques pour ces dimensions à trois niveaux différents de votre organisation :

• Individuel
• Equipe ou groupe : Des gens qui travaillent ensemble.
• Système: Travail de bout en bout via un système, par exemple, le pipeline de développement de votre organisation, de la conception à la production.

Les auteurs du framework SPACE fournissent un exemple de tableau avec des métriques pour chaque dimension et niveau d’organisation. Cela vous donne une idée concrète des métriques que vous pourriez avoir dans votre organisation. Les métriques proposées dans l’exemple sont assez centrées sur GitHub. Ceci est naturel car les chercheurs du framework SPACE travaillent principalement chez GitHub et Microsoft (propriétaire de GitHub).

Le tableau d’exemple nous amène à la plus grande force et défi du cadre SPACE : vous devrez vous l’approprier. Il existe plusieurs options pour ce que vous pouvez utiliser comme métrique dans votre organisation, et les métriques que vous choisissez dépendent de ce qui correspond à votre culture et des données dont vous disposez.

Il y a trois choses à garder à l’esprit avec SPACE. Tout d’abord, vous devez inclure des métriques d’au moins trois dimensions. Deuxièmement, vous devez inclure des métriques de tous les niveaux de l’organisation. Troisièmement, au moins une des métriques doit inclure des mesures perceptives telles que des données d’enquête. Inclure les perceptions sur les expériences vécues par les gens peut souvent fournir des informations plus complètes et précises que les mesures recueillies à partir du comportement du système seul.

Lorsque les recommandations ci-dessus seront remplies, vous serez en mesure de construire une image plus complète de la productivité.

Il est également probable que le fait d’avoir plusieurs métriques créera des métriques en tension. C’est par conception. Avoir une vue plus équilibrée devrait vous aider à prendre des décisions et des compromis plus intelligents entre vos équipes et l’ensemble de l’organisation. Cela garantira également que vous n’optimisez pas une seule métrique au détriment de l’ensemble du système.

Si vous souhaitez commencer à appliquer le framework SPACE à votre organisation, vous pouvez consulter notre canevas modifiable gratuit (PDF, Google Docs).

Rétrospectives : on se ment peut-être

Les organisations de logiciels utilisent souvent les rétrospectives comme mécanisme d’amélioration continue. Beaucoup de gens ont hérité de cette pratique d’une veine de la pensée Agile. Certains les retiennent parce qu’ils ont personnellement eu de bonnes expériences avec eux, d’autres parce qu’ils pensent qu’ils « constituent une meilleure pratique ».

Les rétrospectives peuvent être un excellent outil d’amélioration continue, et vous devriez probablement les utiliser sous une forme ou une autre si vous ne le faites pas déjà. Cependant, sachez que les rétrospectives ont leurs limites. Cette étude sur les rétrospectives fait un excellent travail en mettant en évidence certains des défis communs que vous êtes susceptible de rencontrer.

Premièrement, les rétrospectives au niveau de l’équipe sont souvent « faibles de reconnaître les problèmes et les réussites liés aux domaines de processus qui sont extérieurs aux préoccupations des équipes ». Les équipes logicielles parlent ou se plaignent souvent de problèmes au niveau de l’organisation lors de rétrospectives : collaboration avec les ventes, les chefs de produits, la direction générale, etc. Cependant, cette discussion aboutit rarement à des changements tangibles dans l’organisation au sens large.

Si vous souhaitez organiser des rétrospectives efficaces et favoriser le changement, concentrez-vous principalement sur des sujets que l’équipe peut contrôler ou affecter directement. Chaque fois que l’équipe discute régulièrement de sujets en dehors de leur influence directe, assurez-vous que le retour d’information est adressé au niveau de l’organisation, où un véritable changement peut être créé.

Alternativement, la compréhension de votre équipe des objectifs de l’entreprise et de l’organisation environnante peut être incorrecte. Dans ces cas, essayez de fournir plus de contexte à l’équipe.

Deuxièmement, les membres de l’équipe logicielle ont des préjugés. Par exemple, « le développement…