eXtreme Programming : programmation extrême.
Besoin
Définir un processus de développement logiciel permettant :
- de mettre en avant le travail en équipe
- de satisfaire les besoins des clients
- d'être réactif aux changements des besoins
Analyse
XP est une méthode agile réunissant un ensemble de bonnes pratiques de :
- Expression des besoins
- Scénarios écrits par les utilisateurs pour chaque fonctionnalité de l'application, avec leurs propres
termes. On les demandes sous forme très grossière, en 2 ou 3 phrases, pour permettre d'évaluer avec un risque
mesuré leur temps d'implémentation (entre 1 et 3 semaines). Ce sont ces scénarios qui font servir de base à la
réalisation de tests de conformité. Au moment de l'implémentation proprement dite le développeur viendra
demander face à face une description plus détaillée.
- Gestion de projet
- planifier les versions (planning game)
- livraisons fréquentes (frequent releases) d'un produit en état de marche
- mesurer la vélocité du projet
- itérations entre 2 et 3 semaines. Les programmeurs se focalisent sur les objectifs de cette itération
et aucun autre
- client sur site (on-site customer ou whole team) ou représentant ayant
tous pouvoirs
- contractuels
- droit du client à changer d'avis sur le contenu fonctionnel ou les priorités
- possibilité pour le client de se dégager du contrat à tout moment, sur décision motivée
et à condition d'avoir rémunéré le prestataire pour, au minimum, toutes les itérations qui ont fait
l'objet d'une recette-livraison
- réunion debout chaque jour
- (représentant) client toujours disponible pour dialoguer avec l'équipe de développement.
- rythme raisonnable (sustainable pace) : pas de journées trop longues qui amènent à
décroitre la qualité
- corriger XP lorsqu'il défaille
- Conception
- coder les tests d'abord : il orientent la conception par codage (programmation par
intention)
- simplicité d'abord : les optimisations viendront plus tard
- métaphone du système pour le faire mieux assimiler et comprendre ses tenants et
aboutissants
- cartes CRC
- créer des prototypes rapides (spike solutions) pour éliminer les inconnues
techniques
- ne jamais ajouter de fonctionnalité trop tôt
- remaniement du code (refactoring) : réarranger/réécrire le code chaque fois que
possible
- Gestion de configuration
- intégration continue (continous integration) : à chaque itération. Cette
intégration doit exploiter des tests unitaires offrant une couverture suffisante du système (rejouer les tests
de recette à chaque intégration serait trop long).
- une intégration à la fois
- Implémentation
- standards de codage
- code partagé : le code n'appartient à personne en particulier, faire tourner les gens sur
les différentes parties
- codage en binôme : le débat sur la conception et l'implémentation se fait tôt (avant les
problèmes), la propriété du code est tout de suite partagée
- optimisation à la fin
- Tests
- fourniture par le client et à l'avance de tests fonctionnels automatiques et utilisation de
ces tests comme critère unique de recette de chaque livraison
- Tout ce qui est codé doit avoir un test unitaire
- tout les codes doivent avoir passé les tests unitaires avant d'être diffusés
- ajouter de nouveaux tests lorsqu'un bug est trouvé
- lancer souvent des tests d'acceptation et en publier le résultat
Notes
- Bien adapté aux petits projets
- Fondé sur les travaux de Kent Beck, Ron Jeffries, Ward Cunningham, Martin Flower.
- Officiellement apparu en octobre 2000 avec la sortie de s1[Benk 2000].
- Plutôt adapté aux projets en régie forfaitée.
- Vise à réduire les coûts indirects d'un projet en instaurant une relation
gagnant-gagnant
Limitations
- Peu adapté aux grands projets : les diviser en sous-projets.
Exemples
Des projets XP ont été menés à bien pour :
- Bayerische Landesbank
- Credit Swiss Life
- Daimler Chrysler
- First Union National Bank
- Ford Motor Company
- UBS
Des exemples d'outils pour les projets XP sont :