Transmettre la culture de la qualité logicielle : l’exemple du webcenter d’AXA
Produire du code de qualité est une question de culture et de savoir-faire spécifiques. Ce fait est souvent sous-estimé dans les organisations. Pourtant la non-qualité du code produit des effets bien visibles : désengagement des développeurs, time to market plus long, fonctionnalités dans les applications plus difficiles à ajouter ou à faire évoluer, risques d'indisponibilité de l’application... Comment dans ces conditions créer au niveau des équipes comme de l’entreprise tout entière une véritable culture de la qualité autour du code ? Retour d’expérience avec Antoine Blancke, Technical Leader pour la DSI d’AXA France à Lille et Julien Jakubowski, Consultant OCTO Nord et formateur pour OCTO Academy.
Comment la problématique autour de la qualité du code a-t-elle émergé ?
Antoine Blancke – Au webcenter de Wasquehal, nous développons et réalisons des applications web et mobile pour le compte de la DSI d’Axa France. Sur site, près de 150 experts mettent en œuvre les meilleures pratiques issues de l’agile et du software craftsmanship. Mais ce résultat ne s’est pas mis en place du jour au lendemain. C’est le fruit d’un cheminement et d’un apprentissage qui nous a conduit à revoir nos manières de faire et de concevoir nos logiciels. Plusieurs phénomènes ont en fait convergé.
En 2011, nous avons commencé à réinternaliser certaines activités confiées à des sociétés de service. Nous appliquions déjà les principes d’organisation agile mais en interrogeant les compétences dont nous avions besoin, on s’est rendu compte que nous n’avions fait qu’une partie du chemin. Il fallait aller plus loin, agir sur la qualité du code que nous produisions. Une petite communauté de développeurs inspirée par les principes du software craftsmanship s’est formée. Ils participaient à l’agile tour de Lille et animaient régulièrement des coding dojo. Il existait donc un terrain favorable à la diffusion des principes dits "craft" à l’échelle du webcenter mais le vrai déclencheur a été l’assessment / évaluation réalisé par OCTO fin 2014.
Julien Jakubowski – Les démarches agiles se focalisent sur l’adéquation du logiciel au besoin. Mais la plupart ne traitent pas au fond de qualité du code. En d’autres termes, l’agilité ne fait pas la qualité du code : on peut tout à fait appliquer des principes agiles dans le développement et cumuler dans le même temps de la dette technique. Comment faire alors pour éviter ce que certains appellent la « gueule de bois agile » ? L’assessment effectué par OCTO a permis de formuler un certain nombre de recommandations. La direction du centre a décidé alors d’investir sur la qualité logicielle et d’être sponsor de nouvelles pratiques de développement. Cette implication a été fondamentale. Pas seulement pour régler des questions de budget. Au niveau de l’implication des collaborateurs également. Mettre en œuvre ces pratiques de développement modifie sensiblement les habitudes de travail. Il n’est pas rare de constater sur les premières semaines une baisse de productivité, le temps que ces pratiques soient intégrées. Le management a un rôle important à jouer alors pour soutenir les équipes. Les bénéfices seront beaucoup plus visibles après une phase d’apprentissage inévitable.
Concrètement, comment s’est déroulée la mise en place de ces nouvelles pratiques ?
Antoine Blancke – Il s’agissait d’ancrer au niveau du centre une démarche solide autour de la gestion de la qualité et de la maintenabilité des logiciels produits. Au départ, ces pratiques étaient surtout le fait d’une petite communauté d’initiés. Comment dès lors passer à l’échelle, assurer leur diffusion et faire en sorte qu’elles deviennent un nouveau standard, partagé par tous ? Pour instituer ces changements, la formation a été indispensable. Deux cursus ont été mis en place en fonction du niveau de maturité des développeurs. Deux équipes ont bénéficié d’un accompagnement intensif pendant 3 mois afin d’être en mesure, par la suite, de jouer le rôle de formateur auprès des 8 autres équipes du centre. En tout ce sont plus de 100 personnes qui ont été formées.
Julien Jakubowski – Améliorer la qualité du code c’est agir non seulement sur la pratique mais c’est aussi créer un environnement qui soit favorable. L’individuel est inséparable du collectif car la qualité du logiciel dépend directement de la manière dont les individus vont travailler ensemble. Nous avons mis en place un accompagnement intensif et dans la durée alternant formations et mises en pratique opérationnelle sur les projets. Des rituels collectifs ont été instaurés. Certains tech leads AXA ont bénéficié d’un coaching individuel pour les aider dans leur nouvelle posture et que s’installe une dynamique d’amélioration continue, au-delà de l’intervention des consultants OCTO. Faire émerger une culture autour de la qualité du code demande du temps. Il faut agir sur les habitudes et les mentalités mais tout le monde y gagne.
Quels ont été les premiers résultats constatés ?
Antoine Blancke – D’une certaine manière l’état d’esprit, le mindset existait. Par exemple, nous faisions beaucoup de tests de non-régression, à la main ou de tests automatisés à l’issue des phases de développement. Mais on avait du mal à appliquer ces approches sur des projets legacy. La formation apportée par OCTO nous a permis d’en reprendre le contrôle. Nous avons repositionné les tests afin qu’ils interviennent en amont et pendant la phase de développement en nous inspirant des pratiques TDD (Test Driven Development). Nous nous sommes dotés d’outils d’ingénierie logicielle. A dire vrai, avant ces formations, nous n’étions qu’à mi-parcours en matière d’intégration continue. On déployait des outils mais on ne savait pas toujours ce qui marchait bien ou pas. Les équipes ont gagné en confiance et sérénité d’autant plus que le management a donné de la visibilité aux progrès accomplis. On a été encouragés à intervenir auprès des autres équipes et peu à peu, ces nouvelles pratiques de développement sont rentrées dans les mentalités et sont devenues des standards.
Julien Jakubowski – La perspective a progressivement évolué. Les pratiques d’une petite communauté d’initiés se sont diffusées presque naturellement. Bien des aspects dans la façon de travailler ont été modifiés. Premier signe révélateur de ces évolutions : le rôle de Technical Leader a été redéfini. Traditionnellement, c’était celui qui avait l’expertise technique. Il relisait et contrôlait le code des développeurs à l’issue du processus. Son rôle a évolué pour qu’il accompagne les équipes vers l’excellence en termes de qualité logicielle. L’autre point est que progressivement coder est devenu une activité qui se pratique à plusieurs. Il s’est développé un “ownership” collectif du code notamment à travers les revues de code collectives qui ont été instaurées. Tout le monde s’est senti responsable du code de l’équipe et légitime pour détecter les bugs et les corriger. Je crois que le principal changement de mindset pour les développeurs, c’est à ce niveau-là qu’il est intervenu.
Antoine Blancke – Il était rare qu’un développeur relise le code d’un autre développeur. Aujourd’hui, au webcenter c’est près de 90% du code qui est relu par d’autres. Les équipes ont intégré l’idée qu’un développeur ne peut plus développer seul dans son coin, devant son écran. Il faut que son travail puisse être utilisé sur n’importe quel poste et que son code soit lisible et assimilable facilement par ses collègues. Il vaut mieux échanger régulièrement, quotidiennement plutôt que de devoir tout casser à la fin du sprint car ça ne marche pas.
Quel bilan tirez-vous de cette période ?
Antoine Blancke – Les habitudes sont parfois difficiles à changer. Le travail d’évangélisation d’une certaine manière est permanent même auprès des nouveaux collaborateurs. Pour convaincre, il faut avoir un impact positif et les contre-arguments sont tenaces… Il faut parfois lutter contre des réponses du type “je n’ai pas le temps” ou bien “cela ne va rien m’apporter”. Ce temps-là, il faut le prendre pour entretenir la dynamique, mener une veille technique ou technologique… Adopter les pratiques craft ne se fait pas sans remise en cause de certaines habitudes mais il est clair que pour AXA, il y a eu un avant et un après. Ce qui était l’exception est devenu la règle. Une véritable culture de la qualité du logiciel s’est développée. Nous sommes mieux outillés pour automatiser nos livraisons. Et surtout, les collaborateurs ont conscience que le code est un travail collectif. La revue de code par exemple est un moment attendu dans les équipes.
Julien Jakubowski – Il y a toujours des difficultés. C’est naturel. Les gens n’ont pas le temps d’être formés mais ils ont le temps de créer des bugs puis de les corriger ! C’est paradoxal. Un rituel comme la revue de code par exemple bouscule certains réflexes. Le Technical Leader doit alors jouer un rôle de facilitateur et permettre à chacun de s’exprimer avec bienveillance. Cela s’apprend. Pour un développeur, exposer son code aux autres peut heurter l’égo. Mais quand il comprend que les autres ne sont pas là pour le critiquer personnellement mais pour améliorer son travail, l’état d’esprit est différent. L’apprentissage par le collectif devient la clé essentielle. Aujourd’hui, ma plus grande fierté est de voir que les équipes sont autonomes. Au début du projet, lorsque nous définissions les critères de succès de cet accompagnement, nous avions identifié le critère “donner un talk sur les pratiques craft à une conférence reconnue”. Je me réjouis de voir que ces pratiques sont à ce point entrées dans les mœurs que régulièrement des collaborateurs AXA participent à ce type d’événement car ils ont envie de partager leur expérience.OCTO poursuit son implantation chez les Ch'tis !
Vous faites partie de celles et ceux qui veulent diffuser leurs valeurs et savoir-faire pour concrétiser la transformation numérique de la région Nord avec audace et plaisir ? OCTO Lille recrute des consultant.e.s à Lille qui ont l'amour du logiciel de qualité et aimeraient accompagner nos clients vers l'excellence, tout comme nous l'avons fait avec le Webcenter d'AXA. Plus d'info