User Story vs Use case : soyez Agile !

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 …).. Lire la suite

Cas d’utilisation UML … oui mais …

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

Documentation Agile : Juste ce qu’il faut

Posté par jc-QualityStreet le 28 août 2007

Agilité rime souvent avec Absence de documentation : voilà une idée reçue bien nuisible qui doit être combattue avec force … car mener un projet en utilisant les méthodes Agile (Agile UP, xxUP, XP, SCRUM…), n’a jamais signifié « ne produire aucune documentation ».

A l’origine de cette confusion ? Peut être une mauvaise interprétation de l’Agile Manifesto et de l’une de ses 4 valeurs « un logiciel fonctionnel plutôt qu’une documentation complète », ou plus simplement la facilité, un manque de volonté voire de compétences de certaines équipes de développement souvent soumises à un timing toujours plus serré …

Soyons clairs, privilégier l’application (ou un prototype) qui marche, plutôt que la documentation, à la fois pour mesurer l’avancement d’un projet et valider ce qu’on fait est un principe agile de base, indispensable et dont je suis entièrement convaincu (la documentation ne doit jamais servir d’indicateur de productivité). Mais aujourd’hui, peu de projets peuvent se passer d’une documentation (au sens large) précise et adaptée.

Ma position tient donc en quelques mots … « JUSTE CE QU’IL FAUT », en réfléchissant attentivement :

• A la Valeur du doc (ou de l’artefact) par rapport à l’Effort pour le produire et surtout le maintenir, sans perdre de vue que notre but, notre métier, c’est faire du soft, c’est concevoir des applications informatiques, ce n’est pas produire du papier !
• En termes de réponse à un besoin, de bénéfice pour le projet, de feedback …
• Et toujours en fonction de destinataires potentiels

Car être agile c’est avant tout penser communication, feedback, réactivité et adaptation plutôt que lourdeur, lenteur et bureaucratie, et croyez-moi une telle approche nécessite même une grande discipline ! Etre agile, c’est donc documenter de façon intelligente, appropriée et précise son projet en s’appuyant sur ce dont on a réellement besoin et ce qui est attendu pour éviter un gaspillage de temps et d’argent.

L’expérience me montre que l’utilisation d’un certain nombre de documents est quasi obligatoire sur la plupart des projets (la Vision par exemple, et d’autres pour la gestion de projet, les spécifications, …), et que certains contextes nécessitent plus naturellement (sans imposer) un certain formalisme (je pense à l’Offshore ou encore au CMMI, Capability Maturity Model Integration …). D’ailleurs, à l’autre extrême (autre idée reçue), se référer aux bonnes pratiques du modèle CMMI ne signifie pas pour autant, excès de bureaucratie et documentation à outrance.

Tout est donc affaire de mesure … SCRUM (la méthode Agile la plus populaire du moment) ou encore la conduite efficace de projets agiles vont dans ce sens.
Le Processus Unifié (dans une version customisée et adaptée à l’entreprise) peut assurer un très bon compromis, en permettant de constituer rapidement un excellent référentiel de doc. et bonnes pratiques que le chef de projet devra de nouveau ajuster à chaque projet (par l’intermédiaire du Plan de projet, élément incontournable d’UP qu’on retrouve aussi dans les pratiques du processus PP (« Planification du Projet »), l’un des 7 processus de niveau 2 du CMMI 1.2).

Pour le reste, les qualités de l’auteur de la documentation feront la différence pour la rendre correcte, précise et pertinente mais aussi lisible, légère et acceptable : en effet rédiger des cas d’utilisation ou même des user stories ne s’improvise pas, tout comme décrire des « personas », faire des diagrammes UML, des grilles fonctionnelles, rédiger un guide utilisateur, définir un plan de projet ou encore maintenir un plan d’itération …

Spécifications, Exigences et Cahier des charges : Quoi, Comment ?

Posté par jc-Qualitystreet le 2 juillet 2007

… avant tout un outil de communication et un brin de documentation (juste ce qu’il faut pour rester Agile) visant à rendre compte de l’adéquation de ce qui est livré avec ce qui est attendu, voulu par le Client et les Utilisateurs finaux;
… un travail produit dans le cadre du Recueil & Expression, de la Spécification et de la Gestion du besoin, composantes principales de ce qu’on appelle « l’Ingénierie des exigences » (=« Requirements » );
… des exigences au cœur des projets, qu’elle soient fonctionnelles (ce que le système doit faire, constituant par exemple un backlog de produit agile) ou non fonctionnelles (qualité du produit, principalement les attributs issus de la norme ISO 9126), présentes au travers de ces trois activités essentielles.
… et de nouveaux champs d’intervention pour l’Ergonome Agile comme je le décris dans le précédent billet de cette série: Spécifications, Exigences et Cahier des charges: Qui ? Quand ?

Recueillir & Exprimer les besoins

L’objectif est de fournir une vision claire du système à concevoir, d’offrir la définition et les limites du système, les fonctionnalités clés, les autres exigences et contraintes. Définir puis partager la Vision du produit est donc cruciale.
La vision synthétique est un excellent point de départ :

POUR (public concerné par le produit)

QUI SOUHAITENT (formulation du besoin des cibles)

NOTRE PRODUIT EST (ce qu’est le produit)

QUI (le bénéfice majeur, l’utilité de la solution)

A LA DIFFERENCE DE (pratique actuelle, concurrence)

PERMET DE (éléments différentiateurs majeurs)

Elle peut se prolonger dans de petits docs. à la structure souvent similaire :

Plan d’un Cahier Des Charges de Site Web

Plan de Vision Document (Wiegers)

L’entretien et l’observation sont  les sources d’informations principales mais d’autres techniques peuvent aussi être utilisées : questionnaires, focus group, observation, tests utilisateurs exploratoires, benchmarking, étude de l’existant, de la concurrence), présentation de maquettes…
Le savoir-faire de l’ergonome dans la conduite de chacune de ces techniques est un véritable atout, notamment pour trier et organiserclassifying the voice of the customer », selon Karl Wiegers ), discours qui peut prendre différentes formes : l’input des utilisateurs (« exigences Business, scénarios d’usage, règles de gestion, exigences fonctionnelles, attributs de qualité, contraintes, données, idées et solutions).
Ce premier tri nous servira à établir notre base d’exigences.

Spécifier les besoins

L’objectif est de détailler et de clarifier les besoins exprimés en analysant le fonctionnement du système de manière formelle et exploitable par les équipes de développement.
Même si ce n’est pas forcément leur objectif initial, les user stories et les éléments de conversation les accompagnant (conditions de satisfaction, exemple, wireframes…) constituent un moyen particulièrement efficace de spécifier le besoin de manière collaborative.

Les formats de spécification plus anciens se recoupent (IEEE, RUP, Volere …). Ils  intègrent généralement en leur sein une partie Exigences fonctionnelles. Cette intégration qui se concrétise souvent sous forme de renvois vers d’autres formats ou document  permet à cette documentation générale de rester synthétique, ouverte et abordable.

Exemple SRS Volere

Exemple SRS IEEE 830

« Use cases et user stories », livrables d’ergonomie, diagrammes divers et variés … sont dans tous les cas de précieuses techniques pour spécifier les besoins.
Sur le plan fonctionnel et opérationnel, l’utilisation de ces user stories ou la construction progressive de Cas d’utilisation (« use cases »), (Acteur -> But -> Déclencheur et scénario nominal -> Extensions), le tout combiné aux spécifications IHM (wireframes ),  sont désormais des standards, et des avancées majeures dans une vision toujours plus utilisateur et toujours plus orientée BUT.

Il s’agit avant tout ici d’un travail d’Equipe même si les spécialistes de l’Experience Utilisateur, de l’Analyse et des Tests apportent une vraie plus value.

Gérer les exigences

Les objectifs de cette activité transversale sont de faciliter la reconnaissance et la compréhension du lien entre les exigences, de permettre leur priorisation, et surtout de tracer leur prise en charge dans le projet (tel composant est le fruit de tel UC ou User Story, lui même issu de tel besoin, le tout testé dans tel cas de test); en somme, la vie d’une exigence aussi bien en amont qu’en aval de sa spécification.

Exemple d’une base d’exigences (RequisitePro)

Des outils spécialisés (Doors, Caliber-RM, Requisite Pro…) existent. Au final, ils sont plus complexes que véritablement utiles, car c’est surtout la prise de conscience de l’importance de cette activité qui est cruciale.
La gestion doit s’opérer de manière continue très tôt dans le projet : la base d’exigences ou tout simplement le BACKLOG de PRODUIT qu’ils soient manuels ou automatisés vont servir de fil rouge au projet et de référence à l’ensemble des acteurs.
Lister & vérifier (selon ces huit critères : caractère correct, clair, sans ambiguïté, cohérent, complet, réaliste, pertinent, vérifiable et traçable), qualifier, valoriser et surtout prioriser, suivre les exigences sont des tâches inhérentes à cette activité : il s’agit d’une grosse part du travail de l’analyste ou plus globalement du Product Owner.

Retrouvez des références bibliographiques sur ces questions dans la rubrique “Quelques livres“.

Spécifications, Exigences et Cahier des charges : Qui, Quand ?

Posté par jc-QualityStreet le 27 juin 2007

Plus j’interviens dans les projets de développement informatique (Logiciel, Application Web, Sites Internet, INTRANET, EXTRANET …), plus je m’aperçois du caractère essentiel mais complexe, de trois activités, qui bien menées, maximisent pourtant les chances de réussite des projets:

• Recueillir et exprimer le besoin (Expression des besoins, Cahier des Charges, Vision …)
• Spécifier le besoin (Dossier de spécification, SRS, Use cases, User stories …)
• Gèrer et tracer les exigences (Backlog de produit, Liste des exigences, manuelle à base d’attributs ou sur des outils dédiés)

Évidemment, l’intensité, la répartition de ces activités va varier selon la taille et la nature du projet (Applications mètier, Sites Internet…), selon le contexte (Projet interne, R&D, Client, Appel d’offres), mais toutes trois se doivent d’être présentes et définies sur vos projets de conception…. D’ailleurs, dans un prochain billet, je détaillerai davantage le Quoi, et vous proposerai une réflexion sur le Comment.

Sans détours et sans vous rappeler les rapports CHAOS du Standish Group, je vous affirmerai pourtant que:

• La capture est souvent incomplète, biaisée, mal maîtrisée.
• La spécification souvent confuse, inadéquate, incorrecte, incompréhensible pour ses destinataires.
• La gestion des exigences faite dans l’urgence voire absente, et de toute façon sous estimée.

Sans détours, j’ajouterai même que le recueil, la spécification et la gestion du besoin, nécessitent au final une véritable expertise, la maîtrise de diverses techniques souvent complémentaires (issues des Sciences Humaines), et pas mal de rigueur…
bref, moins de blabla, moins d’artisanat, plus de professionnalisme et de méthode.

QUI
Vaste débat… et potentiellement pas mal de dérives…

Dans un contexte agile, on parlerait de Product Owner. Plus largement, l’Analyste, le Consultant, le Client sont des acteurs récurrents … mais aussi l’Ergonome qui de par son savoir-faire, ses objectifs et sa démarche centrée utilisateur doit en effet être un acteur privilègié du recueil et de l’analyse du besoin. Souvenez-vous , un produit “ergonomique” est un produit utile (issu d’un besoin EXPRIME ou NON) et utilisable : la présence de l’ergonome à ce stade est donc plus que légitime.

QUAND
L’expression des besoins et autres Cahiers des charges (suffisamment ouverts) sont quant à eux le fruit de l’activité de recueil, et servent souvent de déclencheurs pour la suite des opérations en mode agile, itératif ou séquentiel.

Dans une perspective séquentielle (cascade ou V: le pire), l’enchaînement est simple et bien connu. Les disciplines d’ingenierie (Spécification, Conception, Developpement, Intégration, Test) vont se dérouler dans un ordre trés précis avec la nécessaire validation de l’étape précédente pour passer à la suivante.
Les écueils de cette démarche sont nombreux : feedbacks et retours en arrière non prévus, corrections difficiles, pas de pilotage par les risques, manque de visibilité… Dans ce cadre, la gestion des exigences sera au mieux menée de manière transversale, servant de fil rouge à l’ensemble des acteurs et au projet; toutefois la plupart du temps la gestion des exigences ne sera pas envisagée ou sera traitée dans l’urgence.

Non ce qui marche, c’est l’AGILITE avec une bonne dose d’analyse, de test et d’expérience utilisateur.

Dans une perspective agile donc (l’idéal)

… de type SCRUM, méthode Agile la plus populaire, le degré de formalisme sera diffèrent; le tout intégré à chaque Sprint. Un effort particulier sera fait en Sprint 0, l’ingenierie des exigences se jouera principalement au travers du Backlog de produit  & User Stories dans une dynamique plus collaborative, toute aussi disciplinée mais moins formelle. Le backlog de produit servira donc de fil rouge

Dans une perspective seulement itérative

… de type Processus Unifié (”Unified Process”), le concept ou plutôt la discipline “Ingènierie des exigences” prend cette fois tout son sens puisque prévue, formalisée et cadrée, permanente et continue. Les acteurs chargés de ces activités vont donc suivre le projet du début à la fin, certes avec plus de spécification en 1ère partie du projet (80% des cas d’utilisation doivent être rédigés en fin d’Elaboration), et davantage de gestion des exigences dans la seconde partie.

A bientôt pour plus de détails sur le Quoi et une idée du Comment.

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…