L'Agilitateur Création de logiciels : de l'agilité à l'artisanat

Les méthodes agiles ont en commun une faible emphase sur l'outillage face à la communication entre les participants. Cela ne signifie pas pour autant qu'il ne faille pas se soucier de l'outillage : si l'on veut que les participants ne perdent pas leur temps à maîtriser les outils au lieu de produire de la valeur pour le client, il leur faut des outils qui s'adaptent à leur façon de travailler et pas l'inverse.
Ainsi, choisir un outil pour gérer les attentes du client depuis leur expression jusqu'à leur mise à disposition dans le produit fini est toujours délicat. Depuis le post-it jusqu'à l'outil de gestion des cas d'utilisation qui se synchronise en temps réel avec les rapports MSWord, la palette est large et il y en a pour tous les budgets.
Le grand classique d'XP, ce sont les fiches bristol : pas chères et faciles à mettre en oeuvre. Dans le cas d'équipes dispersées géographiquement, on leur préfèrera leur équivalent électronique. Des solutions plus plus spécifiques, mais toujours simples, existent. J'ai, pendant un temps, utilisé XP Web et je compte, à l'occasion, jeter un coup d'oeil à Ice Scrum.

Bien souvent, la tentation est grande de construire son propre outil car, en fin de compte, les outils très flexibles (bristol, wiki) ne permettent pas de garantir le formalisme qui va de pair avec la discipline et, à l'inverse, les outils de saisie pré-formatés n'ont jamais le champ de texte ou la case à cocher dont on aurait besoin. Face à ce dilemme, je m'interroge sur l'opportunité de mettre le format XML, les définitions de schéma XML et les outils associés au service d'un tel dessein.
De prime abord, XML a un double avantage :

1. la possibilité d'écrire et de formatter librement du texte le met au niveau de flexibilité des wikis


2. la définition d'un schéma permet de garantir la présence d'un ensemble d'informations et de les exploiter de manière automatisée

Est-ce une bonne idée de se lancer dans la définition de son propre langage XML ?
Une idée dans l'air du temps est qu'il ne faut pas inventer son propre langage contrairement à ce qu'ont fait des dizaines de personnes. Les arguments 'un schema ne sera pas suffisant pour faire de la validation de documents' ou 'il faudra écrire des logiciels spécifiques pour éditer les données' peuvent être pertinents dans l'absolu. Dans notre cas, il s'agit simplement de structurer une petite feuille de bristol et le langage XML permettant cette structuration restera un formalisme interne au projet.
Bien sûr, il existe déjà des langages XML pour gérer de projets ou, plus simplement, faire des listes de taches ou d'exigences pouvant remplir un besoin similaire mais les utiliser reviendrait quasiment à prendre un logiciel sur étagère. Pour être capable d'adapter, et surtout de simplifier, le langage à son propre contexte de projet, la maîtrise du schéma est essentielle.

Quelle que soit la méthode agile utilisée, la granularité de traitement des attentes du client est quasiment toujours la même : les user stories en XP, les backlog items dans Scrum ou bien encore les features dans FDD. Face à la tentation d'une modélisation complexe des informations nécessaires à la gestion de projet (une fiche par exigence + une fiche par tache + une fiche par test + etc), ces similitudes permettent de centraliser la gestion autour de la seule chose qui apporte de la valeur : la réalisation d'une exigence du client.

Ce choix étant fait, gérer les exigences revient à avoir 1 document XML par exigence. Ce document contient l'ensemble des données relatives à sa réalisation. Cela pourrait donner, par exemple :


<requirement id='275' status='planned'>
    <caption>Lancement de l'application</caption>
    <description>Lors du lancement de l'application, le dernier document utilisé; est automatiquement chargé;</description>
    <priority level='8' />
    <estimate points='2' />
    <tasks>
      <task status='done'>lors du lancement de l'application, si la clef 'CurrentDocument' existe dans le registre, charger le document correspondant</task>
      <task status='done'>lors de l'ouverture d'un document, sauvegarder son nom dans la clef 'CurrentDocument' du registre</task>
      <task status='todo'>lors de la fermeture d'un document, supprimer la clef 'CurrentDocument' du registre</task>

    </tasks>
</requirement>


Un tel document à l'avantage :

• d'être simple


• de pouvoir être complexifié en fonctions des besoins réels du projet et des personnes. Par exemple, rajouter le détail des plans de test, voire les résultats de tests pour chaque build.


• d'être modifiable manuellement avec un simple éditeur de texte


• d'être archivable dans un gestionnaire de sources. Cela permet le partage au sein d'une équipe distribuée géographiquement tout en garantissant un historique versionné.


• d'utiliser une technologie standard qui permet :




• de valider sémantiquement les données saisies par un schema


• de disposer, sans écrire de code, d'outils d'édition tirant parti du même schema


• d'éditer des rapports transversaux. Par exemple, la liste de toutes les taches restant à faire pour l'itération en cours.

Il ne m'a pas fallu plus de 5 minutes pour écrire un XML schema correspondant à la structure décrite précédemment et l'utiliser pour saisir une exigence avec Jaxe (outil que je connaissais déjà).



Honnêtement, je n'arrive pas à trouver de défauts à cette façon de travailler. La souplesse du formalisme me semble être bien en accord le besoin d'agilité dans la méthode de travail et le minimum de rigueur nécessaire se marie avec la discipline exigée par certaines pratiques de développement (TDD, refactoring, ...).

Je l'essaierai probablement en grandeur nature dès que l'occasion se présentera.