Upgrade to Pro — share decks privately, control downloads, hide ads and more …

La qualité d’aujourd’hui est la productivité de demain — Orange Innovation School mars 2021

La qualité d’aujourd’hui est la productivité de demain — Orange Innovation School mars 2021

-> Comprendre comment intégrer les pratiques de qualité dans le logiciel sans perte sur la productivité ?
-> Quelles pratiques de développement pour améliorer la qualité à long terme du logiciel ?

Beb422437c1dfb5366f197919e41ac50?s=128

Arnaud LEMAIRE
PRO

March 30, 2021
Tweet

Transcript

  1. Introduction aux pratiques crafts dans le logiciel La qualité d’aujourd’hui

    est la productivité de demain @lilobase 
 www.lilobase.me VP, Chief Architect Arnaud LEMAIRE
  2. Chapitre 1 : Dette technique

  3. Dette technique, la définition « The obligations incurred by a

    software organization when it chooses an expedient design or construction approach that increases complexity and is more costly in the long term » - Ward Cunningham
  4. Dette technique, un choix éclairé pour une accélération temporaire 1.

    Est-ce une décision business ? 2. Avez vous le temps de refaire cette fonctionnalité ? 3. Donnez-vous carte blanche à l’équipe de développement pour la rembourser ? Temps Fonctionnalités Prise de dette Remboursement
  5. Dette technique, ne prenez pas un crédit subprime Temps Fonctionnalités

    Prise de dette Prise de dette Lenteurs Régressions Bugs Développements très lents Démissions
  6. Dette technique ou logiciel décrépit ?

  7. Dette technique, Les lois de Lehman 1. Continuing Change :

    a system must be continually adapted or it becomes progressively less satisfactory. 2. Continuing Growth : the functional content of a system must be continually increased to maintain user satisfaction over its lifetime. 3. Increasing Complexity : as a system evolves, its complexity increase unless work is done to maintain or reduce it. 4. Declining Quality : the quality of a system will appear to be declining unless it is rigorously maintained and adapted to operational environment changes Le logiciel, un objet technique sous tension permanente :
  8. Dette technique, l’entropie du logiciel Ajout de Code Augmentation de

    la complexité L’entropie du logiciel augmente Décrépitude du logiciel
  9. Dette technique, normalisation de la déviance

  10. Laissez votre logiciel mourir Requirements / Analysis 1 Design /

    Architecture 2 Development 3 Test 4 Maintenance 5
  11. Laissez votre logiciel mourir Development 1 Death 2 Cherchez à

    optimiser le renouvellement et non l’évolutivité du logiciel
  12. None
  13. Chapitre 2 : Le cercle infernal

  14. Le cercle infernal Les temps de développement sont trop longs

    L’équipe n’arrive pas à fournir à temps les fonctionnalités L’équipe génère de la « dette technique » pour accélérer Il faut prendre le temps de résorber la dette
  15. Le cercle infernal, la version agile On arrive à la

    fi n du sprint La vélocité n’est pas bonne, il reste beaucoup de user story L’équipe génère de la « dette technique » pour accélérer Il faut résorber la dette au début du sprint suivant
  16. Le cercle infernal, Avalanche Driven Development

  17. Le cercle infernal, jusqu’à la sortie de route La complexité

    du système le rend ingérable Panique / Code legacy Il faut prendre le temps de résorber la dette Mais on n’a pas le temps
  18. Le cercle infernal, le code legacy « Code that is

    too scary to update & too pro fi table to delete » - Dylan Beattie
  19. Le cercle infernal, refactoring Est-il plus important d’aller chez le

    dentiste deux fois par an ou de se laver les dents tous les jours ?
  20. Le cercle infernal, laissez du mou Occupation à 80% (À

    l’extrême limite : 90%) Ça augmente la productivité
  21. Chapitre 3 : Avoir le bon horizon des évènements

  22. Le bon horizon des évènements, évitez le court terme Temps

    Fonctionnalités Option A Temps Fonctionnalités Option B
  23. Le bon horizon des évènements, évitez le court terme Temps

    Fonctionnalités Option A Temps Fonctionnalités Option B
  24. Le bon horizon des évènements, la qualité est gratuite Temps

    Fonctionnalités Quelques semaines à quelques mois
  25. Le bon horizon des évènements, la qualité est gratuite Les

    pratiques agile et crafts n’ont pas pour objectif d’offrir une réduction des temps de développement, mais de maintenir dans le temps la productivité de l’équipe.
  26. Le bon horizon des évènements, la surqualité n’existe pas

  27. Le bon horizon des évènements, ne confondez pas causes et

    symptômes Les bugs, régressions fonctionnelles, un code dif fi cile à maintenir sont des symptômes L’absence de pratiques, une culture technique défaillante, des équipes techniques sous pression sont les causes Sans traiter les cause, les symptômes ne feront que réapparaitre.
  28. Le bon horizon des évènements, la loi de Conway «

    les organisations qui conçoivent des systèmes [...] tendent inévitablement à produire des designs qui sont des copies de la structure de communication de leur organisation. » Les RH sont les premiers architects de votre système d’information
  29. Le bon horizon des évènements, la loi de Conway

  30. Le bon horizon des évènements, ce n’est pas le cahier

    des charges qui part en production « It is not stack-holder knowledge but developer’s ignorance that get deployed in production » Client Chef de projet fonctionnel Chef de projet technique Solution Architecte Architect logiciel Développeurs Jeu du téléphone, Enterprise Edition™ - Alberto Brandolini
  31. Chapitre 4 : L’excellence technique est un pré-requis à toute

    démarche agile
  32. Excellence technique, la prédictibilité Vous n’avez pas besoin de devenir

    meilleur à estimer les temps de développement Vous devez améliorer la prédictibilité de vos développement L’excellence technique permet d’assurer une meilleure prédictibilité des développements futur.
  33. Excellence technique, validation « The best way to predict the

    futur it to implement it » Validation et non suppositions et illusions - Abraham Lincoln Faîtes de plus petits mensonges
  34. Excellence technique, raccourcissez la boucle de feedback Market Team Working

    Software Company User Une fonctionnalité n’a de la valeur qu’une fois livrée en production, avant ça ce n’est que du rebut.
  35. Excellence technique, la fabrication du logiciel ne nécessite aucun humain

    1. Conception 2. Fabrication 3. Exploitation Le Compilateur / Interpéteur Le code source
  36. Excellence technique, l’intégration continue Continuous Integration Automated testing Stakeholder involvment

    Code management Deployment automation Unit Testing Integrated tests Infra As Code Coding standard Version Control L’intégration continue permet d’aligner l’ensemble des pratiques
  37. Excellence technique, l’intégration continue Continuous Integration Automated testing Stakeholder involvment

    Code management Deployment automation Unit Testing Integrated tests Coding standard Version Control Infra As Code
  38. Excellence technique, l’intégration continue Continuous Integration Automated testing Stakeholder involvment

    Code management Deployment automation Unit Testing Integrated tests Coding standard Version Control Infra As Code
  39. Excellence technique, pair programming 1. Transmission des connaissances et montée

    en niveau accélérée des équipes de développement 2. Moins de défaut dans le code livré 3. Evite les code reviews bloquantes 4. Limite votre bus factor Le pair programming, un gain de temps énorme
  40. www.lilobase.me Thanks ! @lilobase alemaire@quantis.fr https://roti.express/r/xsnild