source: trunk/doc/overview.fr.txt @ 2

Présentation générale d'XP Dojo
===============================

XP Dojo est un logiciel offrant un espace virtuel dans lequel tous les participants d'un projet XP se rendent pour travailler et collaborer. Il réunit le code, les tests, les scénarios et toute autre information concernant le projet, en permettant aux participants d'y travailler selon la méthode XP.

Peu d'outils sont conçus spécifiquement pour XP
-----------------------------------------------

La pratique de l'eXtreme Programming amÚne des façons nouvelles de programmer, de collaborer et de communiquer.

Par exemple, dans un projet XP, le code n'est ni commenté ni accompagné d'une documentation expliquant son organisation. Pourtant, chaque programmeur intervient dans toutes les parties du code, et du code qu'il développe peut avoir été modifié par d'autres la prochaine fois qu'il le regarde. Dans ces conditions, des outils de visualisation et navigation du code trÚs efficaces sont indispensables.

D'ailleurs, le programmeur XP ne navigue pas que dans le code : il navigue en parallÚle dans les tests unitaires de ce code. Il passe systématiquement et fréquemment de l'un à l'autre ou les regarde cÎte à cÎte.

Surtout, l'eXtreme Programming se reconnaît à deux caractéristiques: les tests unitaires sont écrits avant le code, et deux programmeurs travaillent en tandem. A elles seules ces deux pratiques bouleversent les flux et demanderaient une ergonomie particuliÚre.

Enfin, de par sa sensibilisation aux valeurs XP, un développeur XP aspire à des outils plus simples. Pourquoi, en dehors de Smalltalk, sommes-nous encore à travailler avec des fichiers ?

Or les outils de développement existants répondent assez peu à ces besoins, tout en compliquant les choses avec de nombreuses fonctionnalités qui, dans le contexte de l'eXtreme Programming, sont superflues ou inadaptées.

Il y certes des avancées. De plus en plus d'IDE (environnements de développement intégrés), à l'instar d'IntelliJ ou Eclipse, fournissent des remaniements (refactorings) automatisés et intÚgrent le lancement de tests JUnit. Ils intÚgrent également divers outils de gestion de configuration. CruiseControl automatise l'intégration continue. Des outils de tests de recette permettant de définir les résultats attendus avant d'avoir développé le logiciel apparaissent, et FIT notamment permet même d'impliquer un non-développeur dans leur définition.

Mais le tableau est loin d'être idyllique. D'abord, la plupart des avancées citées sont réservées au développement en Java. Dans Eclipse, la plupart des remaniements ne fonctionnent pas ou pas toujours comme l'attendent des développeurs XP habitués à cette pratique - aprÚs quelque semaines de frustration nous avons fini par ne plus en utiliser qu'un seul, le renommage. L'intégration de JUnit n'a pas été étudiée pour le TDD: l'assistant de création de TestCase propose de sélectionner la classe à tester parmi les classes déjà existantes, et même de générer des squelettes de tests en utilisant ses méthodes existantes !

En pratique, il existe assez d'outils pour qu'une équipe connaissont bien XP puisse, au prix d'un certain effort, mettre au point un environnement à peu prÚs adapté à la méthode. Par contre, ces outils ne facilitent pas l'adoption des pratiques XP, et tendent plutÎt à encourager des dérives méthodologiques. Comme souvent, l'intégration entre des outils hétéroclites impose des limitations et engendre des dysfonctionnements.

Cf. article de James Shore sur CruiseControl.

L'objectif principal du projet XP Dojo est donc de fournir un outil simple et autonome spécifiquement adapté aux pratiques XP, notamment :

- la programmation pilotée par les tests unitaires et de recette;

- l'intégration continue;

- le remaniement (refactoring);

- le développement en tandem (pair programming).

Nous ne pensons pas que le rÎle d'un outil est d'imposer une méthodologie, contraindre l'utilisateur ou prendre des décisions à sa place. XP Dojo vise plutÎt à simplifier et fluidifier le travail en mode XP, automatiser les tâches répétitives et encourager l'expérimentation.

Pour les aspects consacrés aux développeurs, XP Dojo se limite à la programmation en Erlang et en C. Nous préférons pour le moment consacrer nos efforts aux nouvelles fonctionnalités qu'au support d'autres langages. Le choix d'Erlang est justifié dans un autre article. Quant au C, il est le complément parfait à Erlang, reste un des langages les plus répandus, et manque cruellement d'outils alors qu'il en aurait le plus besoin pour le rendre plus amÚne à la programmation XP.

Explorer librement et se perfectionner à XP
-------------------------------------------

Le développement d'un outil dédié à XP s'est naturellement présenté à nous comme l'opportunité de mettre en pratique et à l'essai toutes nos convictions techniques et méthodologiques. Par exemple, nous étions attirés par le langage Erlang. Nous souhaitions pousser toujours plus loin l'automatisation totale des tests, travailler avec une métaphore, s'exercer à l'écriture de tests unitaires "documentaires", faire émerger un mini-langage rendant les tests de recette totalement lisibles, combiner les tests de recette avec un systÚme intéractif de formation et d'aide en ligne, augmenter encore la fréquence des intégrations jusqu'à atteindre l'intégration instantanée chaque fois que tous les tests unitaires passent....

Toutes ces idées, suggérées par notre pratique d'XP dans un contexte professionnel, demandaient un peu trop de recherche et de développement pour être envisageable sur ces projets.

Ce désir de travailler sans contraintes nous à conduit à démarrer un projet de logiciel libre.

Adapter XP à un projet open source bénévole
-----------------------------------------------

Le choix d'appliquer au maximum la méthode XP à ce projet de logiciel libre était pour nous une évidence. D'ailleurs, XP ne manque pas d'atouts dans ce contexte:

- les livraisons fréquentes et rythmées sont appréciées par les communautés d'utilisateurs, tout en donnant aux développeurs le sentiment d'avancer malgré le temps limité qu'ils peuvent y consacrer.

- le soin apporté à la qualité, et la fiabilité des nouvelles versions grâce à la non-régression automatisée, est un domaine où XP excelle et pourrait améliorer la mauvaise réputation du logiciel libre.

Par contre, un développement bénévole d'un logiciel libre nécessite aussi des adaptations à la méthode XP et engendre de nouveaux besoins:

- le fait de travailler sur son temps libre implique de le faire souvent chez soi;

- la programmation en tandem nécessite donc des outils permettant la collaboration à distance en réseau (que nous baptisons cyberdojo);

- malgré tout, la programmation en tandem n'est plus possible tout le temps, à moins de s'interdire de travailler lorsqu'aucun autre équipier ne se trouve libre au même moment;

- le temps bénévole fluctue beaucoup au gré des disponibilités et motivations des membres de l'équipe: la notion de vélocité devient inapplicable;

- le rÎle de client se répartit entre les développeurs du projet et toute la communauté utilisatrice: les choses sont moins claires que dans un projet XP classique;

- la propriété collective du code est mise à mal par la distance et les participations fluctuantes (la question des contributions externes se pose aussi).

Bien entendu, nous souhaitions "utiliser l'outil pour développer l'outil". Du coup, XP Dojo supportera le développement open source et intÚgrera les réponses que nous aurons adoptées, aprÚs expérimentation, aux questions ci-dessus.

Notre réflexion à ce sujet nous incite actuellement à amplifier et "extrémiser" les pratiques XP:

- apprendre à découper les scénarios de façon à ce qu'ils soient entiÚrement réalisables en une "séance" (typiquement deux heures de développement);

- passer à l'intégration instantanée, diffusant et intégrant automatiquement chaque changement chaque fois qu'on revient à l'état où les tests unitaires passent;

- la simplicité absolue, l'expressivité et la métaphore s'imposent encore plus pour compenser l'éclatement de l'équipe;

- les tests de recette doivent être lisibles et rédigeables, non pas par une seule personne, mais par toute la communauté, sans nécessiter de formation particuliÚre: en effet la contribution de tests de recettes nous semble la seule façon de gérer efficacement des demandes potentiellement nombreuses;

- l'outil doit permettre à chaque utilisateur d'exprimer ses préférences et priorités parmi les scénarios proposés; un systÚme de vote, à définir, permettrait d'identifier les besoins prioritaires.

Nous pensons donc que ces évolutions constitueront des axes d'amélioration pouvant bénéficier tous les projets XP, mêmes classiques.

BinÎmage à distance
-------------------

Le meilleur exemple de la maniÚre que ces extensions "open source" peuvent intéresser les projets XP en entreprise est le cyberdojo.

Tout d'abord, malgré toute l'insistance que les pratiquants d'XP mettent à préconiser le rassemblement physique de tous les acteurs d'un projet, de nombreuses entreprises multisites, ou situées ailleurs que leurs clients, n'y peuvent rien mais souhaiteraient néanmoins pratiquer XP.

L'outillage de travail en tandem à distance, tout en aidant les (nombreuses) équipes distribuées essayant de pratiquer XP, peut servir aux équipes partageant le même bureau, permettant notamment:

- de ne pas réorganiser tout le mobilier;

- de rapidement et temporairement se connecter à la séance d'un autre binÎme pour les aider ou observer ce qu'ils font;

- de travailler confortablement à trois ou plus (formation, problÚmes épineux);

- de binÎmer tout en conservant le confort de ses réglages personnels (e.g. claviers azerty, qwerty ou dvorak).

XP Dojo fournira, de façon totalement intégrée au reste de l'outil, les fonctionnalités suivantes dédiées à la collaboration à distance:

- gestion de la présence des participants et de la création de séances de travail à deux ou plus;

- transmission de la voix des membres de la séance; possibilité d'entendre, en plus atténué, les échanges d'une ou des autres séances en cours;

- travail en parallÚle, mais indépendant, sur le même code, avec visualisation de ce que fait l'autre (inspiré de SubEthaEdit);

- mode spécial dédié au jeu du ping pong (l'un ajoute un test, l'autre le fait passer).

Retour d'expérience de binÎmage à distance avec les outils actuels
------------------------------------------------------------------

La conviction qu'il fallait développer un outil dédié est issue d'un an de binÎmage à distance avec les outils disponibles de messagerie instantanée, téléphonie internet et partage de bureaux. Nos contraintes, apparemment sévÚres, sont pourtant représentatives d'un logiciel libre ayant une communauté importante:

- interopérabilité entre Linux/BSD, Mac OS X et Windows
- interopérabilité entre des claviers différents
- performances correctes via internet

Nous avons evalué ou expérimenté de nombreuses combinaisons d'outils disponibles: VNC, session distante X11, de nombreux outils de messagerie instantanée, SubEthaEdit, un plugin Eclipse (Sangam)... Nous utilisons actuellement:

- yahoo!messenger pour savoir qui est disponible et former les binÃŽmes
- SJPhone pour la voix
- ssh + /bin/screen + emacs pour partager un bureau

Cette solution demande quand même une dizaine de minutes de mise en place (environ une heure la premiÚre fois), ne fonctionne que dans un sens (un utilisateur Windows doit se connecter pour travailler chez un utilisateur Mac ou Linux), modifie légÚrement l'ergonomie à laquelle nous sommes habitués et n'ajoute aucune ergonomie dédiée au travail en tandem. Elle reste, pour nos besoins, supérieure aux autres possibilités, qui ont toutes révélées l'un ou l'autre des problÚmes suivants:

- des problÚmes d'interopérabilité entre OS et/ou claviers
- une difficulté d'installation et de configuration dépassant nos compétences et notre patience
- des défauts de fonctionnement les rendant inutilisables
- une lenteur insupportable

Avant de binÎmer à distance, nous avions pendant deux ans collaborés et binÎmés ensemble sur un projet XP classique. Outre la frustration d'avoir perdu beaucoup de temps à lutter avec les outils, nous avons trouvé le binÎmage à distance tout aussi utile et bénéfique que le binÎmage normal, mais un peu plus délicat à faire:

- comme on ne voit pas le partenaire, il faut en permanence se parler, expliquer ce qu'on est en train de faire, même ce qu'on est en train de regarder;

- il y a une plus forte tendance à décrocher, à faire quelque chose en parallÚle pendant que l'autre continue;

Mais il y a aussi des avantages car, étant déjà sensibilisés et expérimentés en binÎmage, nous étions peut-être plus attentif à l'autre que lorsque nous binÎmions cÎte à cÎte.

Nous pensons que le fait de se connaître, et de connaître le binÎmage, au préalable, a facilité les choses. Bien que nous n'ayons jamais essayé, nous imaginons qu'il serait encore plus difficile de binÎmer à distance avec quelqu'un avec qui nous n'avons pas travaillé au préalable.

Les difficultés et frustrations sont néanmoins suffisantes pour que:

1) nous avons relaxé notre exigeance initiale de ne jamais coder seul:

2) nous avons décidé de nous réunir physiquement une fois par mois (ce qui nous recommenderions de toutes façons).

La nécessité de disposer d'un outil intégré, simple à mettre en oeuvre, et apportant une ergonomie adaptée à cet exercice nous paraît indéniable pour que ce mode de collaboration devienne viable.

Etat des lieux
--------------

XP Dojo permet actuellement de développer en TDD en Erlang d'une maniÚre trÚs dynamique.

En terme d'organisation du code, de compilation et d'exécution, Erlang ressemble sensiblement à Java:

- chaque module doit se trouver dans un fichier du même nom;

- chaque module est compilé (mais peut être compilé indépendemment des modules dont il dépend);

- la compilation génÚre du bytecode pour une machine virtuelle

- un systÚme équivalent à make permet de définir un ensemble de fichiers source à compiler s'ils ont été modifiés.

XP Dojo simplifie et automatise toutes ces opérations: il suffit d'indiquer la racine du projet pour que tous les fichiers source soit trouvés, compilés et chargés dans la machine virtuelle, et ce continuellement, chaque fois qu'un fichier est modifié ou ajouté.

En outre, XP Dojo filtre parmi les modules trouvés ceux qui contiennent des tests unitaires, ou de recette. Le cas échéant, ceux-ci sont également exécutés et le bilan des résultats affiché.

Une ergonomie pilotée par les tests
-----------------------------------

XP Dojo fera complÚtement abstraction des fichiers source, stockant directement l'arbre syntaxique abstrait:

- l'affichage présente une vue logique des modules et fonctions, comme Smalltalk;

- le code est affiché dans un style uniforme;

- les manipulations (refactoring, indexation) sont facilitées.

L'interface graphique d'XP Dojo affichera cÎte à cÎte le code et les tests unitaires correspondants. Chaque fois qu'on affiche un module, tous les tests qui l'exercent seront affichés à cÎté.

Le code étant compilé et les tests relancés en continu (à chaque modification de code), la synthÚse est affichée dans un tableau de bord, et les tests en échec seront indiqués directement dans le code par des couleurs. Le code non testé (car non couvert ou mutable sans mettre un test en échec) sera égalemet mis en exergue.

L'écriture d'un test pour un fonction inexistante génÚrera instantanément un bouchon de code correspondant.

Intégration instantanée pilotée par les tests et le refactoring
---------------------------------------------------------------

Les opérations de gestion des versions seront gérées automatiquement en fonction de l'état des tests:

- l'ajout ou modification des tests crée automatiquement une session de travail
- dÚs que les tests unitaires repassent à 100% (sans régressions dans les tests de recette), le code est reposé et la session refermée.

Toutes les modifications de code sont exprimées en tant que refactorings (opérations sémantiques). Ainsi, lorsqu'une session est en cours alors qu'une autre se termine, ses modifications (sémantiques) de codes sont automatiquement appliquée sur la session en cours, dÚs qu'elle est stable (100%).

EXEMPLE?