4 min lire
La connaissance est précieuse, mais son véritable pouvoir réside dans la manière dont nous la mettons en pratique. Chez Freyr , nous connaissions bien DevOps, ses pratiques associées et la manière dont 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 du secteur des sciences de la vie. Au début de notre aventure, nos efforts ont permis de poser 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 plus adaptative.
Le principal défi pour traduire les connaissances en actions consiste à savoir quand prendre les bonnes mesures. Étant donné que les actions ont un impact sur de nombreuses personnes dans une organisation, faire la bonne chose au bon moment dépend de notre situation en tant qu'organisation, de nos processus et pratiques actuels, ainsi que des compétences et des capacités de notre personnel.
Cela a marqué un tournant dans notre transformation. En tant qu'éditeur de logiciels spécialisé dans les solutions personnalisées, nous disposions d'une équipe dévouée qui ne ménageait pas ses efforts pour obtenir des résultats. Cependant, nous avons vu une opportunité d'améliorer la qualité, de stimuler la productivité et d'accélérer la conversion des exigences commerciales en produits livrables. Plutôt que de nous concentrer sur des solutions de dernière minute, nous avons cherché à passer d'une résolution réactive des problèmes à une innovation proactive, en élaborant des solutions évolutives et à fort impact.
Nous avions une vision de ce que nous voulions devenir - comment nous voulions travailler, développer, tester, déployer et publier des logiciels. Cependant, nous savions que la réalisation de ces objectifs nécessitait une stratégie réfléchie, un apprentissage continu et un engagement en faveur de l'amélioration.
Aujourd'hui, au cours de l'année écoulée, nous avons réalisé plus de 100 versions avec un taux d'échec de déploiement proche de zéro et nous sommes parvenus à une automatisation presque totale de la mise en œuvre des changements. En outre, nous avons constaté des progrès significatifs en termes de revenus, des équipes plus légères et plus agiles, et une évolution globale vers notre vision de devenir une puissance en matière de produits, de solutions et de services logiciels. Bien qu'il reste encore beaucoup à faire, nous sommes convaincus d'avoir posé des bases solides et d'être prêts à accélérer.
Alors que nous allons de l'avant, 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 tirées. En partageant notre parcours, nous espérons aider d'autres personnes à vivre 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 de diverses ressources DevOps et Agile.
Faire la bonne chose au bon moment
L'un des aspects clés de notre transformation a été l'identification des bonnes actions au bon moment. Avec de multiples initiatives possibles, nous avions besoin d'une approche structurée pour garantir des progrès significatifs.
Avec le recul, nous pouvons regrouper ces actions en trois catégories : Les outils et les processus, l'architecture logicielle et le personnel. Ces catégories sont étroitement liées, les changements apportés à l'une d'entre elles ayant un impact sur les autres. Toutefois, il a été possible de procéder à des changements progressifs dans chaque catégorie et de mesurer les progrès accomplis dans la réalisation de nos objectifs généraux.
Les initiatives dans ces catégories dépendaient souvent les unes des autres. Les changements dans un domaine ouvrent la voie à d'autres améliorations dans un autre domaine.
Les premiers pas
Pour établir une base solide, nous nous sommes concentrés sur trois initiatives fondamentales :
- Intégration de nos bases de code source avec SonarQube pour la mesure de la qualité du code.
- Faire passer toutes les équipes à un outil commun pour gérer les exigences, le code source et les plans de test - dans notre cas, Azure DevOps.
- Structurer les équipes en définissant clairement les responsabilités afin de renforcer l'appropriation et la responsabilisation.
Ces trois initiatives us ont permis us :
- Le travail effectué (exigences et tâches).
- La qualité du code (métriques SonarQube).
- Les personnes impliquées (responsabilités de l'équipe).
Parmi celles-ci, la définition claire des responsabilités de l'équipe a été le plus grand défi. Au départ, les structures des équipes étaient fluides, les personnes se déplaçant d'un projet à l'autre en fonction des 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 de produit existante, qui n'était pas entièrement conçue pour soutenir une propriété claire.
Le rôle de l'architecture logicielle
Nous avons rapidement réalisé que l'architecture du produit était l'un des domaines les plus critiques pour le changement. Une architecture modulaire était essentielle pour permettre à des équipes indépendantes d'assumer la responsabilité de leur travail. Sans cela, nos efforts pour susciter l'adhésion des équipes n'auraient qu'un impact limité.
La réorganisation de notre portefeuille a été un processus complexe. Il s'agissait notamment de passer entièrement au cloud et de commencer à construire des applications cloud-natives à l'aide d'une architecture microservices. Ce sujet sera abordé dans un prochain article. Ce qu'il faut retenir, cependant, c'est que les changements sont progressifs et que certaines étapes doivent précéder d'autres afin de dégager des avantages et de progresser davantage.
Mesures et amélioration continue
Après avoir commencé à travailler sur la réarchitecture (un projet en cours), nous nous sommes concentrés sur le suivi des mesures et la fixation d'objectifs:
- Mesures de la qualité du code dans SonarQube.
- Mesures d'intégration du code dans Azure DevOps.
- Mesures de débit pour les équipes individuelles.
- Adoption de services natifs pour l'informatique en nuage.
Ces objectifs n'étaient pas des mandats stricts, mais des objectifs directeurs destinés à aider les équipes à aligner leurs efforts.
Renforcer l'autonomie des personnes
Une fois les mesures en place, il est devenu évident que les équipes avaient besoin de soutien pour atteindre ces objectifs. Par exemple, s'il était facile de fixer des objectifs pour la couverture des tests unitaires et l'automatisation des tests d'API, il était difficile de les atteindre, en particulier pour les codes hérités qui n'avaient pas été conçus pour être testables.
Pour y remédier, nous :
- Fixer des objectifs moins élevés pour les codes hérités.
- Organisation d'ateliers et de formations pratiques sur l'écriture de tests unitaires de qualité et la conception d'un code testable.
- Fournir des conseils sur l'élaboration de stubs pour les tests d'API.
- Examen des tests unitaires par des architectes chevronnés.
Le triangle des outils, de l'architecture et des personnes
La gestion du code et du référentiel constitue un bon exemple de l'interaction entre ces catégories. L'intégration de SonarQube, qui constitue une amélioration de l'outillage, a révélé une faible couverture des tests unitaires, ce qui a mis en évidence des problèmes architecturaux limitant la testabilité. Les améliorations apportées à l'architecture et aux compétences de l'équipe ont permis d'obtenir des tests unitaires de meilleure qualité, mais ceux-ci n'étaient pas exécutés régulièrement en raison de mauvaises pratiques de branchement. Nous avons remédié à ce problème en normalisant les stratégies de branchement et en garantissant l'intégration régulière du code dans la branche principale, ce qui a permis aux pipelines de CI d'exécuter tous les tests.
La bonne séquence de changement
L'une des approches de la transformation consiste à mettre en œuvre les meilleures pratiques sans discernement. Bien que cela puisse apporter des avantages, les résultats ne justifient souvent pas les efforts déployés, ce qui entraîne une certaine frustration.
Nous avons suivi une approche différente, basée sur le principe du flux: analyser le processus de bout en bout, identifier les goulets d'étranglement et les éliminer progressivement.
Chaque amélioration a révélé de nouveaux goulets d'étranglement, nécessitant de nouvelles actions. Il ne s'agissait pas d'un jeu de "whack-a-mole", mais d'un processus délibéré consistant à faire ce qu'il faut au moment où il le faut.
Par exemple, imposer la couverture des tests unitaires sans améliorer la conception du code aurait conduit à la frustration et au "théâtre de la couverture" (tests superficiels rédigés pour satisfaire aux exigences). En nous attaquant d'abord à l'architecture et aux compétences, nous nous sommes assurés de réaliser des progrès significatifs.
Perspectives d'avenir
Une véritable transformation n'est pas le fruit d'un seul grand changement, mais de décisions intelligentes et opportunes qui entraînent des progrès continus. Nous sommes ravis de partager notre parcours et nos connaissances afin d'aider d'autres personnes à naviguer sur leur propre chemin vers un changement évolutif et à fort impact.
Dans les prochains articles de cette série intitulée « DevOps for the Win », nous analyserons chaque phase de notre transformation dans le triangle DevOps (outils, architecture et personnel) qui us a aidés us des résultats durables.
