Introduction à

eXtreme Programming

1
 Extreme Programming (XP)‫‏‬
• L’autre méthodologie dont on parle beaucoup
• Comme la plupart des autres méthodes XP est
recommandé pour…
o Des équipes de tailles petites ou moyennes
o Des projets avec de nombreuses zones d’incertitude (risques)‫‏‬
o Lorsque les besoins sont vagues ou évoluent rapidement
• Adopte des processus issus d’autres méthodologies
o E.g. SCRUM, Crystal
• A été utilisé ou expérimenté chez…
o Daimler-Chrysler, Ford, Capital One, IBM, et beaucoup d’autres
 Les valeurs

communication simplicité

respect

courage feedback

Communication leads to valuable feedback which encourages simplicity

which allows for courage to change
 Les pratiques
• Les pratiques découlent des 4 valeurs
o Communication, Simplicité, Feedback, Courage
o Considérez les comme des « des fonctions de maximisation »
• Pratique = Étude
o En musique classique, une étude est, à l’origine, une pièce destinée
à améliorer certains aspects techniques d’un élève ou d’un interprète
o Il arrive de ne pas appliquer toutes les pratiques tout le temps en
fonction des projets
o Mais l’utilisation répétée des pratiques XP améliore
incontestablement les compétences des développeurs et leur
capacité à proposer des solutions plus rapidement
• Les pratiques procurent les meilleurs résultats
lorsqu’elles sont utilisées de façon conjuguée (SYNERGIE)‫‏‬
 Les « cercles de vie »

On-site Customer

Coding Metaphor
Standards Refactoring

Le client L’équipe Le code L’équipe Le client

Acceptance Unit Tests Pair Release
Tests Programming Planning

Continuous Collective
Integration Simple Design Ownership
Sustainable
Pace

Small Releases
 Client sur site
• Définit les besoins, les fonctionnalités, définit les priorités et de
répond aux questions des développeurs
• Une interaction quotidienne de vis-à-vis
o Réduit la quantité de documentation écrite
o Et le coût élevé de sa création et de sa maintenance
 Planification de Release
• Où « jeu du planning »
• Le « client » XP de doit définir la valeur métier des
fonctionnalités
o User Stories
• Les développeurs (pas seulement un CP) estiment les
fonctionnalités
• A partir de ces informations, le client et les développeurs
effectuent une sélection en fonction du ration coût / bénéfice
o Permet une priorisation optimale des fonctionnalités
 Livraisons courtes
• Mettre en production un système simple le plus rapidement
possible puis appliquer des cycles de livraisons très courts
• Exemple
o Releaser tous les 2 ou 3 mois
o Chaque release contient plusieurs itérations
• Établir un « rythme »
o Feedback régulier pour le client et l’équipe
• Permet d’évaluer la véritable valeur du produit dans son
environnement réel
 TDD
• Où « Test First », « Test Infected »
o TESTS D’ACCEPTANCE : on demande aux clients de fournir des
tests d’acceptance avant les développements (idéalement
automatisés)‫‏‬
o TESTS UNITAIRES : les développeurs écrivent d’abord des tests
puis créent le logiciel qui répond aux exigences capturées dans les
tests
• Automatisation, Automatisation, Automatisation, (JUnit, XUnit) [5]
o Un développement piloté par les exigences garantit que les
fonctionnalités essentielles seront fournies
 Refactoring
• Les développeurs restructurent le système sans en
modifier le comportement pour supprimer les
duplications, faciliter la communication, simplifier ou
améliorer la flexibilité
• Petites étapes
• Coder, tester, refactorer, tester, coder, refactorer
o Beck suggère [1] des cycles de (10 minutes)‫‏‬
• Un alignement sur un pattern de conception est un
refactoring typique
• Basé sur le travail de Martin Fowler [6,7]
 Programmation en binôme
• Le code est écrit par 2 développeurs sur 1 seule machine
o L’un la tactique, l’autre la stratégie
• Le binôme devrait être « dynamique »
o Les membres en binôme changent de rôle toutes les 30 à 60 minutes
o Et sur tous les types de tâches
• L’expérimentation montre une réelle efficacité *8+
 Programmation en binôme
• Les bénéfices
o Revue de code continue
o Partage continu du métier
o Amélioration continue des compétences techniques
(Java, Design Patterns, Refactoring, IDE…)‫‏‬
• Les développeurs on parfois plus de mal avec cette
pratique que les managers
o Tester pour voir si cela fonctionne
o Peut nécessiter un temps d’acclimatation
o Expérience du développement plus intense
 Conception Simple
• Basé sur le principe que la plus haute valeur métier
dérive du programme répondant aux besoins courants
le plus simple
• Pas d’over-engineering !
• K.I.S.S (un concept difficile à appliquer)‫‏‬
• 2 philosophies communes d’équipes XP
o DTSTTCPW – Do The Simpliest Thing That Could Possibly Work
o YAGNI – You Aren’t Gonna Need IT
 Standards de développement
• Les développeurs produisent du code en conformité avec des
règles favorisant la communication au niveau du code
• L’objectif : produire un code auto documenté
• La raison : le langage comment est le code
• Plus que de la Javadoc; de la bonne Javadoc et des
commentaires appropriés
 Métaphore
• La vision de « l’architecture » selon XP
• Guide les développements en fournissant une vision commune
et unique de la façon dont le système fonctionne
• Définit un vocabulaire et guide l’équipe dans les
développements et la communication
 Intégration Continue
• Intégrer et construire le système aussi souvent que possible
• Intégrer à chaque fois qu’une tâche est finie
• Permet de connaître à tout instant le « statut » du système
 Propriété collective
• Tout développeur peut modifier toute portion de code
à n’importe quel moment
• Ceci est facilité par l’utilisation de Standards de
développement, de TDD et de Pair Programming
(Synergie)‫‏‬
• Sécurise l’équipe en terme de vacances, congés,
maladie, turn-over
o Les progrès ne s’arrêtent pas sur un composant parce qu’un membre
de l’équipe est absent
 Rythme soutenable
• Des développeurs fatigués produisent la plupart du temps un
code de moindre qualité
• Minimiser les « heures supplémentaires » et conserver une
équipe fraîche produit un code de meilleur qualité en moins de
temps
• 40 – 45 devrait être la règle
o Selon les préférences des équipes
• Corollaire : ne jamais faire des heures supplémentaires une
seconde semaine d’affilée
o Éviter le burnout
 Avantages‫‏‬d’XP
• Extrême = continuellement
o Revue de code (pair programming)‫‏‬
o Tests unitaires
o Tests d’intégration
o Tests d’acceptance utilisateurs
• Pouvez vous satisfaire votre client avec du feedback, de
la communication et de la simplicité constante ?
• Le feedback procuré par les estimations, les tests, les
livraisons fréquentes
o Donne confiance aux utilisateurs
o Donne confiance à l’équipe
o Donne confiance au management
 Limitations
• XP peut ne pas fonctionner pour
o Des grosses équipes
o Des équipes distribuées
o Des systèmes trop complexes
o Des projets d’intégration avec du code existant
o Des organisations où la méthodologie est particulièrement rigide
o Des organisation ou règne la culture du burn-out
• Où la valeur d’une personne dépend du temps passé au travail
o Des ego sur dimensionnés
o Des environnements physiques inappropriés
• Mais XP peut être adapté
 Inconvénients‫‏‬d’XP
• Le changement culturel peut être difficile pour les
développeurs et les managers
o Mineurs : rythme soutenable, standards de développement, tests,
refactoring
o Majeurs : client sur site, jeu de planification, livraisons fréquentes,
conception simple
o Extrêmes : propriété collective, programmation en binôme, métaphore
• Requiert des développeurs expérimentés
• Disposer d’un client sur site n’est pas toujours possible
o Manque de disponibilité
o Niveau de prise de décision
o En rupture avec la culture interne
Cycles de feedback
23
 Scrum Daily Scrum Scrum & XP
Team

XP Sprint
backlog
Whole
team

Coding Burndown
Collective chart
ownership TDD standard
Product
backlog

Customer
tests Pair Refactoring Planning Sprint
Product programming game Planning
owner meeting

Continuous Simple Sustainable

Integration design Pace

Metaphor

Small
ScrumMaster releases

Sprint
Review