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

Il y a quelques temps, dans un billet sur la qualité, j'ai mentionné le rôle que joue l'expression des besoins dans la réalisation d'un produit de qualité. J'y raconte comment les pratiques de XP on-site customer et small release permettent de s'assurer que les attentes exprimées sont les bonnes et que l'on n'en prend pas en compte un trop grand nombre simultanément.

Aujourd'hui, un billet de Claude Aubry qui explique le besoin de prioritisation des exigences lors de la réalisation d'un système m'incite à revenir sur le sujet en réfléchissant à la meilleure façon d'exprimer les attentes d'un client dans une approche agile.
Essayons tout d'abord d'identifier quelques caractérisques que l'on peut attendre d'une expression des besoins à partir du manifeste agile :

1. le formalisme attendu reste relatif car l'interaction entre les personnes passe avant un processus trop strict ;


2. la rédaction est succinte car on s'attachera à avoir un logiciel qui respecte ces besoins plutôt qu'une description exhaustive ;


3. le client est partie prenante dans la rédaction car la collaboration tout au long du projet est plus importante qu'un verrouillage contractuel des spécifications ;


4. l'ensemble des besoins n'est pas exprimé dès le démarrage du projet car on s'autorise à introduire en cours de route tous les changements qui apporteront de la valeur au système fini.

Les histoires utilisateur telle que définies par XP sont bien évidemment des candidats naturels pour l'implémentation de telles caractéristiques. Les cas d'utilisation connus des utilisateurs du RUP peuvent l'être également pour peu que l'on n'en prenne pas une approche trop cérémonieuse.
Histoires utilisateurs et cas d'utilisation ne sont, en fin de compte, que les diverses facettes d'une même réalité : la description d'un but que cherche à atteindre l'utilisateur d'un système. Pour prendre un vocabulaire mathématique ensembliste, les histoires utilisateur sont des scénarios qui peuvent être regroupés à travers une relation "a le même but que". Les cas d'utilisation sont les classes d'équivalence de cette relation.

Mais comment trouver les buts en question pour un système donné ? La 3ème caractéristique parmi les 4 listées précédemment laisse entendre que ces buts doivent être fortement orientés client (client a ici un sens large : client externe d'une société de service, chef de produit chez un éditeur de logiciel, maitrise d'ouvrage dans une société utilisatrice, ...) Ce qui caractérise au final les besoins de ce client, c'est le but de l'utilisateur final, ce qui lui apporte de la valeur. Il me semble ainsi naturel d'introduire à ce niveau la modélisation métier de cet utilisateur. Comme on peut le voir à travers deux billets de Christophe Thiry (ici et là), elle peut être exprimée en des termes très simples qui mettent en évidence les raisons pour lesquelles on batit un système.

Reprenons l'exemple de Claude Aubry d'un système de bug tracking. Si on me demandait, en tant que reponsable de produit et utilisateur d'un tel système, d'exprimer les besoins qui dirigent son développement, je reviendrais à l'essence même du métier : livrer un produit. Donc, si on se place dans l'optique de l'utilisation d'un système de bug tracking, mon principal cas d'utilisation est :
UC#1 : Livrer un produit dont on maîtrise les défauts

Ce cas d'utilisation peut être décliné en une myriade de scénarios qui sont autant d'histoires utilisateur. Le problème est que, si on commence avec des scénarios compliqués, l'équipe en charge de la réalisation du système de bug tracking y mettra des coûts tellement élevés qu'il sera impossible de les terminer en une seule itération, ce qui amoindrit considérablement la valeur que l'on peut accorder à de tels scénarios.
J'ai donc tout intérêt, en tant qu'utilisateur, à raconter, pour commencer, une histoire relativement simple qui se limite à ce qui va m'apporter le plus de valeur :
US#1 : Maîtrise élémentaire des défauts d'un produit.
Les défauts du produit sont décrits par un identifiant numérique unique, une description textuelle de 200 caractères max., un état 'ouvert' ou 'fermé'.
A tout moment, le système affiche la liste des défauts ouverts (un par ligne) sur 2 colonnes : identifiant numérique et description textuelle.
L'utilisateur crée un enregistrement de défaut en entrant une description textuelle. Le système alloue un identifiant numérique à l'enregistrement. L'enregistrement est créé en état 'ouvert'.
L'utilisateur ferme un enregistrement en entrant l'identifiant numérique de l'enregistrement à passer en état 'fermé'.


Si le système développé lors de la 1ère itération n'implémente que cette histoire, certains le qualifieront peut être de bug tracker à 2 balles et ils auront raison ! C'est d'ailleurs un peu le but recherché : développer à chaque itération un système fonctionnel, que l'on puisse mettre entre mes mains de client-utilisateur afin que je fournisse un feedback à travers les histoires utilisateur que je vais prioritiser dans les itérations à venir. J'ai déjà parlé d'une telle approche en cascade itérative. Mon expérience me laisse penser que développement agile ou pas, on en revient toujours au même point : c'est le retour utilisateur qui permet à un système de progresser, alors autant profiter de ce mécanisme au maximum en livrant le plus souvent possible un système qui apporte à chaque fois plus de valeur.

On voit donc ici qu'une expression de besoin satisfaisante va toujours être complète au sens de la modélisation métier. Elle ne spécifiera pas une sous-partie de scénario issu du métier de l'utilisateur mais un cheminement complet. Dans notre exemple, une histoire qui aurait simplement demandé la saisie d'un défaut n'aurait eu aucune valeur pour l'utilisateur car il n'aurait pas pu visualiser l'ensemble des défauts saisis.

Quel est l'intérêt de cette contrainte ? La planification.

En ne planifiant que l'implémentation de scénarios complets, au sens où ils apportent une valeur à l'utilisateur en remplissant un but, on laisse le modèle métier planifier l'implémentation du système.
Kent Beck explique ce phénomène qu'il a constaté sur le projet C3 :

One of the lessons I learned from ChryslerComprehensiveCompensation was that I could ignore story dependencies for planning purposes.
This came from two sources that I could identify.
First, Business never asked for irrational stories, like insisting on reports even though they didn't want the stories that created the data on which the reports were based.
Second, doing business value first meant that you would naturally do "Basic Paycheck" before you did "Enhanced Paycheck", since the basic one was far more valuable than the enhanced.


Il ne faut cependant pas croire que l'on va pouvoir modéliser un système complexe avec un ensemble de petites histoires sans dépendances entre elles. Les dépendances existent mais elles n'apparaissent qu'avec le temps lorsque l'on bâtit de nouvelles histoires à partir d'un système existant. Pour reprendre l'exemple du bug tracker, dès que ma première histoire est implémentée dans le système, je peux en rajouter une autre plus compliquée :
US#2 : Gestion des défauts d'un produit par criticité.
Les défauts du produit sont décrits par un identifiant numérique unique, une description textuelle de 200 caractères max., un état 'ouvert' ou 'fermé', une criticité 1(le moins critique)/2/3/4/5(le plus critique).
A tout moment, le système affiche la liste des défauts ouverts (un par ligne triés par criticité décroissante) sur 3 colonnes : identifiant numérique, criticité et description textuelle.
L'utilisateur crée un enregistrement de défaut en entrant une description textuelle et une criticité. Le système alloue un identifiant numérique à l'enregistrement. L'enregistrement est créé en état 'ouvert'.


La rédaction de cette histoire est ici exhaustive mais, quand la complexité du système augmente, on peut sans problème basculer sur une rédaction ne mettant en évidence que les différences avec le système existant. La description complète, que l'on peut conserver par ailleurs pour maintenir une modélisation métier complète, est alors devenue un handicap. En effet, il ne faut pas perdre de vue l'aspect transitoire des histoires utilisateurs : leur bénéfice réside principalement dans la faculté à rapidement évaluer leur coût et prioritiser leur implémentation pour l'itération à venir.