eXtrem Programming techniques

Méthode XP (eXtreme Programming)

Approche autonome pour de petits projets, l’eXtreme Programming peut se substituer plus ou moins intégralement à la phase de développement (CONSTRUCTION) de la méthode RAD.

XP représente l’aboutissement pragmatique d’observations de terrain et de recherches empiriques réalisées par des développeurs expérimentés autant que soucieux de se concentrer sur les nécessités élémentaires de leur métier en utilisant la programmation comme une discipline collective

Voici, avec deux niveaux de détail, une synthèse des 12 pratiques fondamentales de XP dont l’influence sur l’estimation et la planification doit être prise en compte. Dans la première présentation les pratiques sont organisées par type d’usage (leur numérotation est liée à la chronologie de leur apparition dans un projet tel que listé dans le second exemple).

Les pratiques de type collaboratives :

  • 2 - Métaphore (Metaphor) : Des principes simples d’analogies sont utilisés pour faciliter la compréhension des utilisateurs des modèles et de l’application en cours de développement.
  • 3 - Convention de codage (Coding standard) : Le code doit respecter une convention de nommage et de présentation afin d'être lisible par tous les membres de l'équipe.
  • 5 - Programmation en binôme (Pair programming) : Le code est toujours produit par deux développeurs (le pilote et le copilote). Les binômes changent au cours du projet.
  • 6 - Propriété Collective du Code (Collective code ownership) : Chaque développeur doit pouvoir modifier toutes les parties du code si le besoin s'en fait sentir.
  • 12 - Intégration continue Continuous integration) : Le système, dans son intégralité, est régulièrement et fréquemment, assemblé puis testé.
  • Les pratiques de type pilotage du projet :

  • 1 - Séance de planification (Planning Game) : Le client attribue une priorité aux scenarii de développement. Les développeurs discutent le contenu de ces scenarii, définissent les tâches techniques sous-jacentes, estiment ces tâches, puis les réalisent.
  • 3 - Livraisons fréquentes (Frequent releases) : Un rythme de livraisons fréquentes soutient la motivation des développeurs, l’intérêt des utilisateurs et la validation du produit.
  • 7 - Rythme soutenable (Forty-hour week) : L'équipe maintient sa capacité à rester efficace en ne surchargeant pas le planning et en s’aménageant des horaires raisonnables.
  • 8 - Client sur le site (On-site customer) : Pour une communication optimum, le représentant du client et les développeurs travaillent dans le même espace physique (mode plateau).
  • Les pratiques de type conception et développement

  • 4 - Conception Simple (Simple Design) : L’applicatif doit répondre aux critères de lisibilité, de concision, de modularité, de cohérence, de maintenabilité.
  • 10 - Tests unitaires (Unit testing) et tests de recette (Acceptance Tests) : Des tests, automatisés lorsque possible, sont écrits pour chaque classe, chaque méthode, et pour l’ensemble du système. Ces tests doivent être réalisés avec succès à chaque intégration et après chaque refactoring. Sur la base de critères de validation initialement définis, le client s’engage à un retour d'information rapide sur la conformité des livrables.
  • 11 - Remaniement Continu (Refactoring) : La qualité de la conception et du code est systématiquement améliorée.
  • Voici ces 12 pratiques détaillées sous un angle un peu plus technique et présentées dans la chronologie de leur mise en œuvre :

    1 - Le planning est un consensus entre le client et le développeur. Comme pour le Risk Driven Development, il est procédé par priorités (parfois techniques, mais plus fréquemment fonctionnelles). Le développeur se focalise uniquement sur les buts principaux et diffère le traitement des objectifs secondaires. Le principe de Courage s’applique dans les négociations avec le client, lors des éventuelles divergences.

    Technique : Planning Game. Le client produit des scenarii d'utilisation et les priorise. Ces scenarii sont ensuite implémentés par l'équipe de développement. Le projet est considéré comme achevé lorsque le client n'est plus en mesure de trouver un nouveau scénario.

    2 - Les équipes XP emploient des métaphores. La métaphore est une abstraction de niveau élevé. La métaphore ne doit pas être une simplification abusive du concept initial, mais doit permettre de simplifier l'expression d'une chose complexe comme, par exemple, clarifier des fonctionnalités. Le mérite d’une métaphore est d'être synthétique et parlante. Exemple : utiliser la métaphore de la " recette de cuisine " pour expliquer un processus sophistiqué. Dans XP, la plupart des métaphores concernent le fonctionnement de l’application ou l’architecture.

    Technique : des métaphores et des analogies élémentaires sont utilisées pour décrire le système et son fonctionnement avant la livraison de fonctionnalités réelles, afin de le rendre compréhensible par les non informaticiens et les utilisateurs impliqués dans le développement.

    3 - L’application est rapidement disponible dans une version limitée. La phase de construction se compose d’itérations structurées en étapes (spécifications courtes, développement, tests, retour du client). Le fonctionnel est décrit en brefs scenarii implémentables validés immédiatement par le client. Le risque d’incompréhension est alors réduit au minimum. Les modifications peuvent être fréquentes mais concentrées dans un cycle très court. L'objectif est de disposer rapidement d'un pilote opérationnel. Les parties applicatives livrées pourront éventuellement être utilisées en fonctionnalités réduites si les dépendances d’autres parties non livrées ne sont pas trop fortes.

    Technique : Releases fréquentes. Elles permettent un feedback immédiat, tout en offrant des fonctionnalités validées pouvant être utilisées. Fréquence de livraison hebdomadaire.

    4 - Le design est simple et focalisé sur les besoins actuels. Sans préfigurer des évolutions fonctionnelles ultérieures (non exprimées), le développeur code l'essentiel, en se basant sur les besoins immédiats et dans l’ordre de leurs priorités.

    Technique : Planification initiale basée sur la valeur ajoutée des fonctionnalités attendues. Conception simple et codage simple, afin de faciliter les évolutions futures en rendant le produit aisé à comprendre et à modifier. Livraisons en fonctionnalités réduites. Documentation minimale adaptée aux besoins réels.

    5 - Développement en binôme. Deux ressources de développement travaillent simultanément sur l’implémentation du même code. A tour de rôle, elles programment et valident la qualité afin de produire un code propre, robuste et fiable. Dans certains projets, les développeurs s'associent en binômes uniquement lors des séances de refactoring (comme pour la méthode RAD), ou lorsque le problème est particulièrement ardu.

    Technique : Les programmeurs XP travaillent en binôme sur la même machine. Le premier développeur (appelé driver ou pilote), a la responsabilité du clavier et travaille sur la portion de code à écrire. Le second développeur, (appelé partner ou co-pilote), l’assiste en suggérant des options ou en décelant d'éventuels problèmes.

    6 - Appropriation collective du code. L'équipe est collectivement responsable de l'application, donc est supposée avoir connaissance de l'intégralité du code. Selon cette théorie, la qualité de l’ensemble du code est de la responsabilité de l’ensemble des programmeurs. Cette pratique accroît la qualité effective du code, la réutilisation, la compréhension des interfaces et supprime les principaux problèmes de turnover.

    Technique : Les développeurs réorganisent fréquemment les binômes, ce qui permet d'améliorer la connaissance collective de l'application et la communication au sein de l'équipe

    7 - Rythme soutenable. Les semaines n'ont que 40 heures et les ressources fatiguées font plus d'erreurs toujours plus coûteuses à corriger a posteriori.

    Technique : Planning individuel n’impliquant pas d'heures supplémentaires durant deux semaines de suite.

    8 - Le client collabore en permanence et en direct. Afin d'assurer une meilleure réactivité et un feedback rapide, un représentant du client doit être présent pendant toute la durée du projet. Cette ressource dédiée au projet est chargée de déterminer les besoins, de fixer les priorités, de valider les recettes et de fournir l’information utile.

    Technique : Un représentant permanent du client est présent sur le site. Ce représentant doit maîtriser les connaissances pratiques d'un utilisateur final, tout en disposant d’une vision globale du résultat à obtenir. C’est en général un cadre opérationnel.

    9 - Standards de codage. Pour faciliter l'appropriation collective de l’applicatif, la réutilisation et la communication, les programmeurs code dans un style et des règles identiques (normes de nommage pour les variables, méthodes, objets, classes, fichiers, etc.).

    Technique : Standards de codage, frameworks, design patterns, convention de nommage, etc.

    10 - Un logiciel XP est testé et validé en permanence. Avant d'implémenter une fonctionnalité, il convient d'écrire un test qui validera cette implémentation. A la vue des exigences applicatives, les développeurs écrivent d'abord les tests et codent ensuite.

    Technique : Jalons Zéro-Défaut par Test-Driven Development sur la base de tests issus d’une translation de bas niveau des tests d’intégration.

    11 - Intégration continue : Les modules développés sont assemblés journalièrement ou à la fin du codage de chaque jalon. La version de départ d’une nouvelle implémentation de code à jour s’effectue ainsi sur un applicatif stabilisé.

    Technique : Jalons Zéro-Défaut par intégration permanente de configurations testées. Construction planifiée en petits modules intégrés et testés progressivement. Pratique de plusieurs intégrations journalières si nécessaires.

    12 - Refactoring du code. Au cours du développement, le code est remanié continuellement et progressivement. Le logiciel est propre et simple. Dans le cas contraire, les correctifs sont beaucoup plus coûteux, la conception se corrompt, le code se fragilise et l’application se déstructure.

    Technique : Refactoring par amélioration continue de la qualité du code sans en modifier le comportement (commentaire, respect des règles de nommage, simplification, etc.). Le résultat du " nettoyage " s’effectue régulièrement et se valide lors de séances de travail collectif impliquant toute l'équipe.

    Comme il est justement souligné sur le site de Design-Up " Au final, on peut se demander si la méthode porte bien son nom. Le terme extrême évoquant des prises de risques insensées, alors qu'en pratique XP vise une suppression systématique du risque. " Dans XP, c’est en fait le bon sens qui est poussé à son extrême !

     Les principes fondamentaux d’XP

    Le slogan d’XP est représentatif de son pragmatisme " Développez vite, développez juste ! " Pour certains, XP représente une vision humaniste et dynamique du développement logiciel. D’autres qualifient l’approche de " réfléchie et disciplinée ".


    Figure 1. - Cycle de vie itératif incrémental de XP

    Ce sont généralement les petites équipes confrontées à des besoins volatiles qui obtiennent les plus grands profits de XP, car cette méthode s’affirme plus comme un ensemble de pratiques à dimension humaine que comme un processus rigide.

    En résumé, XP propose un ensemble cohérent de techniques répondant à la grande majorité des problèmes de la construction d’application.

    Selon Laurent Desmons (DotNetGuru.org) " Le plus surprenant dans cette méthode qui peut sembler naturelle, est qu’elle n’est concrètement pas évidente à appliquer ni à maîtriser, car elle réclame beaucoup de discipline et de communication. Contrairement à la première impression qui peut faire penser à une ébullition de cerveaux individuels, il s'agit d'aller vite, sans perdre de vue la rigueur du codage et les fonctions finales de l'application. La grande force de XP, et son plus grand risque d’échec, est précisément sa simplicité et le fait qu'on va droit à l'essentiel, selon un rythme qui doit rester constant ".

    Dans sa pratique, XP préconise un déroulement par itérations courtes (Figure 1) mettant en œuvre un ensemble de bonnes pratiques de développement, dans une implication collective du développeur et du client. Il découle de ce principe collaboratif une redéfinition naturelle de la relation client-fournisseur, avec des résultats positifs en termes d’évolution des exigences " client ", de qualité du code, de délais de livraisons, et, en général, de satisfaction des deux parties.

    Les approches classiques de développement sont fondées sur l'idée que le coût de modification du logiciel augmente de manière exponentielle dans le temps. Dans une telle logique, il est normal de chercher à définir complètement le produit avant de procéder à sa réalisation. Pour les praticiens d’XP, certaines techniques de développement permettent de réduire le coût des changements, à tel point qu'il devient plus rentable de retarder au maximum la prise de décisions, pour l’appuyer finalement sur les certitudes déterminées par la maturité du projet. Il en résulte de ces divergences de vision des approches de développement radicalement différentes.

    L’approche classique, cartésienne et industrielle, se fonde sur la maîtrise de la composition du produit et sur le respect d’un processus formel de production (prédictivité). Pragmatique et empiriste, XP se fonde sur une ouverture permanente au changement (réactivité).

    Lors d’un projet XP, les spécifications initiales sont revues, affinées et complétées tout au long du développement. Le client arbitre en permanence les priorités et l’équipe projet oriente son travail en conséquence. L'application est maintenue simple et évolutive par la systématisation d’un ensemble de techniques de conception et de construction.

    Les développeurs travaillent en mode projet et en mode plateau en s’appuyant sur des pratiques collaboratives qui favorisent le transfert de connaissances, améliorent la qualité du produit et accroissent la motivation.

    www.RAD.fr ® © Jean-Pierre Vickoff