Extreme Programming - XP Une méthode de développement par Kent Beck

2 Le cycle de vie d’un système …. spécification Design (conception) codage « déboggage » Mise en service maintenance Analyse de besoins Temps t Le modèle de la « chute d’eau » - La vision traditionnelle

3 ….. mais la maintenance coûte ! Coût de modification Age du système La vision traditionnelle: Un système devient plus difficile à modifier avec le temps Confirmé par la bogue de l’an 2000 ?

4 La crise de logiciel u Une courbe exponentielle du coût de la maintenance u Un manque de qualité äLa qualité se définit par la validité, la sécurité, la tolérance aux erreurs, l’extensibilité, … u Une pénurie de bons programmeurs u Les besoins des clients changent pendant le développement äJusqu’à 25% [McConnell] u La plupart des projets sont livrés en retard äS’ils ne sont pas arrêtés avant u Les moyens disponibles pour le projet sont trop peux

5 Extreme Programming - XP u XP est un processus de développement qui a pour but äDe produire du logiciel de qualité äLe développement ne coûte pas cher äLes systèmes ne sont pas livrés en retard u XP consiste en un ensemble des mesures qu’une équipe de développement doit suivre äP.ex: les tests, la programmation en pairs, …. u XP est une discipline u La discipline est extrême dans le sens qu’il faut vraiment suivre toutes les mesures proposées

6 Vers XP u L’adoption d’XP nécessite d’abord une connaissance des risques de développement äLes retards äL’annulation du projet äTrop de bogues äMauvais compréhension de l’aspect Economique  C-à-d: les besoins des clients, l’orientation du marché äChangement dans l’orientation de l’Économique äChangement de personnel dans l’équipe äL’équipe perd l’intérêt dans le système ä« False Feature Rich » - trop d’effort dépensé dans le développement des propriétés qui ne sont pas les plus importantes

7 La philosophie de l’XP u Pour rapidement trouver et corriger les bogues äOn code en pairs, tout le monde est co-propriétaire du code, et on écrit beaucoup de tests u Pour gérer les risques associées à l’Économique äLe design est fait en itérations successives äLes modifications sont testées et puis intégrées rapidement dans le système äOn garde les designs aussi simples que possible äOn est toujours en train de réviser ses propres designs u Pour gérer les problèmes de personnel äTout le monde est co-propriétaire du code

8 XP marche, mais pourquoi ? u Une meilleure prise de connaissance des risques vis-à- vis de l’Économique äOn développe dans l’itération courante ce qui est le plus important (pour le client) actuellement  Pas de paris sur l’évolution de l’Économique u L’effondrement de la courbe de coût de la modification äLa courbe devient linéaire !!! (le coût de modification d’un système ne change pas avec le temps)  À causes des tests  À cause des propriétés de la programmation à objets

9 Les 4 variables du développement 1) Le coût 2) Le temps (la durée) 3) La qualité 4) La portée (de la spécification) u Les variables sont fixées par l’économique, et ont une influence une sur l’autre u XP: La qualité ne doit pas être traitée comme étant une variable u XP: On varie la variable de portée en fonction des variables de coût et de temps

10 Les 4 valeurs du développement 1) La communication äEntre les programmeurs, dans une équipe entre le Développement et l’Économique, entre l’équipe et le clientèle 2) La simplicité äPour la révision de code et le développement rapide, 3) Le feed-back äSur le système (via les tests), mais aussi sur la performance de l’équipe (p.ex. la vélocité du projet) 4) Le courage äIl faut pouvoir jeter un développement s’il ne marche pas avec les tests ou si l’Économique le rend inutile äPour proposer des idées bizarres

11 Quelques principes de l’XP Il faut des principes pour concrétiser les valeurs u Le feed-back rapide äLes programmeurs ont une tendance à oublier leur code avec le temps äComprendre tout de suite les implications d’une modification  XP : les tests, les mesures, l’intégration rapide u Chercher la simplicité äOn code un composant aussi simplement que possible u La modification par incrémentation äUn changement à la fois (dans l’équipe, la spécification, les outils) u Attendre des changements äOn découvre toujours des moyens de mieux faire des choses  XP : la révision du code

12 Quelques principes de l’XP u Qualité äIl faut savoir varier la variable de portée u Apprendre (et noter) u Un investissement initial minimal äIl y a trop d’incertitude au début d’un projet ; donc, on ne dépense pas de ressources avant qu’on en aie vraiment besoin u Jouer offensivement äIl faut créer un cadre et une mentalité où l’équipe peut progresser äP.ex: il est plus important d’écrire des tests que des rapports u Des expériences concrètes äCe sont les tests qui indiquent si le système marche ou pas

13 Quelques principes de l’XP u La communication honnête äSi le code a besoin d’être révisé, alors il faut le dire u Accommoder les intérêts des gens äUn co-équipier n’est pas un valet; il faut qu’il ait un moyen d’avancer (apprendre, contribuer,.. ) u La responsabilité äEst prise, et jamais donnée u Minimum de bagages äOn achète les outils lorsqu’on en a vraiment besoin ….. u Mesures concrètes äIl faut toujours vérifier la vélocité du projet

14 La mise en œuvre de l’XP u La planification äUne équipe comprend une partie Économique et une partie Développement  L’Économique spécifie les besoins  Le Développement fait les estimations de coût et de durée  Puis l’Économique décide sur la portée u Des versions incrémentales äIl vaut mieux avoir une nouvelle version du système tous les 2 ou 3 mois que tous les 6 mois (mais qui comprend plus de modifications)

15 La mise en œuvre de l’XP u Une métaphore äDécrit le rôle (ou la vision) du système. On s’en sert pour guider le développement et pour évaluer son progrès u Un design simple 1.Tous les tests marchent 2.Pas de duplication de code 3.Le nombre minimal de méthodes et des classes u Les tests äLes tests sont écrits par les clients et par les programmeurs äLes tests servent également à préciser le design äXP parie que le temps « perdu » à écrire les tests est largement compensé par les gains en temps de développement

16 La mise en œuvre de l’XP u La révision de code et du design äOn change le code d’un composant dès qu’on voit une manière plus simple de l’implanter  Plus de travail dans le court-terme, mais …. u La programmation en pairs äOn change les pairs fréquemment au sein de l’équipe  On range son bureau pour faciliter l’XP u La propriété commune äTout le monde est co-propriétaire du code du système äDonc, il est au courant du fonctionnement de chaque partie

17 La mise en œuvre de l’XP u Les semaines de 40 heures äIl ne faut pas faire des heures supplémentaires äUne équipe débordée est une équipe dont le processus ne fonctionne pas ! u Intégration rapide äUn nouveau composant est vite intégré est testé  (si les tests ne marchent pas, alors on jette le composant) u Un représentant du client doit être toujours disponible u Les programmeurs doivent adopter des standards de programmation äImportant pour la propriété commune et l’intégration continue

18 Les rôles au sein d’une équipe u Programmeur äIl code et il propose des estimations pour le processus de planification u Client äIl achète et il écrit des tests et il prend des décisions sur la portée u « Testeur » : il écrit et fait tourner les tests u « Traceur » äIl archive les données de performance de l’équipe  P.ex: la vélocité du projet, le nombre de tests u Si la vélocité est trop élevée, alors on ne fait pas suffisamment de révisions de code u Coach : un programmeur qui guide l’application des principes de l’XP

19 Bibliographie u Extreme Programming Explained äKent Beck, publié chez Addison-Wesley u