Gestion de projet – Vers les méthodes agiles
100
Existe-t-il un modèle de user story ou de scénario client ? Dispose-t-on d’un exemple ou deux ?
1) La réponse de l’expert Pascal Pratmarty, consultant indépendant et ingénieur expérimenté
en développement logiciel.
Examinons l’exemple suivant d’une application web de recherche d’emploi : « En tant que
recruteur, je dois pouvoir être notifié par e-mail aussitôt qu’un utilisateur enregistre un profil
correspondant à mes critères. » Cette phrase est claire pour le client, décrit un scénario testable
et orienté utilisateur. C’est un bon début !
Avec l’écriture des premières stories, il convient de déterminer un vocabulaire commun entre
l’équipe et le client ou son représentant : quels sont les concepts métiers manipulé ? Les différents types d’utilisateurs du système ? Leurs perspectives et possibilités d’action autour de ces
concepts ? Considérez ce vocabulaire comme une langue vivante en miniature, qui doit s’enrichir au gré des nouveaux besoins du projet. D’excellents ouvrages traitent de ce sujet en
profondeur.
Afin d’en faire une unité de base pour la planification itérative, une formule courte et simple doit
synthétiser l’essence de chacun de ces mini-contrats fonctionnels. Nous conservons habituellement toute information relative à un contrat au dos de la carte. Elle ne prendra toute son
importance qu’à l’approche de l’itération, d’abord pour aider à l’estimation de la taille de la
story, puis pour l’écriture des tests d’acceptance qui formeront l’ensemble des objectifs
concrets et mesurables à atteindre.
2) La réponse de l’expert Laurent Bossavit, président de l’association Agile France.
Il n’existe pas de « modèle » au sens « modèle de document », car c’est précisément ce dont
eXtreme Programming se déleste. Un scénario client, c’est simplement une fiche cartonnée
portant quelques mots qui identifient une exigence, une conversation entre le client et les
développeurs, puis enfin un test de recette permettant une confirmation que l’exigence a bien
été prise en compte (ce sont les « 3 C » – carton, conversation, confirmation, de Ron Jeffries).
Pour autant, l’élaboration de la liste des scénarios client (beaucoup, peut-être la plupart,
connus en début de projet, puis certains découverts au fur et à mesure) demande de l’attention, et
des outils existent pour s’assurer de la pertinence des scénarios client envisagés.
L’acronyme INVESTrappelle les critères qui font d’un scénario client un... bon investissement :
– I pour Indépendant : lorsque le client peut en toute liberté décider de l’ordre dans lequel les
scénarios sont implémentés, sans qu’interviennent des contraintes techniques, il est plus facile
d’optimiser la valeur du projet. Bons exemples : « Je peux consulter la liste des factures émises » ;
« Je peux trier les factures par date » ; « Je peux consulter la liste des clients ». Mauvais exemples : « Créer un contrôle permettant d’afficher des listes avec tri sur une colonne quelconque » ;
« Créer la liste des factures » ; « Créer la liste des clients ».
– N pour Négociable : un bon scénario fait état d’un objectif à atteindre, les détails d’implémentation pouvant être négociés en cours de route entre clients et développeurs. Ce n’est pas une
description explicite d’une solution particulière. Bon exemple : « Je peux connaître le montant
total des factures impayées ». Mauvais exemple : « Lorsque je clique sur le bouton "Total", une
ligne est rajoutée à la liste des factures avec le montant total des impayés ». Dans le premier
exemple, les développeurs ont la latitude d’imaginer une solution plus efficace, par exemple un
calcul en temps réel.
GestProjInform Livre Page 100 Vendredi, 3. avril 2009 12:07 12
100
Existe-t-il un modèle de user story ou de scénario client ? Dispose-t-on d’un exemple ou deux ?
1) La réponse de l’expert Pascal Pratmarty, consultant indépendant et ingénieur expérimenté
en développement logiciel.
Examinons l’exemple suivant d’une application web de recherche d’emploi : « En tant que
recruteur, je dois pouvoir être notifié par e-mail aussitôt qu’un utilisateur enregistre un profil
correspondant à mes critères. » Cette phrase est claire pour le client, décrit un scénario testable
et orienté utilisateur. C’est un bon début !
Avec l’écriture des premières stories, il convient de déterminer un vocabulaire commun entre
l’équipe et le client ou son représentant : quels sont les concepts métiers manipulé ? Les différents types d’utilisateurs du système ? Leurs perspectives et possibilités d’action autour de ces
concepts ? Considérez ce vocabulaire comme une langue vivante en miniature, qui doit s’enrichir au gré des nouveaux besoins du projet. D’excellents ouvrages traitent de ce sujet en
profondeur.
Afin d’en faire une unité de base pour la planification itérative, une formule courte et simple doit
synthétiser l’essence de chacun de ces mini-contrats fonctionnels. Nous conservons habituellement toute information relative à un contrat au dos de la carte. Elle ne prendra toute son
importance qu’à l’approche de l’itération, d’abord pour aider à l’estimation de la taille de la
story, puis pour l’écriture des tests d’acceptance qui formeront l’ensemble des objectifs
concrets et mesurables à atteindre.
2) La réponse de l’expert Laurent Bossavit, président de l’association Agile France.
Il n’existe pas de « modèle » au sens « modèle de document », car c’est précisément ce dont
eXtreme Programming se déleste. Un scénario client, c’est simplement une fiche cartonnée
portant quelques mots qui identifient une exigence, une conversation entre le client et les
développeurs, puis enfin un test de recette permettant une confirmation que l’exigence a bien
été prise en compte (ce sont les « 3 C » – carton, conversation, confirmation, de Ron Jeffries).
Pour autant, l’élaboration de la liste des scénarios client (beaucoup, peut-être la plupart,
connus en début de projet, puis certains découverts au fur et à mesure) demande de l’attention, et
des outils existent pour s’assurer de la pertinence des scénarios client envisagés.
L’acronyme INVESTrappelle les critères qui font d’un scénario client un... bon investissement :
– I pour Indépendant : lorsque le client peut en toute liberté décider de l’ordre dans lequel les
scénarios sont implémentés, sans qu’interviennent des contraintes techniques, il est plus facile
d’optimiser la valeur du projet. Bons exemples : « Je peux consulter la liste des factures émises » ;
« Je peux trier les factures par date » ; « Je peux consulter la liste des clients ». Mauvais exemples : « Créer un contrôle permettant d’afficher des listes avec tri sur une colonne quelconque » ;
« Créer la liste des factures » ; « Créer la liste des clients ».
– N pour Négociable : un bon scénario fait état d’un objectif à atteindre, les détails d’implémentation pouvant être négociés en cours de route entre clients et développeurs. Ce n’est pas une
description explicite d’une solution particulière. Bon exemple : « Je peux connaître le montant
total des factures impayées ». Mauvais exemple : « Lorsque je clique sur le bouton "Total", une
ligne est rajoutée à la liste des factures avec le montant total des impayés ». Dans le premier
exemple, les développeurs ont la latitude d’imaginer une solution plus efficace, par exemple un
calcul en temps réel.
GestProjInform Livre Page 100 Vendredi, 3. avril 2009 12:07 12