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

Chapitre 1 : Dette technique

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

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

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

Dette technique ou logiciel décrépit ?

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 :

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

Dette technique, normalisation de la déviance

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

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

No content

Chapitre 2 : Le cercle infernal

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

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

Le cercle infernal, Avalanche Driven Development

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

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

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 ?

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

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

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

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

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

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.

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

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.

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

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

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

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

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.

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

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.

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

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

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

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

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

www.lilobase.me Thanks ! @lilobase alemaire@quantis.fr https://roti.express/r/xsnild