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