Agile tour Lille 2015 allies ensemble contre les defauts
1. Merci à nos sponsors #AgileTourLille
Alliés contre les défauts
Pourquoi et comment nous relisons ensemble le code que nous produisons
2. Alliés contre les défauts
Pourquoi et comment nous relisons, ensemble,
le code que nous produisons.
3. Qui sommes nous ?
Antoine Blancke
Développeur au Web Center AXA
https://www.axawebcenter.fr/
Julien Jakubowski
Consultant-codeur – Octo à Lille
http://www.octo.com/
4. Le WebCenter d’AXA
10 équipes de développement
150 développeurs presque tous internes
Objectif : être une référence dans la qualité /
maintenabilité
5. AXA et OCTO
Nicolas Moreau, DG AXA France : “AXA France a pour ambition de devenir la
meilleure société de services du marché”
Cela implique d’être excellent dans la qualité des logiciels produits au
WebCenter.
Mise en place d’un modèle de suivi de l’amélioration de la qualité basé sur 2
indicateurs de résultat (= les KPI)
6. AXA et OCTO
14 J de formation par développeur sur 3 mois + accompagnement de 9 mois
sur ces pratiques :
● Revue de code
● Développement piloté par les tests (TDD)
● Travailler sur le code existant (legacy code)
● Standards de qualité (clean code)
● Spécification par l’exemple (BDD)
● Communication et feedback efficace
7. La revue de code et vous ?
● Qui fait relire son code par un collègue ?
● Régulièrement ?
● Par n’importe quel développeur ?
● Par toute l’équipe en même temps ?
8. Les revues de code avant…
Audit de code fait par un Tech Leader à chaque fin de sprint
Pair programming / peer review pour les tâches compliquées
Relecture partielle du code : des défauts nous échappaient
Pas d’appropriation du standard : l’équipe apprend peu de ses revues
9. Maintenant au WebCenter
Chaque ligne de code est revue avant la mise en production
Toute l’équipe de dev revoit le code
Pendant les revues, l’équipe ne code pas ⇒ prend 5% du budget de dev des
projets.
10. 5% du budget ???
A quelles réactions s’attendre quand on demande 5% du budget de dev ?
“t’es gentil, mais non”
http://memegenerator.net/Correction-Guy
“ça va pas la tête ? On ne tiendra jamais le planning !”
http://memegenerator.net/Anxiety-Cat
14. Trouver un maximum de défauts, au plus tôt
Revue de code ⇒ 50% de réduction des défauts
Exemple chez CISCO :
15. Le R.O.I. de la revue de code
R.O.I. de 4 pour 1
Raytheon:
- sans revue : 43% du coût des projets logiciels = correction de
défauts
- après que les revues soient généralisées : 5% du coût
21. Revue collective Revue par un pair Pair programming
Efficience (nombre de
défauts détectés)
Propriété collective du
code
Amélioration de la
qualité, évolution des
standards
Facilité de mise en
oeuvre
A
A
A
B B
B A
A A
Et les autres formats de revue ?
C A B
Les formats de revue
26. Préparation de la revue
❏Invitation de l’équipe de dév (au moins un jour à l’avance)
❏Gérer la logistique : Salle + matériels (vidéoprojecteur, grand écran)
❏Indiquer les stories qui vont passer en revue
❏Préparer le code à présenter
30. Et ensuite ?
Nous statuons ensemble sur le sort du code
Les défauts sont consignés et intégrés dans notre flux Kanban
Les standards sont mis à jour au besoin
Les défauts sont corrigés et validés avec une peer-review
33. Dur avec le code, doux avec les gens
Tu as fait une erreur
!
Ton code c’est de la
@(§"* !
Je crois que j’ai
trouvé un bug quand
on met une chaîne
vide.
Ce code ne respecte
pas nos standards,
on avait dit pas plus
de 30 lignes par
méthode.
34. Le modérateur qui perd le contrôle
http://static.tvtropes.org/pmwiki/pub/images/1084894-440px_hulk_13_super.jpg
37. Ce qui est difficile, surtout au début
Avoir peur d’être jugé personnellement
Ne pas oser le feedback sur le code
Faire des remarques peu pertinentes
Abandonner la pratique (pression projet)
38. Ce que nous avons appris
Critiquer le code et non la personne : changement de culture –
Egoless programming
Au début, fixer le rôle de modérateur sur certaines personnes
Ne pas hésiter à échanger sur le code même avant les revues
Il faut des leaders pour maintenir la pratique tech lead
40. Résultats après 4 mois de pratique
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
41. Pour en savoir plus
http://blog.octo.com/revue-de-code-quel-format-choisir/
http://blog.octo.com/comment-rater-vos-revues-de-code-episode-1/ (série de 3 articles)
42. Pour en savoir plus
Antoine
Blancke
Michel Domenjoud Julien Jakubowski
⇒ Stands OCTO et AXA
⇒ Meetup Software Craftsmanship Lille
"Instead of asking why a piece of software is using 1970s technology, start asking why software is
ignoring 40 years of accumulated wisdom."