User Story vs Use Case
On m’a souvent posé la question :
C’est quoi la différence entre un use case et une user story?
La réponse n’est pas simple pour moi. Bien que la différence de concept semble claire, dans les faits, c’est plus complexe.
On révise:
Definition wikipedia:
User Story
« Une user story (histoire utilisateur) est une exigence logicielle formulée en une ou plusieurs phrases dans le langage de tous les jours ou celui lié au métier l’utilisateur. Les user stories sont utilisées dans le développement logiciel dit Agile comme spécifications (en même temps que les tests d’acceptance). Le formalisme est limité à un carte de type post-it. »
Use Case
« Un use case (cas d’utilisation) dans l’ingénierie logicielle et système est une description du comportement d’un système en réponse à une requête externe au système lui-même. En d’autres termes, le use case décrit « qui » fait « quoi » avec le système en question. La technique des use case est utilisée pour définir les exigences de comportement d’un système en détaillant les exigences fonctionnelles avec un approche scénarios. »
Wikipedia en propose même la comparaison:
« Bien que les use cases et user stories proposent tous les deux une solution de définition des exigences utilisateur en terme d’interactions entre celui-ci et le système, il y a des différences majeures entre eux.
Les user stories proposent un format léger et facile à comprendre de l’information. Elles sont la plus part du temps formulées dans le langage de tous les jours de l’utilisateur et contiennent peu de détail. Elles doivent aider le lecteur à comprendre ce que le logiciel doit faire.
Les use cases, eux, décrivent un process et le détaillent pas à pas, ils sont plus formels. Un use case doit fournir le niveau détail suffisant pour être compris seul. Un use case est décrit comme « une description générale des interactions entre le système et un ou plusieurs acteurs, les acteurs pouvant être des personnes ou d’autres systèmes. »»
(Traduction par mes soins, donc soyez indulgents et surtout vigilants.)
Bon, avec tout ça, on est bien avancé !
Dans son livre dédié à Scrum[1], Claude Aubry propose (en §13.5.5) une facette intéressante sur ce débat :
« La technique des user stories n’est pas une technique de spécification », ce en quoi il a tout à fait raison, puisque les exigences dans scrum sont définies et détaillées lors de la réunion de planification du sprint et non pas avant: cqfd.
Et « il est préférable de dialoguer… » combiné avec « rédiger des tests fonctionnels et les passer… »
On voit là bien l’approche radicalement différente, qui est plus dans le processus global de construction du projet que dans l’élément même du use case ou de la user story.
Un autre point indiqué par Claude est le fait que par définition un use case ne peut être utilisé dans un backlog, puisqu’il ne rempli pas les conditions d’entrée dans un sprint. Encore une fois, je suis entièrement d’accord, mais c’est plus discutable, en tout cas, il faut un peu plus d’expérience « agile » pour comprendre ce point. Je vais essayer d’expliquer plus clairement ce point là : Ne peuvent entrer dans un sprint que des éléments suffisamment fins au regard de la vélocité de l’équipe (Aï, aï, j’en ai perdu en route). Comme nous l’avons vu précédemment, une user story est par définition succincte et utilise un format léger, cela entraine une granularité assez fine et donc une complexité/charge relativement petite la plus part du temps. Dans le cas où une user story ne serait pas assez « fine », alors elle ne pourrait être à considérer dans le prochain sprint.
Pour les use cases, la notion de complexité/charge n’intervient jamais dans leur création. En conséquence leur niveau de granularité n’est pas adapté aux sprints. Bien sur, il est possible de découper les use cases en scenarios, puis en diagrammes d’états et ainsi avoir une granularité suffisante pour être utilisé dans un backlog. Mais on perd la vision utilisateur dans ce cas.
Je rajouterai pour ma part et pour vous aidez à faire le choix, les quelques idées et conseils suivants :
Pour moi, la vraie différence est dans la construction du logiciel lui-même.
Les use cases décrivent un système entier et déjà pre-pensé (cahier des charges, appel d’offres,…).
Les use cases ne supportent pas très bien le mode itératif, ou alors comme l’avait évoqué Pascal Roques lors de sa présentation sur la modélisation Agile (SigmaT 8), il ne faut pas avoir peur de jeter son modèle à la poubelle et ne pas chercher désespérément à le maintenir.
Les use cases à eux seuls ne servent à rien, il faut toute la suite des 13 schémas UML et outils associés.
C’est trop orienté architecture, et moi je m’en fiche de savoir si mon logiciel est en java ou en C# avec un poisson givré, un patron-java ou un flexible dans…, Je veux qu’il marche !
Les user stories sont faites pour décrire simplement la manière dont l’utilisateur pourra utiliser son logiciel. On pourra lui ajouter pleins de nouvelles fonctions super utiles, les user stories se complètent les unes aux autres, pas besoin d’un processus lourd, d’un outil de modélisation, le backlog est là (je parle de post-it, au mieux un fichier, pas d’outils de gestion de projet). Les user stories ont par définition aussi cette notion d’utilité et/ou de priorité que n’ont pas les use cases.
Je préfère l’utilisation des user stories dans le contexte de démarrage de nouveaux projets. L’aspect « quelle solution me propose mon logiciel pour faire ça » me plait pas mal, le logiciel orienté service à son utilisateur ! Plus facile pour discuter avec le client du client (SSII et sous traitance obligent) lors d’un atelier sans qu’il ait eu besoin d’apprendre UML.
Encore un point, on ne peut pas tous définir en use case :
« En tant qu’utilisateur, je veux que l’icone clignote quand je reçois un mail », vous traduisez ça comment en use case ? C’est, à la limite, une des 2000 exigences du use case « Recevoir un message »
Et puis si vous ne savez toujours pas quoi prendre, reste la solutio Mac ou Windows ?
o « Je veux acheter un nouvel ordinateur, c’est bien Max ? »
o « bein, t’as quoi pour l’instant ?
o « un pc ! »
o « Ah, et t’as du temps à perdre »
o « non ! »
o « alors reste sur pc »
Si vous avez l’habitude des use cases, gardez les, sinon
Osez le changement.
[1] Scrum, Le guide pratique de la méthode agile la plus populaire, par Claude Aubry, Edition Dunod, sur Amazon
C’est quoi la différence entre un use case et une user story?
La réponse n’est pas simple pour moi. Bien que la différence de concept semble claire, dans les faits, c’est plus complexe.
On révise:
Definition wikipedia:
User Story
« Une user story (histoire utilisateur) est une exigence logicielle formulée en une ou plusieurs phrases dans le langage de tous les jours ou celui lié au métier l’utilisateur. Les user stories sont utilisées dans le développement logiciel dit Agile comme spécifications (en même temps que les tests d’acceptance). Le formalisme est limité à un carte de type post-it. »
Use Case
« Un use case (cas d’utilisation) dans l’ingénierie logicielle et système est une description du comportement d’un système en réponse à une requête externe au système lui-même. En d’autres termes, le use case décrit « qui » fait « quoi » avec le système en question. La technique des use case est utilisée pour définir les exigences de comportement d’un système en détaillant les exigences fonctionnelles avec un approche scénarios. »
Wikipedia en propose même la comparaison:
« Bien que les use cases et user stories proposent tous les deux une solution de définition des exigences utilisateur en terme d’interactions entre celui-ci et le système, il y a des différences majeures entre eux.
Les user stories proposent un format léger et facile à comprendre de l’information. Elles sont la plus part du temps formulées dans le langage de tous les jours de l’utilisateur et contiennent peu de détail. Elles doivent aider le lecteur à comprendre ce que le logiciel doit faire.
Les use cases, eux, décrivent un process et le détaillent pas à pas, ils sont plus formels. Un use case doit fournir le niveau détail suffisant pour être compris seul. Un use case est décrit comme « une description générale des interactions entre le système et un ou plusieurs acteurs, les acteurs pouvant être des personnes ou d’autres systèmes. »»
(Traduction par mes soins, donc soyez indulgents et surtout vigilants.)
Bon, avec tout ça, on est bien avancé !
- Use case, forte connotation procédurale, merci UML
- User story, pas assez formel, mais bien testé.
Dans son livre dédié à Scrum[1], Claude Aubry propose (en §13.5.5) une facette intéressante sur ce débat :
« La technique des user stories n’est pas une technique de spécification », ce en quoi il a tout à fait raison, puisque les exigences dans scrum sont définies et détaillées lors de la réunion de planification du sprint et non pas avant: cqfd.
Et « il est préférable de dialoguer… » combiné avec « rédiger des tests fonctionnels et les passer… »
On voit là bien l’approche radicalement différente, qui est plus dans le processus global de construction du projet que dans l’élément même du use case ou de la user story.
Un autre point indiqué par Claude est le fait que par définition un use case ne peut être utilisé dans un backlog, puisqu’il ne rempli pas les conditions d’entrée dans un sprint. Encore une fois, je suis entièrement d’accord, mais c’est plus discutable, en tout cas, il faut un peu plus d’expérience « agile » pour comprendre ce point. Je vais essayer d’expliquer plus clairement ce point là : Ne peuvent entrer dans un sprint que des éléments suffisamment fins au regard de la vélocité de l’équipe (Aï, aï, j’en ai perdu en route). Comme nous l’avons vu précédemment, une user story est par définition succincte et utilise un format léger, cela entraine une granularité assez fine et donc une complexité/charge relativement petite la plus part du temps. Dans le cas où une user story ne serait pas assez « fine », alors elle ne pourrait être à considérer dans le prochain sprint.
Pour les use cases, la notion de complexité/charge n’intervient jamais dans leur création. En conséquence leur niveau de granularité n’est pas adapté aux sprints. Bien sur, il est possible de découper les use cases en scenarios, puis en diagrammes d’états et ainsi avoir une granularité suffisante pour être utilisé dans un backlog. Mais on perd la vision utilisateur dans ce cas.
Je rajouterai pour ma part et pour vous aidez à faire le choix, les quelques idées et conseils suivants :
Pour moi, la vraie différence est dans la construction du logiciel lui-même.
Les use cases décrivent un système entier et déjà pre-pensé (cahier des charges, appel d’offres,…).
Les use cases ne supportent pas très bien le mode itératif, ou alors comme l’avait évoqué Pascal Roques lors de sa présentation sur la modélisation Agile (SigmaT 8), il ne faut pas avoir peur de jeter son modèle à la poubelle et ne pas chercher désespérément à le maintenir.
Les use cases à eux seuls ne servent à rien, il faut toute la suite des 13 schémas UML et outils associés.
C’est trop orienté architecture, et moi je m’en fiche de savoir si mon logiciel est en java ou en C# avec un poisson givré, un patron-java ou un flexible dans…, Je veux qu’il marche !
Les user stories sont faites pour décrire simplement la manière dont l’utilisateur pourra utiliser son logiciel. On pourra lui ajouter pleins de nouvelles fonctions super utiles, les user stories se complètent les unes aux autres, pas besoin d’un processus lourd, d’un outil de modélisation, le backlog est là (je parle de post-it, au mieux un fichier, pas d’outils de gestion de projet). Les user stories ont par définition aussi cette notion d’utilité et/ou de priorité que n’ont pas les use cases.
Je préfère l’utilisation des user stories dans le contexte de démarrage de nouveaux projets. L’aspect « quelle solution me propose mon logiciel pour faire ça » me plait pas mal, le logiciel orienté service à son utilisateur ! Plus facile pour discuter avec le client du client (SSII et sous traitance obligent) lors d’un atelier sans qu’il ait eu besoin d’apprendre UML.
Encore un point, on ne peut pas tous définir en use case :
« En tant qu’utilisateur, je veux que l’icone clignote quand je reçois un mail », vous traduisez ça comment en use case ? C’est, à la limite, une des 2000 exigences du use case « Recevoir un message »
Et puis si vous ne savez toujours pas quoi prendre, reste la solutio Mac ou Windows ?
o « Je veux acheter un nouvel ordinateur, c’est bien Max ? »
o « bein, t’as quoi pour l’instant ?
o « un pc ! »
o « Ah, et t’as du temps à perdre »
o « non ! »
o « alors reste sur pc »
Si vous avez l’habitude des use cases, gardez les, sinon
Osez le changement.
[1] Scrum, Le guide pratique de la méthode agile la plus populaire, par Claude Aubry, Edition Dunod, sur Amazon
Exigences, validation et traçabilité
Pilotage par le contrôle
La phrase semble incohérente, « piloter par le contrôle », c’est comme finir avant d’avoir commencer, et pourtant c’est ce que nous faisons depuis longtemps.
Les mécanismes du cycle en V sont fondés sur le contrôle et le suivi de projet, pas du produit. C’est assez comique de voir comment un processus normalement fabriqué pour avoir de la visibilité, n’en apporte en fait aucune, il faudra attendre la fin pour voir si le logiciel produit répond aux besoins du client (et surtout du marché). RUP non plus n’apporte pas grand-chose de plus à mon sens, il n’a que découper dans le temps ce principe là, mais la trame reste, voir la phase de construction.
En cycle en V, les exigences et les scénarios de tests sont gérés par 2 processus bien séparés.
La phrase semble incohérente, « piloter par le contrôle », c’est comme finir avant d’avoir commencer, et pourtant c’est ce que nous faisons depuis longtemps.
Les mécanismes du cycle en V sont fondés sur le contrôle et le suivi de projet, pas du produit. C’est assez comique de voir comment un processus normalement fabriqué pour avoir de la visibilité, n’en apporte en fait aucune, il faudra attendre la fin pour voir si le logiciel produit répond aux besoins du client (et surtout du marché). RUP non plus n’apporte pas grand-chose de plus à mon sens, il n’a que découper dans le temps ce principe là, mais la trame reste, voir la phase de construction.
En cycle en V, les exigences et les scénarios de tests sont gérés par 2 processus bien séparés.
Les exigences sont faites pour satisfaire le niveau supérieur. En parallèle, des tests sont décrits pour contrôler ce niveau d’exigence. Il n’y a pas de lien, ni de vérification entre les différents niveaux de tests.
Par définition, les tests sont écrits après les spécifications. Ce qui fait que les tests ne sont connus et utilisés que sous forme contrôle à posteriori. Les tests sont une sanction.
Les exigences, majoritairement écrites sous forme documentaire, voir avec des outils de type Doors, ne peuvent que retranscrire le comportement statique du besoin. La spécification s’apparente la plus part du temps à un catalogue de règles de gestion, qui pense-t-on, mises bout à bout, vont produire un logiciel.
A l’inverse, les scénarios de tests décrivent l’aspect dynamique et cinématique du besoin : L’approche opérationnelle. Ce que l’utilisateur réel va vraiment pouvoir faire.
Encore une fois, les tests étant fournis après comme contrôle du travail fini, les équipes de développement n’ont donc que l’aspect statique et ne connaissent pas le mode opératoire du logiciel qu’ils sont en train de produire.
Le développement est donc piloté par la seule information à caractère statique de se que sera le logiciel et sera sanctionné par un contrôle à postériori.
C’est le pilotage par le contrôle. Incohérent par nature !
La réponse Agile est : « Test first »
La aussi, ce que l’on reproche aux méthodes Agiles est leur manque visibilité à long terme. Et c’est heureusement là qu’elles pourraient bien au contraire vous surprendre.
La grande différence réside dans la construction du backlog.
En agile, nous utilisons les user stories : Une définition succincte mais précise des possibilités offertes à l’utilisateur, leur moyen de vérification, ainsi que les critères d’acceptance. Dans ce cas, les scénarios de tests sont fournis comme (seuls ou en complément) des spécifications en entrée de sprint. Des exigences plus fines de type règles de gestion peuvent être définies au cours de la réunion de planification de sprint.
Le développeur est ainsi « formé » à l’utilisation de ce qu’il va produire. Il connait les objectifs à atteindre. La chaine de construction se répète tout au long du process jusqu’à l’écriture du code de test avant le code lui-même (TDD), qui participe au maintient de la qualité du logiciel (Intégration continue, tests automatisés).
L’approche est donc radicalement différente.
Agile propose un pilotage par les objectifs.
Traçabilité passive vs active.
Le cycle de production des exigences et des tests est par construction séparé et disjoint dans le temps.
Le lien entre les deux process est la traçabilité. Traçabilité « active », puisqu’il faut à chaque étage tirer les liens des éléments avals vers ceux amonts. Il n’y a pas moyen de savoir à priori combien d’exigences avales vont être nécessaires pour couvrir celle amont. D’où, je pense, une inutilité sur ce point de la matrice de traçabilité, puisque même si la matrice montre qu’une exigence amont est liée par une ou plusieurs exigences avales, rien ne garantie que la couverture est totale. Pour cela, il faudra faire une relecture.
A la différence, le mécanisme de construction du backlog (Feature è user story è tâche) peut s’apparenter à une décomposition hiérarchique et arborescente du besoin et propose une traçabilité « passive ». Le backlog (et ceux des sprints) est auto suffisant. Chaque niveau est produit en réponse au niveau supérieur, le nombre d’éléments du niveau inférieur est connu à l’avance (en début de sprint, avant l’implémentation).
En utilisant les outils appropriés (Type Eclipse Mylyn), cette traçabilité peut aller jusqu’aux pièces de code, sans que le développeur ne se rende compte qu’il est en train de faire de la traçabilité. C’est la traçabilité passive.
Le backlog sert au pilotage du projet, à sa construction, à son suivi, sert aussi de release note. C’est n’est pas qu’un outil de suivi de projet, c’est bien le référentiel des exigences, référentiel structuré.
L’agilité en combinant « pilotage par l’objectif » et « traçabilité passive », vous permet donc de savoir quels sont les éléments définis du produit à réaliser, quels sont ceux produits validés, ceux encore à produire. Avec en plus une grande souplesse dans le changement, pour s’adapter aux besoins du client et du marché.
Buzz l'Eclair
Elle est facile, je sais, mais que voulez –vous ? J'ai gardé une âme d'enfant
Google fait son buzz, un savant mélange de blog, twitter, google group, mailing list, spam!
Blog en mode push
Plus besoin d'un reader et d'attendre qu'un lecteur veuille bien se tenir au courant des petits malheurs de votre vie.
Là, c'est comm directe, à peine buzzé, déjà dans votre boite mail. Google a su faire d'une boite mail un rss reader.
Twitter, en seulement 1 journée d’utilisation, 6 buzzs sans rien demander, pareil que twitter !
Google group et mailing list dynamiques.
Là, c'est comm directe, à peine buzzé, déjà dans votre boite mail. Google a su faire d'une boite mail un rss reader.
Twitter, en seulement 1 journée d’utilisation, 6 buzzs sans rien demander, pareil que twitter !
Google group et mailing list dynamiques.
Buzz vous propose par défaut les personnes avec lesquelles vous communiquez le plus, en mail, en chat.
Il permet aussi d'agréger vos billets (blogger), vos twits (twitter), vos photos (flickr, picassa, prochainement)
Faux vrai Spam.
Il permet aussi d'agréger vos billets (blogger), vos twits (twitter), vos photos (flickr, picassa, prochainement)
Faux vrai Spam.
Vrai, puisque par définition c'est du push. Faux, la différence, est que vous pouvez vous gérer vos abonnements, les vôtres, mais aussi ceux qui se sont abonné à votre buzz.
C'est vous qui décidait, tiens, c'est très Agile spirit ça! Ça me plait.
Et cerise sur le gateau, pour les geeks, buzz fonctionne déjà sur IPhone. En même temps IPhone et Buzz, même combat ;-).
Bon, comme toujours, il a quelques défauts de jeunesse. Problème de confidentialité relevé (NouvelObs). Mais qui a dit qu’internet été privé !!!! Faut juste s’en servir correctement.
Tout ça ressemble fortement à Google Wave, mais là où wave n'a pas réussi, je gage fort que Buzz y arrivera, tout simplement, parce qu’il utilise la boite mail! Tiens bizarre, la page about de google wave est 404-Not found ?
A plus pour un nouveau buzz!
C'est vous qui décidait, tiens, c'est très Agile spirit ça! Ça me plait.
Et cerise sur le gateau, pour les geeks, buzz fonctionne déjà sur IPhone. En même temps IPhone et Buzz, même combat ;-).
Bon, comme toujours, il a quelques défauts de jeunesse. Problème de confidentialité relevé (NouvelObs). Mais qui a dit qu’internet été privé !!!! Faut juste s’en servir correctement.
Tout ça ressemble fortement à Google Wave, mais là où wave n'a pas réussi, je gage fort que Buzz y arrivera, tout simplement, parce qu’il utilise la boite mail! Tiens bizarre, la page about de google wave est 404-Not found ?
A plus pour un nouveau buzz!
Noël en février, Scrum en cadeau et en Français
Ce matin, il a neigé sur Toulouse pour la troisième fois de l’année. Pour confirmer se sentiment d’être à Noël. J’ai eu le plaisir de recevoir un exemplaire du livre de Claude Aubry en cadeau.Le livre « Scrum – Le guide pratique de la méthode agile la plus populaire » a fait sa sortie officielle hier 10 février 2010. Le livre est préfacé par François Beauregard de chez Pyxis à Montréal.
Outre l’explication détaillée et illustrée (à peu prés une image toutes les 2 pages) en français de cette (fabuleuse) méthode. Claude s’appuie sur de nombreux retours d’expérience pour étayer son propos. Et après une explication des pratiques, replace ces pratiques dans un processus plus global de pilotage de projet, planification, validation, suivi de projet.
Un chapitre qui plaira sans aucun doute à nos chers (chers ?) qualiticiens, « Estimations, mesures et indicateurs ». Un des succès présenté lors du dernier Agile Tour 2009 à Toulouse.
Le livre nous propose aussi un chapitre complet sur l’adaptation de la méthode au contexte, et sur le processus de transition à Scrum.
A lire absolument pour comprendre que Scrum n’est pas juste la nouvelle méthode à la mode, mais bien une réponse concrète aux besoins de nos clients.
Pour info et recherche :
« Scrum – Le guide pratique de la méthode agile la plus populaire »
Claude Aubry
Chez DUNOD (www.dunod.com)
ISBN 978-2-10-054018-1
Association SigmaT V2
L'association SigmaT entre dans sa deuxième année.
"La SigmaT, association à but non lucratif qui fédère les agilistes toulousains et du sud-ouest, se diversifie pour sa deuxième année d'existence officielle.
Les séminaires, qui ont accueilli des centaines de personnes, continuent tous les trimestres. Le prochain (le 13ème) est pour le 19 mars." Claude Aubry
SigmaT propose un séminaire tous les trois mois, et cerise sur le gâteau, l'Agile Tour.
L'association dispose maintenant de locaux à la Maison de Associations
Adresse: Rue Saint-Roch, 31400 Toulouse, Haute-Garonne, Midi-Pyrénées, plan
Elle y propose des ateliers (1 par mois, sauf mois du séminaire) ainsi que des permanences (tous les lundis de 17h30 à 20h).
Déjà deux ateliers ont eu lieu:
ou en suivant ce lien :
ou encore mieux, en l'ajoutant à votre Google Agenda, en cliquant sur le bouton en bas à droite de l'agenda
"La SigmaT, association à but non lucratif qui fédère les agilistes toulousains et du sud-ouest, se diversifie pour sa deuxième année d'existence officielle.
Les séminaires, qui ont accueilli des centaines de personnes, continuent tous les trimestres. Le prochain (le 13ème) est pour le 19 mars." Claude Aubry
SigmaT propose un séminaire tous les trois mois, et cerise sur le gâteau, l'Agile Tour.
L'association dispose maintenant de locaux à la Maison de Associations
Adresse: Rue Saint-Roch, 31400 Toulouse, Haute-Garonne, Midi-Pyrénées, plan
Elle y propose des ateliers (1 par mois, sauf mois du séminaire) ainsi que des permanences (tous les lundis de 17h30 à 20h).
Déjà deux ateliers ont eu lieu:
- Business Value Game (Jeux de la Valeur Ajoutée)
- XP Game.
ou en suivant ce lien :
ou encore mieux, en l'ajoutant à votre Google Agenda, en cliquant sur le bouton en bas à droite de l'agenda
Inscription à :
Articles (Atom)
