Partie 3: La technique du User Story Mapping

Partie 3: La technique du User Story Mapping


Aperçu de l’article

Notions clés

Définir et organiser ses besoins : pas toujours évident!

Le but de ce chapitre est de vous démontrer l’importance d’un tel exercice dans le cadre de solutions d’entreprises sous SharePoint et de vous guider dans l’expression des besoins de vos utilisateurs.

L’utilisation d’outils dynamiques tels que la technique de User Story Mapping et autres techniques de communications pourront vous aider à organiser un carnet de produit de manière efficace et mener à une définition de besoins structurée et exploitable facilement pour l’analyse fonctionnelle.

 Comprendre les attentes et enjeux lors de cette étape

 Apprendre une démarche simple permettant de définir un besoin

 Organiser et structurer des besoins dans le cadre de projet agile

  Les exploiter dans le cadre de cas de solutions d’entreprises SharePoint

 


Comment définir des besoins dans le cadre d’un nouveau projet?

Cette technique est adaptée à l’identification d’histoires utilisateurs et donc à la définition d’un carnet de produit dans un contexte de gestion de projet agile. Elle est généralement réalisée en plusieurs étapes sous forme d’ateliers. Elle peut être réalisée de manière « Manuelle » (avec post-its et crayons) ou de manière électronique (SpecLog est un très bon outil, mais payant http://www.speclog.net/)

Tout d’abord, si vous souhaitez en savoir plus sur les techniques de User Story Mapping vous pouvez lire les articles suivants, le but n’étant pas de repasser sur la méthode au complet mais plutôt de savoir comment en tirer parti dans le cadre de projets SharePoint.

Le principe est assez simple. Au lieu de définir un carnet de produit sous forme de liste, comme il est coutume de faire, la définition se fait ici sous forme de « carte ». Les avantages sont multiples :

  • Les besoins sont orientés sur les rôles et les responsabilités
  • Facilite l’expression des besoins car ceux-ci sont mis dans un contexte
  • Offre une vue d’ensemble d’un système
  • Facilite la priorisation
  • Révèle les relations entre les besoins
  • Met de l’avant les chaines de valeurs de la solution

Principe de fonctionnement

Voici la manière de lire une User story Map :

Lecture d'une "User Story Map"

 

La User Story Map se lit de haut en bas. Le point d’entrée se situe à la définition des objectifs métiers pour finir par la spécification des histoires utilisateurs (priorisées du haut vers le bas). Des contraintes peuvent également s’ajouter à travers les niveaux hiérarchiques.

Une question fondamentale est associée à chaque niveau hiérarchique, vous amenant à définir les éléments qui le constitueront.

L’axe horizontal représente en théorie la chronologie des actions effectuées par un profil. Il arrive que celui-ci puisse être négligé compte tenu du temps nécessaire à sa réalisation et surtout, il n’apporte pas fondamentalement de valeur pour la suite.

Les objectifs métiers

Les objectifs métiers consistent simplement en la justification du système ou de l’application à développer. Il s’agit en quelque sorte de la ligne directrice de votre solution.

Par exemple, une solution d’entreprise SharePoint pourra vouloir améliorer la productivité de ses employés ou forger un esprit d’équipe, etc.

Objectifs métiers

Les profils

Les acteurs ou profils sont les utilisateurs de votre système. Attention ici un profil N’EST PAS une personne physique. En ce sens qu’une personne physique peut posséder plusieurs profils.

Voici un exemple:

M. Martin est directeur de projet chez Contoso.inc et utilise l’intranet. Voici les profils que M. Martin pourrait détenir dans l’intranet de Contoso.Inc

Profils

  • Utilisateur lambda: Il s’agit de toute personne connecté sur l’intranet peu importe son appartenance à d’autres rôles. En résumé ce que tout le monde peut faire sur l’intranet.
  • Directeur de projet : Le rôle principal de M. Martin, son métier finalement.
  • Gestionnaire de contenu : Personne pouvant contribuer au contenu de l’intranet

Etc..

Il est possible d’avoir autant de profils que l’on souhaite!

Les activités

Une activité est un regroupement d’actions que peut faire un profil particulier. Cet élément sert davantage à des fins d’organisations d’histoires utilisateurs pour permettre une meilleure visibilité des actions et rôles de chaque profil.
Généralement, on retrouvera souvent le verbe d’action « Gérer » dans ces activités
Voici un exemple:

Mr Martin, dans son rôle de directeur de projet, aura très certainement des tâches liées à la gestion de projets. Ainsi, il est possible d’isoler une activité à part entière. De même qu’un utilisateur lambda pourra visualiser les informations contenues dans ces projets.

Activités

 

Les histoires utilisateurs

Il s’agit de la partie la plus importante de l’outil, celle où l’on définit le besoin final exprimé par le demandeur et sur laquelle le fournisseur s’engagera à sa réalisation.

Pour être suffisamment complet, un besoin doit, en théorie, comporter les notions suivantes :

 Qui? (Obligatoire): Qui est concerné? Cette information vous est donnée directement par le profil réalisant l’action.

 Quoi? (Obligatoire) : Quelle est la nécessité? Habituellement, il s’agit souvent d’un verbe d’action.

   Pourquoi? (Optionnel): Quel gain procure la réalisation de cette action? La justification du besoin.

Note : le demandeur est le seul juge de sa pertinence. En d’autres termes, vous n’avez pas à remettre ses besoins en cause ni même d’en proposer même si vous trouvez que ceux-ci ne sont pas légitimes.

 Astuce : Si à première vue, vous doutez fortement de la justification que votre client vous apporte, je vous conseille la  « règle des cinq pourquoi » qui est très efficace pour recherche de la cause fondamentale d’un besoin ou problème (attention, ne le faites pas à chaque fois, cela peut devenir long).

Pour vous aider à formaliser votre besoin, vous pouvez toujours vous servir de ce modèle de phrase :

En tant que « Qui » je souhaite « Quoi » afin de « Pourquoi ».

D’expérience, la partie « Pourquoi » est très souvent négligée, jugée rébarbative et coûteuse en temps (en effet, définir des besoins peut être long et tous les justifier encore plus). C’est pourquoi on remonte généralement la notion de gain à des niveaux plus haut comme par exemple sur le système au complet ou bien sur les activités en ne gardant simplement que le « Qui » et « Quoi » pour le niveau le plus granulaire de besoins.

Vous noterez que le « Comment ? » n’apparait pas ici pour la simple et bonne raison que c’est le sujet de la prochaine partie, après l’analyse des besoins : l’analyse fonctionnelle.

L’ensemble des besoins forme ainsi le carnet de produit ou « backlog », représentant la liste priorisée des fonctionnalités à développer pour le système.

Voici un exemple:

Histoires Utilisateur

 Note: Il est possible de rassembler les actions « CRUD » (Create, Read, Update, Delete) dans une seule et même histoire utilisateur (ex : CRUD un projet). Cependant rappelez-vous que vous vous engagez à livrer cette fonctionnalité au complet à la fin de votre sprint. Estimez donc bien la granularité de vos histoires utilisateurs.
Remarque : Un besoin peut se retrouver sous deux profils différents. Dans ce cas, il faut impérativement que le comportement soit différent selon l’acteur qui réalise l’action.

Voici un exemple:

Besoins dupliqués

 

Dans cet exemple, cela implique que rechercher un projet pour un utilisateur sera différent de la recherche de projet pour un directeur de projet.

Les contraintes

Il est impératif de prendre les contraintes en considération lors de la réalisation d’un besoin. Celle-ci peut être de nature technique, fonctionnelle ou humaine.

Elle peut intervenir à plusieurs niveaux :

  • Objectifs métiers

Contrainte d'objectif métier

 

 

  • Profils

Contrainte de profil

  • Activités

Contrainte d'activités

Vous remarquerez qu’il n’y a pas de contrainte au niveau de l’histoire utilisateur. En effet, au niveau de l’histoire utilisateur, on parlera plutôt de critères d’acceptation représentant les étapes de l’analyse fonctionnelle.

 Note: Par convention, on modélisera une contrainte au-dessus de l’élément sur lequel elle s’applique. (une contrainte pèse sur un élément…;))

Un exemple complet

Exemple complet de la User Story Map

 

 Avec SharePoint

Dans le cadre de SharePoint, l’User Story Map possède plusieurs avantages :

  • Elle constitue votre gouvernance applicative. En effet, cette technique étant centrée sur les rôles et responsabilités, elle vous permet de répondre à la question « Qui fait quoi et comment dans la solution ? ».
  • Elle révèle les flux de données entre les besoins permettant d’identifier un scénario d’implémentation SharePoint lors la phase d’analyse fonctionnelle (notion expliquée dans les parties suivantes).
  • Elle vous indique implicitement les permissions liées aux contenus qui seront manipulés à travers les différents besoins. (exemple pour le type de contenu « Projet » : Utilisateur lambda se verra accorder les droits de lecture seule alors qu’un directeur de projet ceux de contribution). De même les profils peuvent se manifester par des groupes de sécurité dans SharePoint.

Astuces méthodologiques

Ces quelques astuces méthodologiques vous permettrez d’éviter certains pièges du début.

Organiser les ateliers

Une définition de besoins par la technique de User Story Mapping peut être longue. C’est pourquoi, il est intéressant de procéder par ateliers successifs regroupant un nombre restreint de personnes.

Typiquement, une session d’atelier doit se concentrer sur maximum d’une à deux notions de la technique (acteurs, impacts, etc…). Si vous essayez d’attaquer toutes les notions de front, d’expérience, vous perdrez vos interlocuteurs…

De même, n’excédez pas 4 heures par session. Au-delà, la productivité diminue fortement.

Règles à respecter lors d’un atelier :

 Ne jamais proposer, simplement écouter et challenger : votre rôle ici est de guider votre client, pas de l’influencer dans ses besoins.

 Ne jamais parler de SharePoint : découlant directement du point #1.

Voici un exemple de planification d’ateliers éprouvée :

On retrouve généralement trois types d’ateliers

  • # 1 : Identification des acteurs et des objectifs.
  • # 2 : Identification des activités à partir de tâches en vrac
  • # 3 : Transformation des tâches en histoire utilisateur.

 Note : chaque type d’atelier peut être décliné en plusieurs sessions selon la taille du projet.

 Titre: Type Atelier 1 – Découverte du projet

 Durée: 4 heures

Participants:

  • Coach agile
  • Un seul responsable fonctionnel pour tous les profils identifiés

 Objectifs

Expliquer la méthode de « User Story Mapping » pour la définition de besoins (30 min)

Identifier le ou les grands objectifs métiers pour la solution (Réflexion libre 5 minutes).
Si l’on vous demandait les objectifs que vous souhaiteriez atteindre avec la solution, quels seraient-ils?

Exemple : Que les utilisateurs accèdent rapidement à leur informations, gèrent mieux leur projets, etc.

Identifier les acteurs concernés (Réflexion libre 5 minutes).
Quels seront les types de personnes concernées par la solution?

Exemple : Département RH, Finances, Utilisateurs basiques, administrateurs, gestionnaires, etc…

 Matériel nécésaire

  • Ensemble de post-it de couleur
  • Logiciel SpecLog
  • Rétroprojecteur
  • Tableau blanc et crayons effaçables

 Titre: Type Atelier 2 – Définition des tâches et activités

 Durée: 4 heures

Participants:

  • Coach agile
  • Un seul responsable fonctionnel pour tous les profils identifiés

OU

  • Un responsable par « catégorie » de profils (ex : découpage par service RH, Finances, etc…))
  • Un seul responsable fonctionnel pour tous les profils identifiés

 Objectifs

Définir les tâches des utilisateurs dans l’intranet
Listez, en vrac, les tâches qui seront réalisées par les profils identifies.

Exemple : Les gestionnaires peuvent créer un projet, ajouter des personnes au projet, etc. Les utilisateurs consultent les dernières nouvelles de…

Définir les regroupements de tâches sous forme d’activités
Parmi ces tâches, peut-on créer des regroupements définissant une activité plus globale pour un utilisateur ?

Exemple : Les gestionnaires peuvent gérer un projet, les utilisateurs peuvent consulter de l’information.

Définir l’ordre des tâches dans l’activité pour constituer une chaîne d’actions chronologique
Pour chaque activité, il y’a-t-il un ordre particulier dans lequel sont réalisées les tâches pour la compléter?

Exemple : La gestion de projet par un gestionnaire inclut en premier la création du projet, l’assignation et ensuite le suivi.

 Matériel nécésaire

  • Ensemble de post-it de couleur
  • Logiciel SpecLog
  • Rétroprojecteur
  • Tableau blanc et crayons effaçables

 Titre: Type Atelier 3 – Définition des histoires utilisateurs

 Durée: 4 heures

Participants:

  • Coach agile
  • Un seul responsable fonctionnel pour tous les profils identifiés

OU

  • Un responsable par « catégorie » de profils (ex : découpage par service RH, Finances, etc…))
  • Un seul responsable fonctionnel pour tous les profils identifiés

Note : Si un découpage par service de l’entreprise est envisagé, le nombre d’ateliers pour cette étape sera égal au nombre de services N avec à chaque fois un responsable des besoins. (N x 4heures)

 Objectifs

Définir les histoires utilisateurs découlant de chacune des tâches
Pour chacune des tâches identifiées dans une activité, est-il possible de découper en plusieurs actions plus granulaires ou spécifiques?

Exemple : Pour la tâche de création de projet, il faut que je sois capable de créer d’abord un projet de type A au minimum. Pour la tâche de suivi de projet, il me faut impérativement au minimum les heures facturables sous forme de tableau de bord.

 Matériel nécésaire

  • Ensemble de post-it de couleur
  • Logiciel SpecLog
  • Rétroprojecteur
  • Tableau blanc et crayons effaçables

Bien identifier ses interlocuteurs

Lorsque vous entreprenez de réaliser une définition de besoins, il est important avant toute chose de bien choisir vos interlocuteurs qui seront avec vous lors des ateliers. Pour cela, il va falloir identifier les « responsables produits ».

En méthodologie agile, un responsable produit est la personne garante des besoins présents dans un carnet de produit. Par conséquent, un responsable produit doit :

  • Connaître parfaitement le métier pour être en mesure de l’expliquer aux analystes fonctionnels (les comportements, détails, etc…)
  • Être en mesure de prioriser et choisir les fonctionnalités en fonction de leur coût et de leur valeur.

Pour de petits projets, cela est relativement maintenable, une même personne est capable de disposer de ces deux compétences. En revanche, dans le cas de plus gros projets, il est rare (et dangereux?) de laisser la définition et responsabilité des besoins à une seule et unique personne. Pour cela, il peut être intéressant de « découper » le carnet de produit principal par domaines métier avec un responsable de produit pour chacun, laissant ainsi la connaissance des besoins aux personnes pertinentes.

La priorisation finale et la décision finale reviennent au responsable produit principal.

Délégation des décisions

Autre élément important : le nombre d’interlocuteurs.

Ne jamais dépasser 3 interlocuteurs dans un atelier. Pourquoi? Pour éviter tout simplement les « combats de coq »  ou chacun essaie de prouver à l’autre comment cela doit marcher et prouver par A+B que sa fonctionnalité est plus importante.

Par expérience, au-dessus de 3 interlocuteurs, vous risquez de perdre beaucoup de temps en discussion inutiles.

Par exemple, ces personnes peuvent êtres

  • Un décideur : Le responsable du produit qui prendra les décisions sur les fonctionnalités à développer.
  • Un soutien au décideur : Une aide technique ou fonctionnel au décideur pour éventuellement compléter des inconnues.
  • Le coach agile : anime l’atelier en tant que représentant du fournisseur.

Conclusion

La définition de besoins est une phase primordiale dans n’importe quel système. Souvent négligée, sa rigueur est pourtant garante de la réussite de votre projet.

Avec SharePoint, il est coutume de se laisser influencer par les possibilités de l’outil. Cependant, à travers cet article, j’espère vous avoir donné envie de passer plus de temps sur l’étape d’analyse de besoins pour créer des solutions répondant le plus possible à la réalité.

La technique de l’User Story Mapping est un outil simple et très pédagogique pour y parvenir. De plus, dans le cadre de projets SharePoint, elle vous donne déjà une longueur d’avance sur votre gouvernance!

Dans les chapitres suivants, nous verrons comment réaliser une analyse fonctionnelle dans le cadre d’une seule histoire utilisateur.


+ There are no comments

Add yours