Extreme Programming

1. ISI IN S T I T U T S U P E R I E U R INFORMATIQUE الـمعهـد العـالـي للإعـلامــيـة Extreme Programming Réalisé par: Bouchaala Mohamed SlimiHoussem Themri Mohamed

2. PLAN Introduction Description de la Extreme Programming Architecture et valeurs Les pratiques de la Extreme Programming Conclusion

3. PLAN Introduction Description de la ExtremeProgramming Architecture et valeurs Les pratiques de la Extreme Programming Conclusion

4. Introduction 1.1 Les problèmes de monde de développement Les plaies du développement logiciel : D’après une étude américaine menée en 1994 sur 8000 projets, 16 % n’ont pas respecté les délais et le budget initial et, pire, 32 % n’ont jamais abouti.Ainsi, dans le monde de l’ingénierie logicielle, trois plaies pourtant bien connues enveniment le développement d’applications. • La première concerne le planning difficilement maîtrisé ou impliquant de nombreuses heures sup.

5. La difficulté de réalisation: Introduction 1.1 Les problèmes de monde de développement • Le deuxième est issue des besoins souvent mal identifiés ou mal compris en raison d’un cahier des charges mal étudié ou incomplet. • Enfin, le dernier problème concerne la livraison finale du produit qui est parfois bugée. • Avec près de 80% des projets, toutes tailles confondues, qui ne respectent pas les contraintes de départ de temps et de budget, les chefs de projet s’interrogent de plus en plus sur leurs méthodes.

6. Introduction 1.2Apparition des Méthode agile Description de méthode agile: • Les méthodes Agiles sont des groupes de pratiques pouvant s'appliquer à divers types de projets, mais se limitant plutôt actuellement aux projets de développement en informatique (conception de logiciel). • Elles visent la satisfaction réelle du besoin du client.

7. Exemple de cette Méthode : Introduction 1.2Apparition des Méthode agile • La notion de méthode agile a été officialisée en 2001 par un document, le Manifeste Agile (Agile Manifesto), signé par 17 personnalités impliquées dans l'évolution du génie logiciel, en particulier, en tant qu'auteur de leur propre méthode. Rapid Application Development (RAD, 1991) Scrum (1996) Extremeprogramming(XP, 1999) Adaptive software development (ASD, 2000) …

8. PLAN Introduction Description de la Extreme Programming Architecture et valeurs Les pratiques de la ExtremeProgramming Conclusion

9. Description de la XP 2.1Méthode XP Définition : • ExtremeProgramming (XP) est une méthode agile de gestion de projet informatique adaptée aux équipes réduites avec des besoins changeants. Elle pousse à l'extrême des principes simples. • XP se démarque des approches traditionnelles en mettant l'accent sur l'implication du client, le travail d'équipe, l'adaptation au changement et la robustesse des applications développées.

10. Description de la XP 2.1Méthode XP XP VS les Méthode tradionelle comme UML: D’ailleurs, XP utilise le langage universel qu’est UML pour communiquer. Toutefois, par sa volonté de rapidité, XP reste prudent sur l’utilisation d’UML. • les diagrammes UML sont trop longs à réaliser alors que la conception en XP étant très courte et réalisée au fur et à mesure. • La documentation par les diagrammes UML est aussi déconseillée en raison du volume de ces derniers, par rapport aux quelques pages préconisées dans XP.

11. Description de la XP 2.1Méthode XP avantage xp : • Le client garde une visibilité permanente sur l'état d'avancement du développement. • La mise en production du logiciel intervient très tôt dans le projet, ce qui permet au client d'en tirer rapidement des bénéfices. • La priorité d'implémentation des fonctionnalités n'est pas guidée par des contraintes techniques, mais par leur valeur métier.

12. PLAN Introduction Description de la Extreme Programming Architecture et valeurs Les pratiques de la ExtremeProgramming Conclusion

13. Architecture et valeur 1.1Lignes directrices Rendre moins lourdes les démarches : • Le but d’XP est de trouver des solutions plus ou moins simples pour tenter de diminuer les risques et respecter les délais . • on souhaite réduire radicalement la production de documents techniques très formelles et ce focalise plutôt sur un code bien commenté .

14. Changer les principes: Architecture et valeur 1.1Lignes directrices • Contrairement au solution rationnelle xp donne une grande importance sur le développement. • XP indique qu’il vaut mieux agir sur le court terme pour mieux gérer le cout de changement .

15. Architecture et valeur 3.1Lignes directrices • Le but d’XP est de se vouloir orienté sur les personnes plutôt que sur les processus. Alors, le développement tentera d’être une activité agréable plutôt qu’un cauchemar bureaucratique. • Permet une meilleure relation avec le client et la livraison d’un produit conforme totalement aux exigences de ce dernier.

16. Architecture et valeur 3.2Les valeurs de la XP Communication: • Le manque de communication dans un projet représente un grave problème. • Plusieurs pratiques dans XP ont pour finalité de permettre de se poser les bonnes questions et un partage de l’information entre acteurs du projet Dans l’équipes: Le code étant propriété de tous, chacun doit tenir au courant les autres de l’état d’avancement de son travail.

17. Architecture et valeur 3.2Les valeurs de la XP La communication permet le partage des connaissances, ce qui est bénéfique pour l’équipe . Avec le client: XP permet un rapprochement du client par rapport aux informaticiens, elle permet de déterminer de façon claire les besoins nécessaires du client. l'intégration du client dans l'équipe permet d'améliorer les rapports et les performances ainsi que le respect des dates butoirs qui est devenu au fur et à mesure complètement fiable.

18. Architecture et valeur 3.2Les valeurs de la XP Feedback: • Par le mot feedback, il faut entendre « retours », commentaires, avis... Avec le client: Les retours réguliers du client sont demandés pour progresser. les livraisons régulières permet au client de donne sont avis sur les cohérences du produit avec ses souhaits en terme de fonctionnalité.

19. Architecture et valeur 3.2Les valeurs de la XP Le moyen de faire ces feedbacks est la mise en place des tests unitaires qui détectent les bugs et les régressions. Dans l’équipe: Le Feedback au seins de l'équipe est garantit par les commentaires . Le développement d’une tache se fait généralement en binôme d’ou la nécessiter des commentaires .

20. Architecture et valeur 3.2Les valeurs de la XP La simplicité: • Dans XP on cherche toujours à supprimer l’inutile pour optimiser au maximum la productivité. • Un développeur XP doit la solution la plus simple qui peut fonctionner, elle permet de garantir la flexibilité au changement et faire de l'économie. • La simplicité est aussi essentielle pour que le code puisse être repris instantanément par n’importe quel développeur pour le compléter ou le changer.

21. Architecture et valeur 3.2Les valeurs de la XP Le courage : • Le client doit avoir le courage de donner des priorités à ses besoins. • Le responsable doit avoir le courage de commencer le projet avant que tout ait été précisé clairement sur un document contractuel.

22. PLAN Introduction Description de la Extreme Programming Architecture et valeurs Les pratiques de la ExtremeProgramming Conclusion

23. Les pratiques de la XP 4.1 Jeux de planning • Création des scénarios pour les fonctionnalités souhaité par le client . • Evaluation de temps nécessaire pour l’implémentation par l’équipe . le client sélectionne les scénarios en fonction des priorités et du temps disponible.

24. Les pratiques de la XP 4.2Petites livraisons • Les livraisons doivent être les plus fréquente possible. • Intégration continue et les testes réduisent considérablement le cout de livraison .

25. Les pratiques de la XP 4.3Utilisation des métaphores • Décrire le système et son fonctionnement . • Le fonctionnelle et le technique se comprennent beaucoup mieux lorsqu’ils sont d’accord sur les termes qu’il emploient .

26. Les pratiques de la XP 4.4Conception simple • Implémentation des scénarios sélectionnées par le client est l’objectif d’une itération . • Envisager les prochaines évolutions ferait perdre du temps sans avoir le garantie d’un gain ultérieur . Plus l’application est simple ,plus il sera facile de faire évoluer lors des prochaines itération.

27. Les pratiques de la XP 4.5Les testes • Test de recette (fonctionnelle): • Rédiger par le client a partir d’une langage formelle si c’est possible. • Vérifier que tous fonctionnent correctement et conformément a la demande. • Test unitaire: • Ecrit par le programmeur dans le but d ’assurer le bon fonctionnement du programme .

28. Les pratiques de la XP 4.6Refactoring • Amélioration régulière de la qualité du code sans modifier le comportement . • Cette phase n’apporte rien au client mais permettent aux développeurs d ’avancer dans les meilleure condition .

29. Les pratiques de la XP 4.7Appropriation collective du code • L’équipe est collectivement responsable de l’application. Chaque développeur peut faire des modification dans toutes les portions du code.

30. Les pratiques de la XP 4.8Intégration continue • Lorsque une tache est terminer ,les modifications sont immédiatement intégrés dans le produit complet. • Quand tous les testes passent ,l’intégration est terminer. Evite la surcharge de travail

31. Les pratiques de la XP 4.9Client sur site • Présence de représentant du client (Il doit avoir les connaissances de l'utilisateur final et  avoir une vision globale du résultat à obtenir )pendant toute la duré du projet pour répondre aux question de l’équipe.

32. Les pratiques de la XP 4.10 Convention de nommage • Etablir ,respecter des normes de nommage pour les variables , méthode , objet, classe …

33. Les pratiques de la XP 4.11 Rythme soutenable •  L'équipe maintient sa capacité à rester efficace en ne surchargeant pas le planning et en s’aménageant des horaires raisonnables. • 40 heures de travaille /semaine . • L’équipe ne fait pas d’heure supplémentaire .

34. Les pratiques de la XP 4.12 Programation en binome • La programmation se fait par deux: • Driver (pilote) :tient le clavier ,travaille sur la portion du code a écrire . • Partner (copilote) : pour l'aider en suggérant des nouvelles possibilités ou en décelant d'éventuels problèmes Les développeurs changent fréquemment de partenaire ce qui permet d'améliorer la connaissance collective de l'application et d'améliorer la communication au sein de l'équipe.

35. PLAN Introduction Description de la Extreme Programming Architecture et valeur Les pratiques de la ExtremeProgramming Conclusion

36. Conclusion Extreme Programming est une discipline de développement logiciel basé sur des valeurs de simplicité, de la communication, la rétroaction, et le courage. Il travaille en apportant toute l'équipe ensemble en présence de pratiques simples, avec suffisamment de rétroaction pour permettre à l'équipe pour voir où ils sont et pour régler les pratiques à leur situation unique.

37. Bibliographie • http://extremeprogramming.free.fr • http://www.eyrolles.com • http://extremeprogramming.org • http://fr.wikipedia.org/wiki/Extreme_programming • http://xprogramming.com/book/whatisxp • http://medina.developpez.com/cours/extreme-programming

38. Merci Pour votre Attention…