Méthode Agile, XP, c’est quoi ?

La méthode Agile, c’est quoi ?
Je vous ai parlé de la méthode Agile SCRUM lors d’un dernier article. Voici sa sœur : XP pour Extreme programming. C’est donc aussi une méthode associée à Agile.

L’Extreme Programming a été inventée par Kent Beck, Ward Cunningham et Ron Jeffries.

Il faut analyser les projets performants et identifier les facteurs déterminants. Isoler et tester ces pratiques puis les pousser à l’extrême et faire le bilan.

Si l’on recherche plus précisément le berceau de la méthode, on trouve le projet de Chrysler datant du milieu des années 90. Celui-ci consistait à remettre à jour le système de paie de tout le personnel gérant plus de 10 000 personnes.

Vous remarquerez donc que cette méthode demande de l’expérience, car, sans elle, vous ne pouvez déterminer les facteurs ni isoler les bonnes pratiques. Les principes de cette méthode ne sont pas nouveaux : ils existent dans l’industrie du logiciel depuis des dizaines d’années et l’originalité de la méthode est de pousser à l’extrême les concepts de l’apprentissage.

S’il fallait faire un raccourci, très rapide, de cette méthode pour l’appréhender, cela tiendrait à mettre à chaque début de phrase : “Puisque …” et d’y ajouter “alors…”.
La méthode XP tient sur les affirmations suivantes :

• Puisque la relecture du code est une bonne chose, alors elle sera faite systématiquement.
• Puisque l’intégration des modifications des uns permet aux autres d’avancer alors la publication des modifications se fera très souvent.
• Puisque la simplicité est reine de sagesse, alors il faudra toujours choisir la solution la plus simple.
• Puisque l’amélioration du code est importante, alors elle sera faite tout au long de l’avancement des tâches.
• Puisque la compréhension de tous les acteurs est primordial, alors il faudra définir les termes utilisés afin de lever toutes les ambiguïtés.
• Puisque les tests sont indispensables alors ils seront faits a la fin de chaque étape.

On rencontre d’autres aspects associés à la méthode XP comme le respect des délais ou l’acceptation du changement mais je ne trouve pas que cela soit spécifique à cette méthode .

On se rend donc compte avec ces affirmations que les cycles de développement, et donc les cycles de suivi des projets, doivent être courts. Tout au plus de 2 à 3 semaines. S’ils étaient plus longs, on entrerait dans des délais de réalisation élastiques et la méthode tomberait.

Le suivi des projets se fait au fur et à mesure des avancements. Quitte à reprendre un élément pour en refaire une itération. Par apprentissage et puisque la relecture du code le demande, alors on se remettra à l’ouvrage afin de l’améliorer. Malgré tout, il ne faut pas entrer dans une spirale infernale et ne jamais en sortir. Pour cela, des règles d’environnement sont à mettre en consolidation des affirmations :

• Il ne faut pas d’équipe trop grande. 10/16 personnes au maximum. Au delà, l’affirmation de la compréhension serait remise en cause.
• Il faut que pour un développeur, en ajouter un binôme; Il faut donc un composé d’équipe paire. C’est cette paire qui sera en charge de développer et de contrôler le code. Alternativement évidement.

• Il faut que les membres des équipes acceptent le changement et la critique. Sans cela, la relecture du code et la progression par itération seraient perdues.

Pour commencer un projet avec la méthode XP, il faut définir les spécifications. D’après les expériences que j’ai pu lire, avec XP,cela ne prend généralement pas le temps  défini…

Plutôt que de tout spécifier au début du projet, le responsable de projets va expliquer aux développeurs la première fonctionnalité qui est pour lui la plus importante.  Il faut ensuite définir et discuter avec les équipes du contenu et des temps.

Chaque partie du projet, devient très itérative, est ainsi divisée en sous-modules qui doivent être opérationnels au bout d’un intervalle de temps prédéfini relativement court.

A la fin de chaque itération, une livraison est faite permettant de tester. Grâce à ces phases ,  le responsable de projets peut demander des changements . Ce n’est qu’une fois que l’itération est validée que l’équipe en charge de l’élément pourra passer à la conception d’un autre composant.

Dans la pratique, un délai de 3 semaines est généralement choisi par l’équipe pour une fonctionnalité à tester. Bien que rien ne repose sur 3 semaines plutôt de 2 ou 5. Ces délais sont alors exhaustifs mais ils sont généralement considérés comme optimaux.

On a donc bien compris que la méthode XP offre un cheminement par itérations, basé sur l’apprentissage : Mieux on fait, mieux on produira. Cette méthode se déroule à long  terme mais d’itérations en itérations, on tend vers le parfait. Comme chaque partie a été testé, et testé encore. S’il a fallu itérer son développement, les tests terminaux sont de plus en plus réalistes. Les résultats sont donc de plus en plus qualifiant.

Les tests systématiques assurent que le système en cours de création est constamment opérationnel puisqu’un dysfonctionnement provoqué par une évolution du code source est tout de suite détecté et donc rapidement corrigé.

Le fait qu’XP ne permettent pas réellement de prévoir les échéances ne pose en aucun cas un problème pour les livraisons. En effet, les intégrations des classes développées sont faites plusieurs fois par jours. Les tests sont alors lancés pour vérifier la cohérence et la non-régression du produit. Une fois que vous avez une version 1, vous êtes à même de livrer une version nouvelle ou un patch avec les éléments finalisés et testés.

XP ne peut s’adresser qu’à des projets petits ou moyens en raison de ses caractéristiques. En effet, une itération de trois semaines ne semble pas réaliste pour une équipe de 100 développeurs, trois semaines étant approximativement le délai pour, tout simplement, contacter et informer l’ensemble des personnes. La communication, le feedback, les itérations courtes ne peuvent pas s’accommoder à un grand projet. Aussi, l’investissement de tous est demandé pour un projet XP. Quand l’équipe s’agrandit cette demande n’est-elle pas trop utopique ?
A nouveau, les principes même de XP ne permettent donc pas de généraliser la méthode à l’ensemble du monde informatique.

Mais il est clair que si vous partez d’un projet “papier blanc”, cette méthode est bien adaptée comparer à Agile SCRUM par exemple. Vous allez pouvoir avancer, itération après itération et chaque morceau sera testé. L’assemblage sera alors beaucoup plus sûr. Les équipes capitaliseront la connaissance de l’ensemble et toute l’équipe prendra de la valeur à fur et à mesure des progrès de vos projets. A l’inverse, si vous avez un fort renouvellement des membres, vous serez confrontés à éclater les binômes. Vous aurez donc un effet de connaissance délayée et des ralentissements dans les projets.

A lire :
Agile Modeling and eXtreme Programming
Principes de l’eXtreme Programming
Extreme Programming Dow Wells