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

668 views

Published on

Retrouvez les slides de présentation du petit-déjeuner OCTO du 13 Octobre, axé sur la qualité de code. Présenté et animé par Christophe Thibaut d'OCTO, découvrez le retour d'expérience d'AXA avec Emmanuel Lehmann et Antoine Blancke.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
668
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
29
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • MEET Gus
    THERE WERE BUGS IN THE APP HE DELIVERED
    WHY ? BECAUSE THERE WERE ERRORS IN HIS CODE
    WHY? BECAUSE HE DIDN'T LOCATE THEM AND REMOVE THEM BEFORE SHIPPING
    WHY? BECAUSE HE DIDN'T HAVE ENOUGH TIME
    WHY? BECAUSE HE HAD MORE TO DO THAN HE HAD PLANNED
    WHY? BECAUSE HE UNDERESTIMATED THE DIFFICULTY OF THE TASK
    AND THOSE CAUSES HAVE A COMPOUND EFFECT
  • Les T.U. c'est bien, mais là on n'a pas le temps: il faut livrer (paradoxe pas le temps de s'améliorer)
    Les revues ? Encore des réunions inutiles... (idem)
    Quel est le R.O.I d'avoir des tests unitaires ? (idem)
  • Ce n'est pas un bug, c'est un change request (blame)
    La spécification n'était pas assez claire (blame)
    Si vous changez tout le temps d'avis.. (blame)
    Si la vélocité a baissé, ce n'est pas de notre fait (blame)
  • La recette dure un peu plus longtemps que prévu (confusion)
    Nous cherchons un tech lead senior pour sortir le projet (illusion de simplicité, absence de pensée systémique)
    L'équipe A travaille dur souvent jusqu'à 20h pour sortir le projet, alors que dans l'équipe B, à 18h il n'y a plus personne.

  • (PAUSE)
    ALORS QUE FAIRE?
    IL N’Y PAS DE SOLUTION MIRACLE MAIS POUR AUTANT INUTILE DE SE JETER DANS LE PRECIPICE
  • analogie des jeux : trouver une image de jeu ou sport
  • INVITÉS DE DERNIÈRE MINUTE?
    3 OPTIONS:
    OUI, MAIS DANS 2 HEURES
    OUI, JUSTE LE TEMPS D’ACHETER DES COUVERTS EN PLASTIQUE
    NON, CHEZ MOI C’EST TROP PETIT
    QUAND LA MAINTENABILITÉ N’EST PAS MAINTENUE:
    LES NOUVELLES FONCTIONNALITÉS COÛTENT CHER
    OU BIEN ELLES SONT VITE FAIT MAL FAIT, BUGUÉES
    OU BIEN LES DÉVELOPEURS DISENT: NON C’EST PAS POSSIBLE, IL FAUDRAIT TOUT RÉÉCRIRE
    C’EST PLUS SIMPLE D’AJOUTER UN 7ÈME COPIER/COLLER SUR UN CODE QUI EN CONTIENT DEJA 6 QUE DE FACTORISER LE CODE.
  • CA NE VA PAS ETRE FACILE:
    LE CLIENT VEUT SES FONCTIONALITES DEBOGUEES
    LE DIRECTEUR NE VEUT PAS PERDRE DE SOUS SUR CE PROJET
    LE DEVELOPPEUR SE DIT QUE CE N’EST PAS LE MOMENT DE SE POSER
    LA SEULE ACTIVITE QU’ON NE PEUT PAS ABANDONNER EVIDEMMENT C’EST D’ÉCRIRE DU CODE ET DE DÉBOGUER DU CODE
    MAIS TOUS LES PROBLEMES DE QUALITE SE TRADUISENT INVARIABLEMENT PAR DES PROBLEMES DE TEMPS
    LE PROJET EN RETARD = PROBLÈMES DE QUALITE
    LES BUGS QUI DEFERLENT C’EST UN SYMPTOME
    LA CAUSE PROFONDE TIENT A LA QUALITE DU CODE
    C’EST A DIRE À LA QUESTION: EST-CE QUE L’ON PRATIQUE LES PRATIQUES DE BASE?
    UNE REVUE DE CODE NE CORRIGE PAS LES BUGS EN RECETTE, MAIS ELLE LES PREVIENT.
    LES REVUES DE CODES SONT PLUS EFFICACES QUE LES TESTS
    MAIS ON NE SAIT PAS LES FAIRE
  • (parler peu) ou bien animation (moins d'objets) et commenter
    EN RÉSUMÉ:
    EN PRATIQUANT LES BRIQUES DE BASE, COMME IL FAUT, VOUS GAGNEZ DE NOUVELLES APTITUDES
    CE N’EST PAS SEULEMENT DES POINTS D’EXPÉRIENCE, OU PLUTÔT: 10 ANS D’HABITUDES, CE N’EST PAS 10 ANS D’EXPÉRIENCE
    EN PRATIQUANT DÉLIBÉREMENT, VOTRE ENVIRONNEMENT ACQUIERT DES PROPRIÉTÉS INTÉRESSANTES, QUE L’ON PEUT RÉSUMER SOUS LE TERME « CULTURE DE LA QUALITÉ »
    RETIRER LES PRATIQUES DE BASE, ET VOUS AVEZ JUSTE UN DISCOURS
  • Pour changer le logo en pied de page, aller dans AFFICHAGE > Masque > Masque des diapositives : remplacer le logo en place par le logo de votre entité.
    Pour éditer la mention de confidentialité, aller dans le menu INSERTION > En-tête et pied de page, et remplir le niveau désiré.
  • La couleur de fond peut être changée avec les commandes de couleur d'arrière-plan de slide (à choisir dans les couleurs de la palette prédéfinie, de préférence)
    (clic droit sur le fond de la slide +  "Mise en forme de l'arrière-plan").
  • L'image de fond peut être changée avec les commandes de couleur d'arrière-plan de slide
    (clic droit sur la slide + "Mise en forme de l'arrière-plan").
  • Pour changer le logo en pied de page, aller dans AFFICHAGE > Masque > Masque des diapositives : remplacer le logo en place par le logo de votre entité.
    Pour éditer la mention de confidentialité, aller dans le menu INSERTION > En-tête et pied de page, et remplir le niveau désiré.
  • Pour changer le logo en pied de page, aller dans AFFICHAGE > Masque > Masque des diapositives : remplacer le logo en place par le logo de votre entité.
    Pour éditer la mention de confidentialité, aller dans le menu INSERTION > En-tête et pied de page, et remplir le niveau désiré.
  • Petit-déjeuner "Cultiver l'art du code de qualité... Afin de livrer plus vite des applis moins coûteuses"

    1. 1. Vers une culture de la qualité 13 Octobre 2016 cthibaut@octo.com
    2. 2. 1) La qualité, combien ça coûte ? 500 000 000,00 $ / AN
    3. 3. ✅ ❌ Les projets abandonnés pour cause de non qualité coûtent 15% plus cher que les projets réussis de taille/complexité équivalente. La qualité, combien ça coûte en plus ?
    4. 4. 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.23 Conception 1.25 85% 0.19 Code 1.75 95% 0.09 Documents 0.60 80% 0.12 Régressions 0.40 70% 0.12 TOTAL 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.
    5. 5. 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ûtGlobal
    6. 6. 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
    7. 7. 2) D'où viennent les problèmes de qualité ?
    8. 8. 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 erreurs 3. On n'analyse pas les causes profondes 4. On n'est pas suffisamment en sécurité pour apprendre de nos erreurs 5. Pas d'anticipation: on n'agit que dans la crise
    9. 9. 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 X X
    10. 10. Symptômes d'une culture du Bug Fix : pas le temps d'améliorer
    11. 11. Symptômes d'une culture du Bug Fix : Cloisonnement / Blâme
    12. 12. Symptômes d'une culture du Bug Fix : Confusions et Illusions
    13. 13. 3) Aurais-tu des conseils à emporter?
    14. 14. Formez (vous) en permanence Deming
    15. 15. Maintenez la Maintenabilité Weinberg
    16. 16. Gardez le capDeming
    17. 17. Chassez la crainte Tant qu'il y a de la peur, vos chiffres sont faux. Deming
    18. 18. Pair Programming Test Driven Development Revue de Code entraide propriété collective du code refactoring constant standard correction efficace du code non régression confiance amélio-ration continue CULTURE DE LA QUALITE cohésion d’équipe qualité du design dialogue prévention des défauts
    19. 19. RETOUR D’EXPERIENCE AXA AMELIORATION DE LA QUALITE DES DEVELOPPEMENTS 22 Juin 2016 / Petit Déjeuner OCTO - Ronchin MENTION DE CONFIDENTIALITÉ
    20. 20. 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
    21. 21. Dur avec le code, Doux avec les gens
    22. 22. LA REVUE DE CODE MENTION DE CONFIDENTIALITÉ 22 Juin 2016 / Petit Déjeuner OCTO - Ronchin
    23. 23. La revue de code est-elle pratiquée ?
    24. 24. Régulièrement ?
    25. 25. Par toute l’équipe de Dev en même temps ?
    26. 26. Qui fait des revues de code ?
    27. 27. 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 | Titre de la présentation I 30 Septembre 2014MENTION DE CONFIDENTIALITÉ
    28. 28. Chaque ligne de code est revue avant la mise en production Toute l’équipe de Dev revoit le code Maintenant au WebCenter 30 | Titre de la présentation I 30 Septembre 2014MENTION DE CONFIDENTIALITÉ
    29. 29. Les autres bénéfices de la revue de code
    30. 30. Qualité intrinsèque du code
    31. 31. Propriété collective du code 33 |
    32. 32. Facilite l’apprentissage 34 |
    33. 33. Dur avec le code, doux avec les gens 35 | Titre de la présentation I 30 Septembre 2014MENTION 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.
    34. 34. 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 | Titre de la présentation I 30 Septembre 2014MENTION DE CONFIDENTIALITÉ
    35. 35. 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 | Titre de la présentation I 30 Septembre 2014MENTION DE CONFIDENTIALITÉ
    36. 36. Résultats après 4 mois de mise en pratique 38 | Titre de la présentation I 30 Septembre 2014MENTION 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
    37. 37. 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 | Titre de la présentation I 30 Septembre 2014MENTION DE CONFIDENTIALITÉ
    38. 38. BEHAVIOR DRIVEN DEVELOPMENT / TEST DRIVEN DEVELOPMENT MENTION DE CONFIDENTIALITÉ 22 Juin 2016 / Petit Déjeuner OCTO - Ronchin
    39. 39. Behavior Driven Development / Test Driven Development
    40. 40. 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 »
    41. 41. Ficher Feature pour documenter et piloter les développements 19/10/2016 43
    42. 42. Génération des « steps » et implémentation du premier scénario 19/10/2016 44
    43. 43. Tests TDD pour implémenter la méthode de virement 19/10/2016 45
    44. 44. Implémentation des 2 scénarios restants 19/10/2016 46
    45. 45. Méthode implémentée, tous les TU et Scénarios sont OK 19/10/2016 47
    46. 46. En Résumé 19/10/2016 48 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…
    47. 47. Merci

    ×