,
4 min de lecture
La connaissance est précieuse, mais sa véritable puissance réside dans la manière dont nous la mettons en action. Chez Freyr Digital, nous étions familiers avec DevOps, ses pratiques associées, et comment il pouvait transformer notre organisation en une puissance de développement de produits hautement performante, capable de fournir des produits et des solutions de qualité à nos clients des sciences de la vie. Au début de notre parcours, nos efforts ont jeté des bases solides, mais pour devenir véritablement une puissance de développement, nous savions que nous devions adopter une approche plus stratégique et adaptative.
Le principal défi pour transformer les connaissances en actions réside dans le fait de savoir quand prendre les bonnes mesures. Étant donné que les actions affectent de nombreuses personnes au sein d'une organisation, faire la bonne chose au bon moment dépend de notre position en tant qu'organisation, de nos processus et pratiques actuels, ainsi que des compétences et des capacités de nos collaborateurs.
Cela a marqué un tournant dans notre transformation. En tant que portefeuille de fournisseurs de logiciels spécialisés dans les solutions personnalisées, nous disposions d'une équipe dédiée qui se surpassait pour obtenir des résultats. Cependant, nous avons identifié une opportunité d'améliorer la qualité, d'augmenter la productivité et d'accélérer la transformation des exigences commerciales en livrables. Plutôt que de nous concentrer sur des corrections de dernière minute, nous avons cherché à passer d'une résolution réactive de problèmes à une innovation proactive, en développant des solutions évolutives et à fort impact.
Nous avions une vision de l'endroit où nous voulions être – comment nous voulions travailler, développer, tester, déployer et publier des logiciels. Cependant, nous savions que l'atteinte de ces objectifs exigeait une stratégie réfléchie, un apprentissage continu et un engagement envers l'amélioration.
Aujourd'hui : au cours de la dernière année, nous avons effectué plus de 100 mises à jour avec quasiment aucun échec de déploiement et avons atteint une automatisation quasi complète dans le déploiement des changements. De plus, nous avons constaté des progrès significatifs en matière de revenus, des équipes plus légères et plus agiles, et une évolution globale vers notre vision de devenir un acteur majeur dans les produits, solutions et services logiciels. Bien qu'il y ait toujours plus à accomplir, nous sommes convaincus d'avoir posé des bases solides et d'être prêts à accélérer.
À mesure que nous avançons, nous prenons un moment pour réfléchir à notre transformation : ce qui a fonctionné, ce qui n'a pas fonctionné et les leçons que nous avons apprises. En partageant notre parcours, nous espérons soutenir ceux qui traversent des changements similaires.
Cette série de blogs est principalement empirique, partageant ce que nous avons fait, tout en reliant nos actions aux meilleures pratiques et recommandations issues de diverses ressources DevOps et Agile.
Faire ce qu'il faut au bon moment
L'un des aspects clés de notre transformation a été d'identifier les bonnes actions au bon moment. Avec de multiples initiatives possibles, nous avions besoin d'une approche structurée pour assurer des progrès significatifs.
En rétrospective, nous pouvons regrouper ces actions en trois catégories : Outils et Processus, Architecture Logicielle et Humain. Ces catégories sont fortement liées, les changements dans l'une ayant un impact sur les autres. Cependant, il a été possible d'apporter des changements progressifs dans chaque catégorie et de mesurer les progrès vers nos objectifs généraux.
Les initiatives dans ces catégories dépendaient souvent les unes des autres. Les changements dans un domaine ouvraient des possibilités d'améliorations supplémentaires dans un autre.
Les premières étapes
Pour établir une base solide, nous nous sommes concentrés sur trois initiatives clés :
- Intégrer nos bases de code source avec SonarQube pour les mesures de qualité du code.
- Déplacer toutes les équipes vers un outil commun pour la gestion des exigences, du code source et des plans de test — dans notre cas, Azure DevOps.
- Structurer les équipes avec des responsabilités claires pour renforcer l'appropriation et la responsabilisation.
Ces trois initiatives nous ont donné une visibilité sur :
- Le travail en cours (exigences et tâches).
- La qualité du code (métriques SonarQube).
- Les personnes impliquées (responsabilités de l'équipe).
Parmi ces défis, la définition de responsabilités d'équipe claires a été la plus complexe. Initialement, les structures d'équipe étaient fluides, les membres se déplaçant d'un projet à l'autre selon les besoins. La transition vers des équipes dédiées avec des domaines fonctionnels distincts était une étape nécessaire, bien que compliquée par notre architecture produit existante, qui n'était pas entièrement conçue pour permettre une attribution claire des responsabilités.
Le rôle de l'architecture logicielle
Nous avons rapidement réalisé que l'architecture produit était l'un des domaines les plus critiques à modifier. Une architecture modulaire était essentielle pour permettre aux équipes indépendantes d'assumer la responsabilité de leur travail. Sans cela, nos efforts pour créer une appropriation par l'équipe étaient limités en impact.
La refonte de l'architecture de notre portefeuille a été un processus complexe. Elle a impliqué une migration complète vers le cloud et le développement d'applications natives du cloud basées sur une architecture de microservices. Ce sujet sera abordé dans un prochain article. Le point essentiel à retenir, cependant, est que les changements sont progressifs, et certaines étapes doivent précéder d'autres pour débloquer des avantages et progresser davantage.
Indicateurs et amélioration continue
Après avoir commencé les travaux de réarchitecture (un effort continu), nous nous sommes concentrés sur le suivi des indicateurs et la fixation d'objectifs :
- Métriques de qualité de code dans SonarQube.
- Métriques d'intégration de code dans Azure DevOps.
- Indicateurs de débit des fonctionnalités pour les équipes individuelles.
- Adoption de services natifs du cloud.
Ces objectifs n'étaient pas des mandats stricts, mais des lignes directrices pour aider les équipes à coordonner leurs efforts.
Autonomiser les personnes
Avec des métriques en place, il est devenu évident que les équipes avaient besoin de soutien pour atteindre ces objectifs. Par exemple, si la fixation d'objectifs pour la couverture des tests unitaires et l'automatisation des tests d'API était simple, les atteindre était difficile, surtout pour le code hérité qui n'avait pas été conçu pour la testabilité.
Pour y remédier, nous avons :
- Fixer des objectifs plus bas pour le code hérité.
- Ateliers organisés et formations pratiques sur la rédaction de tests unitaires de qualité et la conception de code testable.
- Fournir des conseils sur la création de stubs pour les tests d'API.
- Réalisation d'examens des tests unitaires par des architectes seniors
Le triangle des outils, de l'architecture et des personnes
Un bon exemple de l'interaction entre ces catégories était la gestion du code et des dépôts. L'intégration avec SonarQube, une amélioration des outils, a révélé une faible couverture des tests unitaires, ce qui a mis en évidence des problèmes d'architecture limitant la capacité à être testé. Des améliorations de l'architecture et des compétences de l'équipe ont conduit à des tests unitaires de meilleure qualité, mais ceux-ci n'étaient pas exécutés régulièrement en raison de mauvaises pratiques de gestion des branches. Nous avons résolu ce problème en standardisant les stratégies de gestion des branches et en assurant une intégration régulière du code dans la branche principale, permettant aux pipelines d'intégration continue (CI) d'exécuter tous les tests.
La bonne séquence du changement
Une approche de la transformation consiste à mettre en œuvre des meilleures pratiques sans discernement. Bien que cela puisse apporter des avantages, les résultats ne parviennent souvent pas à justifier l'effort, ce qui entraîne de la frustration.
Nous avons adopté une approche différente, basée sur le principe de flux : analyser le processus End-to-End, identifier les goulots d'étranglement et les résoudre progressivement.
Chaque amélioration a révélé de nouveaux goulots d'étranglement, nécessitant des actions supplémentaires. Il ne s'agissait pas d'un jeu de « tape-taupe », mais d'un processus délibéré consistant à faire la bonne chose au bon moment.
Par exemple, imposer une couverture de tests unitaires sans améliorer la conception du code aurait entraîné de la frustration et un « théâtre de couverture » (des tests superficiels écrits pour atteindre des métriques). En abordant d'abord l'architecture et les compétences, nous avons assuré des progrès significatifs.
Perspectives d'avenir
La véritable transformation ne consiste pas en un seul grand changement, mais en des décisions intelligentes et opportunes qui favorisent un progrès continu. Nous sommes ravis de partager notre parcours et nos connaissances pour aider les autres à naviguer sur leur propre chemin vers un changement évolutif et à fort impact.
Dans les prochains blogs de cette série - DevOps pour la victoire, nous détaillerons chaque phase de notre transformation dans le Triangle DevOps - Outils, Architecture et Personnes - qui nous a aidés à obtenir un impact durable.
