En avant-première à Lille, une matinée dédiée à la qualité logicielle. L'essentiel des pratiques Software Craftsmanship décrites dans notre récent ouvrage Culture Code y ont été présentées. Témoignage de la société AXA sur la mise en place de ces pratiques dans son contexte : le WebCenter lillois a revu sa stratégie et ses pratiques de développement « du sol au plafond ». Découvrez le résultat de 2 100 jours de formation intensive et de 9 mois de coaching des 150 développeurs du WebCenter. Retour d'expérience garanti !

1. RETOUR D’EXPERIENCE AXA
AMELIORATION DE LA QUALITE DES
DEVELOPPEMENTS
22 Juin 2016 / Petit Déjeuner OCTO - Ronchin
MENTION DE CONFIDENTIALITÉ

2. High-quality software is not expensive.
High-quality software is faster and
cheaper to build and maintain than low-
quality software, from initial development
all the way through total cost of
ownership
Capers Jones “The Economics of Software Quality”, 2011

3. Dur avec le code,
Doux avec les gens

4. LA REVUE DE CODE
MENTION DE CONFIDENTIALITÉ
22 Juin 2016 / Petit Déjeuner OCTO - Ronchin

5. La revue de code est-
elle pratiquée ?

6. Régulièrement ?

7. Par toute l’équipe de
Dev en même temps ?

8. Qui fait des revues de code ?

9. Audit de code fait par le Tech Leader de l’équipe à chaque fin de
sprint/itération
Pair-programming/Peer review uniquement pour les tâches compliquées
Relecture partielle du code : des défauts nous échappaient
Pas d’appropriation du standard et des bonnes pratiques : l’équipe
apprend peu de ce genre de revues
La revue de code avant chez Axa
9 | Titre de la présentation I 30 Septembre 2014 MENTION DE CONFIDENTIALITÉ

10. Chaque ligne de code est revue avant la mise en production
Toute l’équipe de Dev revoit le code
Maintenant au WebCenter
10 | Titre de la présentation I 30 Septembre 2014 MENTION DE CONFIDENTIALITÉ

11. Les autres bénéfices de
la revue de code

12. Qualité intrinsèque du code

13. Propriété collective du code
13 |

14. Facilite l’apprentissage
14 |

15. Dur avec le code, doux avec les gens
15 | Titre de la présentation I 30 Septembre 2014 MENTION DE CONFIDENTIALITÉ
Tu as fait une
erreur !
Je crois que j’ai
trouvé un bug
quand on met une
chaîne vide.
Ton code c’est de
la @(§"* !
Ce code ne
respecte pas nos
standards, on s’est
fixé pas plus de 30
lignes par méthode.

16. Avoir peur d’être jugé personnellement
Ne pas oser le feedback sur le code
Faire des remarques peu pertinentes
Abandonner la pratique (pression projet)
Les difficultés au début
16 | Titre de la présentation I 30 Septembre 2014 MENTION DE CONFIDENTIALITÉ

17. Trouver le bon process, la bonne approche
Il faut opérer un changement de culture au sein de l’entreprise
Au sein des équipes de développement également : Egoless
programming
Il faut des leaders dans les équipes pour maintenir la pratique
Ce que nous avons appris
17 | Titre de la présentation I 30 Septembre 2014 MENTION DE CONFIDENTIALITÉ

18. Résultats après 4 mois de mise en pratique
18 | Titre de la présentation I 30 Septembre 2014 MENTION DE CONFIDENTIALITÉ
Pour une release de début Février à fin Mai sur une équipe projet :
20 revues de code collectives
126 défauts remontés
Parmi ceux-là, 5 anomalies très sévères !
6,6 défauts/revue (hors typo)
Des standards qui évoluent continuellement
Une montée en compétence plus rapide des nouveaux arrivants sur le projet

19. Combien ça coute et combien ça rapporte ?
Quels sont les liens entre la revue de code et les standards de qualité ?
Comment se prépare et s’anime une revue de code chez Axa ?
Comment on suit les défauts détectés ?
En quoi « dette technique » et « mauvais code » c’est différent ?
Ce que nous n’avons pas eu le temps d’aborder
19 | Titre de la présentation I 30 Septembre 2014 MENTION DE CONFIDENTIALITÉ

20. BEHAVIOR DRIVEN DEVELOPMENT
/ TEST DRIVEN DEVELOPMENT
MENTION DE CONFIDENTIALITÉ
22 Juin 2016 / Petit Déjeuner OCTO - Ronchin

21. Behavior Driven Development / Test Driven Development

22. Effectuer un Virement
Virement simple
Virement hors provision
Virement plafonné
• RG1 : virement simple, je vire X€ d'un compte
A vers le compte B, le solde est impacté dans
les deux comptes.
• RG2 : virement hors provision, solde A
insuffisant
• RG3 : virement plafonné
• Scenario: Virement simple
• Given j'ai un compte cheque avec un solde de 500€
• Given j'ai un compte épargne avec un solde de 0€
• When j'effectue un virement de 100€ du compte cheque
vers le compte épargne
• Then le solde du compte cheque est 400€
• Then le solde du compte épargne est 100€
• Then le virement est confirmé
• Scenario: Virement hors provision
• Given j'ai un compte cheque avec un solde de 50€
• Given j'ai un compte épargne avec un solde de 1000€
• When j'effectue un virement de 100€ du compte cheque
vers le compte épargne
• Then le solde du compte cheque est 50€
• Then le solde du compte épargne est 1000€
• Then le virement est refusé pour motif hors provision
• Scenario: Virement plafonné
• Given j'ai un compte cheque avec un solde de 1000€
• Given j'ai un compte épargne avec un solde de 0€
• Given la limite de virement est 500€
• When j'effectue un virement de 501€ du compte cheque
vers le compte épargne
• Then le solde du compte cheque est 1000€
• Then le solde du compte épargne est 0€
• Then le virement est refusé pour motif plafond dépassé
Atelier de revue du besoin « effectuer un virement »

23. Ficher Feature pour documenter et piloter les développements
27/06/201623

24. Génération des « steps » et implémentation du premier scénario
27/06/201624

25. Tests TDD pour implémenter la méthode de virement
27/06/201625

26. Implémentation des 2 scénarios restants
27/06/201626

27. Méthode implémentée, tous les TU et Scénarios sont OK
27/06/201627

28. En Résumé
27/06/201628
En découvrant ensemble les scénarios et les
règles, nous bâtissons une compréhension
commune et forte
Les scénarios servent d’exemples pour
piloter le développement
Les scénarios sont attachés à des tests
automatisés qui démontrent l’avancement
et préviennent la régression
Les scénarios et règles documentent la
fonctionnalité de manière permanente et
vivante…

29. Merci