... afin de livrer plus tôt des applis moins coûteuses.

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.

Christophe Thibaut - Vers une culture de la qualité

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.

Mais pourquoi persiste-t-on à corriger plutôt qu'à prévenir les bugs, les défauts ?

Selon Christophe Thibaut, il y a 5 raisons à cela :

1. On n'est pas formé,
2. On ne mesure pas le coût des erreurs,
3. On n'analyse pas les causes profondes,
4. On n'est pas suffisamment en sécurité pour apprendre de nos erreurs,
5. On n'agit sur la qualité que dans la crise.

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 :

• Pas le temps de s'améliorer,
• Cloisonnement des responsabilités et culture du blâme,
• Confusions sur les causes et illusions sur les solutions.

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.

Sortir de la non qualité !

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

• En tant que manager, former ses développeurs, qu'ils soient internes ou prestataires

2. Maintenir la maintenabilité (G. Weinberg)

• Conserver sa démarche de qualité malgré les aléas des projets.

3. Garder le cap (Deming)

• Mettre en place une stratégie cohérente d'apprentissage sur sa démarche :
  • Ne pas abandonner au premier aléa,
  • Conserver les rituels d'amélioration malgré la pression extérieure.

4. Chasser la crainte : tant qu'il y a de la peur, les chiffres sont faux (Deming)

• Mettre en avant et expliquer ses chiffres et les problèmes rencontrés

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…

Emmanuel Lehmann - Déploiement des pratiques de qualité au Web Center Axa

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 :

• Les Tech Leads, très occupés, ne faisaient pas systématiquement les revues de code.
• Les tests unitaires, développés à la fin de chaque user story, étaient parfois plus compliqués que le code qu'ils couvraient. Ils étaient même parfois tellement compliqués à maintenir, qu'ils étaient laissés KO quand ils ne passaient plus au vert !

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.

L’accompagnement d’OCTO

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 :

1. Présentation et réalisation d'atelier sur la démarche,
2. Présentation des résultats de l'audit (de manière parfois un peu abrupte),
3. Mise en place d'un parcours de formation pour l'ensemble des salariés :

• Revue de code (notamment collective)
• Apprendre à donner et recevoir des feedbacks (apprendre à ne critique que le code, et pas la personne)
• TDD
• TDD sur code legacy (apprendre à désendetter du code existant)
• Clean Code

4. Accompagnement des équipes pendant 6 mois puis en dégressif :

• 2 équipes en mode intensif, ayant chacune leur propre coach
• 8 équipes en mode basique, se partageant un coach et ayant un parcours de formation allégé

5. Assistance à la mise en place d'une culture de la qualité :

• Accompagnement de la direction
• Assistance à la mise en place d'une communauté de pratiques : organisation de Dojo et BBL, accueil de meet-up.

Antoine Blancke - Mise en place des revues de code collective au Web Center AxA

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 :

• Une amélioration de la qualité intrinsèque du code, notamment en ce qui concerne le design et le nommage,
• Une appropriation collective du code,
• Une facilitation de l'apprentissage et de la montée en compétences sur le projet.
  • Les nouveaux arrivants sont autonomes plus vites.

Dur avec le code, doux avec les gens

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 :

• Peur du jugement personnel,
• Ne pas oser donner de feedback,
• Avoir peur de faire des remarques peu pertinentes,
• Abandonner la pratique à cause de la pression projet.

Pour surmonter ces difficultés, ils ont beaucoup expérimenté:

• Trouver la bonne approche, le bon processus :
  • Il est nécessaire d'y travailler tous ensemble pour pouvoir l'appliquer à sa façon de travailler.
• Opérer un changement de culture au sein de l'entreprise pour avoir des sponsors,
• Changer les mentalités au sein des équipes, notamment dépassionner le code en mettant en place les principes de l'egoless programming,
• Avoir des moteurs dans l'équipe pour maintenir la pratique, malgré les pressions extérieures.

Après 4 mois de mise en pratique, voici les résultats qu'ils ont obtenus:

• 20 revues effectuées,
• 126 défauts détectés (soit 6.6 par revues),
• 5 anomalies sévères détectées,
• Des standards qui évoluent constamment,
• Une meilleure intégration des nouveaux arrivants.

Emmanuel Lehmann - Mise en place de BDD (Behavior Driven development) au Webcenter

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.

Les avantages du BDD, tel qu'ils ont été vécus par le Web Center

• On découvre les règles ensemble, donc on comprend tous la même chose. C'est donc un gros vecteur de communication, un des principes fondamentaux de l'Agile (les individus et leurs interactions plus que les processus et les outils).
• Le développeur n'a plus à créer le jeu de données seul, il a des exemples pour piloter le développement.
• On est capable de démontrer l'avancement.
• Via les outils permettant d'exécuter les scénarios exprimés en gherkin, on peut prévenir la régression.
• De même, grâce à eux, tout ce qui est produit sert de documentation exécutable et à jour.

Questions / Réponses

A l'issue de ces 4 présentations, nos orateurs ont bien voulu répondre à quelques questions. Les voici avec leurs réponses.

La maintenance des tests unitaires est-il un poids ?

Moins en TDD qu'en "test after".

Dans un scénario gherkin, faut-il mettre en dur les valeurs ?

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.

Comment harmoniser les pratiques entre les membres de l'équipe ? Quelle place pour les outils dans les pratiques de qualité?

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.

Quel scope pour la revue de code ? Qui corrige ? Quand ?

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.

Quels autres tests sont réalisés dans les équipes du Web Center, comme des tests de résilience, de sécurité ou de performance ?

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.

L'exécution des tests se fait parfois sur des environnements bouchonnées. Pourquoi ?

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.

Combien d'application sont en cours de développement au Web Center ?

Près de 150.

Est-ce que des tests manuels sont effectués ?

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.

Travaille-t-il avec des équipes délocalisées ?

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.

Les standards viennent-ils de Sonar ? Ont-ils été définis autrement ?

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.

Comment gérer la résistance au changement ?

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é.

Quels impacts a eu la mise en place des pratiques de 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.

Est-ce que les développeurs sont plus heureux ?

Il y a plus de fierté globale pour ce qui est produit.

Avec les nouvelle pratiques, il y a des nouvelles compétences à rechercher dans les candidats. Comment avez-vous fait ?

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.

Qui ont été les initiateurs du changement ?

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.