Débutant Intermédiaire

[ScrumDay 2015] L’art de manier les exigences agiles

logo-scrumday-2015-01Pour bien commencer le mois d’avril, rien de tel que d’aller à DisneyLand Paris pour y voir non pas Mickey et ses amis mais le ScrumDay, qui se déroulait pour la seconde année consécutive là-bas. Au fil des années, j’ai de plus en plus tendance à faire des rencontres et avoir des discussions fort intéressantes sur l’agilité et ce qui gravite autour que d’enchaîner les conférences. J’ai quand même eu l’occasion d’aller voir Alexandre Boutin qui nous a fait une session Back 2 Basics sur l’art de manier les exigences agiles.

La problématique

Cette session donc, est un rappel, un retour aux fondamentaux de l’agilité, précisément ceux qui concernent les exigences métier. La problématique de départ est la suivante : Comment faire pour découper un produit de manière cohérente pour avoir en sortie de n itérations un produit répondant aux besoins initiaux ? Alexandre utilise la métaphore de la bille géante (le produit) qui doit passer au travers d’un tamis (les itérations). Bien sûr, on peut découper le produit facilement, mais attention au résultat ! Ce que l’on veut éviter, c’est un millier de petits morceaux de billes à la sortie. On veut bel et bien une bille géante ! Pour résumer, ce que l’on voudrait, c’est faire grossir le produit comme une goutte d’eau. Comment faire ?

Le Story Mapping

Pour commencer, Alexandre a abordé une technique bien connue des Product Owners et des coachs : le Story Mapping. Popularisée par Jeff Patton, cette pratique consiste à visualiser un backlog en deux dimensions. Ses objectifs sont multiples :

  • Rendre visible le flux de production de valeur
  • Montrer les relations entre les fonctionnalités principales et leur décomposition
  • Aider à vérifier la complétude du besoin fonctionnel
  • Fournir un support simple à la priorisation
  • Permettre de s’assurer de la cohérence des releases planifiées

Construction

Comment construire une Story Map ? Tout d’abord une Story Map se représente sous la forme d’une timeline de post-its. En effet, le but est de décrire comment chaque utilisateur va utiliser le produit au fil du temps. En prenant l’exemple concret suivant : “Qu’avez-vous fait depuis la sonnerie du réveil pour arriver dans cette salle ?”, nous avons co-construit une Story Map en respectant les étapes suivantes :

  • Lister les actions utilisateurs (ce que font vraiment les utilisateurs avec le produit)
  • Classer de gauche à droite les actions utilisateurs (On crée l’axe horizontal)
  • Décomposer les usages, c’est-à-dire décomposer les actions en user stories (On crée l’axe vertical)

 

Important !

Un story mapping est subjectif ; il n’y a donc pas qu’une seule story map possible ! Et dans le cas d’un produit avec des profils d’utilisateurs différents me direz-vous ? Et bien il suffit de décomposer en type d’utilisateur, avec, au-dessus des post-its d’action utilisateur, des post-its de profil utilisateur, et un post-it “ALL” par exemple pour les actions communes à tous les profils.

UserStoryMapDefinitions

 

Trucs et astuces.

Quelques astuces qui vous seront bien utiles pour construire une story map, offertes gracieusement par Alexandre (décidément fort sympathique) :

  • Ne pas être trop strict sur l’organisation temporelle,
  • Alterner entre la discussion sur les usages et leur décomposition,
  • Créer une nouvelle colonne s’il y a beaucoup d’éléments dans la décomposition,
  • Ecrire lisiblement,
  • Ne pas hésiter à réécrire un post-it et à jeter le précédent.

Quelques règles à ne pas oublier !

  • Un story mapping se pratique avec les utilisateurs. Il permet de concentrer les énergies et générer des discussions riches sur le produit.
  • Chaque type d’utilisateur doit pouvoir sortir du story mapping avec de la valeur produite.
  • Un story mapping prend de la place, voire beaucoup de place. Plusieurs murs sont généralement requis pour un projet moyennement complexe.

Utilisation

Une fois votre Story Map construite et fièrement affichée, vous pouvez l’utiliser pour prioriser les user stories. Il suffit pour cela de faire glisser celles-ci vers le bas. En traçant des lignes horizontales vous pourrez également définir des versions. A ce sujet, Alexandre préconise de ne définir qu’une seule release à l’avance. Cela ne sert à rien d’en définir plus, il faut d’abord valider le fait de pouvoir terminer l’ensemble des stories de la release. D’autre part, les specs, avis, vont très probablement changer dans le futur, de nouveaux usages seront éventuellement identifiés, ce qui influera sur le contenu des prochaines releases. Il est important de prioriser par les bénéfices.

 

Trucs et astuces

Là encore, notre speaker nous gratifie d’une série de tips très intéressants :

  • Faire descendre plus de la moitié des post-its (pour des releases ultérieures).
  • Rassurer utilisateurs et stakeholders (ce qui est descendu sera fait, plus tard. Plus la V1 est petite, plus vite le produit sera mis en production).
  • Adopter une approche minimaliste, avec le MVS (Minimum Viable Solution).

 

Bénéfices

Revenons à notre problème de départ : comment découper un besoin efficacement ? Et bien les bénéfices du story mapping sont multiples :

  • Le découpage est réalisé de manière cohérente avec les participants,
  • Les éléments identifiés sont indépendants (ou presque),
  • Les éléments de plus haute priorité sont identifiés,
  • Le sous ensemble identifié (MVS) est complet et offre de la valeur aux utilisateurs.

Maintenant que nous avons vu ce qu’est le Story Mapping, passons à l’élément principal constituant une Story Map : la User Story.

User Story

Contrairement à ce que beaucoup pensent, la User Story ne vient pas de Scrum mais de l’eXtreme Programming. Nous avons droit à un petit rappel sur ce qu’est cet artéfact inventé par Kent Beck. Une User Story c’est :

  • un besoin utilisateur
  • une description du produit
  • un élément de planification
  • un support à l’échange
  • un mécanisme pour retarder la conversation

Bref, c’est un outil pour faciliter la conversation entre différentes personnes : les utilisateurs, les développeurs, les testeurs, les managers, le marketing, les business analyst, les ergonomes, etc.

Les 3C de Ron

Ron Jeffries, co-inventeur de l’XP, a inventé la formule des 3 C pour déterminer les composantes d’une User Story : Carte, Conversation et Confirmation.

 

Carte

C’est l’élément physique constituant la User Story. Elle contient les éléments suivants :

  • un titre
  • une description succincte utilisant un format pratique, comme par exemple le
    “En tant que [utilisateur],
    Je veux [faire quelque chose]
    Pour [atteindre un but précis]”
  • des notes, règles de gestion, visuels. bref tout ce qui peut être utile.

Exemple fil rouge de cette session :

 

Conversation

C’est un élément fondamental de l’écriture de User Stories. On les partage, le PO n’est jamais seul dans son bureau à rédiger toutes les US d’un projet. Une US évolue avec le temps et les discussions entre les différentes personnes impliquées dans le projet. Il arrive que l’on passe plus de temps à discuter de la User Story qu’à la coder !

 

Confirmation

C’est ce qui va permettre de démontrer et valider une User Story. Plusieurs techniques existent, comme les critères d’acceptation ou les tests d’acceptation.

Exemple :

  • Le pied de l’arbre est enterré
  • Un engrais naturel est déposé au fond du trou
  • La terre est tassée après la plantation
  • La plantation est abondamment arrosée

Un exemple de critère d’acceptation à éviter

  • Le trou fait 60cm de diamètre et 80cm de profondeur (on est dans le moyen, et non la valeur)
  • L’arbre est planté droit (idem, ceci serait plutôt dans une Definition of Done)
  • La pelouse est tondue autour de l’arbre (n’apporte pas de valeur)
  • Le panier pour récolter les fruits est acheté (pas de rapport direct avec la User Story)

Rappels

Une User Story, comme son nom l’indique, est orientée utilisateur. Sa mise à disposition impacte celui-ci. Pour écrire une bonne User Story, il faut donc raisonner “Valeur pour l’utilisateur” et non “Moyen de le faire”. En reprenant l’exemple fil rouge : qu’est-ce qui est important, le moyen de faire le trou ou l’arbre ?

Alexandre revient sur deux erreurs classiques à éviter :

  • Une User Story n’est pas un contrat !
  • Ne pas confondre livrable et résultat : les points gagnés sont différents de la valeur utilisateur !

Types de User Stories

Autre technique intéressante présentée au cours de cette session B2B (j’adore cette expression), le quadrant des types de User stories. J’en avais déjà parlé brièvement dans cet article. Cette technique développée par Claude Aubry permet de classer les User Stories selon deux axes : Visibilité et Valeur, et détermine ainsi 4 catégories de User Stories :

  • la Story fonctionnelle (visible des clients, apporte de la valeur)
  • la Story technique (visible des équipes, apporte de la valeur)
  • le bug fix (visible des clients, rétablit la valeur perdue)
  • le refactoring (visible des équipes, rétablie la valeur perdue)

typesUserStory

Pour ma part, j’emploie beaucoup cette technique auprès des équipes que j’accompagne. Je la trouve très efficace pour améliorer le management visuel.

Bénéfices

Alexandre nous résume les bénéfices des User Stories :

  • Elles apportent de la valeur aux utilisateurs
  • L’effort pour s’accorder sur une Story est raisonnable (conversation)
  • Elles sont indépendantes fonctionnellement
  • Elles sont petites et peuvent être terminées en 1 itération

 

Pratiques liées aux User Stories

Dernière partie de cette conférence, les pratiques liées aux User Stories étaient essentiellement focalisées sur le bon découpage d’une User Story.

Les 5 niveaux de détail d’Alistair

Alistair Cockburn, co-signataire du manifeste Agile, a défini 5 niveaux d’objectifs liés aux Use Cases

goalLevels
Cloud level – trop abstrait

Kite Level : Objectifs à long terme, sans aucune fin précise. Plusieurs opérations fonctionnelles

Sea Level : Je peux raisonnablement espérer réaliser cela en une seule opération fonctionnelle.

Fish Level : Un élément qui ne veut pas dire grand-chose unitairement. J’en ferai plusieurs pour réaliser une opération fonctionnelle.

Clam Level – trop détaillé.

 L’idéal est d’écrire des User Stories évoluant dans le “Sea Level”.

En reprenant notre fil rouge, une Story trop abstraite serait “Fruits naturels : en tant que jardinier du dimanche, je veux consommer des fruits naturels pour me faire du bien”, alors qu’une Story trop détaillée serait : “Avoir une pelle : En tant que jardinier du dimanche, Je veux une pelle à bout cassé pour creuser un trou de 80 cm”.

Bien découper une User Story

Il existe de nombreux patterns de découpage de User Story, comme par exemple découpage du workflow, major effort ou encore type de données. J’y reviendrai dans un article dédié. Il faut bien garder en tête qu’une User Story découpée apporte toujours de la valeur aux utilisateurs du produit.

Les étapes pour aider à bien découper une User Story sont :

  • Evaluer
  • Vérifier que la Story est INVEST (Indépendante, Négociable, Valorisable, Estimable, Small, Testable)
  • Découper
  • Créer une spike story (étude)
  • On reboucle !

 

Conclusion

Qu’elle fut riche et intéressante cette présentation !  Une session animée avec brio par Alexandre que j’ai toujours plaisir à aller voir en présentation. Au premier abord je pensais ne quasiment rien apprendre, mais ces rappels ponctués de trucs et astuces très pertinents concernant des sujets très familiers ont été les bienvenus ! A l’heure où les grands sujets théoriques sur l’agilité à grande échelle se bousculent, cette session back 2 basics a remis à plat quelques fondamentaux et donné des clés pour aider à répondre au mieux aux besoins des utilisateurs, ce qui est l’une des valeurs de ce pourquoi tout le monde était réuni ce jeudi 2 avril 2015 : l’Agilité.

Nombre de vue : 220

COMMENTAIRES 1 commentaire

  1. Alex dit :

    Merci pour cette restitution très fidèle de ma présentation faite au Scrum Day 2015
    Alex

AJOUTER UN COMMENTAIRE