User stories, Use cases : les différences

Posté par jc-QualityStreet le 30 mars 2007

MàJ: Un bon récap et le TABLEAU SYNTHETIQUE DES DIFFERENCES dans ce billet Use Case vs User Story

“User stories” (c’est à dire “Récits d’utilisateurs” ou plutôt “Histoires d’utilisateur“ comme le suggère Claude Aubry) et “Use cases” (”Cas d’utilisation”) ont des similitudes (mon précédent billet, “Use cases, User Stories ? “) mais aussi de réelles différences qui, en fonction de notre contexte, vont nous permettre d’opter pour l’une ou l’autre de ces deux techniques de spécification des exigences fonctionnelles:

• “User stories” et “Use cases” n’ont pas la même portée, n’ont pas le même niveau de détail. Une “User story” s’écrit en une courte phrase (Rôle -> But) alors que le “Use case” est beaucoup plus riche en informations. Il possede un Titre (le but), est liè à un Acteur, propose un Résumé, et surtout, décrit un Déclencheur, un Scénario nominal (séquence d’actions de 3 à 9 étapes), les Variations à ce scénario nominal (à toutes les étapes), ainsi que tous les Cas d’erreur et leur mode gestion. Il peut décrire aussi les règles metiers et les données.
• Une “User story” propose donc uniquement un but, pas une séquence d’actions.
• Une “User story” correspond souvent et seulement à l’un des scénarios (nominal ou alternatif) du “Use case”.
• Une “User story” ne nécessite pas un travail d’analyse aussi poussé que le “Use case” (spécification mais aussi gestion, une activité trop souvent sous estimée).
• Les “User stories” émergent plus rapidement (en 1 ou 2 ateliers de travail).
• Les “User stories” se lisent plus facilement d’autant que les “Use cases” sont souvent mal écrits ou mal présentés.
• Les “User stories” sont rédigées (en principe) sur des cartes: leur durée de vie est limitée et elles n’ont pas pour vocation à être conservées (contrairement aux “Use cases”). Or, ce besoin de traçabilité peut être réel.
• Les “User stories” reposent sur un mode oral, collaboratif, de proximité : elles sont discutées (Customer / Developer) et tout n’est pas rédigé (contrairement aux “Use cases”). Or ce besoin de formalisme peut lui aussi être réel (gros projets, équipe importante, offshore…).
• Les “User stories” contiennent d’entrée des tests d’acceptation (rédigés au dos de la carte); les “Use cases” sont une base solide et efficace pour les tests fonctionnels mais ceux-ci sont réalisés plus tard et ailleurs.
• Une “User story” doit être implémentée et testée en une itération. Un “Use case” peut être traité sur plusieurs itérations (scénario nominal sur une, scénarios alternatifs sur une autre) en fonction des risques à lever.
• “Use cases” ou “User stories” : le choix va impacter le mode d’estimation et de planification du projet (”Technique des points de cas d’utilisation” / “Points d’histoire d’utilisateur et vélocité d’une itération”).
• Les relations entre “User stories” ne sont pas toujours évidentes; le problème est moindre pour les “Use cases” grâce notamment au diagramme de cas d’utilisation (qui accompagne les “Use cases”), et aux notions de package, inclusion, extension.
• Enfin, les “User stories” sont issues de l’univers “Extreme programming” alors que les “Use Cases” sont intimement liés au “Processus Unifié“. L’usage de telle ou telle technique sera donc aussi fonction de la méthode de développement utilisée: UP, RUP, XP, SCRUM…

Use cases, User stories ?

Posté par jc-QualityStreet le 26 mars 2007

MàJ: Le comparatif sous forme de tableau synthétique dans ce billet Use Case vs User Story

Ou plutôt Cas d’utilisation (pratique Processus Unifié, UP), Récits d’utilisateur (pratique Extreme Programming, XP) ?… la question se pose car il s’agit de deux modes de représentation des exigences (fonctionnelles) utilisées dans le cadre des Méthodes Agiles.

J’ai toujours utilisé (moi même rédiger, former, et exploiter) les Cas d’utilisation (MàJ du 08/11/2007: des conseils de rédaction, un modèle et le lien avec UML dans ce billet Cas d’utilisation UML … oui mais… ).

Bien rédigés, ils complètent idéalement le travail que je peux produire pour les utilisateurs, concepteurs et développeurs sur un projet. Mais je réfléchis, comme pour SCRUM (cf. “UP et une dose de SCRUM”) à ce que je pourrais tirer des “User Stories“.
Soyons clairs, les “Use Cases” me semblent plus adaptés à la plupart des projets sur lesquels j’interviens (projets et problématiques métiers importants, taille de l’équipe moyenne, nécessité de formalisation, équipe sur deux sites et Offshore envisagé) mais pour certains projets (délais courts, “métier connu“, équipe réduite, client disponible), les “User stories”, plus concis, allant à l’essentiel et plus rapidement écrits pourraient s’avérer plus appropriés; j’ai déjà quelques idées…

Une “User story” est une exigence du système à développer, formulée en une ou deux phrases dans le langage de l’utilisateur.

Exemples de “User stories”: “En tant qu’utilisateur, je peux réserver des chambres d’hôtel”, “En tant que recruteur, je peux déposer des offres d’emploi”.
Ron Jeffries utilise les 3 C pour la décrire:

• Card (l’histoire est courte et écrite sur une carte 8×13 cm)
• Conversation (les détails de l’histoire sont discutés)
• Confirmation (l’histoire est confirmée par des tests d’acceptation rédigés au même moment que celle-ci, au dos de la carte).

Un “Use case” modélise un sevice rendu par le système. Il représente un ensemble de séquences d’actions qu’un système ou toute autre entité peut accomplir en interagissant avec les acteurs du système.

Exemples d’intitulés de “Use cases”: “S’authentifier”, “Rechercher un livre”. Ces titres ne sont qu’une partie du “Use Case” qui comporte d’autres parties (Acteur, Résumé, Déclencheur, Scénario principal, Extensions…). Un “Use Case” est donc plus détaillé, et nécessite un travail approfondi d’analyse et de formalisation.

Alors pourquoi cette réflexion ? d’une part, comme je le disais, j’ai le sentiment que certains contextes se prêtent mieux aux “User Stories“, d’autre part “User stories” et “Use cases” se rejoignent sur beaucoup de points (pour les différences, consulter ce billet):

• “User Stories” et “Use Cases” formalisent les besoins utilisateurs et sont orientés “But”
• Ils font facilement l’objet d’ateliers de travail avec les utilisateurs pour les découvrir, les expliciter
• Ils vont être priorisés et vont ainsi guider les développements
• Ils mettent en avant les rôles, les différents profils d’utilisateurs
• Ils ne traitent que des exigences fonctionnelles (les aspects “non fonctionnels” sont décrits dans “les exigences non fonctionnelles” (contexte UP) et dans les “Constraints Cards” (contexte XP))
• Ils sont textuels et obéissent à des régles de construction trés précises (Travaux de Rachel Davis, ou critères “INVEST” pour les “User Stories”)
• Ils ne traitent pas des aspects interface et ergonomie (détails abordés dans les exigences d’ergonomie (contexte UP), livrables d’ergonomie, prototypes (contextes UP et XP))
• Ils peuvent être rédigés par les analystes (pour les UC c’est conseillé; pour les “User Stories“, c’est plutôt l’utilisateur ou un membre de l’équipe Client, composée de ceux qui vont s’assurer que le produit répond aux besoins des utilisateurs, c’est à dire Utilisateurs eux-mêmes, Directeur de produit, Analyste ou encore Ergonome)
• Ils ont chacun leur auteur et ouvrage de référence (Alistair Cockburn, “Rédiger des cas d’utilisation efficaces“, Mike Cohn, “User Stories Applied For Agile Software Development“).

Dans un prochain billet, j’aborderai les différences majeures entre “Use Cases” (Cas d’utilisation) et “User Stories”, ce qui me permettra de détailler davantage leur mode de construction et d’envisager l’impact de telle ou telle technique notamment en terme de Qualité Logiciel.

Rédiger des cas d’utilisation efficaces (Livre)

Posté par jc-QualityStreet le 21 mars 2007

Rédiger des cas d’utilisation efficaces… cet ouvrage d’Alistair Cockburn est la référence en matière de cas d’utilisation (Use Case) et d’ingènierie des exigences, le livre de chevet de tout Analyste.
Depuis que je l’ai découvert en 2001, j’effectue sur ce livre un vrai travail d’évangelisation tant je le trouve utile pour décrire un besoin fonctionnel (Spécifications fonctionnelles) et complémentaire par rapport à mon activité d’Ergonome.
Le mode de construction proposé (car c’est une vraie démarche, trés progressive… d’abord Acteur puis But puis Déclencheur et Scénario principal, puis seulement les Variations et Erreurs …) est clair, les explications simples et les exemples nombreux.
Le modèle de référence proposé par Cockburn n’a rien de fondamentalement nouveau mais il sonne juste, est argumenté et détaillé tout au long de la première partie de l’ouvrage: pour l’avoir utilisé sur pas mal de projets, je le trouve tout à fait pertinent. On peut l’utiliser pour modéliser des processus mètier comme des processus système (applications informatiques) et il pousse l’analyste (ou le concepteur) à réflechir en termes d’utilisateurs et de buts, ce qui facilite mon travail au quotidien.
A retenir:

• Un Use Case est avant tout textuel (d’où le titre du livre, et la mise en avant des aspects lisibilité, rédaction…)
• Un Use Case peut être accompagné de représentations graphiques (diagramme des cas d’utilisation pour montrer les relations entre UC, autres digrammes UML, storyboard, ou livrables ergonomie); ça aide …
• Un Use Case ne traite pas des détails de l’interface (on reste sur le fonctionnel; l’interface c’est le boulot de l’Ergonome ! croyez-moi on s’y fait …)
• Un Use Case n’aborde pas les considérations techniques (encore une fois, on reste sur le fonctionnel, on traite le quoi pas le comment…)

Ce livre est un bon investissement … en attendant mes prochains billets sur la question (démarche d’analyse, modèle, lien avec le Processus Unifié, différences / similitudes avec les “User Stories”, en français “Récits d’utilisateur” ou “Histoires d’utilisateurs” au sens XP…)

Retrouvez d’autres références sur l’Ergonomie, le Processus Unifié et le Test Logiciel dans la rubrique “Quelques livres“.

Un "User Proxy" mais pas d’utilisateurs

Posté par jc-QualityStreet le 19 mars 2007

D’ailleurs, je trouve le terme “user proxy” vraiment bien choisi…
Un “User proxy” (au sens XP, Extreme Programming) n’est pas un vrai utilisateur mais il est sur le projet pour aider à le représenter.
Les méthodes agiles et une démarche ergonomique (par exemple au travers de l’ISO 13407) cherchent à impliquer les utilisateurs au plus tôt et tout au long du processus de développement logiciel. Super ! mais on a pas toujours accès à ces derniers et on peut vite se retrouver face à un seul interlocuteur, le représentant des utilisateurs, ce fameux “User Proxy“.
Parfois, on aura de la chance (bon profil, bonne connaissance des tâches et besoins utilisateurs … même si dans tous les cas, les vrais utilisateurs sont toujours plus précieux que leurs représentants), parfois moins… une position délicate pour l’ergonome.
Mike Cohn nous propose dans son livre “User Stories Applied: For Agile Software Development” des solutions quand on doit collaborer avec des “user proxies” sans avoir aucun accès aux utilisateurs (car ça peut arriver):

• En prendre plusieurs (”User proxies”), si possible de profils différents,
• Confronter ce qu’ils nous donnent aux produits concurrents (discuter les fonctionnalités mises en avant…, étudier les guides utilisateur…),
• Mettre trés vite entre les mains des vrais utilisateurs une version, même non finalisée, pour ouvrir la discussion et susciter les feedbacks (interviews, tests …).

bref des conseils pertinents, transposables à beaucoup d’autres domaines, pas seulement logiciel.

Vista UX Guide

Posté par jc-QualityStreet le 14 mars 2007

Les guidelines et standards ergonomiques sont toujours de précieux repères.
Le “User experience Group” de Microsoft nous propose ceux de Vista : Windows Vista User Experience Guidelines, mis à jour fin février 2007 mais toujours sujets à évolution. Un PDF est même disponible.

Une interface conviviale (3/3)

Posté par jc-QualityStreet le 12 mars 2007

vers des exigences d’ergonomie…
Ceci est le dernier volet de ma série consacrée au traitement de cette exigence “L’interface doit être conviviale” avec un focus sur les exigences ergonomiques, le test I.H.M. et le test d’utilisabilité (”user testing” ou “usability testing” en anglais).

Une exigence (”ce que le système doit faire”) doit, dans sa forme, être non ambigue, mesurable et vérifiable. Dans mon précédent billet, je vous présentais la stratégie à adopter pour préciser et requalifier une exigence imprécise en d’autres types d’exigences, dont les exigences d’ergonomie. Voici donc quelques exemples d’exigences d’ergonomie, accompagnées de leur mode de vérification:

• L’application devra se conformer à la nouvelle charte graphique ABC (Test I.H.M.)
• L’interface doit prévenir l’accès de l’application par des automates (logiciels dits robots) (Test I.H.M.)
• La nature hiérarchique des informations doit être présentée aux utilisateurs (Test I.H.M. / Test d’utilisabilité)
• Le tunnel de conversion une fois entamé ne doit pas avoir plus de 15% d’abandon (Test d’utilisabilité)
• L’application devra proposer sur tous les écrans un accès permanent aux principales rubriques et aux utilitaires (Test I.H.M.)
• Le temps pour effectuer la tâche A doit être inférieur à celui sur la version précédente (Test d’utilisabilité)
• L’application devra proposer des écrans et moyens d’interaction cohérents (Test I.H.M.)
• Les utilisateurs devront donner à l’application une note de satisfaction supérieure à celle de la version existante (Test d’utilisabilité)
• 90% des utilisateurs devront réussir la tâche A sans erreur (Test d’utilisabilité)

Je distingue pour ma part (Watkins ne parle quant à lui que de “Test de convivialité” - tiens tiens “convivial”) deux modes de vérification de ces exigences: Test I.H.M. et Test d’utilisabilité. Pourquoi cette distinction ?
Disons déjà qu’on ne teste pas forcément la même chose et qu’on ne couvre pas les mêmes exigences. Ensuite, les coûts, techniques et moyens à mettre en oeuvre sont différents. Enfin le test d’utilisabilité nécessite la présence d’un ergonome pour préparer, conduire et analyser ce type de test bien particulier.

Les Tests I.H.M. ont pour but de vérifier entre autres la bonne application des régles, principes définis dans une charte d’ergonomie ou dans tout autre livrable d’ergonomie (écrans, cinématique). Plus précisément, ils vont donc vérifier la présentation visuelle (menus, paramètres d’affichage, propriètés des fenêtres, résolutions d’écran, effets de bord, position des éléments, format des tableaux, des objets…), la navigation et les interactions (par saisie, menus, claviers, déplacements dans l’écran, touches Tab, raccourcis, liens, breadcrumb, enchaînement des écrans…)
Ces tests peuvent être réalisés par un testeur (ou mieux un ergonome) sur la base d’une documentation précise.

Les tests d’utilisabilité consistent à observer en situation quasi réelle l’utilisation de l’application par des utilisateurs représentatifs. Je glisse dans cette catégorie les interviews des utilisateurs à propos du produit à concevoir ou évaluer. Plus précisément, ces tests ont pour but de valider l’acceptation, de vérifier la perception et la compréhension des contenus et fonctionnalités, des moyens de navigation, et la facilité d’utilisation. Ils cherchent aussi à vérifier le respect de certaines exigences d’ergonomie plus précises sur la base de métriques (nombre d’erreurs, temps de réalisation d’une tâche, satisfaction exprimée) relatives à la facilité d’utilisation, de compréhension ou d’apprentissage.
Ces tests doivent être menés par des ergonomes, à tout moment du cycle de vie logiciel (itératif, c’est mieux ou en cascade). Ces tests sont au coeur de la norme ISO 13407 (Conception Centrée sur l’Homme).
Le choix entre ces deux types de test sera fonction notamment de l’exigence à tester et de la stratégie de test avancée.