La mise en place de fondations de qualité supportée par une démarche itérative est un sujet cœur au travers des échanges de la communauté.
Elle est néanmoins rarement accompagnée par des retours d’expérience concrets.
C’est pourquoi j’ai décidé d’imager une mise en place fortement inspirée de mon expérience personnelle, en toute humilité.
L’objectif est que les pratiques exemplifiée soient pertinentes pour vous, et imagées en contexte, sans chercher à donner une image édulcorée de la réalité.
La lumière étant orientée sur la notion de démarche, le contexte le plus pertinent a été retenu, raccourci en quelques paragraphes des années de mise en place.
La temporalité n’est pas donc pas représentée par choix, et en aucune circonstance ne veut passer un message de facilité, dans ce contexte ou d’autre d’ailleurs.
Cet article couvre les étapes suivantes d’une démarche possible :
- La nécessité d’une organisation de se “prendre un mur” pour réagir
- L’obtention de sponsorship métier et IT dans une période d’opportunités
- Utiliser une crise comme effet levier pour changer les habitudes
- Mettre en place une démarche itérative orientée client et métier
- Axer l’organisation en transverse autour de la qualité
- Intégrer la testabilité “by design” en amont des cycles de développement
- Donner de l’espace pour expérimenter tout en supervisant l’expérience client
Rejoignez la QE Unit pour accéder à des contenus exclusifs et réguliers de la communauté.
La Redoute, une entreprise historique
La Redoute est une entreprise au cœur du panorama français, avec une notoriété de 99% en France et plus de 180 ans d’existence.
Tout le monde garde le souvenir des catalogues sur la table du salon des familles, feuilleté à maintes reprises et plein de surprises.
C’est d’ailleurs cette longévité qui lui avait également valu l’héritage d’un système d’information historique, complexe, plus communément caractérisé de legacy.
Même si aujourd’hui La Redoute a su rebondir, une transformation en profondeur à tous les étages de l’entreprise a été nécessaire.
Dans cet article, nous allons focaliser notre prisme sur le métier, le SI et la qualité logicielle.
La confrontation à la froide réalité
Nous avons identifié la nécessité des organisations de se “prendre le mur” afin de réagir.
Pour la Redoute, je pense que cette période charnière s’est opérée en 2014, par sa sortie du groupe PPR, aujourd’hui Kering.
L’entreprise s’est retrouvée seule face à des pertes opérationnelles importantes, dans un contexte organisationnel et concurrentiel compliqué.
Malgré un site e-commerce assurant plus de 50% du chiffre d’affaires, le mainframe et sa lenteur inhérente restait le cœur du réacteur de l’entreprise.
La plateforme e-commerce était également un frein au développement par des cycles de releases trimestriels, suivis de périodes compliquées de livraisons et de stabilisation.
Régulièrement, les équipes sont fatiguées et ont globalement du mal à fournir des évolutions structurelles, des projets majeurs subissent des délais considérables.
Avec de recul, cette phase de confrontation à la froide réalité est un facteur dans la capacité de l’organisation à s’être plus rapidement adaptée par la suite.
On peut malheureusement faire le parallèle avec un fumeur qui n’arrête de consommer qu’une fois survécu à une attaque cardiaque.
Une transformation accélérée et drastique comme seule option
Une transformation accélérée était la seule possibilité pour survivre dans un contexte de plus en plus concurrentiel et globalisé.
C’est à cette période que La Redoute a démarré une transformation en profondeur, alliant refonte du business model ainsi qu’une digitalisation en premier plan.
La rationalisation et la protection est le mot d’ordre dans un contexte de survie où des coupes sévères s’opèrent à tous les niveaux (e.g. passage des effectifs de 3000 à 1500 personnes).
L’informatique n’est pas épargnée, elle doit unifier ses 3 plateformes web pour répondre aux besoins d’accélération et de rationalisation.
En parallèle, le back-office doit complètement sortir du Mainframe historique dans une architecture distribuée pour apporter plus de rapidité et de souplesse.
C’est dans ce contexte à fortes contraintes que des opportunités se sont créées, notamment pour la qualité, un vecteur d’accélération et de stabilisation des livraisons logicielles.
Le leadership de transformation, le sponsor de-facto
La démarche partant de loin, la première étape de fondations était plus que nécessaire.
Fruit des livraisons difficiles vécues par les différentes équipes, qui plus est de façon répétée, le développement seul ne pouvait résoudre les problématiques rencontrées.
Par une analyse systématique du contexte, notamment d’un point de vue système et organisationnel, le manque de qualité est saillant.
La convergence vers la nouvelle plateforme s’est révélée être une opportunité de partir sur de meilleures bases, avec un sponsoring fort, tant métier que IT.
Le besoin de transformation étant fort, les personnes en position de direction formelles ou d’influence informelles impulsent une dynamique.
On retrouve ici le pré-requis de sponsoring d’une démarche de qualité, qui absente se révèle souvent fatale.
La transversalité métier et IT dans le contexte partagé a, je le pense, été facilitée par l’historique et le sens de l’urgence de transformation.
“Livrer moins, mais tous les jours”, un message fort et nécessaire
Une vision d’équipe est impulsée de pouvoir livrer tous les jours, avec confiance et stabilité, des petits changements.
C’est un message fort dans un contexte précédent où le nombre de sujets poussés dans une livraison était l’indice de performance suivi.
D’ailleurs ce principe implique des changements drastiques des processus de développement logiciel, en prise directe avec les habitudes de l’organisation.
Prenons l’exemple des branches de gestion de version – un autre thème à débattre – dont les développeurs aiment souvent avoir leur propre branche en “local”.
Personnellement, ce mot “local” active un signal d’alerte intérieur.
En faisant le lien avec le system-thinking et les dangers des optimisations locales, il faut garder une perspective globale.
Il a fallu par exemple passer en trunk-based development pour supporter un cycle de livraison journalier de petits changements synchronisés.
D’où le besoin de sponsoring jusqu’à l’engineering pour réussir ces transformations, un changement d’habitude organisationnel étant un réel défi.
Une batterie de test minimale, stable, rapide et orientée client est implémentée
Les cycles de livraisons pouvant être plus rapides et contrôlés, il restait à en assurer leur qualité.
C’est ici qu’une campagne de test minimale est mise en place.
Les rôles minimaux sont définis afin de sécuriser cette démarche : Chef de projet transverse, responsable qualité, DevOps en mettant au cœur du processus les Product Owner, Développeurs et QA.
Une batterie de test initiale est définie, ayant pour objectif de valider le minimum de fonctionnalités cœurs en non-régression, d’un point de vue client.
Dans le contexte de l’entreprise, on se réfère souvent aux customer journey en lien avec des personas pour axer les tests réalisés.
Les premières campagnes sont difficiles, les tests ont du mal à être stables par des problématiques de jeu de données qui doivent être résolues.
Le métier commence à s’impatienter, il faut défendre la démarche mise en place pour ne pas céder aux vieilles habitudes.
Au bout de quelques semaines un rythme de livraison commence à s’installer, même si peu d’évolutions sont intégrées.
Intégrer la testabilité “by design” en amont des cycles de développement
Réussir des premiers cycles est une première étape, mais comment tenir le cap?
D’expérience, le contrôle du run est un pré-requis pour une organisation qui souhaite être plus agile et accélérer.
Le recours au LEAN, à la résolution de problèmes et à l’automatisation sont souvent combinés pour atteindre de réels résultats.
Une fois sous contrôle, reste l’équilibre entre les évolutions et la maintenabilité de l’existant.
C’est à ce moment-là que les exigences ont eu besoin d’être traduites en test en amont des développements.
Sans parler de BDD ou de TDD, l’approche est restée pragmatique en alignant les use-cases métier avec ceux des tests fonctionnels.
Le travail des équipes de QA durant le sprint est ensuite de préparer les tests automatiques, tout en validant les use-cases manuellement, au fur et à mesure des livraisons journalières.
C’est un exercice compliqué, plein de contraintes, qui requiert une réelle priorisation, partage entre les équipes et modularité des tests.
Ce sujet n’est jamais terminé, le focus doit être d’améliorer la maturité des équipes sur leur implémentation et garantir la stabilité et maintenance de l’existant.
Un besoin de liberté et d’expérimentation du métier
Dans une volonté d’expérimentation plus forte d’idées sur les interactions digitales, les équipes ont besoin de plus de liberté d’action.
C’est à ce moment que les features flag sont étudiés.
Ils représentent de réels enjeux d’ingénierie pour être correctement utilisés, de leur conception, maintenance et jusqu’à leur suppression.
Ces features flag seuls sont souvent utiles aux équipes IT pour gérer des déploiements progressifs, mais être accessibles au métier.
C’est ici que la complémentarité par des mécanismes d’A/B Testing entre en jeu afin d’apporter une valeur transverse à l’organisation.
Une fois rôdé, ils permettent de livrer des fonctionnalités mêmes partielles, tout en pouvant graduellement les activer ou même les désactiver.
Ce degré de latitude sur la plateforme fait émerger la question de la stabilité de l’expérience client.
Comment s’assurer qu’elle n’est pas impactée par toutes ces expérimentations continues?
Les prémices de l’observabilité
Les tests fonctionnels orientés sur les parcours clients sont une pièce charnière.
La supervision technique nous parlant de processeur, mémoire et latence réseau est fatigante et loin de l’expérience client.
Un recentrage sur l’expérience est nécessaire.
L’exécution régulière des tests fonctionnels en production vient apporter une première garantie de la stabilité des parcours clients.
Directement intégrés avec la supervision, les équipes tant métier que IT peuvent avoir une vision exhaustive de l’expérience sur les différents devices, pays et environnements.
Avec le temps, on se rend d’ailleurs compte que les données uniquement utilisées en supervision pourraient d’ailleurs se retrouver utiles en reporting.
La mise en place de tableaux de bord permet par exemple de suivre la stabilité des parcours de connexion, d’ajout au panier, de commande.
Sans s’en rendre compte, l’équipe suit d’ailleurs des KPIs communs entre métier et IT, facilitant une collaboration étendue et accélérée.
Les guerres d’excel et de justification de pertes sont quasiment oubliés.
La mise en place de fondations, une démarche transverse, itérative et incrémentale
Je pense que ces trois mots résument la mise en place de fondation pour une démarche de qualité.
Sans transversalité, le sponsoring apparaît difficilement, et les optimisations locales ne font qu’alterner résolutions temporaires et apparitions de nouveaux problèmes.
La transversalité se retrouve également dans les pratiques mises en place, elles vont du métier, QA, IT, développement jusqu’aux opérations.
Il faut savoir composer et adapter, comme dans un ensemble de jazz, au contexte et enjeux du moment, d’où la valeur d’un processus itératif.
Les itérations apportent la capacité à limiter la complexité initiale et à adapter beaucoup plus rapidement des processus efficaces, ou au contrainte inefficaces.
C’est pourquoi une démarche incrémentale dans un écosystème complexe, incertain, et à fort changement humain est plus que pertinente.
Pour terminer, n’oublions pas qu’une démarche itérative ne doit pas signifier qu’elle est sans but, ni vision ou destination en tête.
La vision, une différence clef pour une équipe qui arrive à bon port et celle qui finit par revenir à son port de départ.