Si cette méthode agile est moins populaire aujourd’hui, l’Extreme Programming influence le Scrum d’aujourd’hui et les différents mouvements agiles qui prônent l’excellence technique tels que le Software Craftsmanship et le Devops.
J’en parle beaucoup dans différents articles mais je n’avais jamais fait d’article sur cette méthode agile très populaire au début des années 2000. Beaucoup de gens connaissent son nom mais très peu savent concrètement en quoi elle consiste.
Vous pouvez aussi regarder la vidéo de la minute agile sur ce sujet :
Origines de l’Extreme Programming
Kent Beck, Ward Cunningham, Ron Jeffries ont expérimenté une nouvelle méthode de gestion de projet en 1996 sur le projet C3 chez Chrysler qui a donné naissance à cette méthodologie. Elle a été présentée officiellement en 1999 dans la publication Extreme Programming Explained.
Les 5 valeurs de l’Extreme Programming
L’Extreme Programming se base sur 5 valeurs essentielles que je vais vous présenter ici en quelques mots.
Communication
L’Extrême Programming impose d’avoir une excellente communication au sein de l’équipe. La communication est la base de tout bon fonctionnement.
Simplicité
Il est essentiel de penser KISS (Keep It Simple, Stupid) et de ne développer uniquement ce qui est nécessaire. Les développeurs ne devront pas tenter d’anticiper les choses quite à faire du refactoring à la suite.
Voici un article qui parle de ce sujet que j’avais écris dans le passé.
Article : Le principe KISS pour les développeurs
Feedback
L’Extreme Programming (XP) insiste sur l’importance de livrer rapidement pour avoir des feedback le plus tôt voire le plus souvent possible. C’est d’ailleurs la raison qui fait que l’XP propose des cycles de développement courts.
Les tests unitaires (avec la TDD) et les tests fonctionnels automatisés (exemple le BDD) sont également des feedback rapides sur l’aspect technique du produit. Le fait d’avoir ces retours rapidement permet de ne pas avoir un bug oublié en production.
Articles :
La qualité du produit avec de la TDD
Et si on faisait de la BDD (Behavior Driven Development)
Courage
Il est essentiel d’avoir du courage pour parfois accepter de changer radicalement les choses. Il ne faut pas persister sur une pratique ou une architecture non adaptée mais avoir le courage d’en choisir de nouvelles.
Respect
Si cette valeur n’était pas présente dès 1999, Kent Beck l’a rapidement rajoutée à l’Extreme Programming pour bien insister qu’il était important de respecter les personnes avec qui nous travaillons que ce soit au sein de l’équipe ou non.
Itérations en Extreme Programming
Comme de nombreuses méthodes agiles, l’Extreme Programming insiste sur le fait qu’il faut réaliser des itérations de courtes durées. Chaque itération doit se commencer par une Iteration Planning où l’équipe définira ensemble le travail à réaliser durant cette itération.
L’XP (Extreme Programming) impose de choisir les user-stories qui ont le plus de valeur pour les clients au sein de chacune des Iteration Planning. Sachant que l’Extreme Programming conseille d’avoir des rythmes soutenables, les utilisateurs clés (ou son représentant) devront planifier l’itération selon la vélocité précédente.
Au passage, les user-stories utilisées aujourd’hui en Scrum ainsi que ce concept de vélocité/prédictibilité viennent à la base de l’XP. En Scrum en réalité, c’est l’équipe de développement qui choisit ce qu’elle pense pouvoir réaliser.
Le contenu de ces itérations sera de user-stories (demande fonctionnelle) et de tâches techniques.
Les itérations en XP doivent durer entre 1 et 3 semaines ; cependant il faut aussi faire des Iteration release dans vos projets avec cette méthodologie (ce qui a été repris par certains en Scrum).
Tous les matins excepté le jour de l’Iteration Planning, l’ensemble de l’équipe fera un Daily pour se synchroniser comme le font l’ensemble des équipes Scrum.
L’équipe pourra également faire des rétrospectives de temps en temps quand la méthode n’est plus 100% adaptée et qu’elle doit s’améliorer.
Voici ce que donne l’Extreme Programming de façon simplifiée :
Quelques éléments du cadre de l’XP (Extreme Programming)
On va voir à présent un certain nombre de règles imposées par l’XP que l’on retrouve curieusement dans de nombreuses équipes Scrum matures.
Aujourd’hui cela est devenu très classique mais l’XP (Extreme Programming) insistait énormément sur le fait que l’équipe devait être co-localisée et en openspace et qu’il était indispensable que l’équipe ait un rythme soutenable.
Pour les phases exploratoires, l’XP (Extreme Programming) conseille l’utilisation de Spike que nous avons déjà vu au sein d’un article dédié qui sont des demandes timeboxé et non estimées.
Article : Qu’est-ce qu’un Spike dans un projet Scrum ?
En revanche, l’XP proposait de l’estimation en jours idéaux (le nombre de jour pour effectuer la demande en ne pensant à aucune contrainte de temps et en ignorant les cérémonies). Si cette façon d’estimer se faisait dans de nombreuses entreprises dans la passé, c’est une pratique oubliée en France où l’estimation en « point d’effort » est vraiment bien ancré.
Le test c’est le feedback
Ce framework qui prônent l’excellence technique impose de mettre en place différentes techniques d’ingénierie logicielle. Cela permettra d’imposer un cadre de qualité : TDD, BDD, Pair programming (le fait de coder à deux sur un même poste), norme de codage…
Une release ne pourra pas passer en production sans la mise en place de ces pratiques.
Les rôles en Extreme Programming
Le vérificateur
Celui qui a ce rôle va régulièrement voir les développeurs pour savoir comment ils vont. Si un soucis est constaté, il fera en sorte qu’une action soit mise en place rapidement. En Extreme Programming, on insiste sur le fait qu’il ne faut pas laisser un problème persister.
Le représentant client
Celui-ci va écrire les user-stories et réaliser les tests fonctionnels qui valideront l’ensemble des scénarios exigés par les user-stories. Il prendra aussi la responsabilité de prioriser la prise en charge des demandes par les développeurs.
Le développeur
Le développeur sera celui qui développe l’application. Il sera pluridisciplinaire, estimera les user-stories et pourra donner son avis sur le contenu des user-stories.
Le testeur
Il mettra les tests fonctionnels en place et sera le gardien du résultat de ces tests. Si des tests ne passent plus, il le fera savoir à l’ensemble de l’équipe.
Le coach XP (Extreme Programming)
Le coach XP (Extreme Programming) aidera l’équipe à atteindre un bon niveau de maturité et à s’améliorer continuellement. D’ailleurs, il aidera également à planifier l’ensemble des réunions et à faciliter ces réunions.
Potentiellement, le vérificateur et le coach XP (Extreme Programming) peuvent être la même personne.
Conclusion Extreme Programming
En effet, le Scrum appliqué aujourd’hui sérieusement dans les entreprises a repris tous ces éléments. On pourrait même parler de Scrum XP car l’ensemble des notions de l’Extreme Programming font parti du Scrum que nous voyons tous les jours.
Attention : l’écriture « Extrem programming » est une faute d’orthographe. Il ne faut pas écrire Extrem Programming mais Extreme Programming.
Lien utile : site officiel du framing agile
Merci beaucoup pour votre site je suis actuellement en formation pour devenir développeur Web et web mobile et je n’avais jusqu’alors rien compris a l’extreme programming !! merci beaucoup 🙂