Graduat en Informatique. Projet de développement extreme Programming. extreme Programming

Transcription

1 extreme Programming Ces transparents sont basés sur une libre interprétation de l'ouvrage suivant : L' avec deux études de cas J.L. Bénard, L. Bossavit, R. Médina, D. Williams paru aux éditions Eyrolles 18/11/03 Eric Schmitz 1

2 XP? Limites des démarches par phases. Rupture par rapport au cycle en V. Dans les approches classiques, on cherche à définir de manière détaillée ce que l'on souhaite construire. Ceci fonctionne pour des ponts, des immeubles... MAIS pas pour du «construire» des logiciels. 18/11/03 Eric Schmitz 2

3 Causes d'échecs On ne connaît pas, a priori, les détails des specs. Cet exercice à lieu au début du projet, au moment où les différents intervenants en savent le moins sur le contexte de l'application. Ceci entraîne une remise en cause fréquente des specs => perte de temps. UML n'est pas une solution, même s il n'est pas à rejeter. 18/11/03 Eric Schmitz 3

4 Effet tunnel Visibilité réduite du client pendant la phase de construction. En XP, le client peut intervenir fréquemment pendant la construction de l'application et a un pouvoir pour influer sur le cours du projet. 18/11/03 Eric Schmitz 4

5 Equipes compartimentées Souvent, les développeurs sont isolés, travaillant seuls sur leur machine et communiquent en étoile. Ceci entraine : Une mauvaise distribution de l'info. Une spécialisation abusive des développeurs. Le code est soumis à une paralysie progressive. 18/11/03 Eric Schmitz 5

6 Paralysie progressive La qualité interne (le code) est noyée sous/par les efforts sur la qualité externe (docs, specs, tests). La qualité du code dépend uniquement du développeur. Plus le code dégénère, plus les modifications prennent du temps et risquent d'engendrer des erreurs. C'est au cours de l'implémentation que la validité des spécifications et de la conception est mise à l'épreuve. 18/11/03 Eric Schmitz 6

7 Evolution du coût du changement Coût Approche traditionnelle Il est logique de définir complètement le logiciel avant d'entamer sa construction. T1 T2 T3 T4 MAIS : si on applique certains principes de conception et de programmation, il est possible de garder l'application suffisamment souple. Coût Approche "XP" T1 T2 T3 T4 T5 18/11/03 Eric Schmitz 7

8 Evolution du coût du changement La stratégie gagnante ne consiste plus à figer tout dès le début, mais tout au contraire, à diffuser la prise de décision tout au long du projet. XP propose un ensemble de pratiques concrètes pour obtenir plus de souplesses et exploiter celles-ci pour servir au mieux le client et l 'équipe de développement. 18/11/03 Eric Schmitz 8

9 Les pratiques d'xp 18/11/03 Eric Schmitz 9

10 Pratiques de programmation Conception simple (tjs la solution la plus simple). Remaniement. (nettoyage de code) Développement piloté par les tests unitaires. (d'abord écrire les tests!) Tests de recettes, précisés par le client. 18/11/03 Eric Schmitz 10

11 Pratiques de collaboration Programmation en binôme -> les binômes changent fréquemment. Responsabilité collective du code. Règles de codage. Métaphore. Intégration continue (au moins 1x par jour). 18/11/03 Eric Schmitz 11

12 Pratiques de gestion de projet Livraisons fréquentes. Planification itérative. Client sur site. Rythme durable. 18/11/03 Eric Schmitz 12

13 Les quatres valeurs d'xp 18/11/03 Eric Schmitz 13

14 La communication pour une meilleure visibilité? Effort collectif de création Dont le succès dépend : De la vision commune de ce qui doit être produit. De la capacité à synchroniser les actions individuelles. Ces deux conditions dépendent de la qualité de la communication. 18/11/03 Eric Schmitz 14

15 La communication pour une meilleure visibilité XP met l'accent sur la communication directe. Communication orale Pour sa simplicité. Pour des interactions rapides entre les interlocuteurs. Plus personnelle. 18/11/03 Eric Schmitz 15

16 La communication pour une meilleure visibilité La communication écrite : toutes les informations ayant trait à l'implémentation et à la conception se retrouvent dans le code. La clarté du code fait l'objet de nombreux efforts. Les tests servent également à consigner formellement les besoins des clients. 18/11/03 Eric Schmitz 16

17 La simplicité comme garantie de productivité Mantras exprimant la simplicité : La chose la plus simple qui puisse marcher. (The simplest thing that could possibly work) Tu n'en auras pas besoin. (You ain't gonna need it) Une fois et une seule. (Once and only once) Débarrasser le code de toute complexité superflue. 18/11/03 Eric Schmitz 17

18 La simplicité comme garantie de productivité L'effort de simplicité s'applique également au client. Il doit définir ses besoins avec une grande précision pour éviter d'implémenter des choses inutiles. La simplicité est également recherchée dans le choix des outils et dans la méthode de travail elle-même. 18/11/03 Eric Schmitz 18

19 Le feedback comme outil de réduction de risque XP : Processus de réduction de risque. Risque contrôlé par la mise en place de boucles de feedback. Permets à tout moment de savoir dans quel état se trouve le projet. Et donc de pouvoir rectifier le tir au fur et à mesure. 18/11/03 Eric Schmitz 19

20 Le feedback comme outil de réduction de risque Un exemple en est le principe de livraisons fréquentes. La planification itérative permet de tirer parti des informations recueillies, pour améliorer la planification et faire converger le produit vers une solution mieux adaptée aux besoins. 18/11/03 Eric Schmitz 20

21 Le feedback comme outil de réduction de risque Divers mécanismes de feeback interviennent dans l'activité de programmation : Tests unitaires. Feeback du binôme. Intégré à la conception. Le feeback est un facteur de qualité, car les intervenants améliorent sans cesse leur travail en profitant de l'expérience qu'ils accumulent. 18/11/03 Eric Schmitz 21

22 Le courage de prendre les bonnes décisions. Courage pour se lancer dans un projet sans avoir tout spécifié. Courage pour se borner à réaliser des choses simples. Courage pour appliquer les principes de communication et de feedback. Courage de mettre en place des méthodes nouvelles. 18/11/03 Eric Schmitz 22

23 Les principaux rôles d'xp 18/11/03 Eric Schmitz 23

24 Liste des rôles Le programmeur Le client Le coach Le testeur Le tracker Le manager 18/11/03 Eric Schmitz 24

25 Le programmeur Va écrire, connaître, modifier, gérer l'existence, la sauvegarde, les versions, la transformation en exécutable du CODE. Va TESTER le code pour en obtenir un feedback. Va faire preuve de COURAGE, toute fonctionnalité qui n'a pas été suffisamment testée doit être considérée comme n'existant pas. 18/11/03 Eric Schmitz 25

26 Le programmeur Va poser des questions au client et écouter ses réponses. C'est le client qui détient la connaissance de ce que doit faire le système. Va aider le client à définir ses besoins. XP fournit un cadre méthodologique pour cela. 18/11/03 Eric Schmitz 26

27 Le programmeur Va concevoir : Collectivement lors des séances de planification. En écrivant les tests unitaires du code. En pratiquant le refactoring (remaniement). Est responsabilisé : Il est codeur, testeur, concepteur, analyste. Il a la volonté d'apprendre. 18/11/03 Eric Schmitz 27

28 Le programmeur Est le seul à avoir la reponsabilité des délais (ni le client, ni le manager, ni le coach ne peuvent influencer le programmeur dans ses estimations) A donc un rôle varié. 18/11/03 Eric Schmitz 28

29 Charte des droits du programmeur Le développeur a le droit : De savoir ce qui est demandé, avec des priorités clairement déclarées. De fournir un travail de qualité en toute occasion. De demander et recevoir de l'aide de la part de ses pairs et du client. D'émettre et de réviser ses propres estimations de coûts. 18/11/03 Eric Schmitz 29

30 Le programmeur Charte des droits du programmeur D'accepter des responsabilités, mais qui ne peuvent lui être imposées. De travailler à un rythme de travail durable. 18/11/03 Eric Schmitz 30

31 Pratiques XP du programmeur Programmation en binôme. Tests unitaires. Conception simple. Remaniement. Responsabilité collective du code. Règles de codage. Intégration continue. Rythme durable. 18/11/03 Eric Schmitz 31

32 Le client Le client sur site. Le client spécifie par des scénarios client... En commençant par en faire la liste. En donnant des priôrités aux scénarios. Nécessité de feedback pour le client -> le feedback assure une bonne communication entre le programmeur et le client. 18/11/03 Eric Schmitz 32

33 Le client Le client spécifie par des tests de recette. Pratique XP du client Planification itérative. Tests de recettes. Intégration continue. Rythme durable. 18/11/03 Eric Schmitz 33

34 Charte des droits du client Le client a le droit : A un plan d'ensemble, montrant ce qui peut être accompli, pour quand, à quel coût. D'obtenir le plus de valeur possible de chaque semaine de programmation. De voir des progrès sur une application qui marche, comme doivent le prouver les tests répétables qu'il spécifie. 18/11/03 Eric Schmitz 34

35 Charte des droits du client De changer d'avis, de substituer des fonctionnalités et de changer ses priorités sans en payer un prix exorbitant. D'être informé des modifications portées au calendrier de réalisation, assez tôt pour avoir la possibilité de réduire le périmètre fonctionnel et retomber ainsi sur la date de livraison initiale. D'annuler le projet à tout moment et de disposer d'une application utile et utilisable en contrepartie de son investissement. 18/11/03 Eric Schmitz 35

36 Le coach Garant du processus. Organise et anime les séances de planification. Aide le client à rédiger ses premiers scénarios. Doit avoir le courage de dire les choses telles qu'elles sont. Objectifs du coach : que l'équipe fonctionne bien, sans lui... 18/11/03 Eric Schmitz 36