Comme nous le rappelle Laurent Barbier dans son introduction – en empruntant les mots de Christian Fauré dans sa préface de Culture Code : le code est le reflet de l'ambition "digitale" de la société qui l'a produit. Ce petit-déjeuner est donc l'occasion pour Emmanuel Lehmann et Antoine Blancke, tous deux développeurs chez Axa, de témoigner de la volonté du groupe d'assurance d'améliorer sa production logicielle dans le cadre de sa "stratégie digitale". Ils sont précédés par Christophe Thibaut, qui nous présente les enjeux économiques d'une culture de la qualité du code. Voici le compte-rendu de cette matinée.
Retrouvez la présentation complète des speakers, et la vidéo du petit-déjeuner.
La présentation de Christophe Thibaut débute sur ce chiffre choc : la non qualité coûte un demi-milliard de dollars par an d'après Capers-Jones. Toujours d’après cette même source, un projet abandonné pour cause de non qualité coûte au final 15 % plus cher qu'un projet livré de qualité.
Les sources des problèmes de qualité peuvent se trouver à n'importe quel stade d'un projet, de la conception à la mise en production. Toutefois, toujours d'après les études menées par Capers-Jones, la phase de développement est celle où le taux détection des défauts est le plus élevé (35 %). C'est donc à ce stade qu'il est le plus important mettre en place une démarche de détection des défauts, une démarche de qualité.
Le coût d'un projet sans démarche qualité rattrape celui d'un projet en comprenant une à la fin de la phase de développement (et donc juste avant celle de maintenance). Les pratiques d'une démarche de qualité les plus effectives sont les tests unitaires automatisés et la revue de code, qui ont un coût respectif de 30 % et 5 % du budget – contre 30 à 50 % pour la correction de bugs. Sans prendre en compte l'impact que cela peut avoir sur d'autres critères comme la maintenabilité et l'évolutivité du logiciel après sa livraison initiale.
Selon Christophe Thibaut, il y a 5 raisons à cela :
Qui plus est, l'origine de ces bugs est souvent liée à un problème de temps : on sous-estime le temps de développement, la complexité d'une fonctionnalité ou d'une user story (par erreur ou par pression extérieure). Résultats : on est soumis à la pression de développer dans un délai impossible à tenir, les tests unitaires et les revues sont fatalement mis de côtés et l'on a plus de risques de faire des erreurs de programmation.
Dans de nombreuses entreprises où les démarches de qualité ne sont pas mises en place, on peut constater une culture du bug fix :
Il est important de noter que refondre une application avec trop de dette technique, sans changer ses pratiques, aura tendance à produire une nouvelle application endettée. Parfois, il vaut mieux donc apprendre les pratiques de désendettement (qui nécessitent l’apprentissage préalable des pratiques de qualité, notamment les tests unitaires – et mieux, du TDD ) avant de refondre.
Pour cela, Christophe Thibaut nous donne les conseils suivants:
1.(Se) former en permanence, puisque l'IT nécessite d'apprendre de nouvelles choses tout le temps
2. Maintenir la maintenabilité (G. Weinberg)
3. Garder le cap (Deming)
4. Chasser la crainte : tant qu'il y a de la peur, les chiffres sont faux (Deming)
Sur ces deux derniers points, afin de convaincre la direction, il est important de mesurer l'impact financier d'une démarche de qualité. Pour ce faire, Christophe propose de calculer le coût de la non qualité sur l'exercice en cours, auquel on retranche le coût de la formation aux pratiques de qualité. On fait ensuite une estimation de l'économie attendue sur le prochain exercice. Lorsque ce dernier est terminé, on peut vérifier si la projection est conforme à ce qui a été réalisé (pour peu que le cap ait été conservé).
Enfin, pour mettre en place une culture de la qualité, il est nécessaire d'accompagner les développeurs en amont pour leur démontrer l'intérêt de la stratégie, et de faire un atelier avec eux pour bien comprendre ce qui ne marche pas avant de former les gens. On peut ainsi voir s'il existe des freins structurels qui pourraient ruiner les efforts de mise en place de la démarche.
Enfin, la culture de la qualité – en plus de permettre de limiter les défauts des logiciels – peut aussi permettre de faire progresser la valeur du logiciel. Les développeurs (une fois débarrassés des problématiques de bug fix et de la pression associée) peuvent se focaliser sur le challenge du PO, la compréhension des enjeux DevOps ou encore se former à une technologie qui pourrait permettre d'améliorer le produit.
Dans une DSI, cette culture de la qualité doit partir d'un ou plusieurs projets pilotes, qui, par l’exemplarité des pratiques qu'ils utilisent, pourront servir de références aux autres développeurs. Mais cela peut prendre des années…
Le Web Center d'Axa a été créé en 2011. Dès le départ, ses membres ont appliqué les principes de l'Agile, en utilisant d'abord du Scrum puis des pratiques Lean, comme le Kanban. Cela leur a vite permis de démontrer qu'ils étaient capables de livrer des logiciels pour le groupe. Une fois cela fait, ils ont commencé à appliquer les principes du DevOps, puis à se poser des questions sur la nécessité de mettre en place des pratiques de qualité.
Tout d'abord, par l’utilisation d’outils de qualimétrie. Les Tech Leads se sont mis à faire des revues de code et les développeurs à mettre en place un harnais de tests unitaires automatisés. Malheureusement, des premiers écueils sont apparus :
Confrontée à ces problèmes, la direction du Web Center a fait appel à OCTO en 2014, pour un audit dans lequel nous avons identifiés les projets qui fonctionnaient bien et ceux qui péchaient.
Nous avons notamment démontré que le design des applications reflétait un manque de réflexion a priori sur les tests à réaliser. A l'issue de cet audit, nous avons proposé une démarche de formation et d'accompagnement, que voici :
La revue de code est une pratique qui date des années 60, mais qui n'est pas souvent mise en pratique. Au Web Center, comme Emmanuel Lehmann l’expliquait précédemment, ils avaient commencé par la faire faire uniquement par les Tech Leads. Celle-ci était exécutée à la fin de chaque itération. Parfois, il arrivait que les développeurs se fassent des revues entre eux pour les tâches compliquées.
Deux problèmes ont alors été constatés : la relecture, quand elle était faite, n'était que partielle (seulement 5 % du code). Des défauts passaient souvent entre les mailles du filet. De plus, le Web Center constatait un faible niveau d'appropriation des standards et des pratiques par les équipes.
Aujourd'hui, chaque ligne de code est revue par l'ensemble de l'équipe en même temps. Dans l'équipe d'Antoine Blancke, c'est à chaque fois que la colonne "A revoir" du Kanban atteint un maximum de 3-4 tickets. Pour Emmanuel Lehmann, c'est à chaque fin de sprint. Dans les 2 cas, cela prend deux heures par semaine pour chacune des équipes.
Les bénéfices qu'ils ont constatés sont les suivants :
Pour atteindre ces résultats, ils ont tout d'abord émis une règle essentielle à la revue de code : Dur avec le code, doux avec les gens. Le but n'est plus de pointer un responsable mais de pointer les défauts du code. Pour ce faire, il a fallu apprendre à reformuler ses critiques. Pour ancrer ce principe, ils l'ont affiché dans chacune des salles de revues et dans les open spaces.
Ils ont été confrontés à quelques difficultés au début de la mise en place de la pratique :
Pour surmonter ces difficultés, ils ont beaucoup expérimenté:
Après 4 mois de mise en pratique, voici les résultats qu'ils ont obtenus:
Faire des tests seuls, ce n'est facile. Il peut être compliqué de définir tous les tests de validation par lesquels doit passer la fonctionnalité qu'on a réalisée.
BDD propose une solution à cette problématique. Pour ce faire, en partant du besoin initial, on réunit dans un même atelier de travail un développeur, un PO et un testeur. A eux trois, ils réfléchissent à des cas de fonctionnement de la fonctionnalité (ses règles métier), qui deviennent des scénarios de tests. Tout ou une partie de ces scénarios permettront de définir une ou plusieurs user stories.
Pour décrire ces scénarios, l'usage est d'utiliser le formalisme gherkin. Cela permet de découper le comportement en plusieurs étapes exprimées en langage naturel.
La description d'une fonctionnalité en scénario de tests permet d'éviter les ambiguïtés. La priorisation des scénarios permet aussi un alignement sur quelle règle doit être implémentée, ou pas, pour chaque fonctionnalité initiale. Tout le monde est coupable si une règle a été oubliée.
Suivre l'avancement d'une fonctionnalité en fonction du nombre de scénarios qui restent à être implémentés devient assez simple : on peut dans beaucoup de cas dire que la fonctionnalité est terminée à 80 % quand 8 scénarios sur 10 ont été implémentés.
L'utilisation du formalisme gherkin permet l'usage des outils de BDD (Rspec, Cucumber, …), capables de transformer les règles ainsi décrites directement en plusieurs squelettes de méthodes permettant de s'interfacer avec le logiciel. En général, chaque étape d'un scénario exprimé en gherkin devient une méthode. Une fois implémentées, ces méthodes permettent de valider programmatiquement l'implémentation des règles.
C'est en codant ces méthodes que le développeur va pouvoir commencer à implémenter la fonctionnalité attendue et qu'il rentrera cette fois dans un cycle TDD.
A l'issue de ces 4 présentations, nos orateurs ont bien voulu répondre à quelques questions. Les voici avec leurs réponses.
Moins en TDD qu'en "test after".
On peut faire des scénarios gherkin avec un jeu de valeurs intégré dans un tableau avec les résultats attendus dans chacun des cas.
Ce n'est pas gênant d'avoir un jeu en dur, puisque les tests font partie intégrante du code.
Il faut écrire noir sur blanc les standards pour les partager avec les nouveaux arrivants.
Dans le cadre de la revue de code, on écrit directement le compte-rendu dans la pull request.
La plateforme d'intégration continue est au cœur du processus : chaque soir, a minima, l'intégralité des tests est exécutée (unitaires, intégration, BDD) et les outils de qualimétrie sont lancés.
Pour l'équipe d'Emmanuel Lehmann, c'est chaque mercredi. Pour Antoine Blancke, c'est une étape du Kanban, qui est réalisée en mode opportuniste. Dans les deux cas, l'intégralité des commits est revue et c'est le développeur qui a produit le code qui le corrige, seul ou en pair programming.
C'est du vrai code, lancé chaque jour dans la plateforme d'intégration continue. Des tests de sécurité (comme Zap) et de montées en charge sont lancés sur la pré-prod.
C'est un choix, pour des raisons de vitesse d'exécution des tests pour avoir une boucle de feedback courte. Seules certaines applications fonctionnent ainsi.
Près de 150.
Oui, des équipes de tests font des tests manuels dans le cadre de la recette. Les testeurs font ça en mode "pair testing" avec les développeurs. Cela prend à peu près 4h par semaine et par développeur. En gros, il y a un testeur pour 4 développeurs au Web Center.
Il y a des équipes de développement à Nanterre, mais les pratiques n'y sont pas diffusées.
Certaines personnes font du télétravail de temps en temps, mais ce n'est pas une problématique au quotidien.
Tous les PO sont à Nanterre, mais ça ne pose pas de problème pour les démos.
A l'origine, ils ont été définis par les architectes et un collège de tech leads.
Depuis la mise en place des pratiques, ils sont alimentés au fur et à mesure, mais ne sont pas forcément intégrés à Sonar. Ils sont restés sur les règles standards, ils n'ont pas la volonté d'être différents de la communauté pour permettre une meilleure intégration des nouveaux arrivants. De plus, les principaux standards émergeant des revues de code sont des règles de design, de nommage ou de respect des principes DDD (Domain Driven Design) par exemple, qui, par essence, sont très difficiles à automatiser.
Certaines personnes ont fait un bon accueil aux nouvelles pratiques, sachant qu'ils allaient faire comme les Géants du Web. Globalement, il n'y a pas eu forcément beaucoup de résistance. Il y a eu toutefois un travail de sensibilisation, parfois en forçant un peu la main et en démontrant par l'exemple. Toutefois, majoritairement, tout le monde est convaincu par les pratiques mais tout le monde ne les applique pas forcément, en fonction de son aisance. Le constat est que les équipes ayant été soumises au format intensif de formation et d'accompagnement les appliquent quotidiennement, là où les autres le font moins, avec l'excuse du manque de temps.
Aujourd'hui, les équipes "intensives" ont réussi à démontrer que leurs débits de fonctionnalité sont restés les mêmes avec une meilleure qualité.
Il y a un meilleur relationnel puisqu'il n'y a plus de pointage du doigt, plus de mode "coupable". Il y a une bien meilleure ambiance et les gens du métiers et des tests ont l'impression de faire du développement. Tout le monde est concerné.
Il y a bien moins de problèmes sur les applications, notamment de dégradation exponentielle.
Tout le monde parle de qualité, notamment en rétrospective. Le métier suit les métriques.
Il y a plus de fierté globale pour ce qui est produit.
Ils ont revus le rôle du Tech Lead et modifier la fiche de poste associée.
De même, ils ont revus les fiches de poste des développeurs, en y ajoutant des compétences sur les tests et le clean code et en y demandant d'avoir participé à des communautés de pratiques. Malheureusement, ils trouvent très peu de personne ayant fait du TDD.
Ca n'a pas été le métier, pour qui ça allait ajouter un coût. C'est venu du responsable du Web Center, un ancien développeur ayant une forte culture de la qualité et pour qui il est important d'avoir des développeurs expérimentés.