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 ?

Arnaud LEMAIRE

March 30, 2021
Tweet

More Decks by Arnaud LEMAIRE

Other Decks in Programming

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

    View full-size slide

  2. Chapitre 1 : Dette technique

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  6. Dette technique ou logiciel
    décrépit ?

    View full-size slide

  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 :

    View full-size slide

  8. Dette technique, l’entropie du logiciel
    Ajout de Code
    Augmentation
    de la complexité
    L’entropie du
    logiciel augmente
    Décrépitude
    du logiciel

    View full-size slide

  9. Dette technique, normalisation
    de la déviance

    View full-size slide

  10. Laissez votre logiciel mourir
    Requirements / Analysis
    1
    Design / Architecture
    2
    Development
    3
    Test
    4
    Maintenance
    5

    View full-size slide

  11. Laissez votre logiciel mourir
    Development
    1
    Death
    2
    Cherchez à optimiser le renouvellement et
    non l’évolutivité du logiciel

    View full-size slide

  12. Chapitre 2 : Le cercle infernal

    View full-size slide

  13. 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

    View full-size slide

  14. 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

    View full-size slide

  15. Le cercle infernal,


    Avalanche Driven Development

    View full-size slide

  16. 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

    View full-size slide

  17. Le cercle infernal, le code
    legacy
    « Code that is too scary to update
    & too pro
    fi
    table to delete »
    - Dylan Beattie

    View full-size slide

  18. 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 ?

    View full-size slide

  19. Le cercle infernal, laissez du
    mou
    Occupation à 80%
    (À l’extrême limite : 90%)
    Ça augmente la productivité

    View full-size slide

  20. Chapitre 3 : Avoir le bon horizon des
    évènements

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  24. 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.

    View full-size slide

  25. Le bon horizon des évènements,
    la surqualité n’existe pas

    View full-size slide

  26. 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.

    View full-size slide

  27. 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

    View full-size slide

  28. Le bon horizon des évènements,
    la loi de Conway

    View full-size slide

  29. 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

    View full-size slide

  30. Chapitre 4 : L’excellence technique est
    un pré-requis à toute démarche agile

    View full-size slide

  31. 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.

    View full-size slide

  32. 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

    View full-size slide

  33. 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.

    View full-size slide

  34. Excellence technique, la fabrication du
    logiciel ne nécessite aucun humain
    1. Conception 2. Fabrication 3. Exploitation
    Le Compilateur /
    Interpéteur
    Le code source

    View full-size slide

  35. 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

    View full-size slide

  36. 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

    View full-size slide

  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

    View full-size slide

  38. 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

    View full-size slide

  39. www.lilobase.me
    Thanks !
    @lilobase
    [email protected]
    https://roti.express/r/xsnild

    View full-size slide