[Agile conference] Construisez votre produit en racontant une histoire

Logo Agile ConferenceLors de l’agile conférence 2011, Laurence Anot nous a offert une présentation sur le sujet du Story Mapping. Il s’agit d’une méthode de travail rassemblant les protagonistes d’un projet afin de définir collégialement le product backlog. Durant la session, Laurence Anot nous a proposé une vision théorique du sujet, la complétant par son retour d’expérience. Elle nous a ainsi permis d’identifier certaines bonnes pratiques ainsi que les dérives possible.

La suite de cette article présente les étapes importantes de la mise en place du Story Mapping.

Qu’est ce que le Story Mapping ?

Une première approche de la description du Story Mapping a été abordée en introduction de cet article. Attardons nous sur certains détails. L’information première qu’il faut retenir est la construction du Product Backlog. Il est l’OBJECTIF de l’atelier Story Mapping. Toutes les actions qui y seront menées doivent garder en focus la production d’un backlog complet et précis.

Un aspect également important du Story Mapping est la dimension collaborative de l’activité. En effet afin d’obtenir un backlog digne de ce nom, il faut que les échanges soient les plus pertinents possible. Il faut donc définir les intervenants les plus efficaces pour mener l’atelier (Point abordé dans la suite de l’article).

Qui dit travail en équipe dit, mutualisation des informations, conservation de ces dernières, il faut donc un support de travail collaboratif voir interactif. Les équipes agiles sont familiarisées avec le paperboard, les post-it et le crayon, utilisons ces outils.

Reste à définir une présentation des informations, le Story Mapping propose une vision en graphe dont nous étudierons la construction dans la suite de l’article, la Story Map.

Nous voici donc avec une liste de principes qui vont régir l’atelier.

Mais attention, devons-nous utiliser le Story Mapping à tout va, existe-t-il des règles d’application ?

Laurence Anot au travers de son expérience nous indique qu’il existe des contraintes de mise en oeuvre, telle que l’adhésion des protagonistes du projet. Il faut que ces derniers acceptent de se retrouver dans une salle ensemble durant plusieurs jours afin de construire la Story Map.

Une autre contrainte étant l’instant judicieux pour mettre en place le Story Mapping. Heureusement, Laurence Anot et son expérience nous offrent des éléments de réponses. (cf point suivant)

Quand le mettre en oeuvre?

Selon que le projet soit à son commencement, ou que ce dernier soit déjà dans un état d’avancement important,  la méthode est applicable à des moments clefs :

Dans le cadre d’un nouveau projet :

  • En phase d’avant projet (analyse du besoin, estimation globale)
  • Iteration 0 (Construire le backlog)

Dans le cadre d’un projet existant :

  • Lors d’une transition vers scrum
  • Lors d’une nouvelle release

Comment l’implémenter ?

Plusieurs étapes doivent permettre de s’assurer de la qualité du backlog.

Définition des acteurs du Story Mapping :

Avant de cartographier le projet, il est important de définir les protagonistes de cette activité.
Un projet est généralement partagé en plusieurs équipes ( le pilotage (product owner, business analyst,marketting …) et les équipes d’implémentation …).
Afin de créer de la collaboration, il est important de créer une mise en cohérence entre ces différentes équipes. A ce niveau il faut fédérer, dans son élaboration, des membres de chacune d’elles autour de la Story Map. Chacun ayant sa propre vision du projet, de nombreuses questions et problématiques pourront ainsi être mises en avant, permettant de s’assurer la couverture d’un maximum de sujets.

Lorsque cette phase de définition des acteurs est cloturée, l’aspect technique de l’atelier peut commencer. Le contenu d’une Story Map est dirigé par la vision utilisateur du produit. Dans un premier temps il important de définir cette vision utilisateur. Lorsque cette étape sera définie, le découpage en fonctionnalité, la priorisation des tâches pourra commencer.

Définition d’utilisateurs (persona) :

Avant toute chose, il est important de ne pas oublier qu’il s’agit de développer des applications pour des utilisateurs et pour parvenir à appréhender leur vision, il est préconisé de se poser les questions suivantes :

  • Qui va utiliser l’application ?
  • Quels sont leurs rôles ?
  • Quelle sera leur utilisation de l’application, leur approche fonctionnelle?

Dans ce cadre une solution s’impose, mettre en place des persona (notion introduite dans les années 90 au monde de l’IT par Alan Cooper) dont les caractéristiques doivent répondre aux questions précédemment posées.
Leur rôle est de créer un consensus entre les différents utilisateurs du projet au travers de leur activités.

Nota : Attention à ne pas caricaturer un utilisateur au travers du persona.

Définition de scénariis utilisateur :

Suivant leurs rôles, leurs métiers, l’utilisation des fonctionnalités par les utilisateurs (persona) n’est pas la même. Il peut exister des actions communes qui pourront être mutualisées.

Dans cette phase, le groupe de réflexion va mettre en avant l’utilisation qu’aura le persona de l’application, quel sera le trajet parcouru pour réaliser son travail, son activité. Les chemins ainsi décrits pour chaque persona, définissent la colonne vertébrale de l’application. Certains chemins pourront être divergents ou convergents, ce qui pourra impliquer une mutualisation. Ces derniers sont définis au travers d’items de scénariis.

Exemple de scenario pour deux persona :

Pour le persona1 : login, effectuer une recherche sur les éléments A, modification d’un des éléments A de la recherche, association d’un élément B à l’élément A modifié.

Pour le persona2 : login, création d’un élement A, effectuer une recherche sur les éléments A pour visualisation

Nous pouvons donc constater par persona les scénario comme suit :

Définition des priorités :

A ce stade de la technique nous avons des utilisateurs qui possèdent chacun des chemins contenant des items différentes et/ou communes. A ce niveau d’avancement de l’atelier, le client a la possibilité de prioriser ces items.

Retour à l’exemple :

Nous pouvons constater que le login et la recherche sont des items communes. Seulement, le client considère que pour bien fonctionner il faut pouvoir créer un élément. La modification et l’association étant d’importance moindre. Les items définies par ordre de priorité seront :

  1. Login (Task 1).
  2. Effectuer une recherche sur les éléments A (Task 2).
  3. Modification d’un des éléments A de la recherche (Task 3).
  4. Association d’un élément B à l’élément A modifié (Task 4).
  5. Création d’un des éléments A (Task 5).

Voici donc le premier jet de la Story Map :

Lorsque les priorités dans le temps sont définies, l’équipe repart sur ces dernières afin d’affiner la fonctionnalité en redécoupant plus précisémment les items en sous-tâches. De nouveau une priorisation est faite et ainsi de suite jusqu’a ce que le degré de granularité soit de l’ordre de la story.

Voici une ébauche de ce que pourrait être le résultat :

Releases

Nous voilà avec une story map à partir de laquelle nous pouvons aisément créer le product backlog. Toutes les tâches définies en tant que Story l’alimenteront.

Qui plus est, depuis la map, le client est capable de nous fournir le “walking skeleton” d’une fonctionnalité / tâche. A partir de l’association de plusieurs squelettes, le client est en mesure de définir des releases, des MMF (Minimal Marketable Features).

Conclusion :

La story map est un excellent support de discussion :

  • Fédérateur de communication, d’interrogations
  • Permet d’identifier les points de dépendance avec l’extérieur ou entre chaque scénariis et tâches
  • Permet une analyse de risque rapide

Il est toutefois à noter que le Story Mapping n’a pas vocation à présenter des briques techniques mais des fonctionnalités. Les critères d’acceptation techniques, comme la charge utilisateur n’y sont, par exemple, pas identifiés.

Nombre de vue : 25

COMMENTAIRES 2 commentaires

  1. lpep dit :

    bonjour,

    si “pouvoir créer un élément” est prioritaire par rapport à “modifier” et “associer”, la task5 du “premier jet de la Story Map” ne devrait-elle pas se situer juste après la task2 ?

  2. Pascal Poussard dit :

    Bonjour,

    Il s’agit ici d’un exemple mais effectivement il pourrait être cohérent de définir les priorités en considérant le Persona 2 avec une plus grande importance.
    Dans ce cas, la task5 pourrait soit être en priorité par rapport à la task 2 ou bien avant la task 3.
    Cela dépend du cas client réel et ne remet pas en cause l’application de la Story Map.
    Ces priorités doivent avant tout être discuter avec les participants de l’atelier.

AJOUTER UN COMMENTAIRE