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 [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 :
Voir