Les premières étapes de notre transformation DevOps

Dans le deuxième chapitre de cette série – DevOps pour la victoire, nous explorons les premières étapes cruciales d'un parcours de transformation DevOps. Les premières étapes de tout parcours de transformation sont souvent les plus difficiles. Dans le DevOps, identifier les bonnes premières étapes – celles qui sont à la fois percutantes et réalisables – est essentiel pour générer des progrès significatifs.

De nombreuses organisations commettent l'erreur d'implémenter aveuglément les meilleures pratiques sans tenir compte de leurs contraintes uniques, ce qui conduit souvent à la frustration et à la lassitude face à l'échec. Au lieu de cela, une approche plus stratégique est nécessaire – une approche qui identifie les goulots d'étranglement et les élimine systématiquement.

Comment identifier les premières étapes ?

Un principe puissant pour identifier par où commencer provient d'une recherche publiée il y a 30 ans dans Le But : Un processus d'amélioration continue d'Eliyahu M. Goldratt. L'idée est simple : identifier le goulot d'étranglement principal – le facteur limitant qui restreint les performances du système. Dans notre cas, cela est devenu évident lorsque nous avons vu le travail s'accumuler au sein de l'équipe de développement. Les tâches étaient commencées mais non terminées, et le carnet de commandes ne cessait de croître.

Pour découvrir les causes profondes, nous avons organisé des sessions d'analyse approfondie avec les équipes de développement, les responsables techniques et les chefs de produit. Ces discussions ont mis en évidence plusieurs problèmes clés :

• Les équipes prenaient en charge de nouvelles tâches avant d'avoir achevé les tâches existantes.
• Il n'existait pas de critères clairs d'achèvement des tâches – ce que les développeurs considéraient comme « terminé » différait souvent des attentes des parties prenantes.
• Il n'y avait aucune mesure objective de qualité avant de considérer le travail comme terminé, ce qui entraînait des défauts et des retouches.
• Les réaffectations fréquentes ont perturbé la stabilité de l'équipe, entraînant des inefficacités.

Mettre en place des équipes stables.

L'une des premières mesures correctives a été la restructuration des équipes pour assurer la cohérence et la concentration. Au lieu de traiter les groupes d'individus comme des groupes de travail ad hoc, nous avons formé des équipes stables et durables avec des responsabilités clairement définies.

La mise en place de certaines équipes, comme les équipes de développement, a été relativement simple. Cependant, l'organisation des équipes de support – telles que l'infrastructure, la gestion de projet, la gestion de produit et l'analyse commerciale – s'est avérée plus complexe. Nous avons procédé à plusieurs ajustements pour trouver les bonnes combinaisons.

En suivant le principe de la pensée axée sur l'équipe décrit dans Team Topologies par Matthew Skelton et Manuel Pais, nous :

• Création de petites équipes autonomes (4 à 7 membres) pour promouvoir une expertise approfondie du domaine et la responsabilisation.
• Élimination des dépendances inter-équipes en s'assurant que les individus étaient entièrement affectés à une seule équipe.
• Nous avons revu les structures d'équipe, en particulier pour les fonctions de soutien comme l'infrastructure et la gestion des produits, afin d'optimiser le flux.

Utiliser des outils pour une meilleure visibilité et gestion

Une fois les équipes structurées, nous sommes passés à Azure DevOps pour la gestion du backlog et du travail. Une plateforme unifiée a permis :

• Meilleure visibilité du travail afin que les équipes puissent suivre les progrès de manière transparente.
• Définitions standardisées de l'état « terminé » pour harmoniser les attentes entre les différentes fonctions.
• Amélioration de la gestion de l'arriéré, réduisant l'extension du périmètre et les conflits de priorités.

Mettre en œuvre des indicateurs de qualité objectifs

Pour résoudre le problème des mesures de qualité peu claires avant de marquer les tâches comme « prêtes pour les tests », nous avons intégré un outil d'analyse statique de code, fournissant des informations objectives sur :

• Couverture de code
• Vulnérabilités de sécurité
• Défauts de code

Nous avons également amélioré notre définition de « terminé » afin de faire des contrôles qualité une étape obligatoire avant de marquer les éléments de travail comme achevés.

Gérer les travaux en cours (WIP)

L'un des changements les plus marquants a été le suivi et la limitation du travail en cours (WIP). Un WIP élevé indiquait des goulots d'étranglement, nous permettant d'aborder de manière proactive les domaines où le travail stagnait.

Cette approche systématique, ancrée dans The Goal et Team Topologies, a jeté les bases de l'amélioration continue, réduisant les dépendances et améliorant la responsabilisation.

Dans notre parcours de transformation DevOps, l'une des réalisations les plus importantes a été qu'après les améliorations initiales, la principale contrainte au flux s'est déplacée vers la conception logicielle, plus précisément la testabilité de notre code. Après avoir résolu les goulots d'étranglement initiaux en améliorant la configuration de l'équipe, en définissant une « Définition de Terminé » et en mettant en œuvre l'analyse de code, nous avons remarqué que le travail s'accumulait pendant la phase de test. Le code développé par les équipes Scrum attendait souvent d'être testé par les membres de l'assurance qualité (QA) au sein des mêmes équipes Scrum.

S'attaquer au prochain goulot d'étranglement : la lacune en matière de tests

Une fois les goulots d'étranglement initiaux résolus, une nouvelle contrainte est apparue : les retards de test. Alors que les tâches de développement progressaient efficacement, les tests sont devenus un obstacle, empêchant des livraisons plus rapides. Après enquête, nous avons identifié les défis clés qui ralentissaient le processus :

• Dépendance aux tests manuels : La plupart des tests ont été exécutés manuellement, ce qui a entraîné des boucles de rétroaction lentes et une détection tardive des défauts.
• Dépendance de l'interface utilisateur (UI) dans les tests : Étant donné que les composants de l'interface utilisateur (UI) étaient généralement finalisés en dernier, les tests ne pouvaient commencer que tard dans le cycle de développement.
• Manque d'automatisation proactive : Les tests automatisés, tels que les tests d'interface utilisateur basés sur Selenium, n'étaient écrits qu'après les tests manuels, limitant leur efficacité dans la validation précoce.

Passage aux approches axées sur le test.

Pour briser ce goulot d'étranglement, nous avons priorisé les tests unitaires et les tests d'API par rapport aux tests d'interface utilisateur (UI). Ce changement a nécessité des modifications fondamentales dans l'état d'esprit de développement et la conception logicielle :

Améliorations des tests d'APIs

Pour rendre les tests d'API efficaces :

1. APIs bien définies : Les APIs devaient être simples, bien documentées et disponibles dès le début de la phase de développement afin que les testeurs puissent créer des cas de test de manière proactive.
2. Éviter d'utiliser la base de données comme point d'intégration:
   • L'utilisation de bases de données comme point d'intégration entre les équipes a créé des dépendances qui ont ralenti les tests.
   • La création de cas de test nécessitait la mise en place de bases de données avec des données complexes, ce qui augmentait le temps de configuration et limitait la capacité à tester plusieurs scénarios.
   • En passant à l'intégration basée sur des API (principalement REST sur HTTP et, plus récemment, GraphQL), nous avons considérablement réduit les retards et les complexités causés par les dépendances de bases de données.

Ce changement a permis des progrès plus rapides dans l'automatisation des cas de test pour les APIs, démontrant que l'accent mis sur les conceptions API-first a amélioré à la fois la testabilité et l'efficacité.

Renforcement des pratiques de tests unitaires

Les tests unitaires ont posé un défi plus important :

• Progrès rapides, puis des tests de façade : Initialement, nous avons atteint des niveaux élevés de couverture de code, mais les revues de code ont révélé que de nombreux tests unitaires étaient superficiels, écrits uniquement pour atteindre les objectifs de couverture. Ces tests n'ont pas permis de vérifier des fonctionnalités significatives, de couvrir les scénarios d'échec ou de valider les cas limites.
• Changer les mentalités : Les développeurs devaient comprendre la valeur des tests unitaires, non seulement pour améliorer la qualité du code, mais aussi pour accélérer le développement en détectant les problèmes tôt.

Défis liés à la rédaction de code testable

Le plus grand obstacle aux tests unitaires efficaces était le manque de testabilité dans la base de code elle-même. Les problèmes clés comprenaient :

• Fonctions larges et monolithiques.
• Composants étroitement couplés.
• Mauvaise séparation des préoccupations.
• Abstraction insuffisante.

Ces problèmes rendaient difficile l'isolement et le test efficace des unités individuelles. Pour y remédier, nous avons :

1. Fournir des lignes directrices: Nous avons partagé les meilleures pratiques concernant :
   • Sélection des fonctions pour les tests unitaires.
   • Refactoriser le code pour améliorer la testabilité.
   • Concevoir et utiliser des maquettes pour faciliter les tests.
2. Axé sur les améliorations progressives : Les développeurs ont été encouragés à apporter des changements petits mais significatifs pour améliorer la testabilité au fil du temps.

Progrès, défis et perspectives d'avenir

Pour les produits existants, l'amélioration de la testabilité est restée un processus lent en raison de contraintes architecturales. Cependant, ces actions ne visaient pas seulement à améliorer la base de code actuelle, elles représentaient un investissement pour l'avenir :

• Les développeurs ont adopté de meilleures habitudes, intégrant la testabilité dans les nouvelles bases de code.
• Les équipes sont devenues plus autonomes, réduisant ainsi leur dépendance à l'égard des efforts externes de QA.
• L'organisation a évité de répéter les erreurs passées, garantissant que les futurs produits seraient plus faciles à maintenir et à faire évoluer.

Le point essentiel à retenir ? DevOps ne consiste pas à mettre en œuvre des outils ou des listes de contrôle. Il s'agit d'améliorer continuellement le flux de travail, une contrainte à la fois.

Dans le prochain chapitre de cette série, nous explorerons « Concevoir pour la testabilité ». Nous approfondirons la manière dont l'amélioration de la conception logicielle peut supprimer les contraintes de test, permettant des boucles de rétroaction plus rapides et une meilleure qualité logicielle – d'abord dans les structures d'équipe, ensuite dans la gestion des flux de travail, et enfin dans la testabilité – nous posons ainsi les bases d'une transformation DevOps durable.