XP : ce célèbre inconnu Extreme Programming Thierry Cros http://etre-agile.com 1
XP : plus qu'agile Pourquoi XP Installer XP Rôles et Cycle de Vie Pratiques : Coder et livrer Développement Responsable Valeurs et Principes de l'extreme Programming Pratiques : Conception Pratiques : Facteur humain Pratiques : Exigences et Planification http://etre-agile.com 2
Idées reçues... XP cet inconnu célèbre XP, c'est pour les Développeurs «fous» XP, cela ne fonctionne que sur de petits projets sans enjeux XP, c'est du TDD et du pair programming c'est à dire 2 personnes pour faire le boulot d'une seule... XP c'est juste un complément à Scrum XP, on n'écrit aucune doc XP c'est anti qualité XP c'est impossible dans un domaine régulé (aéronautique, pharmaceutique...) http://etre-agile.com 3
Pourquoi XP? Pourquoi un «soft»? Améliorer un process métier «Time to Market» Répondre aux changements Projets : 2/3 d'échecs Maîtriser les variables «projet» Coût Nouveaux matériaux Des cartes perforées... à Eclipse Logiciel ou software?... Un matériau souple, malléable : en tironsnous vraiment partie Soft : pâte à modeler http://etre-agile.com 4
XP : un nom pas vraiment marketing... Mais qui annonce la couleur Extreme Programming Ce sont donc des extrémistes.. Des révolutionnaires! Ah bon... On ne conçoit pas, on ne teste pas... http://etre-agile.com 5
XP : «programming» Quelles activités apportent vraiment une Valeur Ajoutée? Programming «Coder» (Java...) Paramétrer Programming = Réaliser le produit Remettre en cause, réduire voire éliminer les activités «non V.A.» http://etre-agile.com 6
XP : «extreme» programming Une fois les activités «non VA» réduites, quelles activités conserver et dans quelle proportion? Dialogues Tests Conception Relecture Extreme Programming = «Pousser à fond» certaines activités http://etre-agile.com 7
Extreme Programming = centré réalisation, ie Valeur Métier http://etre-agile.com 8
XP : Extreme Programming XP : pousser à fond les activités qui ont prouvé leur utilité. XP Un ensemble complet pour le développement de systèmes à forte composante logicielle. Rôles Cycle de Vie Valeurs et Principes Pratiques Gestion des exigences et Planification Facteur humain, Équipe complète Conception Réaliser et Livrer XP :à l'origine de l'agilité (cf historique du Manifeste) http://etre-agile.com 9
XP : «la» synthèse L'originalité d'xp réside Dans la synthèse faite de principes et pratiques Dans l'apport de pratiques spécifiques (stories, TDD...) http://etre-agile.com 10
Exemple de principe XP L'économie, une préoccupation permanente XP v1 : «Petit investissement de départ» XP v2 : Science de l'économie livrer au plus tôt et régulièrement, réduire le délai entre réalisation et mise à disposition Retarder les investissements non avérés http://etre-agile.com 11
XP et Scrum : complémentarité gagnante Scrum : la marque qui fait vendre l'agilité Scrum intègre de plus en plus de pratiques XP... à tel point que pratiquer Scrum c'est bien souvent mettre en œuvre des pratiques XP Scrum v1 : itération d'un mois / XP v1 itération de 3 semaines Scrum v2 : itération de 3 semaines / XP v2 itération d'une semaine Product Owner : pas dans l'équipe / Client : dans l'équipe... http://etre-agile.com 12
XP et Lean XP : une adaptation du Lean au développement de logiciels... Bien avant le «Lean Software» Exemples Lean : livrer rapidement, XP : versions fréquentes, cycle trimestriel Lean : respecter les personnes, XP : valeur de respect Lean : chasser les gaspillages, XP : la définition même d'xp http://etre-agile.com 13
Bref historique 1999 XPEv1 2000 les débuts en France Projets «pionnier» 2004 XPEv2 Solution viable Aujourd'hui, un renouveau grâce à l'avènement de Scrum (ScrumMania) http://etre-agile.com 14
La «constitution» XP Valeurs Principes Rôles Pratiques Cycle de Vie http://etre-agile.com 15
Rôles Une équipe, plusieurs rôles Client (Product Manager) Spécifie les demandes et les tests-client, planifie en tenant compte de la VA des demandes Développeur Estime les demandes, réalise Manager Fait confiance, aplanie le terrain, Un point focal pour tous: la Valeur Métier offerte par le produit http://etre-agile.com 16
Autres rôles Coach Pose des questions Ne manage pas Tiens la main de celui qui tient le stylo (le clavier) Principe de diversité Tracker Testeur/Analyste Rédiger le test Discuter! Tester Consultant occasionnel... http://etre-agile.com 17
Cycle de Vie XP Exploration 2 mois max. 1 Engagement 1 semaine 2 3 4 Pilotage par feedback Des années! 1. Fin d'exploration : carottages : architecture, périmètre initial, estimations 2. Engagement : premières valeurs des variables projet : - Coût - Délais - Périmètre - Qualité 3. 4. 5. Les différentes versions livrées n. Fin de l'application. 5... Mort de l'appli n http://etre-agile.com 18
Architecture C'est quoi l'architecture? Squelette de la solution : framework, matériels et logiciels de base (BDD...) L'une des pires métaphores : soft!= hard Conception émergente : dans le cadre de l'architecture... émergente. Nous retardons autant que possible les coûts d'infrastructure, ils sont engagés quand ils sont avérés.. http://etre-agile.com 19
Valeurs de l' Extreme Programming Communication Combien d'exemples... et de contre-exemples! Feedback Pour contrôler à partir d'éléments les plus objectifs Simplicité Le pari de l'extreme Programming, pour tous, tout le temps Courage De changer de rôle, de vision du produit Respect Respecter et être respecté en tant que personne Principe Lean http://etre-agile.com 20
Valeur? Valeur : norme de conduite personnelle et/ou sociale* Exemples? * http://fr.wikipedia.org/wiki/valeur http://etre-agile.com 21
XP : les principes Humanisme Flot continu Économie Opportunité Bénéfices mutuels Redondance Autosimilarité Échecs Amélioration continue Diversité Réflexion Qualité Petites étapes Responsabilité choisie http://etre-agile.com 22
Pourquoi des principes Entre valeurs et pratiques, les principes - guident l'adaptation d'xp - sont autant d'axes d'amélioration d'un existant http://etre-agile.com 23
Humanisme Le propos d'xp est le changement social Revaloriser le métier du développement Prendre en compte la dimension humaine dans les activités liées au logiciel Exprimer les besoins Développer Avoir le droit de bien faire S'accomplir dans son travail - Être fier de son travail Pouvoir influencer la façon dont on travaille Être responsable, auto-géré : mettre en cause les intermédiaires http://etre-agile.com 24
Humanisme : hédonisme et responsabilité Le plaisir de coder, de participer au développement du produit La responsabilité de la fabrication D'un monde centré «pouvoir» (LE Chef de projet) À un collectif coresponsable Pas facile... Ni pour le Manager, ni pour le Développeur http://etre-agile.com 25
Économie Livrer rapidement pour déclencher le Retour sur Investissement (ou le Cashback) Retarder les investissements (principe de décision du Lean) http://etre-agile.com 26
Autosimilarité Autosimilarité de feedbacks concrets et rapides Tâche : résultat de test dans l'heure Itération : un ensemble cohérent en une semaine Version : trimestre, le feedback par excellence Appliquer un principe qui fonctionne de différentes façons, dans différents contextes Communication Simplicité Courage Autosimilarité : feedback à tous les étages http://etre-agile.com 27
Petites étapes Une clé de l'extreme Programming : Construire sur du solide, par petites étapes Petit à petit ne signifie pas «lentement» Autosimilarité TDD ½ heure (la barre doit être toujours verte) Itération 1 semaine Version quelques semaines http://etre-agile.com 28
Réflexion Pourquoi et comment on travaille Créer des analogies entre le métier et... le reste Pratiques Architecture Le principe d'amélioration continue dans XP http://etre-agile.com 29
Flot continu Délivrer «continuellement» : toutes les activités, tout le temps Le Client injecte des histoires, le Développeur les développe Raccourcir le Lead time (entre demande et mise en exploitation) Il s'agit de «tirer», pas de «pousser» http://etre-agile.com 30
Théorie des Contraintes Il existe toujours un goulot d'étranglement dans une ligne de production Identifier ce goulot Agir Améliorer Anticiper en amont Lavage Séchage Corbeille rangement http://etre-agile.com 31
Développement : terminer une histoire Stories et Tests Développement Validation Où est le goulot d'étranglement? http://etre-agile.com 32
Pratiques de l'extreme Programming 13 pratiques de base 1. Gestion des exigences et planification 2. Le facteur humain 3. Conception 4. Coder et livrer http://etre-agile.com 33
Histoires et Planification 1/4 Exigences? Les besoins sont décrits sous forme d'histoires d'utilisation*. Le cycle est itératif incrémental, la durée par défaut d'une itération est d'une semaine. La vision globale produit, pratiques est planifiée à l'échelle du trimestre. Une marge de sécurité activités optionnelles permet d'absorber les imprévus (slack). Contrats : périmètre négocié * Ce sont les User Stories : «En tant que... je peux... pour telle V.A...» http://etre-agile.com 34
Histoires 800 Valeur Métier (surtout Feature) En tant que Pilote, je règle le commutateur en mode " niveau horizontal" afin de maintenir les ailes à l'horizontale et l'avion sur sa trajectoire initiale. 5 Estimation en points Une histoire est : 1) un déclencheur de discussions dans l'équipe 2) l'unité de planification (correspondance histoire / itération) http://etre-agile.com 35
Story : les 3C* Carte Conversation Pour estimer, développer la story Confirmation Tests d'acceptation Tout n'est pas écrit * cf. Ron. Jeffries http://etre-agile.com 36
Importance des Tests d'acceptation Spécifier un test, c'est spécifier le produit «Deal» entre Product Manager et Développeurs Automatiser les T.A. Fitnesse GreenPepper... http://etre-agile.com 37
Itération d'une semaine* La capacité d'une itération : Nombre de cases = vélocité Ensemble des histoires du produit (le «Backlog» de Scrum) Tableau non infini! Le Client planifie en fonction 1. de la valeur métier des histoires 2. de leur estimation en points 3. d'urgences ou nécessités 4. de facilité à faire. * En phase d'adaptation, la durée est... adaptée. Une semaine reste une bonne «côte», humainement signifiante. http://etre-agile.com 38
Itération, objectif : terminer les histoires ITERATION V(n+1) Périmètre de l'itération = { Histoires } - Produit testé et incrémenté, - Backlog mis à jour http://etre-agile.com 39
Estimer l'effort nécessaire pour terminer une histoire Point d'effort Planning Poker http://etre-agile.com 40
Plan trimestriel Plusieurs niveaux de planification dans XP Releases (trimestriel, pluri annuel) Itérations (semaine) Tâches (quotidien) Toujours la valeur de feedback concret et rapide http://etre-agile.com 41
Slack (matelas) Pour éviter les mauvaises surprises et une sensation de pression sur l'équipe Slack : entre 2 itérations Slack : en jouant sur la vélocité http://etre-agile.com 42
Contrat Périmètre négocié Parmi les 4 variables, le périmètre est généralement la plus souple Paiement à l'utilisation Paiement en fonction de ce qui est mis en exploitation Coût Délais Périmètre (scope) Qualité http://etre-agile.com 43
Facteur humain, équipe 2/4 Un plateau-projet, où nous sommes assis ensemble Équipe complète : esprit d'équipe, entr'aide, y compris le Client (repris dans Scrum v2010) Espace d'information : les infos sont affichées, disponibles directement (radiateur d'information, transparence) Un rythme viable pour tous les membres de l'équipe : Développeurs, Client... Nous codons en binôme. http://etre-agile.com 44
Assis ensemble Plateau Projet Aménager espace collectif et privatif L'environnement est une facette importante : pouvoir communiquer, partager directement en face à face, en parlant http://etre-agile.com 45
Équipe complète Tous les membres de l'équipe, y compris le Client Pouvoir travailler en transparence Pouvoir dire Je ne sais pas J'ai besoin d'aide Prendre conscience de la perte d'information lorsque l'équipe n'est pas complète http://etre-agile.com 46
Espace d'information Afficher les informations utiles Profiter des murs! Radiateur d'information Vélocité Kanban (stories, tâches) Planning des personnes Indicateurs (vélocité, plan de release...) Diagrammes techniques... http://etre-agile.com 47
Rythme viable S'inscrire dans la durée : un développement dure plusieurs mois, voire plusieurs années On ne «sprinte» pas! Plutôt une course d'endurance Attention : rythme viable pour tous Développeurs Utilisateurs Exploitants... http://etre-agile.com 48
Binôme (Pair Programming) Une relecture immédiate par un pair Cela n'a rien à voir avec une relecture à contre-temps par un IQ Deux rôles Pilote Partenaire Des protocoles simples (permuter, durée, constitution du binôme...) À pratiquer en fonction des besoins de l'équipe... Code sensible Intégration d'un nouveau venu http://etre-agile.com 49
Conception 3/4 Conception émergente une règle d'or, pas de duplication de code Attention aux couplages Test Driven Development : d'abord écrire le test, puis coder, puis mettre au point, période de ½ heure. Le refactoring est une conséquence de «conception émergente» http://etre-agile.com 50
Conception émergente Itération 1 Histoires d'utilisation A320 Itération n Histoires du A380 A320 Avion A320 A380 YAGNI! http://etre-agile.com 51
TDD 1/3 User story «je calcule une division» Des classes : Calculateur, Afficheur... class Calculateur { integer: op1, op2; char: operateur; // méthodes GetOp1(): integer; additionner(...):integer; soustraire(...): integer; }; TDD - ½ heure : 1) Écrire les tests 2) Coder 3) Passer les tests http://etre-agile.com 52
TDD 2/3 : petit à petit, rapidement Construire sur du solide (la barre toujours verte) Valider par petites étapes Accélère la mise au point : si les tests étaient au vert à 10 heures et sont au rouge à 10h20, c'est probablement du à ce qui a été modifié entre temps Tests-Développeurs : pour rassurer le Développeur System Under Test Feedback concret et rapide http://etre-agile.com 53
class Calculateur { integer: op1, op2; char: operateur; // méthodes GetOp1(): integer; additionner(...): integer; soustraire(...): integer; }; Tous les tests précédents OK, Tous les nouveaux tests KO. 2) Coder diviser(dividende, diviseur): int { return (dividende / diviseur); } Le premier test passe, le deuxième non, certains tests précédents (par ex testgetop1) non plus. TDD 3/3 1) Les tests test_division_nominal() { assert (Self->diviser(15,3), 5); } test_division_erreur() { try () { self->diviser (1,0); } Catch(system_divide_by_zero); } 3) Tester-coder-mettre au point diviser(dividende, diviseur): int { op1 = dividende, op2 = diviseur ; If (diviseur == 0) then { } ; else return (dividende / diviseur); } Tous les tests passent. http://etre-agile.com 54
Coder et livrer 4/4 Intégration continue, plusieurs fois par jour Nous testons et intégrons très souvent, le build dure 10 minutes maximum. (Ten Minutes Building) Le code-source et les tests sont des documents obligatoires Le code est partagé entre tous Gestion de configuration : une seule version officielle (qui évolue en permanence) Déploiement au plus tôt : chaque nuit... chaque deux semaines ou au maximum chaque trimestre http://etre-agile.com 55
Intégration continue Plusieurs «niveaux» Chaque nuit À la demande Systématiquement (chaque «commit») : 10' Building Ressources Serveur dédié Gestion type Hudson Associer Gestion de conf Intégration continue et Tests http://etre-agile.com 56
Documents Les documents obligatoires Le code-source (un code est un modèle exécutable) Les tests 1ère règle : challenger les documents 2ème règle : produire les documents nécessaires (normatif, régulé...) Comment? En appliquant les valeurs & principes XP http://etre-agile.com 57
Code source partagé Le développement est collectif Diminuer le risque du «gourou» indispensable Faciliter la répartition de tâches Favoriser la montée en compétences Susciter la curiosité Améliorer le plaisir de coder http://etre-agile.com 58
Déployer au plus tôt Voir le 1er principe agile Question d'économie et de feedback http://etre-agile.com 59
Une version officielle (gestion de conf) Éviter absolument les «branches» Une et une seule version http://etre-agile.com 60
Installer XP http://etre-agile.com 61
Quand ne pas faire de l'xp XP, tout comme la véritable agilité est une question de valeurs. Si vous «n'achetez» pas Communication Feedback concret et rapide Simplicité Courage Respect Alors ne vous lancez pas dans XP http://etre-agile.com 62
Installer XP? Full XP? Planification / Équipe complète / User stories / Tests-Client + Ingénierie : Conception émergente / TDD Quel cadre? Client : partie prenante, «dans le coup» Projet «perdu» ou volonté forte de changement Techniques qui autorisent le refactoring Capacité à changer http://etre-agile.com 63
Shu Ha Ri Attention à l'impression de «déjà vu» Attention aux imitations! Ne pas pratiquer XP ne conduit pas au succès... Shu Appliquer strictement pour comprendre Ha Jouer avec les pratiques, comprendre leur sens Ri Adapter XP Une mauvaise idée? Ri sans Shu. http://etre-agile.com 64
S'adapter La v1 de XP proposait un principe d'adaptation locale. Ainsi, l'installation de XP s'adapte au contexte... L'approche agile est une nouvelle vision, conception du projet, du produit logiciel dans l'organisation, des rôles. http://etre-agile.com 65
Développement Responsable Imaginez... Clients, Managers, Développeurs... Désormais, vous êtes propriétaires de vos pratiques (amélioration continue) : En quoi cela change-t-il la perception de votre rôle, de votre responsabilité? Quelles pratiques jetez-vous, conservez-vous? Être assertif pour être responsable. Être agile : un savoir-être, des savoir-faire. http://etre-agile.com 66
Choisir XP? Une question de valeurs... Et de conduite du changement Pilote Chantiers Déploiement Donc de communication, D'objectifs et d'indicateurs Une question de personnes Plus importantes que les processus http://etre-agile.com 67
En résumé... XP, une constitution compléte Des rôles : Client, Développeur... Un Cycle de Vie complet Des Valeurs et Principes Des pratiques Exigences et planification Facteur humain Conception Coder et livrer http://etre-agile.com 68
L'important... XP et Scrum : faciliter l'adaptation de l'agile grâce à la ScrumMania Scrum : la marque qui fait vendre l'agile XP et Lean : pour être audible, faciliter la conduite de changement Lean : une dimension industrielle Pas de gué-guerre de méthode L'important ce n'est XP, Scrum, CMMI... L'important c'est... http://etre-agile.com 69
Bienvenue en Extreme Programming http://etre-agile.com 70
V1 http://etre-agile.com 71