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 :-)