By Marc Audefroy, le 24 novembre 2012.
Commençons par un bref rappel des valeurs et principes de l’extreme programming ou XP :
Les pratiques de l’Extreme Programming
Les valeurs de bases d’eXtreme Programming
Pour que les pratiques de l’eXtreme Programming fonctionnent, il est nécessaire de respecter 4 valeurs.
La communication pour une meilleure visibilité
La communication est en effet un point indispensable dans une équipe XP. Lorsqu’on parle de communication, il s’agit surtout de communication directe (orale). Elle favorise en effet le transfert de compétence, la détection de problème, l’entraide au sein de l’équipe et la confiance entre le client et l’entreprise.
La simplicité comme garantie de productivité
Côté client, c’est à lui de définir ce dont il a réellement besoin et d’y mettre des priorités. Côté développeur, il est inutile de s’occuper de cas qui n’arriveront peut-être jamais. C’est en appliquant cette simplicité que la rapidité de développement et la possibilité de changement seront favorisées.
Le feedback comme outil de réduction du risque
Le feedback est au coeur de la méthode eXtreme Programming. En effet, elle est gage de qualité. On retrouve la notion de feedback à différentes échelles du projet : des tests unitaires au tests de recettes jusqu’à la structure itérative de la méthode.
Le courage de prendre les bonnes décisions
Le courage est une qualité qu’il faut pour pouvoir respecter les trois précédentes valeurs. Il faut du courage pour se focaliser uniquement sur ce dont on a besoin, de maintenir une transparence en communiquant sur nos difficultés(et nos atouts) et admettre les différents feedbacks comme par exemple devoir jeter une partie de code qu’on aurait créé et qui ne conviendrait pas.
Les règles d’eXtreme Programming
Il existe 13 régles si on veut respecter l’eXtreme Programming. Celles-ci se découpe en 3 catégories :
Les pratiques de programmation
- Une conception simple (simple design) : inutile d’inventer des mécanismes génériques, le “péché mignon” du développeur, si ce n’est pas nécessaire. Il faut toujours implémenter la solution la plus simple.
- Le remaniement (refactoring) : Il est important que les développeurs reviennent sur leur code pour le rendre plus simple, enlever les parties inutilisées.
- Développement piloté par les tests unitaires(Test Driven Developpement) : Le développeur écrit des tests unitaires avant d’écrire le code. Cette pratique lui permet de bien structurer dans son esprit ce qu’il veut faire ainsi que d’éviter le phénomène de régression.
- Test de recette (acceptance test) : Ces tests sont créés par le client. Il lui permet de définir les objectifs que les développeurs doivent atteindre. Si le test passe, alors la fonctionnalité est validée tel que le client la veut.
Les pratiques de collaboration
- Programmation en binôme (pair programming) : Les développeurs doivent développer en binôme (deux par ordinateur). Cela permet une relecture en temps réel du code. Les binômes sont changés régulièrement
- Responsabilité collective du code (collective code ownership : Les développeurs travaillent en binôme et changent régulièrement, ainsi, chacun travaille sur chaque partie de l’application. Chacun à le devoir d’améliorer le code même s’il n’en est pas l’auteur.
- Règle de codage (coding standards) : Des règles de codage sont décidées au début du projet. Chacun doit s’y tenir afin de garantir la cohérence du code et ainsi faciliter la modification de celui-ci par n’importe quel développeur.
- Métaphore : Le système ainsi que les sous-systèmes doivent être décrit par des métaphores ceci dans le but de faciliter la communication.
- Intégration continue (continuous integrated) : Les développeurs doivent synchroniser le plus souvent possible leur travail afin de faciliter le processus d’intégration.
Les pratiques de gestion de projet
- Livraisons fréquentes (fréquent releases) : Le logiciel doit être livré régulièrement. Cela permet au client ainsi qu’aux développeurs de s’assurer que le produit correspond bien aux attentes.
- Planification itérative (planning game) : Lors d’une réunion dédiée, le planning décrivant l’itération en cours est décidé par le client et l’équipe de développement.
- Client sur site (on-site customer) : Le client doit être intégré à l’équipe, la communication est ainsi optimale. Le client au sens eXtreme Programming n’est pas forcément le client au sens commun. Le client, au sens XP, est celui qui prend les décisions et qui est capable de répondre aux questions des développeurs.
- Rythme durable (sustainable pace) : L’équipe de développement doit avoir un rythme qui peut être conserver tout le long du projet. Ce rythme doit favoriser le travail de qualité. Les périodes de “rush” sont à éviter.
Les rôles eXtreme Programming
EXtreme Programming définit six rôles principaux dans un projet IT :
- Le programmeur : c’est le développeur. Dans son rôle XP, il est responsabilisé. En effet, sa proximité avec le client ainsi que le respect des différentes règles(dont la responsabilité collective du code) responsabilise et revalorise le métier de développeur.
- Le client : Le client au sens XP est celui qui est présent au sein de l’équipe de développement, qui répond aux questions des développeurs et définit la priorité dans laquelle doit être implémenter les fonctionnalités. Il a le devoir de fournir un feedback aux développeurs ainsi que des tests de recette.
- Le testeur : le testeur est le bras droit du client. C’est à lui que revient la tâche d’installer les outils nécessaires à l’intégration continus, des tests de recettes et unitaires. Il est également là pour aider le client à créer les test de recette.
- Le tracker : Le tracker est là pour suivre l’avancement des tâches au sein d’une itération. Son rôle est donc de détecter au plus vite les éventuelles difficultés qui surviennent afin de les résoudre le plus vite possible. Ce rôle doit être évité d’être tenu par un membre hiérarchique supérieur afin d’empêcher un sentiment de surveillance.
- Le manager : C’est le supérieur hiérarchique des développeurs. Il est là pour demander des comptes(à son équipe XP comme au client) et fournir les moyens humains et matériels pour l’avancement du projet. Il ne participe qu’aux réunions de planification et doit donc faire confiance à son équipe XP pour la réalisation du projet.
- Le coach : Le coach est le garant du respect des règles eXtreme Programming. C’est à lui que revient le rôle de mettre en place la méthode. Son objectif est que l’équipe puisse fonctionner sans lui. Il doit donc s’armer de courage pour dire les choses telles qu’elles sont.
Un des objectifs de toutes ces règles est de pouvoir faire face aux changements réguliers d’un projet IT. Voici une évolution que l’on retrouve souvent dans les projets IT :
Et voici la courbe du coût du changement revue par les auteurs d’eXtreme Programming :
Facteur de compétitivité des entreprises
Dans la deuxième partie du livre, les auteurs d’eXtreme Programming nous explique la mise en place d’eXtreme Programming et ce que cela lui apporte.
Par où commence-t-on?
Dans une première partie, on nous explique la façon d’amener la méthode eXtreme Programming. En effet, certaines pratiques d’eXtreme Programming peuvent être vues par l’entreprise comme une perte de rentabilité(la programmation en binôme) ou alors comme du “flicage” pour les développeurs(le rôle de tracker par exemple).
La formation de toute l’équipe à l’eXtreme Programming est indispensable. Il est d’ailleurs important de souligner que la philosophie d’eXtreme Programming insiste dans le fait que toute l’équipe doit participer aux diverses formations. 3 différentes méthodes sont communiquées dans le livre :
- Le coaching : un consultant eXtreme Programming est présent dans l’entreprise et joue le rôle de coach.
- L’immersion XP : L’équipe se rend à une formation sur plusieurs jours et est encadrée par une entreprise de formation dans la création d’un projet fictif en utilisant les pratiques eXtreme Programming.
- L’Heure Extreme : Ce sont des ateliers d’environ une heure mettant en pratique une notion d’eXtreme Programming.
Toutes les pratiques eXtreme Programming peuvent être dures à mettre en place dans une équipe. Il est donc recommandé de commencer par certaines pratiques comme la planification itérative et l’élaboration des tests unitaires avant le code.
Coûts et retours sur investissement
Cette partie du livre décrit les conséquences et la manipulation des variables clés qui font d’un projet XP une réussite.
Les variables clés
Les auteurs d’eXtreme Programming identifie 4 variables clés dans le déroulement d’un projet :
- Les coûts directs et indirects
- La qualité livrée
- La durée des projets
- Le périmètre fonctionnel des projets
Le livre nous explique les mécanismes de ces 4 variables ainsi que de leur inter-dépendance. Suite à cette analyse, la seule variable qui ressort manipulable est le périmètre fonctionnel des projets. En effet, il est impensable de diminuer la qualité du produit. Il est possible de modifier les coûts et le temps de développement mais le client ne sera pas satisfait. Par contre, réduire le nombre de fonctionnalités d’une version pour conserver la qualité, le coût et la durée de développement sera plus envisageable par le client.
Les auteurs listent ensuite les coût directs (exemples : la main-d’oeuvre, logiciels) ainsi que les coût indirects (exemples : les coûts du turn-over, défauts de qualité). Puis, on nous montre comment la méthode eXtrem Programming influe sur ces coûts, parfois en les augmentant comme pour la présence du client sur site, mais souvent en les diminuant. Les diminutions sont surtout visible sur les coûts indirects. En effet, les pratiques d’eXtreme Programming décrivent un environnement de travail serein au sein de l’équipe diminuant fortement le turn-over et le travail en binôme ainsi que les tests favorisent un travail de qualité.
Les aspects contractuelles
L’eXtreme Programming pose une certaine problématique lors de l’aspect contractuelle. En effet, la méthode n’est pas applicable suivant le type de contrat. En France, il existe 3 types de contrats:
- Les contrats forfaitaires : Le client définit un cahier des charges précis et contactera une société de service pour le mettre en oeuvre.
- Les contrats d’assistance technique : Le client définit et met en oeuvre le cahier des charges en faisant appel à du personnel compétent chez un fournisseur.
- Les contrats d’assistance forfaitée : Le client contacte un fournisseur qui lui fournira une équipe entière chargé de la réalisation du projet.
Seul le dernier contrat est véritablement adapté à la méthode XP (bien qu’il est possible de l’appliquer au second). En effet, le fait que ce soit une équipe en charge de la réalisation et d’être chez le client, le déploiement de la méthode est favorisé. Cependant, les auteurs du livre souligne le fait qu’il va falloir adapter les termes du contrat pour pouvoir spécifier les principes d’XP tels que le travail en binôme et le rythme durable par exemple. Le droit d’arrêt du projet est également donné au client, la méthode XP, grâce à sa structure itérative ainsi qu’aux livraisons d’un logiciel fonctionnel favorise la facture de ce qui est déjà fait.
Qualité et processus
Les auteurs du livre nous rappelle ce qu’est la norme iso:9000 ainsi que ces 8 principes.
- L’orientation client
- Leadership
- Implication du personnel
- Approche processus
- Management par approche système
- Amélioration continue
- Approche factuelle pour la prise de décision
- Relations mutuellement bénéfiques avec les fournisseurs
On nous explique alors les convergences entre l’eXtreme Programming et cette norme ainsi que les différents processus tel que les indicateurs de qualité(tests unitaires, recette) qui inscrivent XP dans la norme ISO:9001.
Méthodologie
Les auteurs nous expliquent que la méthode eXtreme Programming s’inscrit dans un mouvement plus vaste : celui de l’Agilité. Pour qu’une méthode soit validée comme étant agile, elle doit respecter le manifeste Agile :
L’importance est donnée:
- aux individus et aux interactions plus qu’aux processus et aux outils
- à des logiciels immédiatement disponibles plus qu’à une documentation exhaustive
- à la collaboration avec le client plus qu’à la négociation contractuelle
- à la réactivité face au changement plus qu’au respect d’un plan
Les méthodes Agiles s’appuient sur ces 4 valeurs clés et se différencient par la suite par leurs principes et leurs pratiques. Le livre nous décrit en quelques lignes d’autres méthode tel que Crystal, Adaptive Software Development (ASD), Feature Driven Development (FDD), Dynamic System Development Model(DSDM) ou encore Scrum.
Etudes de cas
Dans cette dernière partie, 2 études de cas nous sont décrites. La première relate la réalisation d’un projet Web dans une équipe qui met en place pour la première fois eXtreme Programming. L’étude est analysée au rythme des itérations. La seconde étude de cas relate quant à elle un projet industriel. On nous explique alors la mise en place de la méthode XP avec les succès et les échecs à travers les points de vue des différents rôles.
Conclusion
La lecture de ce livre m’a appris énormément sur la méthode XP. J’ai cherché à travers ce billet de transmettre certaines valeurs de cette méthode. Seulement, ne vous contentez pas de ce billet pour la mettre en place. Je vous invite en effet à lire le livre pour comprendre les fondements de ces valeurs ainsi que l’importance qu’y attache eXtreme Programming. Le livre met également l’accent sur le fait que mettre en place eXtreme Programming n’est pas un objectif mais une base. On nous invite, une fois mise en place, à la modifier pour qu’elle s’adapte parfaitement à notre environnement de travail.
Certaines des pratiques de l’eXtreme Programming ont irrigué Scrum (ou le contraire, peu importe) : « une équipe », « une même pièce », la notion de « stories », le « rythme soutenable » ou encore le « planning game », raison pour laquelle ces deux approche sont très complémentaires.
Cet article vous a proposé un rapide aperçu de Scrum et XP et aura, je l’espère, contribué à mettre en exergue la complémentarité des deux approches. Beaucoup de notions ont été évoquées de façon trop brève, et je reviendrai dessus dans de prochains billets… N’hésitez pas à laisser vos commentaires et questions !
