Construire l’autonomie des équipes d’ingénierie logicielle | de Yury Fedoseev | janvier 2023

Donner aux ingénieurs l’autonomie conduit à une motivation, une productivité et un investissement accrus dans la réussite de leurs projets et de l’organisation

Aujourd’hui, les équipes de génie logiciel souhaiteraient plus d’autonomie. L’autonomie apporte de nombreux avantages, notamment en rendant les ingénieurs plus heureux et en les aidant à se concentrer sur le codage. Rapport annuel sur l’état des développeurs d’Atlassian 2022confirme ceci :

« Les développeurs ayant une plus grande autonomie sont également plus susceptibles de consacrer leur temps à des activités liées au code ainsi qu’à l’apprentissage de nouvelles compétences techniques. Ceux qui ont moins d’autonomie sont plus susceptibles de communiquer et de se coordonner plus fréquemment avec leur équipe, mais ont tendance à travailler moins souvent sur du code. »

Selon Daniel Pink, l’autonomie est l’un des trois facteurs de motivation intrinsèques décrits dans son livre « Conduire : la vérité surprenante sur ce qui nous motive« , publié en 2009. L’autonomie permet aux individus de contrôler leur propre vie et leur travail et d’utiliser leur jugement et leur créativité pour résoudre des problèmes et accomplir des tâches. Lorsque les gens sont autonomes, ils sont plus susceptibles d’être engagés, créatifs et motivés, ce qui se traduit par une amélioration des performances et des résultats.

En génie logiciel, l’autonomie fait référence à la capacité d’une équipe à fonctionner de manière indépendante et à prendre des décisions de manière indépendante, sans avoir besoin d’être constamment guidé ou supervisé par la direction ou d’autres parties externes. Cela peut inclure la définition de leurs propres objectifs, la hiérarchisation de leur travail et la détermination des meilleures méthodes et outils pour accomplir les tâches. L’autonomie peut être bénéfique pour les équipes d’ingénierie car elle leur permet d’être plus efficientes et efficaces et favorise un sentiment d’appartenance et de responsabilité parmi les membres de l’équipe. Cependant, il est important d’avoir une communication et des lignes directrices claires en place pour s’assurer que l’équipe est alignée sur les buts et objectifs généraux de l’organisation.

Construire l’autonomie des équipes logicielles est un parcours qui dépasse souvent la responsabilité d’une équipe. Dans de nombreux cas, cela nécessite de modifier l’architecture et de mettre en œuvre des changements organisationnels.

Autonomie et dépendance sont souvent considérées comme des concepts opposés. Pour atteindre une plus grande autonomie, il est important d’identifier et de classer les dépendances entre les équipes. Il existe deux types de dépendances à prendre en compte : les dépendances logicielles et matérielles.

Les dépendances souples font référence à des relations moins critiques qui peuvent être ajustées ou modifiées sans impact majeur. D’autre part, les dépendances dures sont essentielles et ne peuvent être modifiées sans conséquences importantes. Lorsque l’interface d’interaction de l’équipe est bien définie, la différence entre ces types est claire. Dans la plupart des cas, il est facile de définir le type de ces dépendances.

Les dépendances dures nécessitent des interactions et des communications constantes entre les équipes basées sur l’architecture ou le SDLC pour offrir de la valeur aux clients finaux. Les dépendances souples, en revanche, ne nécessitent pas d’interactions continues entre les équipes. La communication peut toujours avoir lieu, mais elle sera nettement moins fréquente qu’avec les dépendances matérielles.

Les dépendances dures peuvent être démontrées par des exemples tels que la communication entre deux équipes. Par exemple, si une équipe est responsable du développement d’applications, comme une application Web, et qu’une autre équipe est responsable de l’assurance qualité, les priorités et l’arriéré de l’équipe d’assurance qualité auront un impact sur les indicateurs de performance clés de l’équipe de développement d’applications, tels que les délais .

Un autre exemple de dépendance est la relation entre deux équipes, où l’une est responsable du développement d’une application orientée client, telle qu’une boutique en ligne, et l’autre est responsable du développement d’un système de paiement. Cette dépendance peut être considérée comme une dépendance souple, car les modifications apportées à l’application de la boutique en ligne ne nécessitent généralement pas toujours de modifications du système de paiement.

Après avoir identifié et catégorisé les dépendances entre les équipes, la prochaine étape pour atteindre l’autonomie de l’équipe consiste à minimiser les dépendances matérielles. Celles-ci découlent souvent de la conception de systèmes sans tenir compte de l’objectif final de créer un produit orienté client. La mise en œuvre de certains modèles peut réduire considérablement le nombre de dépendances matérielles entre les équipes.

Développement full-stack

Lors du développement d’un produit avec un composant d’interface utilisateur, comme une application Web ou mobile, il doit y avoir une communication et une intégration transparentes entre le front et le backend. Si la plupart des fonctionnalités du produit dépendent fortement de cette communication, il est plus efficace d’avoir une seule équipe responsable du développement du frontend et du backend plutôt que d’avoir des équipes distinctes pour le développement du client et du backend.

La formation d’une équipe unifiée avec un ensemble partagé d’objectifs et d’indicateurs de performance clés (KPI) garantit que tous les membres travaillent vers les mêmes objectifs, ce qui accélère le développement et réduit les délais. De plus, cette configuration permet une meilleure collaboration et communication entre les membres de l’équipe, ce qui conduit à une résolution de problèmes plus efficace et à un processus de développement plus rationalisé.

Avoir une seule équipe responsable à la fois du développement frontend et backend d’un produit avec de lourdes exigences d’interface utilisateur améliorera considérablement le processus de développement, réduira les délais et fournira une sortie plus rapide.

Équipe interfonctionnelle

Rassembler toutes les personnes impliquées dans les différentes étapes du cycle de vie du développement logiciel en une seule équipe interfonctionnelle peut grandement bénéficier au développement de produits. Cette approche implique de combiner des individus de différents rôles et disciplines, tels que des chefs de produit, des ingénieurs et des ingénieurs d’assurance qualité (QA), en une seule équipe responsable du développement du produit.

L’un des principaux avantages de cette approche est qu’elle permet une intégration plus transparente de l’AQ dans le processus de développement. Les ingénieurs AQ peuvent fournir des informations précieuses sur les hypothèses de produit et négocier avec les autres membres de l’équipe, y compris les chefs de produit et les ingénieurs, pour s’assurer que le produit final répond à toutes les normes de qualité.

De plus, l’intégration d’ingénieurs et de pratiques DevOps dans l’équipe peut grandement bénéficier au processus de développement. Le fait que les ingénieurs DevOps travaillent en étroite collaboration avec le reste de l’équipe garantit que le produit est développé en tenant compte du déploiement et que le produit final est prêt pour la production lorsqu’il est expédié.

Dans l’ensemble, le fait d’avoir une équipe interfonctionnelle responsable du développement de produits permet une approche plus ciblée du développement, mettant l’accent sur les résultats plutôt que sur les résultats. Cette approche permet une meilleure collaboration, communication et résolution de problèmes entre les membres de l’équipe, ce qui conduit à un processus de développement plus efficace et à un produit final de meilleure qualité.

Propriété du code

En ce qui concerne les meilleures pratiques pour la constitution d’équipes autonomes, un aspect important à prendre en compte est la façon dont les équipes sont organisées au niveau du code source. L’une des méthodes les plus recommandées pour développer des logiciels consiste à isoler les équipes au niveau du code, ce qui signifie que chaque équipe doit avoir ses propres référentiels de code. Cela permet aux équipes de travailler de manière indépendante et d’avoir plus de contrôle sur leur propre base de code.

Cependant, dans certains cas, avoir plus de personnes travaillant sur le même projet peut être nécessaire. Un exemple de ceci est lorsque le projet est une application monolithique. Dans ce cas, la mise à jour des dépendances peut être plus difficile car tous les ingénieurs travaillant sur l’application doivent être informés de la mise à jour. De plus, il peut être presque impossible d’isoler des équipes pour travailler sur leurs propres domaines au sein d’une application monolithique.

Dans de tels cas, la meilleure approche consiste à isoler les domaines au sein de l’application monolithique et à créer des référentiels distincts pour chaque domaine, chaque référentiel étant détenu et géré indépendamment par une équipe spécifique. Cela permet aux équipes d’avoir plus de contrôle sur leur propre base de code et de travailler de manière indépendante sans affecter les autres équipes.

Diffusion des données

Dans le paysage technologique actuel, la plupart des architectures modernes sont basées sur la construction de systèmes distribués, qui s’appliquent également aux données. Les systèmes complexes comportent souvent plusieurs copies de données, chacune adaptée aux besoins spécifiques des différentes équipes. Par exemple, une équipe responsable de la recherche peut disposer de sa propre copie des données stockées dans Elasticsearch, tandis qu’une équipe de machine learning peut avoir besoin d’une réplique des données d’origine dans un stockage OLAP ou d’un sous-ensemble de données créé via des événements pour exécuter ses expériences.

L’utilisation du stockage partagé entre les équipes peut entraîner plusieurs problèmes, tels que des modifications de schéma inattendues et le provisionnement de ressources insuffisantes. Cela peut entraîner des perturbations dans les systèmes de production et réduire considérablement l’autonomie des équipes. Par conséquent, il est important de fournir aux différentes équipes des solutions de stockage dédiées qui répondent à leurs besoins spécifiques et leur permettent de travailler de manière autonome sans affecter les autres équipes. Cette approche donne également aux équipes plus de contrôle sur leurs données, ce qui se traduit par de meilleures performances et un développement plus rapide.

Lors de la création de systèmes distribués, il est essentiel de prendre en compte les besoins en données des différentes équipes et de leur fournir des solutions de stockage dédiées qui répondent à leurs besoins spécifiques. Cette approche permet de s’assurer que les équipes peuvent travailler de manière indépendante et efficace et protège l’intégrité des systèmes de production.

La tendance des ingénieurs logiciels à rechercher plus d’autonomie dans leur travail reflète le désir de s’approprier davantage leurs projets. En offrant aux ingénieurs plus d’autonomie, les managers peuvent les aider à s’approprier leurs projets, ce qui conduit à une plus grande motivation et productivité. Cela peut avoir un impact positif sur l’ensemble de l’organisation, car les ingénieurs investiront davantage dans la réussite de leurs projets et de l’entreprise dans son ensemble.

Les managers jouent un rôle crucial en aidant à créer un environnement qui permet aux ingénieurs de travailler de manière plus autonome et d’augmenter la productivité. J’espère que cet article a fourni des informations et une inspiration précieuses aux gestionnaires et aux ingénieurs qui cherchent à créer des systèmes autonomes et à augmenter la productivité de leurs organisations.