Construction d’un Story Map

Une des caractéristiques des projets agiles, dits itératifs, incrémentaux et adaptatifs, est la réduction des cycles de développement et le découpage en itérations. Dans ce contexte, les équipes sont focalisées sur le court terme, et oublient souvent le moyen et le long terme.

Nul besoin de vous rappeler qu’il serait dangereux de se lancer sur un train d’itérations sans avoir défini de vision du produit et établi une feuille de route.

Lors de mes interventions, j’utilise souvent le Story Map pour préparer le projet et avoir une idée du périmètre macroscopique à adresser.

Avantages du Story Map

Le Story Map (ou carte d’histoires) est une technique qui permet la construction d’une feuille de route et offre de nombreux avantages.

Le Story Map donne :

  • une meilleure explication de ce que doit faire le produit,
  • de la visibilité en mettant en perspective les choses macroscopiques à faire dans le projet,
  • une vue de l’avancement du projet, sur ce qui a été fait et sur ce qui reste à faire.

Le Story Map permet :

  • une organisation et une priorisation à haut niveau des choses à faire dans le projet,
  • une planification des versions du produit,
  • une initialisation du Backlog Produit.

Construction du Story Map

Un Story Map est toujours constitué de deux dimensions.

  • Une dimension temps ; axe horizontal
  • Une dimension contenu ; axe vertical

Construction de l’axe horizontal

Sur l’axe horizontal, il y a plusieurs approches possibles pour la projection dans le temps :

  • Soit par liste des macro fonctionnalités du produit, les « usages » (souvent celle que j’utilise)
  • Soit par liste des caractéristiques du produit, les « features »
  • Soit par liste des profils utilisateurs, les « rôles »

Une combinaison d’approches peut être réalisée sur cet axe.

Construction de l’axe vertical

Sur l’axe vertical, le contenu est déduit de la liste des items de l’axe horizontal par décomposition (il existe de nombreuses stratégies de raffinage que je ne présenterais pas ici). Le contenu est alors priorisé en fonction de la valeur métier.

Dans l’exemple ci-dessous, les macro-fonctionnalités (usages) ont été décomposées en histoires utilisateur.

Avec cette représentation, il est aisé de déplacer une colonne soit vers la droite, soit vers la gauche. Le déplacement d’une colonne sur l’axe horizontal implique automatiquement le déplacement de tout le contenu de l’axe vertical.

Introduction de la notion de version

Le découpage précédent avec des histoires utilisateur permet d’envisager la construction des versions du produit. Une version étant un regroupement de plusieurs itérations.

Il suffit de créer des lignes horizontales qui vont délimiter le périmètre de chacune des versions.

De même, avec cette représentation, il sera facile de modifier le contenu des versions en déplaçant les histoires d’une version à une autre sur l’axe vertical.

Initialisation du Backlog Produit

Avec cette carte d’histoires, vous avez obtenu en réalité votre première version du Backlog Produit. Il est alors très facile de construire les premiers items de votre Backlog et de les raffiner ensuite.

Voilà, vous savez presque tout sur cette technique !

N’hésitez pas à laisser vos commentaires et réactions.

Stéphane

Différence entre besoin et exigence, parle-t-on de la même chose ou pas ?

requirements concept

Trop souvent, que ce soit dans le cadre de mes interventions ou lors de la lecture de différents articles trouvés çà et là sur le web, je constate que le terme exigence est utilisé de manière trop restrictive et uniquement pour représenter une condition ou une capacité que doit posséder un produit. Aléatoirement, les termes « besoin » et « exigence » sont employés pour désigner vaguement quelque chose exprimé par l’utilisateur d’un produit.

C’est oublier qu’une exigence, c’est aussi l’expression d’une condition ou d’une capacité qu’un utilisateur a besoin pour atteindre un objectif ou résoudre un problème.

Pour commencer à répondre à la question ci-dessus, il convient de revenir sur les définitions de ces deux mots.

Besoin

La définition du terme « besoin » dans le dictionnaire Larousse ne nous aide pas trop sur ce point et apporte même de la confusion puisque le terme « besoin » est défini en utilisant le mot « exigence ». Ainsi on y trouve la définition suivante « un besoin est une exigence née d’un sentiment de manque, de privation de quelque chose qui est nécessaire à la vie organique », ou bien « un besoin est une chose considérée comme nécessaire à l’existence ».

Dans la norme AFNOR X50-150, il est précisé qu’un besoin est une nécessité, un désir, un manque ou une insatisfaction éprouvé par un utilisateur, un client…, par ce que l’on appelle une partie prenante. Ce qui fait la spécificité d’un besoin, et cela constitue une différence majeure avec l’exigence, c’est qu’il n’est pas toujours exprimé !

Exigence

Pour le terme « exigence, et toujours dans le domaine normatif (ISO, IEEE, CMMi), il est souvent fait référence à deux niveaux d’exigences :

  • L’exigence de niveau utilisateur ; qui exprime une attente ou un problème à résoudre de la part d’une partie prenante. Cette partie prenante peut être soit un utilisateur, un client ou une maîtrise d’ouvrage. L’exigence de niveau utilisateur appartient au domaine du problème et est exprimée dans le langage de la partie prenante considérée (ie. le client).
  • L’exigence de niveau système ; qui exprime une condition ou une capacité que doit posséder un produit ou un composant de produit pour satisfaire un contrat, une norme, une spécification ou tout autre document imposé formellement. L’exigence de niveau système appartient au domaine de la solution et est exprimée dans le langage du fournisseur.

L’exigence de niveau utilisateur est donc bien un énoncé qui traduit un besoin de l’utilisateur. C’est une transformation du besoin en quelque chose. A la différence du besoin, ce quelque chose va respecter des critères qualité comme la concision, la non ambiguïté, la clarté, la précision…

On le voit, il y a donc une différence importante entre les deux notions…

Valeurs agiles en ingénierie des exigences

Word cloud with agile project concept on black

Nous connaissons tous les valeurs agiles promues dans le Manifeste Agile pour le développement de logiciel de 2001 (http://agilemanifesto.org/) et reprises ci-dessous :

  • Les individus et leurs interactions, plus que les processus et les outils
  • Des logiciels opérationnels, plus qu’une documentation exhaustive
  • La collaboration avec les clients, plus que la négociation contractuelle
  • L’adaptation au changement, plus que le suivi d’un plan

Les signataires de ce Manifeste ont mis en avant l’équipe, le produit, la collaboration et le changement, mais ils n’ont pas oublié de mentionner la chose suivante : « Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers. ».

Alors que l’ingénierie des exigences est une discipline qui commence à être reconnue par les organisations qui définissent et conçoivent des systèmes complexes, nous assistons dans le même temps à la montée en puissance de la gestion de projet agile.

Dans ce nouveau contexte organisationnel, nous ne pouvons pas nous empêcher de nous poser les questions suivantes : Retrouvons-nous les quatre valeurs de l’agilité en ingénierie des exigences ? Si oui sous quelle forme les trouve-t-on ? Et comment peuvent-elles être déclinées ?

L’équipe – Les individus et leurs interactions

En ingénierie des exigences, les parties prenantes constituent la source principale des exigences. Un objectif fondamental de l’ingénierie des exigences est de comprendre les désirs et les besoins des parties prenantes et d’en extraire des exigences. Les utilisateurs d’un produit, d’un système ou d’un logiciel sont également des parties prenantes et leurs exigences représentent des conditions ou des capacités requises pour résoudre un problème ou atteindre un objectif.

Le processus qui produit les exigences est un processus itératif et incrémental. Ce processus que l’on appelle couramment « processus de développement des exigences » est un processus cognitif qui repose sur une communication intensive et sur l’action réciproque entre les parties prenantes et l’équipe en charge de la définition et de la réalisation du produit. Les processus et les outils sont importants pour manipuler le contenu souvent complexe et soutenir ce processus cognitif.

Néanmoins, cette première valeur de l’agilité insiste sur le fait que les processus et les outils ne sont pas une fin en soi ; ils doivent être introduits de façon raisonnable et avec discernement, et doivent être utilisés avec soin et pragmatisme.

Le produit – Des logiciels opérationnels

L’ingénierie des exigences est la base de la compréhension des besoins des utilisateurs et de l’appropriation par l’équipe de développement de leurs exigences, afin qu’elle puisse construire le bon produit. La valeur principale de la discipline et le facteur principal de la réussite d’un projet résident dans la connaissance des besoins des parties prenantes. L’interaction avec et entre les membres de l’équipe partageant la connaissance est une façon de préserver cette connaissance.

L’agilité met en avant le logiciel opérationnel au détriment de la documentation et considère que la documentation n’est pas une fin en soi. Contrairement aux idées reçues, cela ne veut pas dire qu’il n’y a pas de documentation dans un projet agile, mais que cette documentation sera réalisée avec parcimonie et en particulier, en fonction de la nécessité ou non de capitaliser sur la connaissance.

Par définition, une exigence est une représentation documentée d’une condition ou d’une capacité. Aussi, en agilité, la documentation des User Stories dans le Backlog du produit est déjà une première étape de la documentation des exigences. C’est le « contrat » minimal entre le Product Owner et l’équipe en charge de la réalisation du produit.

N’oublions pas que dans certains domaines spécifiques tels que le médical, l’automobile ou l’aéronautique, la conformité et les contraintes réglementaires définissent des normes sous forme de spécification, ce qui exige l’existence d’une documentation écrite par rapport aux exigences.

La collaboration – La collaboration avec les clients 

Le socle des connaissances en ingénierie des exigences aborde le sujet de la collaboration avec le client dans les activités d’élucidation et de négociation des exigences. Les objectifs de ces activités couvrent des principes importants de l’agilité et les éléments utilisés dans les projets agiles, tels que la communication directe, les personas, les techniques de créativité, l’enquête contextuelle, les User Stories, … font partie des techniques et des outils de l’ingénierie des exigences.

Afin de faire adhérer l’équipe à l’idée de collaboration, il est important de disposer d’un référentiel unique de l’information. Ce référentiel devra être partagé entre toutes les équipes, unique et centralisé, organisé et structuré… Une partie de ce référentiel sera constituée d’exigences.

Avec son schéma de certification, l’IREB(*) offre un module de niveau avancé traitant de l’élucidation et de la consolidation des exigences avec les parties prenantes et les utilisateurs. Ce module de niveau avancé met l’accent sur les valeurs agiles et la collaboration entre les équipes.

Le changement – L’adaptation au changement

Les démarches agiles comme Scrum ou Kanban fournissent une réponse aux changements comme principe de base des valeurs agiles au travers de méthodes spécifiques, de techniques et de bonnes pratiques. Les modèles de cycle de vie agiles donnent des conseils sur comment et quand appliquer ces méthodes, techniques et bonnes pratiques.

Le fait de répondre au changement n’est pas une spécificité de l’agilité. A sa manière, la discipline de l’ingénierie des exigences au travers des activités de gestion des exigences (traçabilité, analyse d’impact, versionnement des exigences…) répond à cette nécessité. L’ingénierie des exigences offre également des méthodes spécifiques et des techniques qui soutiennent cette prise en compte du changement.

En conclusion, nous pouvons affirmer que l’ingénierie des exigences et la gestion de projet agile ne sont pas incompatibles. Le socle des connaissances en ingénierie des exigences est tout aussi important et pertinent dans le modèle de cycle de vie en cascade ou en V que dans l’agile. Les aspects collaboration et communication sont très présents dans l’un et l’autre, et la satisfaction des utilisateurs constitue un objectif commun. Des adaptations sont néanmoins nécessaires et se traduisent par des activités d’ingénierie menées avec des intensités variables, des techniques et des outils différents, des rôles des acteurs redéfinis.

Article inspiré du document IREB(*) « Ingénierie des exigences et développement agile ».

(*) IREB = International Requirements Engineering Board (www.ireb.org)

Y’a-t-il des exigences dans un projet agile et si oui comment doivent-elles être gérées ?

C’est une question qui se pose naturellement lorsqu’une organisation souhaite mettre en place l’agilité dans ses projets. Pour y répondre, il convient de revenir aux fondamentaux de l’ingénierie des exigences.

Revenons à la notion d’exigence. L’exigence est une « caractéristique observable de l’extérieur d’une entité souhaitée » (Alan Davis). C’est donc une vue « boîte noire » d’un produit. Une exigence ne doit pas décrire l’intérieur de la boîte mais uniquement ce qui est visible de l’extérieur. Par conséquent, une exigence n’est pas et ne doit pas être une description d’une solution concrète. Partant de cette définition, et compte tenu qu’un produit (un système) est souvent décomposer en sous-systèmes, nous constatons que plusieurs niveau d’exigences peuvent coexister, tout va dépendre de l’endroit où se porte l’attention.

L’exigence représente le QUOI. Elle doit être justifiée et doit par conséquent être reliée à un objectif de haut niveau d’une partie prenante, le POURQUOI. L’exigence ne décrit pas le COMMENT. Le COMMENT doit être décrit dans les spécifications de conception, d’architecture, de tests…

POURQUOI ? (pour quelle raison)            objectifs

QUOI ?                                                            exigences

COMMENT ?                                                  spécifications

Les normes internationales (IEEE, CMMi, ISO) ont défini le terme exigence en utilisant trois définitions complémentaires :

  1. Une exigence est une condition ou une capacité dont un utilisateur a besoin pour résoudre un problème ou atteindre un objectif.
  2. Une exigence est une condition ou une capacité que doit posséder un produit (ou un composant de produit) pour remplir un contrat, se conformer à une norme ou tout autre document imposé formellement.
  3. Une exigence est une représentation documentée d’une condition ou d’une capacité du cas 1 ou du cas 2.

Cela montre clairement qu’il y a deux niveaux d’exigences à considérer pour un produit. En ingénierie des exigences, nous avons l’habitude de distinguer les « exigences utilisateur » (dans le cas 1) et les « exigences système » (dans le cas 2).

Les « exigences utilisateur » traduisent le problème à résoudre, l’opportunité à saisir pour un utilisateur, c’est le domaine du problème. Elles doivent être reliées à des objectifs de haut niveau que nous appelons des « buts ». Les exigences de haut niveau (les buts) sont décomposées en exigences plus fines par un mécanisme de scénarisation. La scénarisation permet d’envisager les différentes manières d’atteindre le but de haut niveau.

Selon l’IREB, les exigences utilisateurs peuvent être décrites sous la forme de buts et de scénarios. Les scénarios peuvent être regroupés en cas d’utilisation. Le niveau de granularité des exigences utilisateurs les plus fines peut être obtenu au niveau d’une étape d’un scénario.

Les « exigences système » sont une réponse aux « exigences utilisateur », c’est le domaine de la solution. On dit généralement que les « exigences système » satisfont les « exigences utilisateur ». Les deux niveaux d’exigences représentent toujours une vue « boîte noire » de notre système.

Dans une approche agile, le focus est mis sur les exigences de l’utilisateur et la valeur délivrée. La notion de User Story est très souvent employée pour décrire ce que souhaite l’utilisateur d’un produit. Elle s’exprime sous la forme :

« En tant que <utilisateur>, je souhaite <faire cela> afin de <atteindre un objectif>. »

Nous voyons que dans l’expression d’une User Story, un parallèle assez évident peut être fait entre le besoin de l’utilisateur <faire cela> et l’exigence utilisateur (le cas 1 défini plus haut), et <atteindre un objectif> avec un but de haut niveau.

Lors de l’identification des User Stories, il arrive très souvent que le souhait de l’utilisateur soit exprimé de manière très macroscopique, comme par exemple « En tant que conseiller de clientèle, je souhaite simuler un crédit à la consommation afin de proposer une offre à mon client. ». Cette User Story est trop « grosse » pour être réalisée dans une seule itération, il va donc être nécessaire de la découper en User Stories plus petites, c’est ce que l’on appelle le « grooming ». Ces User Stories macroscopiques sont souvent appelées soit des Thèmes, soit des Epics. Les Thèmes et les Epics peuvent être considérés comme des buts de haut niveau pour l’utilisateur. Lors du raffinage des Thèmes & Epics en User Stories, une démarche de type « scénarisation » doit être utilisée.

Dans Scrum, la décomposition des Thèmes & Epics en User Stories est réalisée en collaboration entre un Product Owner et l’équipe de réalisation.

J’ai un produit complexe à concevoir, quelles sont les questions essentielles à se poser ?

  • quel problème dois-je résoudre ? quel est l’objectif à atteindre ?
  • pourquoi dois-je concevoir ce produit ? quelle est sa justification ?
  • que doit faire le produit pour atteindre l’objectif ? comment doit-il se comporter ?
  • comment savoir si l’objectif est atteint ?
  • quel risque vais-je prendre pour atteindre l’objectif ?
  • comment vais-je le réaliser ?
  • combien la réalisation du produit va-t-elle me coûter ?
  • quand et sous quelle forme vais-je pouvoir livrer le produit ?

Lorsque la User Story est dimensionnée pour pouvoir être réalisée dans une itération, l’équipe de développement réalise une décomposition en tâches. Les tâches vont permettre la réalisation des US. Il est important à ce stade de se concentrer sur ce que doit faire le système pour satisfaire la US et comment il doit se comporter. C’est à ce niveau qu’apparaissent alors les exigences système. Les exigences système décrivent les fonctions et les interfaces du futur système. Les tâches étant en réalité la manière de réaliser les exigences système.

Cette notion d’exigence système dans un projet agile est très importante et souvent sous-estimée car c’est sur la définition de ces exigences que sera réalisé le futur système. Le référentiel d’exigences système constituera une référence pour les demandes de changements et l’analyse d’impact des modifications qui ne manqueront pas d’arriver sur le projet. Le référentiel d’exigences système est également le point de départ pour la capitalisation et la réutilisation des exigences.