22 février 2006

Xp Day en France

Pour info, un événement "agile" en France : http://www.xpday.fr/
Les 23 et 24 mars à Paris,

Après Londres, Bruxelles, Rotterdam, Karslruhe, la conférence "XP Day" a désormais sa version française. XP Day France s'adresse aux professionnels du logiciel, quel que soit leur niveau de connaissance de l'Extreme Programming.
Je ne pourrai pas y être et c'est bien dommage, les premiers XP Day en France, cela fait bien plaisir, il y a bien loin depuis la création de l'asso XP France en 2000...

19 février 2006

Modéliser "agile" : les demandes

l'Extreme Programming propose l'utilisation de cartes "bristol" qui contiennent des demandes, en fait des identifiants de demandes qui sont autant de prétextes à discussion, communication, entre client et développeur. Ces demandes sont aussi les items de gestion du projet. A chacune d'elles sont associés :
  • une priorité
  • un "poids" en termes de jetons ou points qui représentent l'effort nécessaire à la réalisation.
En fonction de ces éléments, le client établit - en tenant compte aussi de la vélocité ie la capacité de réaliser de l'équipe pour l"itération - la liste des demandes embarquées.

En modélisation agile, avec UML, il s'agit de :
  1. satisfaire au principes et pratiques de la modélisation agile,
  2. garder à l'esprit qu'un scenario de cas d'utilisation est équivalent à une user story XP.
De même, les cas d'utilisation sont réellement mis en oeuvre, voir à ce sujet le retour d'expérience significatif d'Alistair Cockburn.

Quelques éléments supplémentaires dans : cas d'utilisation efficaces.

Modéliser "agile"

Sans reprendre les principes et pratiques de la modélisation agile, quelques aspects pragmatiques de la modélisation agile. Voir aussi How Can Enterprise-Level Professionals Be Agile?.

Focaliser sur la valeur ajoutée
C'est l'un des principes du développement agile. Quelle est la valeur ajoutée de cette demande ? De cette action ? De ce document ? De cette réunion ?
Attention au terme "valeur ajoutée", il ne s'agit pas de valeur intrinsèque uniquement, plutôt de comparer le bonus obtenu avec le prix à payer. Ici, la question est alors : quelle est la valeur ajoutée de cette modélisation ?
Contrairement donc à un préjugé tenace, être agile est bien synonyme d'efficacité, d'amélioration de la productivité. Avec pour pierre angulaire l'humanité inhérente à la réussite du projet.
En résumé, "modéliser agile" est incompatible avec "modéliser inutilement".


Communiquer pour mieux collaborer
L'un des fondamentaux de l'approche agile (y compris Extreme Programming). Un modeleur agile ne passera des heures sans feedback de ses coéquipiers (clients, développeurs).

Feedback concret du système
De même que le feedback des collaborateurs est très régulièrement demandé, de même le feedback offert par le passage de tests du système est un élément crucial de la modélisation agile.

Concrètement, nous examinerons dans les jours qui viennent trois situations réalistes :
  • Modélisation métier ou domaine,
  • Modélisation de demandes,
  • Modélisation de solution.

10 février 2006

Extreme Programming et UML

Récemment, un fil de discussion a animé la liste "XP France", le sujet tournait autour de :
"quid de la modélisation en général et de l'UML en particulier"... entr'autres choses.

Alors... UML est-il "compatible Extreme Programming" ?

Pour être clair, je m'inscris parfaitement dans la modélisation agile. En ce qui concerne XP, je partage les idées de l'article Agile Modeling and Extreme Programming de Scott W. Ambler ; ma réponse à la question est donc oui, sans réserve !

Quelques précisions
Il s'agit de faire attention à ce qu'est UML... et ce qu'il n'est pas. UML est le langage de modélisation objet de l'OMG. Ce n'est pas une méthode ni un outil informatique. UML est le plus souvent découvert via le processus unifié ou l'une de ses variantes. UML est souvent associé à un outil modeleur. Or UML permet une autre utilisation basée sur le travail collectif, des outils pas nécessairement informatiques, des cycles courts... bref une modélisation agile.
De même pour XP. XP est une méthode de développement basée sur des valeurs, principes et pratiques. XP n'est pas destinée exclusivement aux développeurs, malgré le nom qui prête à confusion sur ce point. XP n'interdit pas les documents mais pose un regard critique - légitime - sur le flot de documentation produit par les méthodes habituelles, documentation souvent inutile, obsolète, mal positionnée dans le temps. XP n'interdit pas la modélisation mais rappelle que seul un code qui passe avec succès est garant de qualité. XP est riche en pratiques pour le développeur, riche en pratique de gestion du projet (planning process) et n'aborde pas les aspects strictement "gestionnaire" ou "client".

Un bref rappel...
... en ce qui concerne UML : l'élément de base de l'UML est le modèle (normal pour un langage de modélisation me direz-vous). Un modèle c'est quoi ? C'est une représentation d'un système (ie une société d'objets) à partir d'un point de vue : expression de besoins ou conception par exemple. Le modèle s'organise en paquetages, éléments de modélisation et diagrammes. Voir à ce sujet l'article Diagrammez vos modèles UML.

Un premier point important par rapport à XP. Si la création - et le maintien - d'un ou plusieurs modèles est une demande du Client et/ou du Manager (exigence qualité par exemple) alors il s'agit pour l'équipe d'une "histoire" à intégrer dans une ou plusieurs itérations, un peu comme les autres (fonction des priorités, poids en jetons, vélocité). Au passage cela permet de prendre conscience du coût d'un tel produit. En ce sens, XP est parfaitement compatible avec UML. Dans XP, les responsabilités et rôles sont définis ainsi : c'est le Client qui détermine les demandes.

Un modèle UML... est-ce utile ?
Cette question légitime trouve une réponse de la façon suivante. Le (ou les) modèle est créé une première fois. Ne pas le produire générerait un stress a priori. Avant de le maintenir, voire de créer d'autres modèles, il est important de faire le bilan : ce modèle est-il utile ? A qui ? Pendant combien de temps ? Quelle valeur ajoutée ? En fonction de ces réponses, la décision pourra être de poursuivre dans le sens de la modélisation ou pas. Cette tactique est d'ailleurs efficace pour tout type de livrable du projet.

Question de sensation
Examinons maintenant un point crucial dans l'appréciation de la modélisation. De même que certaines personnes ont une mémoire auditive et d'autres une mémoire visuelle (que faites-vous pour retenir un numéro de téléphone ?), de même certains développeurs "voient" l'architecture (la forme ou le squelette de l'application, par exemple l'utilisation d'un pattern tel que Observateur...) en lisant quelques entêtes de fichiers-sources. D'autres (dont je fais partie) voient une architecture plus rapidement dans quelques diagrammes bien faits. Diagrammes qui visualisent les aspects statiques et dynamiques du système en particulier. Nous touchons là à un élément naturel probablement inéluctable. Attention donc aux contraintes dans un sens ou dans l'autre.

Utiliser UML
Pratiquement, quel est l'utilisation d'UML la plus naturelle dans XP ? Il se trouve que l'Extreme Programming propose une autre technique de modélisation : les CRC Cards. UML pourrait être considéré comme un remplaçant. Comment ? Tout d'abord le contexte, par exemple découvrir les objets et interactions dans la réalisation d'une demande (user story) ou d'une tâche. Supposons un binôme qui démarre la réalisation d'une nouvelle tâche et qui se pose la question des tests, de la conception de cette réalisation. Ou bien une équipe qui doit donner un poids à une demande sans aucune idée de ce que peut être sa mise en oeuvre. Un tableau (tableau blanc, paper board...), quelques développeurs autour. Un diagramme d'interaction (séquence, collaboration)... et c'est parti ! Un diagramme de classes permet de "compiler" les différents apports des diagrammes d'interaction. Notez que les classes dans UML possèdent un compartiment dédié aux responsabilités (compartiment que l'on ne retrouve malheureusement pas dans les modeleurs). Combien cela dure-t-il ? L'une des clés de XP est le feedback rapide. Il importe donc de ne pas tomber dans le piège d'une modélisation trop longue sans le feddback des tests de code.

UML côté Client
XP définit trois rôles dans le projet. Si UML est généralement associé au développement de logiciels, ce langage permet également de modéliser des processus, des domaines. C'est l'activité de modélisation métier. Une solution possible avant de commencer la rédaction de demandes de développement est de travailler au changement induit par le prochain outil logiciel. Dans cet ordre d'idées, modéliser les processus impactés peut permettre de cerner plus rapidement le contour fonctionnel de façon plus rapide (modifier un modèle est plus rapide que modifier un code bien que le feedback soit moins probant). Ici, UML propose en particulier les diagrammes d'activités, d'état-transition et bien évidemment les classiques diagrammes d'interactions et structurels (appelés pour simplifier diagrammes de classes).

En guise de conclusion...
UML est-il compatible XP ? Oui, même si UML ne fait pas partie des outils proposés naturellement par XP. Pas n'importe quel UML, plutôt une mise en pratique qui respecte les principes d'XP tels que feedback rapide, assumer la simplicité, petit investissement de départ...
Et plus généralement, ceci étant vrai pour beaucoup de choses : tout dépend du contexte... Peut-être une affaire de décohérence quantique :-)