Je devais faire quelque chose.
Les ingénieurs de développements étaient aveugles après leur environnement de test. Les équipes de production faisaient face à des incidents sans connaissance des applications.
Les responsables des releases avaient la pression de déployer des changements logiciels comme des patates chaudes à l’étape suivante, ne laissant aucun temps pour la révision, encore moins pour des tests.
C’était le bord**.
Tout le monde était frustré, y compris les plus importants : nos utilisateurs.
L’initiative a été menée chez La Redoute, l’e-commerçant approchant le milliard de revenus ayant plusieurs fois réapparu de ses cendres, aujourd’hui en croissance.
Je dirigeais une équipe d’ingénieurs back-end de plus de 70 personnes lorsque j’ai décidé de concentrer l’équipe sur un objectif commun : le pipeline de livraison.
Cet article partage une expérience concrète d’évolution d’une organisation existante pour délivrer du Quality Engineering.
Suivez la QE Unit pour plus de Quality Engineering de la communauté.
Créer un sentiment d’urgence autour d’un objectif commun simple
La simplicité permet de concentrer les efforts. La première chose était de rallier les acteurs autour d’un objectif commun créant un sentiment d’urgence.
J’ai d’abord recherché des faits internes, tels que des incidents récents avec des impacts sur les clients, des temps de résolution lents, montrant des problèmes factuels dans les processus.
Un benchmark externe utilisant Accelerate a complété l’approche pour démontrer notre écart par rapport à une norme de marché connue, impactant également l’entreprise.
Avec tous les changements à venir, nous devions changer.
Focaliser les méthodologies sur les facteurs limitants
J’ai décidé de concentrer l’équipe sur la pipeline étant un facteur limitant qui accumulait trop de dettes organisationnelles et techniques.
Le message était de fournir la Quality at Speed sans dépendre d’un projet technique, en suivant ces principes :
- Mesurer le résultat business ;
- Déployer au moins une fois par jour ;
- Livrer avec stabilité, récupérer rapidement.
La contrainte de déploiement quotidien a généré la plupart des réclamations : « Impossible avec les étapes manuelles », « Trop risqué aujourd’hui », « Le métier ne peut pas tester tous les jours ».
C’était effectivement les problèmes à résoudre.
J’ai ensuite sélectionné deux principaux ensembles de méthodologies à mettre en œuvre :
- Lean software factory
- Développement en trunk-based development ;
- Pipelines standard de CI/CD ;
- Automatisation des tests (unitaire, fonctionnel, intégration).
- Lean software measurement
- Observabilité ;
- Métriques business ;
- Métriques Accelerate.
Ensuite seulement, il était temps de parler de technologie.
Utilisez l’architecture pour soutenir des processus systématiques
L’usine logicielle que nous avions construite avait des pipelines CI/CD avec différents environnements; c’est leur conception qui laissait à désirer.
Les ingénieurs logiciels n’avaient pas accès au déploiement après le premier environnement de test ; les environnements restants étaient réservés à l’équipe opérationnelle en raison des processus hérités.
Je pense que l’autonomie fait la différence.
Les rôles ont été distribués pour permettre aux développeurs d’itérer jusqu’à la production, en maintenant les étapes d’approbation pour l’entreprise ou le team lead pour des exigences d’audit.
L’étape suivante consistait à augmenter les exigences de test des Quality Gates avec :
- Un temps de build maximal pour cycle-time rapide et tests unitaires minimaux ;
- Un nombre minimum de tests fonctionnels pour assurer leur présence ;
- Des sanity-checks systématiques avant et après le déploiement pour feedback rapides.
Nous passons ensuite aux mesures logicielles Lean, en commençant par « Mesurer le résultat business ».
Utiliser la technologie pour soutenir les résultats business
L’équipe des opérations assurait la majeure partie de la surveillance avec des tableaux de bord techniques basés sur l’infrastructure.
Les métriques business ont poussé les développeurs vers les impacts pour les utilisateurs en dehors de leur environnement de développement- les responsables des opérations ont commencé à regarder la même chose.
La réalisation de « Livrer avec stabilité, récupérer rapidement » a été mesurée avec les métriques Accelerate sur des tableaux de bord standard.
Je me suis appuyé sur un ingénieur motivé pour construire un tableau de bord d’observabilité simple mais standard avec diverses métriques.
Il était alors temps de conduire ces changements.
Piloter l’équipe en responsabilisant sur les résultats
De l’ingénierie à l’exploitation, les équipes ont besoin de sécurité psychologique pour devenir de véritables unités de Quality Engineering.
J’ai assumé l’entière responsabilité si quelque chose n’allait pas, quels que soient l’origine les problèmes d’ingénierie: mon équipe ou celle de production.
« L’échec était acceptable, sauf celui de l’amélioration continue. »
Antoine Craske
Nous avons également précisé aux team lead que le pouvoir d’itérer jusqu’à la production s’accompagne de la responsabilité d’en assurer les opérations.
L’exigence suivante était de donner le rythme.
Définir le rythme avec des jalons minimaux
Les équipes avaient 90 jours pour améliorer leur performance, en alignant le statut et les plans d’action sur une réunion hebdomadaire de 30 minutes.
Les composants logiciels étaient évalués selon leur état de compatibilité avec l’architecture pour ensuite en évaluer la performance.
Objectif simple, question simple : « Déployez-vous quotidiennement ?
Nous avons utilisé des tableaux de bord d’entreprise pour lier les outputs aux outcomes, en veillant à ce que les applications disposent des métriques disponibles et avec des ratios de suivi.
Notre approche Lean a permis des résultats plus rapides.
Nous avons accepté le compromis de ne pas avoir tout ce que nous voulions – nous ne mesurions pas le change fail rate– le délai, le cycle et la stabilité étaient suffisants.
Les réalisations de résultats ont permis aux premières victoires de célébrer avec l’équipe; d’abord en petits groupes, puis au sein de l’organisation.
Les ambassadeurs étaient un moyen d’influencer l’organisation en évolution.
Aligner la structure organisationnelle pour des interactions précieuses
La structure organisationnelle détermine les sources de pouvoir. Des changements sont nécessaires pour réussir après les premières victoires avec le modèle existant.
Auparavant, le pouvoir était clairement pour les équipes opérationnelles chargées de la production, créant des goulots d’étranglement dans le flux de modifications logicielles.
L’adaptation de l’organisation s’est concentrée sur une collaboration viable minimale:
- Des équipes, composants et flux en domain-driven ;
- Gestion centralisée á décentralisée du release management ;
- Automatisation avec self-service et API.
Les messages visuels sont également importants.
Voir ci-dessous les équipes logicielles allant en production avec les équipes de plate-forme et d’infrastructure en soutien.
Une entreprise a un budget limité. Changer une structure organisationnelle nécessite de choisir entre des ressources dédiées ou partagées :
- Dédié pour les équipes alignées sur le value-stream flux par domaine, nécessitant une itération rapide sans hand-over, et où le temps d’inactivité favorise la vélocité ;
- Partagé pour les équipes fournissant des composants réutilisables pour d’autres équipes, soit en isolant une complexité spécifique (par exemple middleware, DBA).
Dans le cadre de ces changements, nous avons également clairement affecté un ingénieur QA et un contact de support de la plate-forme à chaque équipe.
L’étape suivante consistait à mesurer les flux de la structure organisationnelle.
Aligner l’organisation sur les flux système souhaités
Les déploiements quotidiens imposent une contrainte pour rationaliser les activités nécessaires à la réalisation d’un objectif particulier.
Le value-stream était essentiel pour éliminer les facteurs limitants, en se concentrant sur l’expérience du développeur pour obtenir des changements rapides et stables.
La responsabilité de l’expérience développeur a été définie entre l’équipe de la plateforme pour fournir les moyens nécessaires et les chefs d’équipe pour s’améliorer en permanence.
J’ai fixé un objectif d’équipe global pour la livraison quotidienne, en clarifiant la priorité partagée. De plus, j’ai fixé des objectifs de Quality at Speed en objectifs individuels.
L’alignement des incentives du système est nécessaire pour étendre les changements organisationnels.
Les départements produits et opérations n’étaient pas alignés sur ces mêmes objectifs, créant des frictions limitant les améliorations.
« Apprentissage : Impliquer les parties prenantes dès la phase d’idéation.
Antoine Craske
J’ai essayé seul mais j’ai échoué avec le système RH annuel (malheureusement pas trimestriel), ne prenant pas le sujet au bon moment, et manquant de plus de soutien exécutif.
L’apprentissage : Prendre du recul et impliquer le C-level et les autres parties prenantes dès la phase d’idéation.
Le changement est possible en s’appuyant sur les compétences des acteurs.
Tirer parti des compétences existantes pour obtenir des résultats limités dans le temps
Les compétences ont un impact direct sur la capacité à changer les méthodes de travail au niveau de l’organisation, des processus et de la technologie.
La relation faisant appel à des soft-skills d’empathie, d’écoute active et d’influence était essentielle pour embarquer les gens dans le changement.
L’écoute active, la reformulation et la manifestation d’intérêt en prenant des notes et en envoyant des résumés ont fait la différence dans la future considération des acteurs.
Les compétences spécialisées étaient principalement axées sur les aspects de conception pour un flux de processus fiable, l’orchestration en self-service et le traitement des données.
Il n’y avait pas besoin du dernier expert en observabilité : sachez ce que vous voulez construire, recherchez des moyens standard et commencez avec des personnes motivées.
Agir avec curiosité, persévérance et un état d’esprit de croissance était l’aspect le plus important de la construction du moteur de changement.
Oui, le Quality Engineering nous oblige à agir en dehors de notre zone de confort.
Construire du Quality Engineering axée sur le pipeline
Après 90 jours, nous avons déployé un moyen reproductible d’effectuer des déploiements quotidiens contrôlés dans le périmètre restant.
Passant l’étape de révélation, j’ai laissé les team leads piloter l’expansion en restant en support et en déléguant le pilotage opérationnel et le plan d’amélioration.
On en revient à l’autonomie : donner aux gens des attentes claires et un soutien à l’expérimentation fait la différence dans la performance organisationnelle.
« Il était essentiel de définir les règles du jeu avec la mesure du business, le déploiement au quotidien et la stabilité opérationnelle. »
Antoine Craske
Ce cas est un exemple d’application du Quality Engineering contraignant l’ensemble du cycle de vie du logiciel à la livraison continue de valeur.
Nous avions d’autres changements en cours tels que l’évolution du business, l’adaptation de l’architecture et des changements organisationnels.
Il s’agissait de prendre une priorité avec des jalons à court et à moyen terme, réalisables de manière réaliste en 90 jours avec un minimum de ressources.
Quel est votre prochain objectif sur la pipeline ?
Suivez la QE Unit pour plus de Quality Engineering.