XP : ce célèbre inconnu

Transcription

1 XP : ce célèbre inconnu Extreme Programming Thierry Cros 1

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

3 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...) 3

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

5 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

6 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.» 6

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

8 Extreme Programming = centré réalisation, ie Valeur Métier 8

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

10 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...) 10

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

12 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

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

14 Bref historique 1999 XPEv les débuts en France Projets «pionnier» 2004 XPEv2 Solution viable Aujourd'hui, un renouveau grâce à l'avènement de Scrum (ScrumMania) 14

15 La «constitution» XP Valeurs Principes Rôles Pratiques Cycle de Vie 15

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

17 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

18 Cycle de Vie XP Exploration 2 mois max. 1 Engagement 1 semaine 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é Les différentes versions livrées n. Fin de l'application Mort de l'appli n 18

19 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

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

21 Valeur? Valeur : norme de conduite personnelle et/ou sociale* Exemples? *

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

23 Pourquoi des principes Entre valeurs et pratiques, les principes - guident l'adaptation d'xp - sont autant d'axes d'amélioration d'un existant 23

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

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

26 Économie Livrer rapidement pour déclencher le Retour sur Investissement (ou le Cashback) Retarder les investissements (principe de décision du Lean) 26

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

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

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

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

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

32 Développement : terminer une histoire Stories et Tests Développement Validation Où est le goulot d'étranglement? 32

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

34 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...» 34

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

36 Story : les 3C* Carte Conversation Pour estimer, développer la story Confirmation Tests d'acceptation Tout n'est pas écrit * cf. Ron. Jeffries 36

37 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

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

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

40 Estimer l'effort nécessaire pour terminer une histoire Point d'effort Planning Poker 40

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

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

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

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

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

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

47 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

48 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

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

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

51 Conception émergente Itération 1 Histoires d'utilisation A320 Itération n Histoires du A380 A320 Avion A320 A380 YAGNI! 51

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

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

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

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

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

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

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

59 Déployer au plus tôt Voir le 1er principe agile Question d'économie et de feedback 59

60 Une version officielle (gestion de conf) Éviter absolument les «branches» Une et une seule version 60

61 Installer XP 61

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

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

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

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

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

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

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

69 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

70 Bienvenue en Extreme Programming 70

71 V1 71