Exprimer ses besoins
Par Olivier Azeau le 12 novembre 2006, 22:30 - En français - Lien permanent
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.
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 :
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 :
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 :
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 :
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.
- le formalisme attendu reste relatif car l'interaction entre les personnes passe avant un processus trop strict ;
- la rédaction est succinte car on s'attachera à avoir un logiciel qui respecte ces besoins plutôt qu'une description exhaustive ;
- 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 ;
- 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éfautsCe 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.
Commentaires
Un article très intéressant propose une approche centrée utilisateur pour récolter des besoins sous une forme très proche des User Stories, pour ne pas dire identique. Ca me semble très pertinent et très efficace, ce que je pourrai vous confirmer dans le temps (je vais l'expérimenter sur notre projet de l'année).
Voici le lien : http://agilealliancebeta.or...
J'ai bien aimé l'approche en 2 dimensions criticité/temps pour déterminer le meilleur contenu possible pour la 1ère version (slide 31). Je reste cependant un peu sur ma faim quant à la mise à jour du modèle métier suite au feedback des itérations. Ce point mériterait à mon avis plus une escription plus détaillée. Mais peut être ce détail vient-il naturellement quand on a effectivement déroulé une phase initiale avec cette méthode ?
En tout cas, la description qui y est faite des histoires utilisateur (peu importe comment on les nomme, 'tâche' ou autre) me conforte dans mes choix de granularité. Un distributeur de billet sert à retirer de l'argent et non pas à saisir un code secret de CB tout comme un bug tracker sert à livrer un produit dont on maîtrise les défauts et non pas à saisir des fiches de bug.
Je viens de mettre en pratique cette phase de lancement sur notre projet, mais nous avons dû la réaliser en une journée seulement, du fait des créneaux de temps qui nous sont alloués. Le fait de réfléchir aux rôles utilisateurs est une chose, mais ce qui a le plus servi à mon avis est de réfléchir aux intéractions qu'ils ont entre eux. Cela a permis de révéler des User Stories "cachées" dans le métier, auxquelles nous n'aurions probablement pas pensé sans avoir eu ce travail sur les intéractions. Et comme je le pensais, les tâches(buts) déduites de ce diagramme se sont tout naturellement transformées en user stories, le concept est très proche en fait. Il nous a fallu simplement rajouter les user stories purement techniques, qui sont liées à l'implémentation du noyau minimum nécessaire pour s'intéresser aux fonctionnalités utilisateur.