Qu'est-ce que l'eXtreme programming ?

À la découverte de l’eXtreme Programming

L'eXtreme Programming regroupe un ensemble de pratiques et de valeurs clés en phase avec le manifeste agile.
 

Historique de l'eXtreme Programming

Le premier projet mené en eXtreme Programming a démarré le 6 mars 1996. À cette époque, Chrysler recrute Kent Beck pour reprendre le projet " Chrysler Comprehensive Compensation System " (projet C3). Au moment où il rejoint l'entreprise, le projet a débuté depuis 1994 et est au point mort. Il emmène Ron Jeffries avec lui pour relever le challenge. Les deux feront partie en 2001 des 17 signataires fondateurs du manifeste agile.

Le projet C3 consistait à unifier différents logiciels de gestion des paies de l'entreprise pour arriver à un logiciel unique. Kent Beck était alors déjà intéressé par des pratiques innovantes sur le développement, notamment au sein du monde " SmallTalk " (cf son livre SmallTalk – Best Practice Patterns).

Au démarrage du projet C3, Kent Beck test de nombreuses méthodes qu'il a déjà pu expérimenter mais aucune ne lui permet de répondre à l'ensemble des contraintes qu'il rencontre. Il doit alors sortir des sentiers battus pour trouver une pratique qui lui permettra de venir à bout du projet. Il commence par découper le projet en phases incrémentales – ces dernières sont définies avec le client ; il met en place des tests unitaires menés par les développeurs et propose la mise en place du pair programming – le développement en binôme.

Ces pratiques se retrouveront dans l'eXtreme Programming. Les phases incrémentales définies avec le client permettent de prioriser les fonctions essentielles, la mise en place systématique de tests automatisés permet de gagner du temps en évitant le besoin de recourir à une équipe dédiée à la réalisation des tests et enfin le pair programming pousse à la création d'un code plus aisément modifiable par d'autres développeurs.

À l'été 1996, Kent Beck baptise son concept “eXtreme Programming”. Le nom eXtreme est directement inspiré des athlètes de l'extrême. Ces derniers évoluent dans des environnements très contraignants et sont pourtant capables de répondre à tous les défis imposés par leur environnement. Dans la même optique, Kent Beck voit l'ensemble des méthodes qu'il a mise en place comme des " outils " permettant aux développeurs de répondre à l'ensemble des défis " extrêmes " qu'ils doivent relever, peu importe la difficulté et le niveau de challenge. C'est une application " à l'extrême " des principes du développement agile.

" Je voulais que mes équipes aient le même sentiment d'invulnérabilité face aux défis à relever que les athlètes évoluant dans des environnements extrêmes ".

En moins d'un an, l'eXtreme Programming était né. En 1997, Kent Beck a publié un ouvrage intitulé eXtreme Programming Explained dans une logique de transmission, de partage et de clarification du concept. À la suite de cette publication, l'eXtreme Programming se répand progressivement à l'international et dans de nombreux secteurs d'activités.

À lire aussi : retour sur les fondements de l'approche agile

L'eXtreme Programming : des valeurs qui s'inscrivent dans la philosophie agile

L'eXtreme Programming c'est un ensemble de valeurs, de principes et de pratiques autour du développement logiciel. C'est une manière de développer un logiciel en se focalisant sur des valeurs de simplicité, de communication, de feedback, de courage et aussi de respect.

Principes clés eXtreme Programming


Dans un développement logiciel s'appuyant sur l'eXtreme Programming, chaque participant au projet est considéré comme un membre de ce que l'on appelle " l'équipe globale ". Cette équipe compte un représentant " client " qui travaille au quotidien avec l'équipe. Ce dernier définit les fonctionnalités, hiérarchise les priorités et guide le projet. Dans l'équipe, il y a bien sûr des développeurs et il peut aussi y avoir des testeurs. Ceux-ci aident notamment le " client " à définir les tests de validation. Généralement, en eXtreme programming un coach est aussi là pour guider l'équipe.

Les équipes fonctionnant grâce à l'eXtreme Programming utilisent une forme de planification et de suivi assez simple pour décider de ce qui doit être fait, dans quel ordre et estimer la date de fin du projet. Les équipes sont concentrées sur la valeur ajoutée et développent le logiciel via des incréments intégrés en continu. Les incréments doivent passer les tests définis grâce au " client ".

En eXtreme Programming, les développeurs travaillent en pair programming. L'objectif est de se concentrer sur la qualité et la transmission du code : une revue de code est par conséquent faite en permanence. À ce titre, le pair programming et le TDD constituent la colonne vertébrale de l'eXtreme Programming. Le design est volontairement simple au début et il évolue parallèlement avec les besoins du logiciel à l'instant T.

Aussi, un projet mené en eXtreme Programming implique de l'intégration continue, une appropriation collective du code et donc un respect des standards de développement.

Enfin, le rythme de développement induit par l'eXtreme Programming doit permettre à chaque membre de l'équipe d'évoluer à un rythme qui peut être tenu de manière durable.
 

Scrum VS eXtreme Programming

Ces deux cadres sont des philosophies agiles de développement. Pourtant on les voit souvent opposées.

Parmi les différences principales, on peut dire que là où Scrum permet une optimisation de la productivité, eXtreme Programming s'intéresse davantage à l'ingénierie logicielle en elle-même.

Aussi, en plus d'itérations plus courtes, les équipes qui travaillent en eXtreme Programming s'attaque aux différents items dans un ordre de priorité stricte là où une équipe Scrum aura une latitude de manoeuvre par sur l'ordre de priorité des items une fois le sprint lancé. Par contre, une équipe XP pourra rajouter de nouveaux items au cours d'une itération en remplacement d'items équivalents si le client décide d'une nouvelle priorité.

Toutefois, des ponts entre les deux approches existent. La routine du daily meet-up existe dans les deux approches. Aussi, le rôle du Product Owner en Scrum est assez similaire à celui du client en XP – ce dernier aide à la rédaction des users stories, à leur priorisation et il se tient toujours à leur disposition même si le degré de précision est moins exigeant.

Une équipe Scrum pourra aussi des pratiques telles que le Pair Programming, le TDD ou encore le refactoring pour améliorer la qualité, accélérer le process de release ...

À lire aussi : Qu'est-ce que le software craftsmanship ?
 

Conclusion

L'eXtreme Programming élève le développement logiciel à un niveau de sophistication assez élevé en se concentrant sur la qualité grâce à un ensemble de pratiques de développement poussées à l'extrême. Par rapport à la comparaison avec l'approche Scrum, il n'y a pas une meilleure approche que l'autre pour développer. Chaque équipe doit adopter l'approche avec laquelle elle est le plus à l'aise et qui est la plus adaptée pour répondre au problème posé.

Source :

ronjeffries.com

refactoring.com

Les dernières actus