Posté par jc-Qualitystreet le 9 novembre 2009
Les « User Stories » sont de plus en plus utilisées sur les projets Agiles, et c’est une très bonne chose.
Leur simplicité, leur orientation à la fois « But Utilisateur » et « Valeur Business », ainsi que le focus immédiat sur les critères d’acceptation les rendent en effet terriblement efficaces pour les projets de conception.
Une fois la règle des 3 C assimilée (Carte, Conversation et Confirmation) et les critères INVEST bien décrits, quand les équipes et le Product Owner commencent à découvrir les stories, ils me demandent souvent si le format « User Voice » doit être respecté …
Ce format c’est le fameux :
En tant que < Rôle d’utilisateur >,
Je peux < But >,
Si bien que < Justification >
Un format au sein duquel,
- Le rôle représente celui qui fait l’action et qui en bénéficie
- Le but représente l’action accomplie
- La valeur Business représente les bénéfices qui se dégagent de l’action
Alors, doit-on utiliser ce format ? Ma réponse est sans équivoque OUI !
- Le format “User Voice” donne du sens à la fonctionnalité… pour qui et pourquoi l’équipe va la développer
- Il permet de se rapprocher d’une démarche expérience utilisateur, et notamment Personas. Le rôle c’est notre Persona, une vision concrète, réaliste et partagée de l’utilisateur final.
- Il est clairement orienté ACTION et BUT (démarche de conception le plus efficace)
- Il justifie toutes les fonctionnalités d’un point de vue Business, et oblige le Product Owner et les équipes à s’interroger systématiquement sur la valeur de chaque fonctionnalité
Mon conseil : Donnez un titre à la User Story (court et signifiant), et décrivez là ensuite au format « User Voice » !
Posté par jc-Qualitystreet le 11 août 2009
Le Story Map est l’un des éléments forts que j’ai retenus de ma dernière certification Product Owner, délivrée par Arlen Bankston (LithtSpeed).
Jeff Patton - Story Map - http://agileproductdesign.com
Intégré à un large radiateur d’informations, le User Story map est une dose supplémentaire d’UX (user Experience) dans votre projet Scrum, le complément idéal, voire indispensable de votre Backlog de produit.
Contrairement au Backlog de produit, le Story Map est multidimensionnel, plus visuel et plus collaboratif notamment au moment de sa construction.
Les règles sont simples:
- Le User Story map représente donc le backlog de produit
- Il est lié aux Personas, placés sur la gauche du Story Map
- Il se lit sur 2 axes:
- Horizontal, l’axe temporel - séquences d’action, que les ergonomes et les analystes apprécieront puisqu’il se fonde sur les analyses de l’activité et analyses métier
- Vertical, l’axe priorité, qui servira à définir quelles User Stories seront retenues sur la release ou sur le sprint
- Les grandes activités sont placée au dessus sur une ligne horizontale (les post it jaunes sur la photo qui suit), puis sont décomposées en User Stories (les post it bleus).
- Les User Stories sont affichées en colonne sous l’activité dont elles dépendent et classées par priorité. La User Story la plus nécessaire à la réalisation de son Activité est placée le plus haut, les autres suivront par ordre d’importance (on peut se réfèrer au modèle de Kano pour le déterminer). Une décomposition trés fine et le respect des critères INVEST pour les User Stories est plus que souhaitable
Jeff Patton - Story Map - http://agileproductdesign.com
Avec le Story Map, vous avez :
- Des user Stories enfin liées les unes aux autres (c’était une vraie lacune de la technique des User Stories jusqu’alors)
- L’association de toute une séquence d’actions et d’un Persona
- Un point d’entrée évident vers d’autres livrables Ux, type Storyboards…
- Une représentation concrète des flux et des séquences dans une approche très orientée Utilisateurs
- Une véritable aide à la priorisation qui met l’accent sur les fonctionnalités nécessaires à la réalisation d’une activité
Bref, un Backlog de produit plus performant, un découpage des sprint et des release plus aisé, et une meilleure appropriation des backlogs (souvent indigestes) par les équipes.
Le User Story Map fait enfin VIVRE le Backlog aux yeux de tous!
Posté par jc-QualityStreet le 16 février 2009
User Stories et Use Cases (cas d’utilisation) sont deux façons très populaires de capturer les besoins utilisateurs (exigences fonctionnelles).
Toutes deux sont orientées BUT, plutôt centrées Utilisateurs, sont découvertes au cours d’ateliers de travail et peuvent être admirablement combinées avec les activités Expérience Utilisateur (Personas, Storyboard, Wireframe …).. WAIT! There is more to read… read on »
Posté par jc-QualityStreet le 25 août 2008
Une User story est une exigence du système à développer, formulée en une ou deux phrases dans le langage de l’utilisateur. Les User Stories émergent au cours d’ateliers de travail menés avec le Métier, le Client ou les Utilisateurs.
Quelques Exemples :
“En tant que recruteur, je peux déposer des offres d’emploi”; “En tant qu’utilisateur, je peux réserver une chambre d’hôtel”; ” En tant utilisateur, je peux annuler une réservation”; “En tant que jeune diplômé, je peux créer un CV”; “En tant que jeune diplômé je peux supprimer un CV”; “En tant que jeune diplômé je peux modifier un CV”…
WAIT! There is more to read… read on »
Posté par jc-QualityStreet le 5 octobre 2007
N’oubliez pas qu’un cas d’utilisation est avant tout TEXTUEL, et n’associez donc pas aussi radicalement ce cas d’utilisation (Use Case) au diagramme UML: privilègiez plutôt la démarche.
En effet, se lancer dans la rédaction des cas d’utilisation, pour décrire un besoin fonctionnel (spécifications), c’est se lancer dans une véritable démarche d’analyse, progressive, parfois lente, parsemée d’ateliers de travail, d’entretiens …
C’est aussi adopter une vraie réflexion en termes d’utilisateurs (acteurs), de buts et de tâches.
Croyez-moi, c’est bien là l’essentiel.
Le diagramme des cas d’utilisation UML (« Use Case diagram ») est quant à lui trés précieux pour bénéficier d’une vue globale sur l’application; il permet de visualiser immédiatement les liens entre acteurs et cas d’utilisation, ou encore de délimiter explicitement les différents packages. « Modéliser graphiquement » est un principe du Processus Unifié (ceci dit toujours fonction des destinataires), donc le diagramme des Use Cases ne doit pas absolument pas être négligé !
Pour ma part, ce n’est pourtant pas le diagramme qui m’a séduit …
j’ai découvert les cas d’utilisation en 2000 quand j’étais consultant au Luxembourg et j’ai très rapidement perçu, en les construisant (et grâce à de bons mentors), la forte complémentarité à la fois avec la démarche Ergonomique (profil utilisateurs, réflexion sur les buts et scénarios, UCD …) et avec les activités, livrables de l’Ergonome ou Designer d’interaction (Personas, Storyboard, Diagramme de Tâches, Wireframes).
Le fait que les cas d’utilisation se focalisent seulement sur le Quoi (Fonctionnel et Métier) _c’est une règle d’or_, sans décrire les éléments d’interfaces (Ecrans et enchaînement), laissés aux spécialistes de l’IHM, est aussi un élément que j’ai beaucoup apprécié, selon moi un vrai point fort.
Modéle générique de cas d’utilisation
Donc, depuis tout ce temps, j’évangélise … en insistant principalement sur 6 points :
- La démarche de découverte et de construction progressive des cas d’utilisation: l’essentiel …
- La forte adéquation avec le développement itératif (dans l’estimation, la priorisation, la planification, le traitement)
- La complémentarité avec le travail de l’Ergonome
- La lisibilité, le formalisme des cas d’utilisation (élément clé de son efficacité et de son acceptation par les équipes)
- La gestion des modifications (pas si simple que ça!)
- Le lien fort avec les cas de tests et une approche de validation fonctionnelle (c’est l’idéal!)
… Et je recommande toujours « Rédiger des cas d’utilisation efficaces », d’Alistair Cockburn, la référence que je conseille à tous ceux qui souhaitent s’attaquer à l’analyse système ou mètier.
Enfin, même si aujourd’hui je me retrouve davantage dans les User stories, je reste convaincu de la pertinence des cas d’utilisation dans pas mal de contextes … quand ils sont bien rédigés 
