Un avis ? Un commentaire ?
Cet espace est pour vous.
Dans l’article précédent, nous proposions quelques ressources pour (mieux) appréhender le Behavior Driven Development. Mais quid de l’implémentation de cette méthodologie dans le cadre de projets dont le code historique (ou legacy) représente une part très importante ? Florent Vaution, Software QA Manager chez Ouest-France, a tenté l’expérience et présente ici son témoignage.
A mon arrivée chez Ouest-France il y près de 3 ans, un parcours d’intégration est organisé et me permet de rencontrer différents acteurs qui gravitent autour du SI : métiers du commerce/marketing, métiers du numérique, journalistes, membres de la DSI. A cette occasion, je fais rapidement deux constats :
Beaucoup plus proche de mon métier, je note aussi un manque cruel de formalisation des tests ainsi qu’une documentation pas forcément à jour, ou quand elle l’est, l’effort important de mise à jour en cas d’évolution.
L’idée de rapprocher ces acteurs via une approche BDD émerge assez rapidement. Avec pour objectifs de casser cette défiance, de faire comprendre aux métiers les contraintes et problématiques de la DSI, de redonner du sens aux équipes techniques vis à vis de ce qu’elles produisent pour qu’elles s’investissent et s’approprient leur production. Et ceci pour tous les services de la DSI, des sites web à la distribution du journal dans les boîtes aux lettres des abonnés, de la gestion du compte client à l’impression quotidienne du journal papier.
OK, pour le BDD on comprend bien. Mais il est où le legacy là-dedans ?
Faisons un focus sur cette performance quotidienne qui est d’imprimer tous les jours à près de 600 000 exemplaires du journal papier divisés en 52 éditions (une édition correspond à une zone géographique précise, la zone de Rennes représente 5 éditions par exemple : centre, est, nord, ouest, sud, et chaque édition comporte des pages locales différentes) et répartis sur 3 imprimeries différentes. Ce miracle est possible principalement grâce à un gros legacy. La majorité des applications sont âgées de 15 – 20 ans, et il y a, heureusement, très très très peu de turn-over. Ce qui signifie qu’une partie des personnes qui ont créé ces applications sont toujours présentes et donc qu’elles sont très bien maîtrisées et peu soumises aux défauts.
Les rotatives de Ouest-France, à Rennes le 24 novembre 2014 afp.com/DAMIEN MEYER
L’équipe technique de la DSI est en charge de maintenir et faire évoluer les solutions de mise en page et d’impression du journal papier.
Au niveau organisation, l’équipe technique de la DSI est constituée de PPO, de 5 développeurs, d’un scrum master et d’un testeur. Une petite équipe pour gérer un petite trentaine d’applications différentes. Le legacy est géré grâce à la méthodologie Kanban. Les applications plus récentes et encore en cours de développement sont gérées par la méthodologie Scrum.
Mon rôle dans cette organisation est d’aider à établir la stratégie de test sur les différentes applications développées, de partager les bonnes pratiques venant d’autres équipes et d’accompagner les membres de l’équipe dans ce changement pour qu’il se passe de la meilleure façon possible. A noter que la démarche est aussi déployée dans plusieurs autres équipes.
Côté documentation des différents applicatifs, elle est maintenue sous Word depuis leur création. Côté tests, uniquement des campagnes de non régression étaient présentes dans Testlink mais sans réelle traçabilité avec les “exigences”.
Les solutions développées sont utilisées au sein de trois domaines fonctionnels :
Mais pas facile de faire évoluer un processus industriel qui doit fonctionner tous les jours et qui est soumis aux aléas de l’actualité ! En effet, une information de très grande importance et qui arrive tardivement après le bouclage, peut nécessiter une reprise de la maquette complète du journal (modification, ajouts ou suppression de pages). Les applications mises à disposition doivent donc être prêtes à aborder ces dernières nouvelles.
Le moindre défaut sur cette chaîne peut prendre des proportions considérables : maquette éditoriale à revoir donc décalage de l’impression et distribution plus tendue, remplacement de publicités donc perte de CA et de confiance des annonceurs déjà peu nombreux, non impression de tout ou partie des éditions donc perte de CA. A titre d’exemple, ne rien imprimer représente une perte quotidienne de 600K€ environ.
C’est dans ce contexte très établi que je mets les pieds dans le plat. Heureusement, mon discours a un écho favorable auprès de plusieurs personnes, notamment auprès du DSI, et nous mettons en place un plan d’action en 3 étapes.
© investissements.org
Pourquoi changer ? Cette question, je l’ai entendue souvent. Et il m’arrive encore de l’entendre. La réponse n’est pas évidente quand on est sur un système qui fonctionne, qui permet de produire correctement le journal tous les jours. Néanmoins, nous arrivons aux limites d’un système. Les applications sont basées sur des technologies anciennes, une partie des personnes qui y ont contribué est passée à autre chose (mobilité interne, retraite). Se pose donc la question de la mise à jour et de l’évolution de ces applications.
C’est une réelle opportunité pour démarrer la démarche BDD !
J’ai donc commencé par mettre au point une formation pour expliquer ce qu’est le BDD et ce que j’en attends : de la collaboration entre équipes métiers et équipes techniques !
La formation mêle les concepts théoriques et des ateliers pratiques de réflexion collective pour répondre à un besoin. Le besoin est fictif et volontairement hors de leur champ de compétences mais on peut aussi prendre des cas très concrets.
Bien sûr, l’aspect formalisation qui accompagne cette démarche est abordé et quelques règles sont données pour bien commencer.
L’écho de cette formation a été plutôt bon, et quelques jours plus tard l’équipe a décidé de se lancer dans la démarche. Les membres de l’équipe ont donc bien saisi l’opportunité qui s’offraient à eux.
Nous avons alors défini un plan d’accompagnement pour supporter la démarche et rendre l’expérience la plus bénéfique possible.
Nous avons défini ensemble le contexte le plus favorable pour se lancer. Et nous avons profité de l’évolution mineure d’une application existante. L’idée était double :
Nous avons fait le choix de mettre le testeur de l’équipe au centre de la mise en place de cette démarche. Nous avons estimé qu’il était le mieux placé pour à la fois formaliser les discussions autour de l’évolution et exprimer des contraintes de test.
Le plan ne s’est malheureusement pas déroulé sans accroc. L’écueil que nous avons rencontré est que ce testeur n’avait finalement pas totalement saisi les objectifs et qu’il a aussi repris la totalité des fonctionnalités de l’application mais d’une mauvaise façon. Le testeur a utilisé une méthode très directive avec une action par step. Ce qui inclut des steps techniques non compréhensibles par l’ensemble des membres de l’équipe. On est alors en contradiction avec les principes premiers de la démarche BDD.
Ce qui fait que nous nous sommes donc retrouvés avec un patrimoine de plusieurs centaines de scénarios inutilisables. Grosse frustration du testeur et de moi-même, et léger moment de doute. Mais on se remotive collectivement car on se dit que c’est tout de même la bonne démarche !
© reussitepersonnelle.com
Donc on efface tout et on recommence. J’ai fait des ateliers plus précis avec lui et le Scrum Master pour s’assurer que nous étions tous sur la même longueur d’ondes. Ces ateliers étaient basés sur des cas très concrets et mettaient en avant l’aspect collaboratif. Pourquoi ces 2 personnes uniquement ? Parce que le testeur se faisait le représentant de l’équipe technique et le Scrum Master le représentant de l’équipe métier. Je dis bien le Scrum Master car :
Et aussi tout simplement parce que ces deux personnes sont les plus à même à faire passer des messages au quotidien à l’ensemble de l’équipe.
Donc nous sommes repartis pour un tour. Au-delà de l’aspect perte de temps engendrée par cet écueil, cela a permis de montrer que cette démarche BDD n’est pas si évidente que cela à formaliser afin que tout le monde ait le niveau d’information suffisant et la même compréhension d’une fonctionnalité.
Une autre question s’est aussi levée au début de la démarche : doit-on aussi mettre à jour la documentation existante (Word) ? Nous avons collectivement fait le choix de ne pas le faire. Cela démontre l’adhésion à la démarche initiée et la volonté de la faire aboutir.
Une fois le bon niveau de formalisation atteint, il a fallu reprendre l’existant depuis la documentation existante afin d’obtenir une documentation centralisée et facilement évolutive.
La suite a été la prise en main de la démarche par l’ensemble de l’équipe. Nous avons poursuivi la démarche en ajustant les pratiques avec l’ensemble des membres de l’équipe pour atteindre la bonne façon de faire. Quand je dis la bonne façon de faire, cela signifie que c’est la façon qui convient à tous les membres de l’équipe.
Et ça fonctionne bien ! Les membres de de l’équipe ont bien sûr eu une période de prise en main nécessaire. D’où l’intérêt d’avoir deux personnes à leurs côtés pour échanger, corriger, améliorer leurs pratiques, de manière collaborative. Néanmoins, l’équipe s’est révélée opérationnelle dans l’application de la démarche BDD.
Une fois cette étape franchie sur une application, il faut réfléchir au déploiement de la démarche sur les quelque trente autres.
Nous avons appliqué la même tactique qu’avec la première : toujours profiter des opportunités engendrées par les évolutions, les refontes de produit, les nouveaux développements. C’est donc au gré des événements que le déploiement s’est déroulé et continue à se dérouler car toutes les applications n’ont pas subi d’évolutions et donc ne sont pas inscrites dans la démarche BDD. A ce jour, 16 applications voient leur développement guidé par cette démarche collaborative. Les autres suivront tôt ou tard. Les équipes sont prêtes.
Mais comme rien n’est parfait dans ce bas monde, nous avons dû faire face à un imprévu en cours de route : le départ du testeur qui avait entamé la démarche et qui en était le référent dans l’équipe. Nous avons donc entamé des recherches pour le remplacer et pour poursuivre l’effort au sein de l’équipe. C’était un coup dur car la dynamique était bonne et cet évènement risquait de balayer tous les efforts accomplis.
De plus, trouver la bonne personne pour animer la démarche au quotidien n’a pas été une chose facile.Il faut mêler de bonnes compétences en test (c’est quand même le métier premier) et des soft skills pour embarquer rapidement dans la démarche et l’animer au quotidien. Une combinaison pas si courante que ça autour de nous.
En effet, ce n’est pas parce que les autres membres de l’équipe sont autonomes qu’il n’y a plus rien à faire. C’est peut-être même à ce moment que l’effort doit être plus important pour toujours chercher de l’amélioration, ne pas s’endormir sur des certitudes. Et donc, il faut un animateur de la démarche, un référent, qui peut pousser les autres membres de l’équipe à s’améliorer, à penser à tous les impacts d’une évolution, qui peut s’assurer que tout se déroule correctement, qu’il n’y a pas de raccourci de fait, qui peut répondre à des questions sur la méthode, l’outillage …
Vous me direz, c’est bien beau tout ça, mais est-ce que c’est efficace ?
Très bonne question. Je rappelle les objectifs initiaux :
J’ajoute à ces objectifs des choses plus terre à terre tel que l’amélioration globale de la qualité des produits développés, la réduction du temps de conception d’une nouvelle fonctionnalité, la réduction du temps de maintenance de la documentation.
Concernant la défiance, nous n’y sommes pas encore tout à fait. Il existe encore de grosses phases de recette métier après plusieurs itérations de développement et malgré tous les tests effectués par l’équipe technique. Dans notre cas, il y a aussi une dimension organisationnelle : l’équipe n’a pas accès à un journaliste pour lui servir de Product Owner. Si nous nous cantonnons au PPO (Proxy Product Owner), alors il y a du mieux car il a gagné la compréhension des contraintes techniques à travers les échanges systématiques avec l’équipe technique.
Pour ce qui est de redonner du sens aux équipes techniques, c’est difficile de se prononcer, notamment sur la partie legacy qui n’évolue pas ou peu. Si on regarde les applications plus récentes et celles qui ont bénéficié des plus grosses évolutions, alors on peut dire que l’implication est supérieure. C’est encore plus flagrant sur les nouveaux développements lancés après la mise en place de la démarche BDD et qui bénéficient depuis le début de ses bienfaits.
Si on regarde les objectifs plus terre à terre, l’amélioration de la qualité est difficile à mesurer (d’ailleurs comment mesure-t-on la qualité ? Hightest et Brice Roselier proposent quelques pistes dans cet article). Ce que je peux dire c’est qu’il n’y a pas eu de dégradation car le journal est imprimé tous les jours. Il y a bien sûr des incidents de temps à autre mais rien qui n’empêche la sortie sur les rotatives.
A propos de la réduction du temps de conception d’une nouvelle fonctionnalité, j’ai du mal à quantifier s’il y a eu un progrès. Ceci est dû au fait que la méthode BDD demande un effort plus important que ce qu’ils pratiquaient auparavant. Elle apporte aussi une réalisation meilleure du premier coup. Mais comme les mises en production sont au mieux trimestrielles, l’équipe technique a le temps de faire les choses…
Le paramètre sur lequel on voit la plus grande amélioration est la maintenance de la documentation. Fini la spec qui mêle le besoin et la solution. Nous avons d’un côté la documentation des fonctionnalités exprimées du point de vue des utilisateurs, et de l’autre la documentation technique de la solution. Ainsi si l’implémentation de la solution change, la documentation fonctionnelle n’a pas à être touchée. Et dès le moindre changement fonctionnel, la documentation est mise à jour automatiquement. Ce qui permet aux membres de l’équipe de toujours avoir une référence documentaire à jour.
La mise en place d’une démarche BDD dans un contexte où le legacy est très majoritaire n’est pas une pratique évidente à mettre en oeuvre. Il faut une équipe volontaire, qui croit en la démarche et qui souhaite s’y investir. Car c’est un investissement. Et pas sur du court terme mais plutôt sur du moyen-long terme, le temps de reprendre petit à petit un existant qui peut être conséquent.
Des questions restent toujours ouvertes (traçabilité des changements, granularité des scénarios, …) et les axes d’amélioration sont encore nombreux. Ce qui est sain et encourageant car c’est un signe que les personnes qui intègrent la démarche sont pleinement investis !
Sachez profiter des événements qui seront un terreau bénéfique à la mise en place de la méthode.
Préparez le terrain avec des formations, des ateliers pour accompagner les équipes dans ce changement.
Chaque équipe est différente, adaptez-vous !
Identifiez les relais dans les équipes qui porteront au quotidien la démarche.
Merci à Florent Vaution de Ouest-France pour ce témoignage inspirant, et bon courage aux QA qui se lancent ou se démènent déjà pour mettre en place une démarche de BDD dans leur organisation !
Crédit image couverture : © Ouest-France
Cet espace est pour vous.