L’eXtreme Programming (XP) est une méthode agile qui a été inventée par Kent Beck, Ward Cunningham et Ron Jeffries lorsqu’ils travaillaient sur un projet de calcul des rémunérations chez Chrysler. Cette méthode pousse à l’extrême des principes simples et connus de l’industrie du logiciel.
- puisque la revue de code est une bonne pratique, elle sera faite en permanence (par un binôme)
- puisque les tests sont utiles, ils seront fait systématiquement avant chaque implémentation
- puisque la conception est importante, elle sera faite tout au long du projet (refactoring)
- puisque la simplicité permet d’avancer plus vite, nous choisirons toujours la solution la plus simple
- puisque la compréhension est importante, nous définirons et ferons évoluer ensemble des métaphores
- puisque l’intégration des modifications est cruciale, nous l’effectuerons plusieurs fois par jour
- puisque les besoins évoluent vite, nous ferons des cycles de développement très rapides pour nous adapter au changement.
L’Extreme Programming repose sur 5 valeurs fondamentales :
- La communication : La communication, quelle soit avec le client ou au sein de l’équipe permet d’éviter les dérapages possibles d’un projet.
- La simplicité : Privilégier un code simple et épuré. Ne pas faire plus que nécessaire. Utilisation d’outils simple.
- Le feedback : Si des points ne sont pas clair, agir, expérimenter ou questionner pour obtenir des réponses.
- Le courage : Affronter les difficultés plutôt que de les ignorer ou de repousser à plus tard leur prise en compte.
- Le respect : Du client, de l’équipe, des processus.
Ces 5 valeurs se déclinent en 12 pratiques :
- Client sur site (ou tout du moins une incarnation du client) : La personne jouant le rôle du client doit avoir les connaissances de l’utilisateur final et avoir une vision globale du résultat à obtenir. Ils doit répondre aux questions fonctionnel que pourrait se poser l’équipe.
- Jeu du Planning : Le client donne une priorité aux scénarios. Les développeurs discutent du contenu de ces scénarios, estiment la charge de travail nécessaire et les risques relatifs. Le client sélectionne ensuite les scénario en fonction des priorités et du temps disponible.
- Intégration continue : Le projet est fréquemment compilé et testé. Permet de réagir et de débusqué d’éventuelles erreurs.
- Livraisons fréquentes : Rassure le client et lui permette de réagir rapidement si l’application livrée ne correspond pas à ses attentes. Maintient la motivation de l’équipe.
- Rythme soutenable : L’équipe ne fait pas d’heures supplémentaires deux semaines de suite. Si le cas se présente, il faut revoir le planning. Un développeur fatigué travaille mal.
- Tests unitaires et tests de recette : De préférence automatisés.
- Conception simple : L’applicatif doit répondre aux critères de lisibilité, de concision, de modularité, de cohérence, de maintenabilité.
- Utilisation de métaphores : Des analogies sont utilisés pour faciliter la compréhension des utilisateurs.
- Refactoring (ou remaniement du code) : On retravaille le code pour l’améliorer tout en gardant les mêmes fonctionnalités. (Les tests unitaires permettent de s’assurer que le fonctionnel n’est pas affecté par les changements effectués sur le code)
- Appropriation collective du code : Le code appartient à tout le monde et chaque développeur peut modifier toutes les parties du code si le besoin s’en fait sentir.
- Convention de nommage : Le code doit respecter une convention de nommage et ainsi être lisible par tous les membres de l’équipe.
- Programmation en binôme : Le pilote tient le clavier et tape. Le co-pilote suggère de nouvelles solutions et relis le code pour éviter d’éventuelles erreurs.
Même si certaines pratiques sont assez contraignantes (comme le binomage) d’autres sont essentielles au bon déroulement d’un projet (intégration continue, livraisons fréquentes, refactoring, convention de nommage, les tests…). C’est pourquoi les pratiques de d’XP sont souvent utilisées avec d’autres méthodes agiles comme SCRUM, on parle alors de SCRUM XP.
