Checklist Extreme Programming
Une checklist pour s'assurer que l'on parle bien d'Extreme Programming.
Lors d'un recent entretien d'embauche, nous avons demandé au candidat s'il connaissait XP. Sa réponse nous a laissés pensifs :
Ah oui, XP ! Sur l'un de mes précédents projets nous avions déjà essayé de coder sans spécification. C'était bien, mais chacun faisait un peu ce qu'il voulait dans son coin, un peu en mode "cow-boy", ce qui nous a causé quelques soucis...
Avant cela, nous avions rencontré à plusieurs reprises des gens qui nous disaient mettre en place l'Extreme Programming sur leur projet. Extrait d'une conversation type :
- Nous avons une démarche itérative proche d'XP, nous livrons tous les mois environ.
- Et vous avez tout mis en place ? Les tests, le travail en binômes... ?
- Oui, nous avons automatisé les tests de charge du système.
- Ah bon, c'est tout ? Et les tests unitaires, les tests fonctionnels ?
- Non, nous n'avons pas encore mis cela en place, ces tests sont très difficiles à automatiser dans notre contexte.
- Et le travail en binômes ?
- Ca ne s'applique pas à notre projet, notre système est décomposé en modules indépendants qui n'occupent chacun qu'un seul développeur.
Selon les cas, l'image d'XP est donc soit incomplète, soit franchement erronnée. Mais alors, qu'est donc XP, exactement ? N'y a-t-il pas moyen d'en donner une définition simple, non ambigüe, capable de mettre fin aux malentendus ?
Malheureusement, l'exercice n'est pas facile, puisqu'il s'agit de définir une démarche qui couvre l'ensemble des activités d'une équipe de développement - des techniques de programmation jusqu'à la planification du projet, en passant par les relations avec la maîtrise d'ouvrage, ou encore la répartition et le suivi des tâches au quotidien dans l'équipe. Comment définir tout cela en quelques mots ?
A défaut d'élaborer une définition dense, nous proposons de lister ici un ensemble de caractéristiques d'un projet XP, une sorte de checklist permettant de déterminer si le projet en question suit efficacement la démarche.
- L'équipe livre de nouvelles versions de l'application à un rythme régulier (time-boxing), typiquement toutes les semaines ou toutes les deux semaines.
- L'équipe dispose d'un plan de développement qui identifie le contenu fonctionnel attendu pour chacune de ces versions pour les mois à venir.
- Le plan de développement est établi en collaboration avec le "client" du projet, et il est visible de tous.
- Le client est capable de changer les priorités des semaines à venir, et l'équipe est alors capable de se réorganiser sans surcoût excessif.
- Le produit livré par l'équipe de développement comporte très peu de bugs.
- L'ensemble de l'application est couvert par des tests entièrement automatisés.
- Tous les développeurs sont rassemblés dans une "war room", les postes de développement sont regroupés en un bloc central.
- Les développeurs travaillent principalement en binômes, avec des permutations fréquentes des binômes de sorte que chacun soit amené à travailler avec l'ensemble de l'équipe.
- L'équipe se reunit tous les jours pour faire un point sur l'avancement des développements et organiser les activités suivantes.
- Chaque développeur de l'équipe est capable d'intervenir sur l'ensemble de l'application.
- Les développeurs intègrent leurs développements dans la version commune du code au moins une fois par jour.
- Le code de l'application est propre, structuré, sans duplication. Les développeurs ont une bonne maîtrise de l'évolution du code.
- L'équipe se réunit régulièrement pour faire un point sur son fonctionnement, met en place des actions d'amélioration, et vérifie les effets de ces actions.
Cela correspond-t-il aussi à l'image que vous vous faites d'un projet XP ?
