Qu’est-ce que l’Extreme Programming ?

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.

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’Extrême Programming

Cette méthode agile 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 pour bien insister qu’il était important de respecter les personnes avec qui on travaille 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 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 écrites sous le langage client et de tâches techniques sous le langage des développeurs.

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 :

extreme programming iteration simplifiee
extreme programming iteration simplifiée

Quelques éléments du cadre de l’XP

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 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 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 ?

L’Extreme Programming par contre 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’estimée 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

cette méthodologie qui prônent l’excellence technique impose de mettre en place différentes techniques d’ingénierie logicielle pour 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.

Conclusion

En effet tous ces éléments ont été repris par le Scrum appliqué aujourd’hui sérieusement dans les entreprises. On pourrait même parler de Scrum XP car l’ensemble des notions de l’Extreme Programming font parti du Scrum que l’on voit tous les jours.

Leave a Reply

Your email address will not be published. Required fields are marked *