Qu’est-ce que l’Extreme Programming ?

Ecrit par << Paquet Judicaël >>

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 (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 :

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

Cette méthodologie 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. 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 (Extreme Programming) car l’ensemble des notions de l’Extreme Programming font parti du Scrum que l’on voit tous les jours.

Attention : l’écriture « Extrem programming » est une faute d’orthographe. Il ne faut pas écrire Extrem Programming mais Extreme Programming.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.