lundi 11 mars 2013

Spécifications Agiles : User Story ou pas User Story

En Scrum, les spécifications sont abordées par la constitution du Backlog Produit. Il est alors courant d'utiliser des User stories. Mais au fait, qu'est-ce que c'est exactement qu'une User Story ? Et en quoi celle-ci se différencie t'elle d'autres méthodes d'expression du besoin telles que les Use Case, ou les Requirements ?

Je vous propose ici de voir plus en détail cet objet étrange qu'est l'histoire utilisateur, et de la comparer à d'autres approches pour réaliser des spécifications Agiles.


User Story

Une User Story est l'expression d'un besoin utilisateur. Elle est simplement constituée d'une phrase de description qui exprime un besoin avec une vue utilisateur. Cette phrase sert de support à la discussion, elle est complétée d'un ensemble de conditions d'acceptation qui en définissent le périmètre exact du besoin.
Les objectifs d’une User Story sont les suivants :
  • Etre un support de communication. Pour cela elle ne sera pas trop détaillée.
  • Etre compréhensible par toute l’équipe (technique et fonctionnel). Pour cela on n’utilisera pas des termes trop techniques, et on préférera le langage de l’utilisateur à celui du développeur.
  • Etre support de pilotage de l’avancement du projet. Pour cela on préférera les histoires de petite taille.
L’expression d’une User Story respecte en général le formalisme suivant :
En tant que <rôle de l’intervenant> je veux <description du besoin> dans le but de <objectif de la demande>
Ce formalisme permet de s’assurer que les points principaux ont été réfléchis, à savoir :
  • qui est le demandeur principal du besoin ?
  • Quelle est la demande ?
  • Dans quel but fait-on cette demande ?
comme un exemple vaut toujours mieux qu’un long discours, voici une illustration de ce que peut être une User Story :
User Story en tant que vacancier, je veux pouvoir donner une évaluation de l’hôtel que j’ai réservé sur le site dans le but d’enrichir la base des avis
Condition d’acceptation
  1. l’utilisateur doit pouvoir saisir un commentaire de 500 caractères
  2. l’utilisateur doit  obligatoirement  donner une note sur 10
  3. l’utilisateur doit pouvoir joindre des photos
  4. Le commentaire doit être visible sur la fiche de l’hôtel

Investir ses User Stories

Pour pouvoir être considéré comme "User Story" un besoin utilisateur doit autant que possible respecter un certain nombre de contraintes rassemblées sous la dénomination mnémotechnique INVEST
Indépendante
Le critère le plus difficile à respecter. Toutes les User Stories du backlog doivent être autant que possible indépendantes les unes des autres. En effet pour garder toute sa souplesse au Backlog Produit, nous ne devons pas conditionner une la réalisation d'une User Story à l’existence préalable d'une autre User Story.
Négociable Une User story doit rester ouverte à la discussion jusqu’à la fin de sa réalisation. Ceci veut dire qu'une user story est une base de discussion, et qu'on s'autorise à la faire évoluer en fonction de besoin afin de trouver la meilleure implémentation possible de besoin initial. Cela en vue de la simplification des besoins techniques et d'une meilleure satisfaction client.
Valorisable Il doit être possible de donner une valeur métier à toute User Story. Ceci signifie que toute User Story doit être compréhensible et avec un sens pour un utilisateur final. De ce fait, toute expression technique sort du scope de la User Story.
Estimable Le périmètre de la User Story doit être suffisamment défini pour pouvoir la chiffrer (ou l'estimer).
Suffisamment petite (Small)
La granularité de la User Story doit être faible. Il faut que l'équipe soit en mesure d'embarquer un minimum de 4 à 5 User Stories par sprint. En effet en Scrum le décompte de l'avancement du projet se fait sur des éléments finis, si l'équipe n'embarque qu'une User Story dans son sprint, et qu'elle la termine à 90%, l'avancement sera considéré comme nul, ce qui n'est pas la vérité.
Testables Les User Stories doivent être testables par un utilisateur. Ceci peut avoir un sens très différent en fonction du type d'application, mais cela reste très lié au fait que la User Story doit avoir une valeur métier et donc rendre un service à l'utilisateur.

 

 

User Story vs Use Case

Un Use Case est la description d’une suite d’interactions entre un acteur et le système. Ces interactions sont décrites sous forme d’un scénario principal (séquence d’interactions entre l’acteur et le système pour rendre un service fonctionnel), et d’un ensemble de scénarios alternatifs.
Exemple :
Nom Création de comptes
Acteur internaute
Pré condition l’internaute doit être nouveau sur le site et ne pas avoir de compte
Résultat attendu un compte doit être créé pour permettre à l’internaute d’accéder à toutes les parties du site
Scénario principal
  1. l’acteur clique sur le bouton de création de compte
  2. le système affiche un formulaire
  3. l’acteur saisi les éléments du formulaire
  4. le système vérifie que l’adresse mail est bien formée
  5. le système envoie un mail de confirmation à l’acteur
  6. L’acteur clique sur le lien dans le mail
  7. Le système valide la création du compte
  8. Le système envoie un site mail de bienvenue
Scénarios alternatifs       4a. le système détecte une erreur dans le mail
             4a.1. le système affiche à nouveau le formulaire en surlignant en rouge la zone du mail
      6a. L’acteur ne clique pas sur le lien du mail
             6a.1. 24 heures après l’envoi du mail le mail de rappel est envoyé
             6a.2  48 heures après l’envoi du mail la création du compte est annulée 
Ce qui ressort de cet exemple, c’est qu’un Use Case est bien une description du besoin exprimé avec une vue utilisateur, comme pour les User Stories. Par contre la granularité n’est pas du tout la même. Un Use Case est beaucoup plus gros qu’une User Story. A titre d’exemple on aurait pu avoir les User Stories suivantes pour couvrir le périmètre de ce Use Case :
  • En tant que nouveau visiteur du site, je veux pouvoir créer un compte en saisissant mon nom et mon prénom dans le but d’accéder aux parties protégées du site
  • En tant qu’administrateur du site, je veux que les adresses mail soient vérifiées dans le but de garantir la communication entre l’administrateur est les internautes enregistrés.
  • En tant que nouvel utilisateur du site, je veux recevoir un mail de confirmation quand mon compte est crée et opérationnel dans le but de m’assurer de la fin du processus de création
  • En tant qu’administrateur, je veux que les comptes non validés soient supprimés après un certain délai dans le but de ne garder que les informations des internautes actifs.
Un autre point que l’on peut voir ici, est que le Use Case fait apparaître très tôt des éléments d’interface ou des choix sur la façon dont les choses sont faites. Alors que les User Stories laissent la place à la discussion avec les développeurs. C’est particulièrement le cas avec la validation de l’adresse mail. Dans les User Stories on dit simplement que le mail doit être validé sans dire comment. Dans les Use Cases, on précise toute l’interaction et donc la façon de faire.
En conclusion, les Use Cases propose une façon de décrire un besoin avec une vue utilisateur, mais le niveau de granularité peut poser des problèmes dans le cadre de leur utilisation dans des processus Agiles
  • Il est difficile de les utiliser pour faire le suivi de l’avancement, car ils sont de taille trop importante
  • Il demande de se poser très tôt des questions sur le comment faire, ce qui réduit les interactions avec l’équipe



User Story vs Requierement

Contrairement aux User Stories, la méthode des requirements ne définit pas le logiciel par rapport à une vision utilisateur, mais par rapport à ce que doit faire le système.

Nous allons donc trouver une expression du besoin qui sera de la forme
Le système doit ...
Cette approche présente certains inconvenants :
  • La description de l’application peut être très lourde à rédiger, et à lire…
  • On a des difficultés à rassembler les exigences de façon logique et cohérente.
  • Sans avoir une vision globale de toutes les exigences, il est possible d’avoir de grosses incompréhensions
Concernant le dernier point, Mike Cohn donne un exemple assez marquant dans son livre “User Stories Applied” :
Soit le système suivant défini avec des requirements :
  • Le système doit avoir un moteur à essence  
  • Le système doit avoir 4 roues
  • Le système doit avoir un volant pour le diriger
A ce stade tout le monde doit commencer à se représenter mentalement une voiture. Le système est défini de façon très précise laissant peu de part à l’échange et la négociation. En effet, le moteur est à essence, pas de place pour le diésel, ou l’électrique on a exactement 4 roues… De toute façon on ne sait pas à quoi l’utilisateur va s’en servir, cela coupe donc court à toute discussion.
Avec ce type d’expression, nulle part on n’exprime pourquoi l’utilisateur a besoin de ce système. Avec des User Stories, ce même système aurait été exprimé comme ceci
  • En tant que jardinier, je veux pouvoir tondre ma pelouse
  • En tant que jardinier, je veux  pouvoir tondre des grandes surfaces sans effort
Et là… on constate qu’avec une vision du besoin de l’utilisateur l’éclairage est complètement différent. Avec les requirements nous allions fournir une voiture à notre utilisateur alors que ce qu’il voulait c’était une tondeuse à gazon.
Bien sûr ceci n’est qu’un exemple, mais il montre bien qu’une vision utilisateur est primordiale à la bonne compréhension. Sans cette compréhension, le besoin d’avoir une vision globale de tous les requierments est primordial, au risque de faire de grosses erreurs d’interprétation. Malheureusement, cette vision globale est très difficile à avoir, à cause du volume important des documents nécessaires et à la difficulté de les organiser.
 

Références

Livre "User Stories Applied
Vous pouvez compléter la lecture de cet article par le très bon bouquin de Mike Cohn "User Stories Applied".

1 commentaire:

  1. Article très intéressant, mais attention, votre vision de la discipline "requirements/exigences" est trop restrictive. En ingénierie des exigences, il y a la notion d'exigences utilisateur (qui peut être proche des US ou des CU) et la notion d'exigences système (celle que vous décrivez lors de la comparaison US / Requirements). Les normes IEEE /ISO-CEI donnent des définitions distinctes de ces deux notions. De même, la structuration de la documentation des exigences est également un point essentiel.

    RépondreSupprimer

N’hésitez pas à laisser des commentaires, pour faire part de retours d’expériences sur le sujet, pour exprimer votre accord ou votre désaccord, ou tout simplement pour poser une question. C'est toujours avec plaisir que je vous répondrai.