Programmation agile le cas de la programmation extrême.

Présentation au sujet: "Programmation agile le cas de la programmation extrême."— Transcription de la présentation:

1 Programmation agile le cas de la programmation extrême

2 Plan Quel est le problème à résoudre ? XP: qu’est-ce ? pourquoi et quand l’appliquer ? “X” ? Méthodologie logicielle Variables Valeurs Règles Pratiques Références

3 Le problème fondamental : le risque Développement du logiciel Échoue à livrer le logiciel, Échoue à produire un logiciel valable. Glissements des échéanciers Annulation de projets Le système est dépassé Quantité de défauts, bugs, etc. Incompréhension ou changement des pratiques d’affaires Des fonctionnalités puissantes, mais sans intérêt Roulement de personnel

4 Méthodologie logicielle Une méthodologie logicielle est un ensemble de règles et de pratiques utilisées pour créer des logiciels. Une méthodologie “ lourde” possède plusieurs règles, pratiques et documents. Elle requiert de la discipline et du temps pour l’appliquer correctement. Rational Unified Process (1491 fichiers dans 159 dossiers, en 2000) Une méthodologie “légère” a peu de règles et de pratiques, qui sont faciles à appliquer.

5 Programmation extrême Une discipline pour le développement de logiciel pour de petites équipes (2-10 personnes) afin de développer un logiciel rapidement dans un environnement où les besoins et les spécifications changent rapidement.

6 Web 2.0 La fin des cycles de release 2- Les utilisateurs doivent être traités comme des co-développeurs « la bêta perpétuelle » le produit est développé avec de nouvelles fonctionnalités apparaissant de manière mensuelle, hebdomadaire voire quotidienne. L'observation en temps réel du comportement de l'utilisateur dans le but de voir quelles sont les nouvelles fonctionnalités utilisées, devient donc un nouvelle compétence centrale. Modèle d’affaire Microsoft dépend de la remise à niveau que chacun fait sur son PC tous les deux ou trois ans. Google ne dépend que de la capacité des utilisateurs à se servir des nouvelles fonctionnalités qui leur sont proposées.

7 Un développeur web d'un grand service en ligne dit à ce sujet : « Nous mettons deux ou trois nouvelles fonctionnalités quelque part sur le site chaque jour, si elles ne sont pas utilisées, nous les retirons. Si elles sont appréciées, nous les implémentons partout ailleurs sur le site. » Cal Henderson, le principal développeur de Flickr, a révélé récemment qu'il déployait une nouvelle version (ndt : plus exactement un nouveau « build ») de son application toute les demis-heures. C'est là un modèle de développement radicalement différent !a révélé récemment qu'il déployait une nouvelle version (ndt : plus exactement un nouveau « build ») de son application toute les demis-heures

8 Objectif de XP Livrer le logiciel dont on a besoin lorsqu’on en a besoin.

9 Quand utiliser XP? Domaines pour lesquels les besoins changent / évoluent On ne possède pas une idée claire / définitive de ce que le système doit faire On s’attend à des changements fréquents des fonctionnalités du système (de l’ordre de quelques mois). Pour gérer les risques liés au projet. Si le client a besoin d’un nouveau système à une date spécifique, le facteur de risque est grand. Si le système présente de nouveaux défis pour l’équipe de développement, le facteur de risque est encore plus grand. Si le système présente de nouveaux défis pour l’ensemble de l’industrie du logiciel, le facteur de risque est énorme.

10 Quand utiliser XP? XP exige une équipe de développement étendue Les développeurs Les gestionnaires Les clients Pourquoi ? Poser des questions Négocier la portée et les échéanciers Créer des tests fonctionnels Demande plus que l’implication des seuls développeurs.

11 Tests Unit Test: tester une composante du système. Functional tests : Tester le logiciel en fonction des besoins fonctionnels. S’assurer que le programme fonctionne bien de la manière prévue toutes les options des menus sont présentes le programme est conforme aux standards de l’industrie par rapport à l’environnement du programme Par exemple, sous Windows F1 lance le module d’aide. Regression Test: tester le logiciel révisé pour voir si les fonctions précédentes qui fonctionnaient fonctionnent toujours. System Test: tester tout dans l’environnement de développement et dans l’environnement de l’usager. alpha test et beta test.alpha testbeta test Acceptance Test : Test réalisés par les usagers pour un nouveau système ou un système modifié dans le but d’approuver le système et de le rendre disponible Des changements cosmétiques ou mineurs peuvent résulter des tests, mais le système est considéré comme stable et traitant les données en conformité avec les besoins et exigences. Test Case: un ensemble de données de tests, de programmes de tests et les résultats attendus Test Scenario: un ensemlbe de cas de tests qui assure que le processus d’affaire est testé de bout en bout Black Box Test: Test d’un logiciel en fonction de ses sorties sans connaissance des opérations internes White Box Test: Test d’un logiciel en fonction de ses sorties à l’aide de connaissances des opérations internes, e.g. les chemins possibles à l’intérieur d’un logiciel http://www.pcmag.com/encyclopedia_term/0,2542,t=testing+types&i=52777,00.asp

12 Quand utiliser XP? “Testabilité” du logiciel Productivité Les projets XP démontrent une plus grande productivité des développeurs lorsqu’elle est comparée à des projets similaires appartenant au même domaine corporatif.

13 Pourquoi “extrême” ? -- I Si la revue de code est une bonne pratique, la revue de code sera réalisée en permanence (programmation par paires). Si les tests sont importants, tous vont écrire des tests tout le temps (tests unitaires), même les clients (tests fonctionnels) Si le design est important, le design sera partie intégrante de la pratique de tous les membres (refactorisation) Si la simplicité est une qualité à rechercher, le système utilisera toujours le design le plus simple possible capable de supporter les fonctionnalités courantes (le plus simple qui puisse possiblement fonctionner).

14 Pourquoi “extrême” ? -- II If architecture is important, everybody will work defining and refining the architecture all the time (metaphor) If integration testing is important, we’ll integrate and test several times a day (continuous integration). If short iterations are good, we’ll make the iterations really, really short –seconds and minutes and hours, not weeks and months and years (the Planning Game).

15 Four Variables We will control four variables in our projects Cost Time Quality Scope External forces (customers and managers) get to pick the values of 3 of the variables. The development team gets to pick the resultant value of the 4 th variable.

16 Values XP is based on Communication Simplicity Feedback Courage.

17 Value : communication Problems with projects can invariably be traced back to somebody not talking to somebody else about something important A programmer doesn’t tell someone else about a critical change in the design A programmer doesn’t ask the customer the right question, so a critical domain decision is blown A manager doesn’t ask a programmer the right question, and project progress is misreported

18 Value : communication and XP Practices XP practices that can’t be done without communication Unit testing Pair programming Task estimation

19 Value : simplicity What is the simplest thing that could possibly work? Not to look toward the things you’ll need tomorrow and next week and next month XP stance: It is better to do a simple thing today and pay a little more tomorrow to change if it needs it, than to do a more complicated thing today that may never be used anyway

20 Value : simplicity and XP Practices The more you communicate, the clearer you can see exactly what needs to be done and the more you have confidence about what really doesn’t need to be done The simpler your system is, the less you have to communicate about Practices Simple design Refactoring

21 Value : Feedback at scale of minutes and days Concrete feedback about the current state of the system Don’t ask me, ask the system Feedback for customers When customers write new stories (description of features), the programmers immediately estimate them Feedback on project progress Watching the completion of tasks to give the whole team feedback about whether they are likely to finish everything they set out to do in a span of time

22 Value : Feedback at scale of weeks and months The customers and testers write functional tests for all the stories (simplified use cases) implemented by the system. The customers review the schedule every two or three weeks to see if the team’s overall velocity matches the plan, to adjust the plan The system is put into production as soon as it makes sense, so the business can begin to “feel” what the system is in action and discover how it can best be exploited.

23 Value : Feedback and XP practices The more feedback you have, the easier it is to communicate Simple systems are easier to test XP practices The planning game Small releases Testing Pair programming Continuous integration On-site customer

24 Value : Courage Courage to take decisions Radical surgery on code Throwing code away Starting over from scratch Prototyping multiple design alternatives, and keep only one for “real” development

25 Last but not least Respect

26 Principles From the 4 values, a dozen or so of principles (rules) are derived to guide the development style

27 Central Principles Main principles Rapid feedback time between action and feedback is critical Assume simplicity Incremental change Big change made all at once just don’t work Embracing change Preserves the most options while solving the most pressing problem Quality work Nobody likes working sloppy

28 Less central principles Teach learning No doctrine Small initial investment Too many resources too early in a project is a recipe for disaster Play to win Playing to win vs playing not to lose For sure we need to write reports, … but getting a working system is more important… Concrete experiments Every time you made a decision and you don’t test it, there is some probability that the decision is wrong.

29 Less central principles Open, honest communication Able to tell each other where there are problems in the code Able to express fears and get support Free to deliver bad news to customers and management, to deliver it early, and without being punished Work with people’s instincts, not against them XP is a process where following short-term self-interest (win, learn, be in control, good work…) also serves long-term team interest Accepted responsibility Not telling people what to do Does not mean that you always do exactly what you feel like doing

30 Less central principles Local adaptation Adapt XP principles and practices to local conditions Travel light You can’t expect to carry a lot of baggage and move fast Be prepared to change direction Artifacts Few Simple Valuable Honest measurement This will take 14.176 hours (???)

31 Back to basics There are 4 activities to support Coding Testing Listening Designing

32 XP Practices What is a practice? the usual way of doing something Aim of practices in XP: Structure the 4 activities In XP, there are 12 practices

33 12 Practices The Planning Game Small Releases. Metaphor. Simple Design. Testing. Refactoring. Pair Programming. Collective Ownership. Continuous Integration. 40-hour Week. On-site Customer. Coding Standard.

34 Practice: The Planning Game Determine what will be accomplished by the due date, determining what to do next The XP "customer“ define the business value of desired features The programmer provides cost estimates The XP "customer“ choose what needs to be done what needs to be deferred

35 Practice: Small releases XP teams put a simple system into production early, update it frequently on a very short cycle

36 Practice: Metaphor XP teams use common "system of names" and a common system description that guide development and communication We don’t literally mean “the system is…” Give everyone a coherent story within which to work Help everyone on the project understand the basic elements and their relationships "this program works like a hive of bees, going out for pollen and bringing it back to the hive" as a description for an agent-based information retrieval system

37 Practice: Simple design A program built with XP should be the SIMPLEST program that meets the current requirements. There is not much building "for the future".

38 Practice: Testing XP teams focus on validation of the software at all times. Programmers develop software by writing tests first, then software that fulfills the requirements reflected in the tests. Customers provide acceptance tests that enable them to be certain that the features they need are provided.

39 Practice: Refactoring XP teams improve the design of the system throughout the entire development removal of duplication (a sure sign of poor design), on increasing the "cohesion" of the code, while lowering the "coupling". High cohesion and low coupling have been recognized as the hallmarks of well-designed code for at least thirty years This is done by keeping the software clean without duplication with high communication simple yet complete

40 Practice: Pair Programming XP programmers write all production code in pairs, two programmers working together at one machine

41 Practice: Collective ownership All the code belongs to all the programmers This lets the team go at full speed, because when something needs changing, it can be changed without delay

42 Practice: Continuous integration XP teams integrate and build the software system multiple times per day This keeps all the programmers on the same page, and enables very rapid progress integrating more frequently tends to eliminate integration problems that plague teams who integrate less often

43 Practice: 40-hour week (sustainable pace) Tired programmers make more mistakes. XP teams do not work excessive overtime, keeping themselves fresh, healthy, and effective This means that they work overtime when it is effective, and that they normally work in such a way as to maximize productivity week in and week out.

44 Practice: On-site customer An XP project is steered by a dedicated individual who is empowered to determine requirements, set priorities, answer questions as the programmers have them

45 Practice: Coding standards to work effectively in pairs, to share ownership of all the code, all the programmers need to write the code in the same way with rules that make sure the code communicates clearly Software, naming, language, {}…

46 XP map A spike solution is a very simple program to explore potential solutions

47 References Kent beck, Extreme Programming Explained: Embrace Change, Addison Wesley, 2000 Martin FowlerMartin Fowler, Refactoring : Improving the Design of Existing Code, Addison-Wesley, 1999 http://www.xprogramming.com http://www.xprogramming.com/xpmag/index.htm http://www.xprogramming.com/Practices/xpractices.htm http://www.extremeprogramming.org/