Programmation eXtrme

1
Programmation eXtrême

• Daniel Le Berre
• MI3 Génie Logiciel
• Décembre 2001

2
Ce cours

• Basé sur l ouvrage de Kent Beck  eXtreme
  Programming explained embrace change . Adison
  Wesley,ISBN 0201616416
• Voir aussi le site www.xprogramming.org

3
XP en deux questions ?

• Pour qui ?petites à moyennes équipes écrivant
  des logiciels dont les besoins sont vagues ou
  changent rapidement
• Pourquoi extrême ?Le bon sens est poussé à son
  extrême !

4
Quelques principes

•  Si les relectures de code sont bonnes, nous en
  ferons tout le temps! (programmation par paire) 
•  Si tester est important, tout le monde testera
  tout le temps (tests unitaires), même le
  consommateur (tests fonctionnels). 
•  Si concevoir est important, nous en ferons une
  occupation quotidienne pour tout le monde
  (refactoriser). 

5
Quelques principes (suite)

•  Si la simplicité est bonne, nous laisserons
  tout le temps le système dans la plus simple
  conception qui peut achever les fonctionnalités
  courantes (la plus simple chose qui puisse
  fonctionner). 
•  Si larchitecture est importante alors tout le
  monde définira et raffinera l architecture tout
  le temps (métaphore). 
•  Si le test d intégration est important alors
  nous intégrerons et testerons plusieurs fois par
  jour (intégration continue). 

6
Quelques principes (fin)

•  Si les itérations courtes sont souhaitables,
  alors nous ferons des itérations très très
  courtes secondes, minutes et heures, pas
  semaines, mois et années (the jeu de la
  planification). 

7
Les promesses (1) aux programmeurs

•  ils auront l occasion de travailler sur des
  chose importantes, tous les jours. Ils n auront
  pas à faire face à des situations effrayantes
  seuls. Ils pourront faire tout ce qui est en leur
  pouvoir pour faire fonctionner leur système. Ils
  prendront les décisions pour lesquelles ils sont
  le mieux qualifiés, et ne prendront pas celles
  pour lesquelles ils ne le sont pas. 

8
Les promesses(2) - aux clients et managers

•  Recevoir la plus grande valeur possible de
  chaque semaine de travail. Chaque semaines il
  verront des progrès concrets sur les buts qui les
  préoccupent. Ils seront capables de changer de
  direction au cours du projet sans que cela
  induise des coûts exorbitants. 
• En résumé  réduction des risques, améliorer la
  réponse au changement et la productivité tout au
  long du cycle de développement, et ajouter du
  plaisir au développement de logiciels en équipe. 

9
XP, une méthodologie

• Cycles courts gt retours tôt, concrets, en
  continue.
• Planification incrémentale
• Ordonnancement flexible des fonctionnalités à
  implanter gt réponse aux besoins changeants
• Dirigée par les tests gt le système évolue, les
  problèmes sont détectés tôt.
• Basée sur la communication orale, les tests, et
  le code source !
• Conception évolutive.
• Collaboration de programmeurs ordinaires.

10
Limites

• Équipes de 2 à 10 personnes
• Pas de contraintes matérielles fortes
• Les tests doivent pouvoir être effectués en moins
  dune journée.

11
Une question de risques

• Retards.
• Projet annulé.
• Système peu ou pas utilisé (maintenance).
• Système ne répond pas/plus aux besoins du client.
• Trop de possibilités non utilisées.
• Turnover des équipes.

12
Retards

• Cycles courts gt retards limités.
• Le client vérifie lavancée des travaux toutes
  les une à quatre semaines.
• Dans une itération, une tâche ne dure que un à
  trois jours.
• Les fonctionnalités les plus importantes sont
  implantées d abord gt les fonctionnalités non
  présentes en cas de retard seront secondaires.

13
Projet annulé

• XP demande au client la plus petite release du
  système qui lui apporte le plus gt si le projet
  échoue, ce sera vite fait, avant que le projet ne
  coûte trop.

14
Projet peu/pas utilisé

• Peu utilisé (maintenance coûteuse) les tests
  sont lancés et relancés après chaque changement
  gt système toujours de première fraîcheur.
• Trop de bugs les tests sont écrits à la fois
  par les programmeurs (fonctions par fonctions) et
  les clients (fonctionnalité par fonctionnalité).

15
Besoins du client

• Le client doit faire partie de léquipe !
• La spécification du projet est continuellement
  raffinée gt lapprentissage du client et des
  programmeurs se retrouve dans le logiciel.
• Cycles courts gt peu de changement durant un
  cycle.
• Le client est libre de remplacer des
  fonctionnalités non implémentées par une nouvelle
  fonctionnalité.

16
Usine à gaz

• Seules les tâches les plus prioritaires sont
  effectuées.

17
Turnover des Équipes

• Chaque programmeur estime le temps nécessaire à
  la réalisation de la tâche gt il faut respecter
  ces estimations gt il est peu probable que lon
  demande à un programmeur limpossible.
• Contact avec les autres programmeurs gt moins de
  solitude gt moins dinsatisfaction.
• Nouveaux membres aidés par les autres membres.

18
Une journée dXP

• Choix dune tache.
• Choix dun partenaire.
• Écriture des tests.
• Implantation et tests
• Écriture dautres tests.
• Refactorisation/Conception et tests
• Intégration et tests
• (cf TD/TP de la semaine dernière).

19
Conclusion de la journée

• Programmation par paire.
• Développement dirigé par les tests tester
  dabord, coder ensuite. Tous les tests doivent
  réussir.
• La paire fait aussi de la conception pas de
  décomposition du système par équipe, les
  changements peuvent être effectués partout dans
  le code.
• Lintégration (et les tests d intégration)
  suivent directement le développement.

20
Limportance des tests

• Tests réussis confiance.
• Plus de confiance plus defficacité.

21
XP vs GL

• XP est contre lhypothèse  le coût du
  changement augmente exponentiellement durant avec
  le temps .
• Au contraire, il est préférable de retarder toute
  décision qui nest pas sure.
• Préconditions
• objets découplage interface/implantation.
• Conception simple
• tests automatisés
• de la pratique dans la modification de conception.

22
La méthodologie XP

• Le jeu de la planification
• Release courtes
• Métaphore
• Conception simple
• Tests
• Refactorisation

• Programmation par paire
• Appartenance collective
• intégration continue
• 40 heures par semaines
• Un client sur site
• Conventions de codage

23
Le jeu de la planification

• Les gestionnaires décident
• La portée du logiciel.
• Priorité des tâches.
• Composition des releases.
• Jalons.
• Les programmeurs décident
• Estimations de temps.
• Conséquences des choix techniques (Ex BD).
• Organisation de léquipe.
• Calendrier détaillé (tâches à haut risque
  dabord, flexible pour prendre en compte les
  besoins du client).

24
Releases courtes

• Doivent contenir les besoins les plus importants
  du client.
• Doivent être cohérentes on ne fait pas le
  travail à moitié pour diminuer le temps de mise
  en production.
• Planification sur un mois ou deux préférable à 6
  mois ou un an.

25
Métaphore

• Chaque projet est guidé par une métaphore
   l ordinateur doit apparaître comme un bureau,
  le calculateur de retraite est comme un
  tableur,... .
• Remplacement de larchitecture en développement
  traditionnel.
• Apporte une cohésion densemble facile à partager.

26
Conception simple

• Une bonne conception
• réussit tous les tests.
• pas de duplication (Ex hiérarchie de classes
  //).
• Reflète chaque intention importante du
  programmeur.
• Contient le moins de classes et de méthodes
  possible.
• Comment faire ? Faire un premier jet et enlever
  toutes les classes dont labsence ne viole pas
  ces règles !

27
Tests

• Programmeurs gt pour avoir confiance en leur
  code.
• Client gt pour avoir confiance dans les
  fonctionnalités du système.
• Résultat le programme supportera mieux les
  changements.
• Tests pour les méthodes de production qui
  pourraient défaillir uniquement.

28
Refactorisation

• Simplification de la conception après ajout dune
  fonctionnalité.
• La nouvelle conception doit passer les tests
• Ex IMoney la semaine dernière.

29
Programmation par pair

• 1 ordinateur 2 programmeurs.
• 1 pense au code nécessaire pour une méthode.
• Lautre pense globalement
• lapproche a telle marché.
• Quels sont les autres cas de tests qui ne
  marchent toujours pas.
• Ny a til pas une solution plus globale pour
  résoudre tous ces problèmes ?

30
Appartenance collective

• Chacun peut modifier tout morceau de code à
  chaque instant.

31
Intégration continue

• Le code est intégré et testé après quelques
  heures, une journée au plus.
• Machine dédiée à lintégration.
• Les tests d intégration doivent réussir. Sinon
  
• résoudre les problèmes.
• recommencer à zéro le développement.

32
40 heures par semaines

• Il faut être frais et dispos pour bien travailler
  !

33
Un client sur site

• Pour répondre aux questions, résoudre les
  conflits, définir les priorités à bas niveau.
• Coûte cher, mais apporte beaucoup au projet.

34
Conventions de codage

• Si tout le monde peut changer le code, il faut
  que tout le monde utilise les mêmes conventions
  de codage.
• Elles doivent être adoptées par toute lequipe.