Upload
octo-technology
View
582
Download
1
Embed Size (px)
Citation preview
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
MENTION DE CONFIDENTIALITÉ
22 Juin 2016 / Petit Déjeuner OCTO - Ronchin
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É
Titre de la présentation I 30 Septembre 2014
Chaque ligne de code est revue avant la mise en production
Toute l’équipe de Dev revoit le code
Maintenant au WebCenter
30 | MENTION DE CONFIDENTIALITÉ
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 |
Titre de la présentation I 30 Septembre 2014
Dur avec le code, doux avec les gens
35 | 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.
Titre de la présentation I 30 Septembre 2014
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
36 | MENTION DE CONFIDENTIALITÉ
Titre de la présentation I 30 Septembre 2014
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
37 | MENTION DE CONFIDENTIALITÉ
Titre de la présentation I 30 Septembre 2014
Résultats après 4 mois de mise en pratique
38 | 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
Titre de la présentation I 30 Septembre 2014
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
39 | MENTION DE CONFIDENTIALITÉ
BEHAVIOR DRIVEN DEVELOPMENT/ TEST DRIVEN DEVELOPMENT
MENTION DE CONFIDENTIALITÉ
22 Juin 2016 / Petit Déjeuner OCTO - Ronchin
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