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 ?

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