XP ou eXtreme Programming - Ce qu'il faut en connaître

XP ou eXtreme Programming - Ce qu'il faut en connaître

Introduction

> Ami développeur, si tu penses que l'acronyme XP est l'apanage de MS Windows et qu'il signifie eXPerience, il est l'heure de recycler tes connaissances. XP, maintenant tu le sauras, signifie également Extreme Programming (Programmation extrême pour ceux qui souhaiteraient une traduction en français). Ce concept, exposé par Beck KENT en 1999 dans son livre Extreme Programming Explained : Embrace Change, est depuis la source d'une certaine ébullition dans le petit monde du développement de logiciel. L'XP fait partie d'un ensemble plus vaste de méthodes de programmations dites « Agiles » dont les principes généraux sont exposés dans l'Agile Manifesto du même auteur (traduction en Annexe).

> L'article qui suit expose les fondements de cette méthode de travail innovante afin que chacun puisse juger de son intérêt et évaluer si elle mérite d'être retenue dans le cadre de son projet.

Qu'est-ce que l'eXtreme Programming?

> L' Extreme Programming (XP) - tel qu'il est défini sur le site eXtremeProgramming.org - est une approche tout à fait réfléchie et disciplinée du développement logiciel. Âgée d'environ huit ans, elle a déjà fait ses preuves un peu partout dans le monde dans de nombreuses entreprises de toutes tailles et dans tous les secteurs de l'industrie.
> L'XP a du succès parce qu'elle met en avant la satisfaction du client. La méthodologie est conçue pour livrer le logiciel dont le client a besoin quand il en a besoin. L'XP habilite les développeurs à pouvoir répondre en toute confiance aux changements d'exigences du client , même tardivement dans le cycle de vie de l'application.
Cette méthodologie insiste également sur le travail en équipe. Chefs de projet, clients, et développeurs font tous partie d'une équipe dédiée à la livraison d'un logiel de qualité. L'XP implémente une manière simple et néanmoins efficace qui permet de développer selon un style « logiciel collaboratif » (groupware style).
> L'XP améliore un projet logiciel de quatre manières fondamentales : la communication, la simplicité, le rétrocontrôle, et le courage. Les programmeurs XP communiquent avec leurs clients et leurs collègues programmeurs. Ils maintiennent leur ouvrage simple et propre. Ils obtiennent un rétrocontrôle grâce à la mise en place dès le premier jour de tests sur le logiciel. Ils livrent le système au client le plus tôt possible et implémentent au fur et à mesure les modifications suggérées. En se reposant sur ces fondements, les programmeurs XP sonr capables de répondre courageusement aux changements de spécifications et de technologies.
> L'XP est différente. On peut la comparer à un puzzle avec de nombreuses petites pièces. Chaque pièce prise individuellement n'a pas de sens, mais leur combinaison fait apparaître une image complète. Elle se démarque des méthodes traditionnelles de développement logiciel et introduit un changement dans notre façon de programmer.

Quelle est la distribution des rôles ?

> L'XP se définit comme une méthode de travail incrémentale et itérative centrée sur le développeur. Elle s'articule autour de cinq rôles principaux : le Coach, le Client, les Développeurs, le Manager et le Tracker.

1 - Le Coach

Il remplit - selon une terminologie précédemment définie - le rôle du Chef de Projet. Il coordonne le travail de l'équipe et aide ses membres à mettre effectivement en pratique les concepts de l'XP. C'est lui l'interlocuteur privilégie du Client et de ce fait préside à toutes les réunions.

2 - Le Client

C'est le Maître d'Ouvrage. Il participe à la rédaction et à la spécification des scenarios qui décrivent les activités du système informatique. Il doit être présent lors de la planification de chaque itération et doit élaborer et valider les Tests de recette avec le Coach. Idéalement, c'est un utilisateur final du système et il doit être disponible sur le site de développement tout au long de la réalisation du projet afin de conférer à l'équipe un maximum de réactivité.

3 - Les Développeurs

Leur rôle, c'est de coder et tester le logiciel produit selon les règles de l'XP. Ils travaillent en étroite collaboration avec le Client qui doit au fur et à mesure du développement , leur préciser ses besoins et vérifier qu'ils sont effectivement couverts de la façon qu'il souhaite. Ils participent aux réunions de lancement et de spécification de scenarii en début de chaque itération.

4 - Le Manager

Le Manager remplit le rôle du Maître d'Oeuvre. Il suit le projet en veillant à allouer des ressources suffisantes pour sa bonne marche. Il ne participe qu'au réunions clés.

5 - Le Tracker

Son rôle est de suivre le projet avec un regard extérieur avec pour mission d'anticiper et de faire remonter les points d'achoppement qui risquent d'émerger au cours du processus de développement.

> Pour le bon déroulement d'un projet XP, chacun de ces rôles doit être tenu. Mais selon l'effectif de l'équipe affectée, une personne peut tenir plusieurs rôles (Coach et Tracker par exemple).

Les principes de l'XP

> La méthode d'XP est un processus de développement dont les itérations sont stéréotypées [ Planifier > Concevoir > Coder > Tester ] . Mais ce qui lui est spécifique et qui la distingue des autres méthodes de gestion de projet (en cascade, en V, ...), c'est qu'à chaque itération est associée une recette (livraison du logiciel au client qui le valide). Ce mode de plannification qui présente l'avantage de ne pas nécessiter l'obtention des spécifications complètes de l'application pour travailler efficacement, permet également de mettre à profit le rétrocontrôle pour améliorer au fil des itérations, le processus de développement.

> Voyons quels sont les principes mis en œuvre lors de chacune de ces phases.

Planification

  • Rédiger les User stories (équivalent XP des Cas d'utilisation)
    Cette première étape permet de définir les besoins du client sous forme de brefs scenarii fonctionnels (user stories) qu'il aura rédigé. Chaque scenario, rédigé en quelques phrases claires, représente une fonction à implémenter. Le niveau de détail doit au départ être minimal. L'équipe de développement évalue la durée idéale (c'est-à-dire, en considérant une durée journalière de travail normale, sans que le développeur soit distrait de sa tâche) pour développer chaque fonction. Si cette durée dépasse 3 semaines, le scenario doit être redéfini ou décomposé.
  • Plannifier les livraisons pour générer l'organisation de l'emploi du temps
    Le nombre idéal de scenarii nécessaires pour pouvoir commencer à plannifier se situe entre 20 et 80. En les triant par ordre de priorité et de complexité et en évaluant leur dépendances et interactions, il va être possible d'organiser l'étape suivante : le planning des livraisons. C'est ce qui est fait lors de la Réunion de plannification des livraisons qui fait intervenir tous les acteurs.
  • Faire fréquemment des petites livraisons
    L'XP prévoit qu'il soit effectué une recette au terme de chaque itération. En mettant à la disposition du client un produit qui peut être évalué, il est possible de corriger rapidement et sans dérive les besoins mal compris ou mal pris en compte.
  • Mesurer la vitesse d'avancement du projet
    Il suffit pour cela de comptabiliser le nombre de scenarii implémentés à chaque itération. Vous devez également totaliser le nombre de tâches techniques réalisées lors de l'itération. Cette vitesse qui doit rester la plus constante possible, peut être accrue lorsqu'un binôme ayant terminé toutes les tâches qui lui étaient assignées, travaille sur un ou plusieurs nouveaux scenarii avant la fin de l'itération en cours. La vitesse d'avancement sert à déterminer combien de scenarii peuvent être implémentés avant une date donnée, ou bien combien de temps sera nécessaire pour traiter un ensemble de scenarii.
  • Diviser le projet en itérations
    Idéalement, le projet doit être divisé en une douzaine de cycles de courte durée (1 à 3 semaines). On fait en sorte que la charge de travail soit calibrée pour rester compatible la durée fixée des itérations qui doit rester constante. Afin de ne pas brider la productivité, il est conseillé d'allonger les itérations (et de réduire éventuellement l'équipe) si le client n'est pas en mesure d'être suffisamment disponible.
  • Organiser une réunion de plannification en début de chaque itération
    Lors de la Réunion de plannification d'itération, les scenarii prioritaires choisis par le client sont subdivisés en tâches elles-mêmes réparties entre les différents membres de l'équipe de développement. Chaque itération XP doit être organisée en intégrant :
    - Une phase de conception courte lors d'une Réunion de lancement avec le client et l'équipe de développement pour détailler, chiffrer et arbitrer les scenarii à réaliser durant l'itération.
    - Une phase de développement qui se déroule parallèlement à celle d'élaboration des Tests de recette réalisés par le Client (qui peut se faire aider par le Coach afin d'être plus précis et complets). Les Tests de recette doivent en pratique, être mis a disposition du développeur avant qu'il n'ait réalisé 50% des développements correspondants. Ils doivent être confrontés à la description des scenarii pour que l'ensemble définisse parfaitement les besoins du Client.
    - Le passage des Tests de recette qui valident le code livré au cours de l'itération.
    - Une phase de retour d'information qui a pour objectif d'améliorer les performances de l'équipe sur l'itération suivante à partir de l'analyse du déroulement de  l'itération qui s'achève.
    Les modules qui n'ont pas passé avec succès les tests lors de l'itération précédente sont également pris en compte dans l'évaluation de la charge de tavail et intégrés dans le planning.
  • Faire bouger les gens d'un poste à un autre
    La mobilité au sein des différents postes permet aux membres de l'équipe d'avoir une meilleure vision globale du projet et d'être plus facilement interchangeables.
  • Commencer chaque journée de travail par une réunion informelle
    Cette réunion matinale quotidienne doit favoriser la communication au sein de l'équipe. Elle est mise à profit pour faire remonter les problèmes, les solutions et organiser les centres d'intérêts de l'équipe. Tous les membres se tiennent debout en cercle afin d'éviter de longues discussions. Il est plus efficace d'avoir une seule réunion courte à laquelle tout le monde assiste que plusieurs durant la journée avec seulement quelques développeurs.
  • Réparez l'XP lorsqu'il se casse
    Ce rôle revient au Coach qui veille à la bonne utilisation des compétences et vérifie que les règles de l'XP sont bien mises en pratique tant au niveau du codage que de l'organisation générale de l'équipe. Ces règles ne sont néanmoins pas immuables et il lui revient de faire régulièrement le bilan de ce qui marche et de ce qui ne marche pas afin d'améliorer avec son équipe le processus XP.

Conception

  • Être simple
    Il faut toujours envisager la solution la plus simple, celle qui répond ni plus ni moins à la demande de du client, sans chercher à anticiper les besoins non encore spécifiés ni chercher à développer des composants génériques.
  • Choisir une Métaphore pour le système
    La description du fonctionnement de l'application à l'aide de Métaphores utilisées par tous les participants est un moyen simple d'améliorer la compréhension des besoins. Il permet de nommer les classes et les méthodes d'une manière logique.
    La façon dont vous nommez vos objets est très importante pour comprendre la conception générale du système et pour réutiliser le code. Choissez un système de noms pour vos objets qui permette à chacun de comprendre à quoi ils servent sans avoir besoin de connaissances spécifiques du système ou difficiles à assimiler. Être capable de deviner comment s'appelle une chose lorsqu'elle existe déjà peut faire gagner beaucoup de temps.
  • Utiliser le système de cartes CRC pour les sessions de conception
    Une carte CRC (Classe-Responsibilité-Collaboration) sert à représenter un objet. La Classe de l'objet peut être écrite sur sa partie supérieure, ses Responsabilités (méthodes) listées sur la partie gauche, et les Classes de collaborations sur la partie droite en face de chaque responsabilité. Ces cartes n'ont pas besoin d'être rédigées de manière exhaustive. Elles ne doivent contenir que les informations suffisantes pour permettre de visualiser les objets et leurs interactions.
    Le meilleur atout des cartes CRC, c'est qu'elles permettent aux gens de s'affranchir du mode de raisonnement procédural et de mieux apprécier la technologie objet. Elles permettent également à toute l'équipe de participer à la conception du système ce qui favorise l'émergence de bonnes idées.
  • Créer des Spike solutions afin de réduire le risque
    Les Spike solutions sont des solutions basées sur une exploration en profondeur qui visent à la compréhension et la résolution des difficultés techniques ou des problèmes de conception les plus coriaces. Cette méthodologie consiste à créer des programmes très simples (dont la plupart seront rejetés) qui ne s'intéressent qu'au problème en cours d'examen et ignorent le reste du projet, se bornant à explorer les solutions possibles. Lorsqu'une difficulté menace de paralyser le développement du système, il est conseillé d'affecter un binôme sur le problème pour une ou deux semaines afin de réduire le risque potentiel.
  • N'ajouter aucune fonction tôt dans le développement
    Pour ne pas dépenser d'énergie inutilement, il est important de se concentrer uniquement sur les tâches qui ont été plannifées pour l'itération en cours, en gardant des œillères pour ne pas être tenté d'anticiper sur d'hypothétiques besoins à venir du client.
  • Remanier le code à chaque fois et partout où c'est possible
    Le remaniement (refactoring) consiste à améliorer le code sur lequel on repasse. Effacer le code qui ne sert plus et qui a été mis en commentaires, le nettoyer, le simplifier voire reprendre la conception si elle ne semble pas satisfaisante sont donc la règle. Il est recommandé d'organiser pour toute l'équipe des séances fréquentes et régulières (une demi-journée par semaine par exemple), sous peine de voire cette pratique négligée.

Codage

  • Le Client doit être toujours disponible
    Idéalement, il doit intégrer les locaux de l'équipe de développement afin d'être à même de préciser les spécifications du projet en faisant part de ses besoins au fil de l'avancement, et d'exercer rapidement un rétrocontrôle sur le code et le logiciel élaboré. Avant même de lancer le projet, le Client doit être sensibilisé au fait que son rôle est capital et qu'il doit être prêt à s'engager sur toute la durée du projet. L'équipe de développement ne doit jamais rester en attente d'information ou de jeux de tests pour garder une bon niveau de productivité.
  • Le code doit être rédigé selon les standards agréés et acceptés par l'équipe
    Cela permet de gommer les différences d'habitudes et d'intégrer les nouveaux venus facilement. Les commentaires qui accompagnent le code doivent également subir ce processus de standardisation. L'acceptation de ces règles rendent le code plus facile à lire et à maintenir par l'ensemble de l'équipe.
  • Coder les Tests unitaires d'abord
    Cette méthodologie qui consiste à constituer d'abord des classes de tests puis de les appliquer aux classes à tester, nécessite la maîtrise d'outils tels que JUnit. Cette charge initiale de travail est récupérée secondairement du fait de la meilleure fiabilité des composants utilisés. L'automatisation des tests permet de vérifier facilement l'absence de régression du code après avoir apporté une série de modifications.
  • Utiliser la Propriété collective du code
    En considérant que chaque développeur est responsable de la totalité du code produit, l'XP incite chaque membre de l'équipe à participer efficacement à l'ensemble du projet et à le maîtriser suffisamment pour pouvoir intervenir quelque soit sa place. Le fait que tous les modules doivent être intégrés avec leurs tests et validés, permet plus facilement à chacun d'intervenir sur l'ensemble du code. L'équipe peut ainsi faire face au renouvellement inopiné d'un des membres.
  • Toute la production de code doit être programmée en binôme
    La programmation en binôme vise à un meilleur niveau de compétence et de vigilance lors de l'écriture du code. Le changement fréquent de poste par remaniement des binômes qui est recommandé par l'XP, n'affecte théoriquement pas la stabilité du projet car il reste un élément fixe. Ce principe controversé par certains, est certainement nécessaire pour tous les points ardus du projet ou lors des séances de remaniement du code.
  • Seul un binôme intègre le code à la fois
    Afin d'éviter les problèmes de compatibilité et de régression du code, l'intégration de nouvelles fonctions doit être faite par les développeurs eux-mêmes, de manière séquentielle. Un seul binôme intègre à la fois et de préférence sur un poste dédié à cette activité. La propriété collective du code permet au binôme qui intègre d'intervenir sur le code existant en cas de conflit, les tests unitaires automatiques déjà réalisés garantissant qu'aucune modification délétère puisse être effectuée par inadvertance. De cette façon, la dernière version du système est toujours identifiée.
    Même si chacun peut évaluer sur son poste de travail l'intégration de ses modules quand il veut en se servant de la version en cours du système, chaque binôme doit néanmoins attendre son tour pour pouvoir le faire effectivement, générant ainsi la nouvelle version de référence du système.
  • Intégrer souvent
    L'intégration fréquente (voire quotidienne) vise à réduire les conflits entre les développements réalisés par les différents membres de l'équipe en minimisant les problèmes lors de la synchronisation du code, en utilisant CVS (Concurrent Versions System) par exemple. Cela permet en outre de disposer en permanence d'une version de référence de l'application dans le reposoir de code. Chaque binôme est reponsable de l'intégration de son code. Elle doit être effectuée chaque fois qu'une pause se présente. Ce peut être après avoir bouclé ses Tests unitaires ou lorsqu'une portion plus petite d'une fonction est achevée.
  • Laisser les optimisations pour la fin
    Il ne faut pas essayer de deviner à priori où se trouvera le goulot d'étranglement de votre application. Mieux vaut le mesurer, le faire fonctionner correctement, et enfin l'améliorer le pour le rendre plus rapide.
  • Pas d'heures supplémentaires
    L'adoption par l'équipe d'un rythme de travail durable est le seul garant d'un travail efficace et de qualité sur le long terme. En cas de difficulté, une Réunion de plannification de livraisons doit être organisée pour redéfinir les objectifs du projets ou son timing.

Tests

  • Tout code doit avoir des Tests unitaires
    Les Tests unitaires sont la pierre angulaire de l'XP. Afin de créer des suites de tests automatiques, vous devez préalablement créer ou télécharger une structure de tests unitaires. Deuxièmement, vous devez tester toutes les classes du système. Les méthodes triviales de type getter et setter sont habituellement omises. Enfin vous devez essayer de créer vos tests avant de rédiger votre code. Plus un test est difficile à élaborer et plus il est nécessaire. Les Tests unitaires sont systématiquement livrés dans le reposoir en même temps que le code qu'ils testent. Ces tests automatiques vous feront gagner cent fois le temps que vous y avez consacré lors du développement en vous épargant la recherche fastidieuse de nombreux bogues.
  • Tout code doit avoir passé avec succès tous les Tests unitaires avant de pouvoir être livré .
  • Lorsqu'un bogue est découvert il faut créer des tests
    La présence d'un bogue impose qu'un Test de recette soit élaboré afin d'éviter sa récurence. En créant un Test de recette avant le débogage, on aide le Client à définir de manière concise le problème et à communiquer ce problème aux développeurs qui savent ainsi où concentrer leurs efforts et quand le problème est résolu. Les développeurs peuvent alors créer des Tests unitaires pour mettre en évidence le défaut au niveau plus spécifique du code. Lorsque l'anomalie a été localisée et réparée, les Tests unitaires doivent être tous validés, puis le Test de recette passé avec succès. La correction du bogue est alors effective.
  • Les Tests de recette sont effectués fréquemment et le score est publié
    Les Tests de recette sont élaborés par le Client à partir des scenarii (user stories) choisis lors de la Réunion de plannification d'itération. Ils vont constituer la boîte noire du système. Le Client doit spécifier les situations à tester lorsqu'un scénario a été correctement implémenté. Afin d'en valider le bon déroulement, chaque situation peut nécessiter un ou plusieurs Tests de recette. La vérification de la réussite de ces tests est sous la responsbilité du Client qui doit également décider de l'ordre de priorité du traitement lorsque des tests ont échoués. Un scenario n'est pas achevé tant que les Tests de recette n'ont pas été bouclés. Ces tests ont intérêt à être automatisés pour pouvoir être exécutés souvent et le score de réussite est porté à la connaissance de l'équipe afin de mesurer les progrès du projet.
    Le terme Test de recette a été remplacé par celui de Test fonctionnel. Ce dernier reflère mieux l'intention qui est de garantir que les besoins du Client ont été couverts et que le système peut être validé.

Schéma global de la méthode

 

eXtreme Programming

Quand doit-on avoir recours à l'XP ?

Là encore reportons nous à ce qu'on peut lire sur le site eXtremeProgramming.org.

> L'XP a été créée pour les domaines problèmatiques du fait de changements de spéfications. Il se peut que votre Client n'ait pas une idée très claire des tâches que le système doit effectuer. On peut être confronté à un système pour lequel un changement de fonctionnalités dans des intervalles de quelques mois est pressenti. Pour de nombreux environnements logiciels, le changement dynamique des spécifications est la seule constante. C'est là que l' XP réussira alors que les autres méthodologies échouerons.

> L' XP a été aussi établie pour régler les problèmes de risque lié au projet. Si votre client a besoin d'un nouveau système à une date précise le risque est élevé. Dans le cas où ce système est un nouveau défi pour votre équipe, le risque est plus grand. Lorsque ce système est un nouveau défi pour l'industrie informatique tout entière, le risque est encore plus élévé. Les pratiques de l' XP sont établies pour atténuer les risque et accroître les chances de succès.

> L'XP est conçue pour de petits groupes de développeurs - de 2 à 12 - bien que cette méthode ait été utilisée avec succès pour des pojets plus importants avec des groupes de 30. Il s'adresse à des développeurs ordinaires qui n'ont pas besoin d'être docteur en informatique pour s'en sortir. Par contre, vous ne pourrez pas mettre en œuvre l'XP si le projet est mené par une énorme équipe. Pour des projets dont les besoins sont dynamiques ou qui sont à haut risque, vous pourrez néanmoins trouver qu'un petite équipe de développeurs XP sera de toute façon plus efficace qu'une équipe plus importante.
L'XP fait intervenir une équipe élargie. L'équipe d'XP inclut nous l'avons vu, non seulement les Développeurs, mais également les Coachs, Managers et Clients qui travaillent tous main dans la main. Poser des questions, négocier les objectifs et la plannification ou créer des tests fonctionnels requière plus que la seule implication des développeurs dans le développement du logiciel.

> Un autre besoin c'est la "testabilité". Vous devez être capable de créer des Tests unitaires et fonctionnels automatiques. Alors que certains domaines seront mis à l'écart pour cette raison, vous risquez d'être surpris par le grand nombre qui ne le sont pas. Parfois, il vous faudra faire preuve d'un peu d'ingéniosité. Vous serez peut-être amenés à modifier la conception de votre système pour le rendre plus aisé à tester. Rappelez vous simplement que là où il y a une volonté, il existe un moyen de tester.

> Le dernier point de la liste c'est la productivité. Les projets XP font unanimement preuve d'une plus grande productivité lorsqu'on les compare à d'autres projets développés dans un environnement d'entreprise comparable.
Mais cela n'a jamais été un but en soi de la méthodologie XP. L'objectif réel a toujours été : Livrer le logiciel dont on a besoin quand on en besoin. Si c'est le point primordial de votre projet, il est peut-être temps d'essayer l'XP.

Documentation

Sites de référence

Articles

  • L'eXtreme Programming : les 13 bonnes pratiques. Alban DALLE - Programmer n°59 (déc 2003) p38-40.
  • L'Extreme Programming - Design Up
  • Série d'articles

Livres en français

Annexe « Agile Manifesto »

Principes sous-tendus par l'Agile Manifesto

> Nous suivons ces principes :

  • Satisfaire le consommateur est notre priorité principale grâce à la livraison précoce et continue d'un logiciel de qualité.
  • Faire bon accueil aux modifications d'exigences, même lorsqu'elles sont tadives dans le développement. Les processus agiles exploitent le changement pour en faire un avantage compétitif pour le consommateur.
  • Livrer un logiciel fonctionnel fréquemment, tous les quinze jours à deux mois en privilégiant l'intervalle le plus court.
  • Commanditaires et développeurs doivent travailler ensemble quotidiennement pendant toute la durée du projet.
  • Construire des projets autour de personnes motivées. Leur procurer l'environnement et les moyens dont ils ont besoin, et leur faire confiance pour mener le travail à son terme.
  • La façon la plus efficace de transmettre une information à une équipe ou au sein d'une équipe de développement c'est de converser en face-à-face.
  • Le logiciel fonctionnel est la mesure principale de progression.
  • Les processus agiles promeuvent le développement durable. Commanditaires, développeurs, et utilisateurs doivent pouvoir être capables de soutenir une allure constante indéfiniment.
  • Prêter une attention constante à l'excellence technique et une bonne conception améliore l'agilité.
  • La simplicité -- l'art de maximiser la quantité de travail à ne pas faire -- est essentielle.
  • Les meilleures architectures, spécifications, et conceptions émergent d'équipes qui s'auto-organisent.
  • À intervalles réguliers, l'équipe est appelée à réfléchir sur la façon de devenir plus efficace, puis règle et ajuste son comportement en conséquence.

Document rédigé à partir des sources de documentation citées par Lionel RAFFIN pour www.smart-doc.org - Mars 2004





Cet article provient de Smart-doc.org
http://smart-doc.org/