Be prepared for changes!

1. Be prepared for changes! Hortis GRC SA - www.hortis.ch

2. eXtremeProgramming,une introduction Par Didier Besset didier.besset@hortis.ch Hortis GRC SA - www.hortis.ch

3. But de XP Coût du développement software Barry W. Boehm , Software Engineering Economics, Prentice Hall PTR, 1981;ISBN: 0138221227 Hortis GRC SA - www.hortis.ch

4. eXtremeProgramming: principes • Développementitératifs, • Plannification adaptable, pas rigide, • Architecture évolutive, non-contraignante, • Des tests, des tests, et encore des tests, • Be prepared for changes! Hortis GRC SA - www.hortis.ch

5. eXtreme Programming Méthodologies Héritées des grossystèmes Rapid Application Development La Métaphore du Cycle

6. eXtreme Programming Méthodologies Héritées des grossystèmes Rapid Application Development Historical Perspective

7. Perspective littéraire • Voltaire (1694-1778),DictionairePhilosophique: • “Le bon sens est la chose du monde la mieux partagée, car chacun pense en être bien pourvu.” Hortis GRC SA - www.hortis.ch

8. eXtremeProgramming en quelquesmots • Utilisation du bon sens, • Faire les chosessimplement, • Priviliégier la communication, • Interagir de près avec le client; • Faire tout cela à 100%, • Sans compromis! • Be prepared for changes! Hortis GRC SA - www.hortis.ch

9. Perspective littéraire • René Descartes (1596-1650),Discours de la méthode: • “... La seconde, de diviserchacune des difficultésquej’examinerais, en autant de parcellesqu’il se pourrait, et qui seraitrequis pour les mieuxrésoudre.”(page 47 de l’édition G.F. 1966) Hortis GRC SA - www.hortis.ch

10. Années Analysedépassée! Méthodologie “Cascade” Analyse Design Code Test Hortis GRC SA - www.hortis.ch

11. Fonctions Tâches Analyse Design Code Analyse Analyse Analyse Analyse Analyse Analyse Analyse Design Design Design Design Design Design Design Analyse Analyse Analyse Code Code Code Code Code Code Code Test Test Test Test Test Test Test Design Design Design Années Code Code Code Semaines Jours Test Test Test Test Application de la 2èmeméthode de Descartes Projet Hortis GRC SA - www.hortis.ch

12. Plannification à la SCRUM • Client et développeursécrivent ensembles les fonctionalitéssur un support (cartesou JIRA): • User stories; • Le client donne des priorités à chaquefonctionalités , • Les développeursfractionnentchaquefonctionalité en tâches, • Les développeursattribuent “unemesure de complexité” à chaquetâche. Hortis GRC SA - www.hortis.ch

13. Plannification à la SCRUM • La mesure de complexitépeut se convertir en temps de réalisation, • vélocité (auto-calibrée!); • La complexité de chaquefonctionalitéestcalculéecomme la somme des complexités de chaquetâche, • Le client décidealors de la prochainelivraison du système. Hortis GRC SA - www.hortis.ch

14. Plannification à la SCRUM • Si une date de livraisonest en passe d’être dépassée... • ... on signale le probléme au client... • ... qui décidera des fonctionalités a retirer pour conserver la date de livraison; • Après une “bonne” livraison, le client décide de la mise en service. Hortis GRC SA - www.hortis.ch

15. Sénarios de test New user stories Requirements Bugs Plannifi- cation Iteration Acceptance Livraison Release plan Latest version Recette client Structure Architecture Estimation de la vélocité Structure en itérations et livraisons User Stories Hortis GRC SA - www.hortis.ch

16. Les 8 cheminsversXP Sépar. métier et technique Simplicité Test Programmer en paires Intégration continue Code à tous Livraisonsfréquentes Refactoring Hortis GRC SA - www.hortis.ch

17. Séparationmétier et technique • Le client connait son métier, • Les développeursconnaissentleursoutils, • Le client définit les priorités, • Les développeursdéfinissent les délais. Hortis GRC SA - www.hortis.ch

18. Séparationmétier et technique • Le client doitles développeurs pas! • décider des enchainements (workflow), • définir les champs, les menus et les boutons, • choisirunechartegraphique; • Les développeursdoiventle client pas! • déciderd’une architecture, • choisirleursoutils (langage, data base, etc...), • définir les classes et les interfaces. a le dernier mot pour ont le dernier mot pour Hortis GRC SA - www.hortis.ch

19. Tests • Test Driven Design: • Écrire un test avant de coder; • Tests unitairesécrits par les développeurs: • Tester tout ce qui peut “foirer”, • utiliser les valeurslimites; • Tests d’acceptanceécrits par le client: • Vérification des requirements, • Bon départ pour la documentation; • Be prepared for changes! Hortis GRC SA - www.hortis.ch

20. Intégration Continue • Chaquechangementestimmédiatementinclusdans un systèmedéployé, • Le déploiement fait partie du développement, • Un système utilisable existe en permanence, • les développeurspeuvent essayer le système, • le client aussi! • Be prepared for changes! Hortis GRC SA - www.hortis.ch

21. Livraisonsfréquentes • Conséquencedirecte du principed’intégration continue, • Le client a le système en main le plus tôt possible, • Celaluidonnel’occasion de réagiravantqu’il ne soittroptard, • Choc des nouvellesfonctionnalitésatténué, • Be prepared for changes! Hortis GRC SA - www.hortis.ch

22. Simplicité • Écrire du code lisible (pas de virtuosité), • Les autresdoiventpouvoir le lire, • vousaussi, après quelquessemaines! • Les intentions doiventêtreclaires: • Utiliser des standards (format, coding), • Éviter les abbréviations, • Éviter les commentaires; • Ne pas prévoir le futur (vousn’êtes pas devin): • C’estuneperte de temps pour aujourd’hui, • Ce sera uneperte de temps demain! Hortis GRC SA - www.hortis.ch

23. Programmation par paires • 2 personnes font plus que le double de travail, • “One types while the other thinks,” • Une variation des pairesest le meilleurmoyen de faire circulerl’information, • Les nouveaux venussontpromptementintégrés, • Les juniors apprennent beaucoup plus vite... • … et donc, contribuent beaucoup plus vite! Hortis GRC SA - www.hortis.ch

24. Le code appartient à tous • Chaquedéveloppeurdoit savoir tout faire, • Pas de chasse gardée, pas de “prima donna”, • Personne ne doitêtre indispensable, • Donc, le projet ne s’arrêtera pas siquelqu’uns’absente, • Le principe de simplicitéest un pré-requis. Hortis GRC SA - www.hortis.ch

25. Refactoring • Amélioration continue qui fait partie du développement, • Architecture évolutive, qui s’adapte: • “This skill helps develop software that stays soft, and allows more focus on features and less on infrastructure, delivering more value withoutrisking the long term.” (Ron Jeffries) • Be prepared for changes! Hortis GRC SA - www.hortis.ch

26. Conséquencessur le code • Coder dansl’ordresuivant: • “Make it run ”Créer un cas test, le faire passer, • “Make it good ”Refactorer le code pour en améliorer la lisibilité et l’architecture, • “Make it fast ”Si besoinest, optimiser l’exécution; • “Say things once and once only! ” • Ne rienduplifier • “extract method” au lieu de “cut&paste”. Hortis GRC SA - www.hortis.ch

27. Sépar. métier et technique Simplicité Customers know their business, Developer team knows how to use the tools. Clearly stated code, no duplicated logic, fewest number of objects. Test Programmer en paires Automated tests ensure that a change doesnot create new errors. Business test cases. “One types, the other thinks”. This ensuresthe best communication within the team. Intégration continue Code à tous Anyone would can contribute to the code will.Customers get the best of our developers. Customers can always see a working version. Full control over development. Livraisonsfréquentes Refactoring Customers make their product evolve with the market. Changes are possible on the fly. When adding a new feature, existing code isadapted if needed, ensuring code reuse. Les 8 cheminsversXP (conclusion) Hortis GRC SA - www.hortis.ch

28. Questions? Hortis GRC SA - www.hortis.ch