C'est à l'outil que l'on reconnaît le bon ouvrier
Par Olivier Azeau le 6 juin 2006, 23:32 - En français - Lien permanent
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.
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 :
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 :
Un tel document à l'avantage :
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.
- la possibilité d'écrire et de formatter librement du texte le met au niveau de flexibilité des wikis
- 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.
Commentaires
Je me demandais récemment s'il ne serait pas justement intéressant de réaliser un outil qui guiderait l'utilisateur (ou un groupe en réunion avec un vidéoprojecteur), à identifier des UserStories généralistes, puis des thèmes, puis à les décomposer, les reclasser, prioriser le tout, etc. Et là un magnifique export XML est récupéré par l'équipe de dév qui l'intègre dans leur outil favori (comme IceScrum, au hasard ;), voire ce module fait partie de leur outil. Dans tous les cas, il n'y a pas de solution miracle je pense. Et puis les post-its (ou fiches cartonnées) épinglés sur un tableau en liège, même si c'est rustique, c'est relativement efficace.
Juste un mot sur IceScrum, l'adresse indiquée pointe sur le serveur de dév. Visitez plutôt http://prog13.free.fr/icesc... (en anglais par contre désolé)
Il me semble qu'il y a implicitement quelque chose d'itératif dans tout cela : la définition de user stories nourrit le développement tout comme une version du produit développé nourrit l'écriture de nouvelles user stories. J'ai effleuré le sujet dans ce billet : http://agilitateur.azeau.co... . Un outil qui viserait à adresser cette problématique devrait, à mon avis, tenir compte de cet aspect itératif.
Par ailleurs, je n'ai aucune idée de l'existant en matière d'outil d'aide à la "modélisation de processus métier".
En ce qui concerne la capacité du client à faire du XML, je ne doute pas que l'utilisation de notepad soit un peu limite mais un outil tel que Jaxe ou comme Etna (lorsqu'il sortira) http://xtech06.usefulinc.co... me semble être largement dans le domaine du possible.
Après tout, un client agile est censé savoir définir des tests automatisables. J'ose espérer qu'un logiciel tel que FIT http://fit.c2.com/ est à sa portée !
PS : j'ai modifié le lien vers IceScrum
La modélisation métier ne me semble pas nécessaire. Travailler avec des thèmes permet d'identifier ses grands secteurs métiers, puis pour chaque secteur de raffiner des sous-secteurs, etc jusqu'à la production de US. L'approche par raffinages successifs est intuitive et généralement efficace. C'est d'ailleurs cet esprit qu'on utilise dans la planification, où on raffine au fil des sprints.