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

L'an dernier, Pascal Roques, bien connu pour ses ouvrages sur UML, avait publié un article décrivant une démarche de modélisation "agile". Il est récemment revenu sur le sujet en publiant un exemple d'utilisation de cette démarche.

Cette démarche est décrite de la manière suivante :
Une démarche de modélisation "agile" pour passer des besoins utilisateurs au code. Le processus que nous vous proposons de suivre pour le développement d’applications Web se situe à mi-chemin entre UP (Unified Process), un cadre général très complet de processus de développement, et XP (eXtreme Programming), une approche minimaliste à la mode centrée sur le code. Il s’inspire également des bonnes pratiques prônées par les tenants de la modélisation agile (Agile Modeling).
Passons sur la qualification d'approche minimaliste à la mode centrée sur le code dont est affublé XP (il y aurait beaucoup à dire là dessus, j'y reviendrai peut être un jour) pour nous intéresser à l'agilité effective de la méthode présentée. Il ne faut pas reprocher aux gens qui ont des idées (et même souvent de bonnes idées) sur les moyens de développer du logiciel de les faire connaître mais on peut légitimement s'interroger sur le qualificatif "agile" qui semble être devenu un terme marketing à la mode pour énoncer une certaine rupture avec des méthodes de développement cérémonieuses et vieillottes.
L'interrogation ainsi posée n'est pas originale. L'annonce du dernier article sur dotnetguru a suscité les mêmes réactions : les liens avec XP sont plus que flous.
L'auteur a toutefois précisé que ce qui est principalement agile dans la méthode présentée, c'est la façon de modéliser : une démarche légère, non systématique, où chaque diagramme doit avoir une vraie valeur ajoutée en accord avec les valeurs défendues par la modélisation agile.
Admettons.

Le problème avec ce type de discours, c'est qu'il devient difficile de rattacher des principes à des dénominations quand celles-ci deviennent plus ou moins galvaudées.
Je ne remets pas en cause la validité de la démarche de modélisation simplifiée mise en avant dans ces articles. Cependant, je suis certain de trouver des personnes qui tiendront le raisonnement suivant :



Qu'est ce qu'une méthode agile ?
Pour déterminer si un objet a une certaine propriété, le plus simple est de revenir à la définition initiale de cette propriété.

Dans le développement logiciel, on est agile quand les interactions entre les individus passent avant les processus et les outils.
Comment nous est récapitulée la démarche ? Avec un beau schéma de processus qui indique les étapes à suivre pour aller des besoins jusqu'au code !



Je veux bien croire que l'intention de l'auteur n'est pas d'imposer une démarche stricte dans l'enchainement des diagrammes mais, si tel est le cas, l'intention est bien masquée.
Heureusement, pour la partie 'outils' il nous est précisé, dans un excès de mansuétude, que les schémas pourront être réalisés à la main.

Dans le développement logiciel, on est agile quand le logiciel produit est plus important qu'une documentation exhaustive.
Là encore, un dessin pris dans l'article vaut mieux qu'un long discours :



Qui peut oser croire qu'une conception documentaire aussi détaillée a quelque chose d'agile ?
Je n'ai rien contre quelques diagrammes de séquence de haut niveau. Ils aident souvent à définir ou, après coup, à comprendre la logique globale d'un système. Mais, de là à quasiment écrire les lignes de codes, tests et boucles, compris sous forme de schéma, il y un pas que tout développeur agile hésiterait à franchir. Vouloir détailler autant que possible la conception sous forme de schémas, c'est oublier que la conception est constituée dans sa grande majorité de code source.

Dans le développement logiciel, on est agile quand la collaboration avec le client est plus précieuse qu'un contrat bien ficelé.

Les aspects interactifs relatifs au besoins du client ne sont pas explicités dans la démarche. Les cas d'utilisation sont supposés connus dès le départ. Il n'est pas précisé si l'ensemble des cas d'utilisation du système doivent être connus avant toute modélisation ou si l'approche est un peu plus incrémentale. Dans le doute, on s'abstiendra de faire des hypothèses sur ce sujet.

Dans le développement logiciel, on est agile quand la prise en compte des changements passe avant les plan pré-établis.

La conclusion de l'article nous donne un bel indice sur cet aspect là (je grasse) : "Nous avons ainsi montré qu’il est possible avec une démarche systématique mais simple d’aboutir de façon efficace à du code résultant des différents diagrammes UML".
Maintenant que nous disent les principes agiles : "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly". Il n'y a pas de place pour le systématisme dans l'agilité. Bien sûr, il n'est pas question de remettre en permanence en cause les pratiques de développment sous peine de ne plus faire que ça mais vouloir croire (ou faire croire ?) qu'une démarche de développement logiciel peut être systématique, c'est, au mieux, de l'inconscience et, au pire, de la tromperie.

Voilà donc pour l'agilité de la démarche.

Je le répète une dernière fois, je ne veux pas ici mettre en cause la validité de la démarche proposée. Je pense même que la décomposition analytique qu'elle propose est adaptée à certains contextes (des besoins très bien identifiés, des développeurs très peu expérimentés ayant besoin d'un cadre sécurisant) tout en évitant de tomber dans la documentite aigüe en limitant le nombre de types de diagrammes.
Ce qui me chagrine, c'est l'usage abusif du terme "agile" dans une méthode qui n'a rien de tel.