Petit-déjeuner "Cultiver l'art du code de qualité... Afin de livrer plus vite des applis moins coûteuses"

Vers une culture de la qualité

13 Octobre 2016

[email protected]

1) La qualité, combien ça coûte ?Non-

500 000 000,00 $ / AN

✅100

❌115

Les projets abandonnés pour cause de non qualité coûtent15% plus cher que les projets réussis de taille/complexité équivalente.

Capers JonesSoftware Quality: A

Survey of the

State of the Art

Non-La qualité, combien ça coûte en plus ?

Où sont les problèmes ?Quels sont les remèdes efficaces ?

Origine des Défauts

Défauts / P.F % Défauts Eliminés avant Livraison

# Défauts Livrés / PF

Exigences 1.00 77% 0.23Conception 1.25 85% 0.19Code 1.75 95% 0.09Documents 0.60 80% 0.12Régressions 0.40 70% 0.12TOTAL 5.00 85% 0.75

Données exprimées en termes de Points de Fonctions.Les PF montrent tout type de défaut, pas seulement les défauts du code.Défauts dans le code = 35% de tous les défauts.

Quel est l'impact de la NQ sur le coût global ?

La mauvaise qualité revient moins cher jusqu'à la fin de la phase de programmation;

après quoi c'est la bonne qualité qui revient moins

cher.

Dette Technique

Coût

Glo

bal

Prévenir ou Corriger ?

• Prévenir : harnais de tests unitaires– détecte un défaut en moins de 10 mn– peut couvrir jusqu'à 80% du code

• Prévenir : revue de code– prévient plus de défauts que tout autre méthode

• Corriger : – debug + test + gestion : de 0.25 à 3 JH par défaut

30% du

budget

des dev.

5% du

budget

des dev.

50% du

budget

des dev.

2) D'où viennent les problèmes de qualité ?

Pourquoi persiste t'on à corriger nos erreurs au lieu de les prévenir ?

1. On n'est pas formé aux pratiques de qualité2. On ne mesure pas le coût des erreurs3. On n'analyse pas les causes profondes4. On n'est pas suffisamment en sécurité pour

apprendre de nos erreurs5. Pas d'anticipation: on n'agit que dans la crise

D'où viennent les "bugs" ?

bugs

erreurs de program-mation

complexitésous

estimée pas de T.U,zéro revue

pression sur le temps

XX

Symptômes d'une culture du Bug Fix : pas le temps d'améliorer

Symptômes d'une culture du Bug Fix : Cloisonnement / Blâme

Symptômes d'une culture du Bug Fix : Confusions et Illusions

3) Aurais-tu des conseils à emporter?

Formez (vous) en permanenceDeming

Maintenez la MaintenabilitéWeinberg

Gardez le capDeming

Chassez la crainteTant qu'il y a de la peur, vos chiffres sont faux.

Deming

Pair Programming

Test DrivenDevelopment

Revue de Code

entraide

propriété collective du code

refactoringconstant standard

correction efficace du code

non régression

confianceamélio-ration

continue

CULTURE DE LA

QUALITE

cohésion d’équipe

qualité du

designdialogue

prévention des

défauts

RETOUR D’EXPERIENCE AXA AMELIORATION DE LA QUALITE DES

DEVELOPPEMENTS

22 Juin 2016 / Petit Déjeuner OCTO - Ronchin

MENTION DE CONFIDENTIALITÉ

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

Dur avec le code,Doux avec les gens

LA REVUE DE CODE



La revue de code est-elle pratiquée ?

Régulièrement ?

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

Qui fait des revues de code ?

Titre de la présentation I 30 Septembre 2014

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

29 | MENTION DE CONFIDENTIALITÉ


Chaque ligne de code est revue avant la mise en production

Toute l’équipe de Dev revoit le code

Maintenant au WebCenter


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

Qualité intrinsèque du code

Propriété collective du code

33 |

Facilite l’apprentissage

34 |


Dur avec le code, doux avec les gens


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.


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



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



Résultats après 4 mois de mise en 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


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


BEHAVIOR DRIVEN DEVELOPMENT/ TEST DRIVEN DEVELOPMENT



Behavior Driven Development / Test Driven Development

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 »

03/05/2023 43

Ficher Feature pour documenter et piloter les développements

03/05/2023 44

Génération des « steps » et implémentation du premier scénario

03/05/2023 45

Tests TDD pour implémenter la méthode de virement

03/05/2023 46

Implémentation des 2 scénarios restants

03/05/2023 47

Méthode implémentée, tous les TU et Scénarios sont OK

03/05/2023 48

En Résumé

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…

Merci

Technology

Petit-déjeuner "Cultiver l'art du code de qualité... Afin de livrer plus vite des applis moins coûteuses"