Découpage des User Stories

De Wiki Agile
Aller à : navigation, rechercher

Auteur : Clear Systems
Source : Splitting User Stories
Date : 03/04/2017


Traducteur : Fabrice Aimetti
Date : 06/05/2017


Traduction :

Splitting-user-stories-matryoshka.jpg
Selon une étude menée par Mike Cohn (Mountain Goat Software) sur 2000 pratiquants Agile, l'une des trois difficultés rencontrées lors de l'écriture des user stories consiste à consacrer trop de temps à essayer de découper les stories d'une manière cohérente pour construire quelque chose.

Et cette étude a identifié quatre problématiques principales :
- comment découper les stories de telle façon qu'elles apportent de la valeur tout en pouvant être terminée dans une itération ;
- comment éviter la tentation de découper les stories selon des domaines opérationnels (exemple : développement et test) ;
- comment consacrer le temps nécessaire et suffisant au découpage des stories pour ne pas y passer tout son temps et pouvoir construire quelque chose ;
- comment ne pas se perdre parmi les plus de cinquante manières différentes qui existent pour découper une story.

Mike a bâti un modèle pour découper les stories qui apporte au sujet de la simplicité, une structure et de la clarté. Il suggère que les sites internet qui formulent 30, 50, ... voire plus, manières différentes de découper des stories, ne font que créer de la confusion et qu'il n'existe tout simplement pas beaucoup de manières utiles de considérer ce problème. Il a donc synthétisé tout cela dans ce qu'il appelle le modèle SPIDR* :

Spikes : vous devez peut-être mener certaines recherches. Celui-ci est en fait à utiliser en dernier ressort lorsque les autres techniques du modèle SPIDR ne semblent pas fonctionner pour résoudre le problème.

Parcours : S'il existe plusieurs parcours alternatifs possibles dans une user story, vous pouvez peut-être les découper en plusieurs stories (mais pas forcément une story par parcours). Par exemple, le parcours nominal, le parcours optionnel, ...

Interfaces : Peut-être que votre première user story sera juste pour Androïd, ... ; vous fournirez peut-être une première interface utilisateur très simplifiée avec un nombre limitée de fonctionnalités.

Données : Peut-être que dans votre première itération pour développer un site de vacances, vous ne couvrirez que les visites de musées, puis un peu plus tard les visites de monuments, puis les activités en plein air, ...

Règles : Peut-être qu'à la première itération, vous souhaiterez qualifier les clients potentiels en vous basant sur leurs niveaux de solvabilité. Ce n'est pas forcément déployable, mais vous en apprendrez un peu plus. Puis vous les qualifierez selon leur pouvoir d'achat, leurs habitudes d'achat, ... Cela comprend également les contraintes réglementaires et non fonctionnelles.

Cette approche n'est peut-être pas parfaite mais elle constitue un cadre de travail simple pour, je pense, 80% des cas au minimum. Un autre modèle qui vaut le coup d'être regardé est How to Split User Story de Richard Lawrence (http://agileforall.com/author/rlawrence/).

J'aurais tendance à dire qu'être dense et mystérieux ce n'est pas être Agile. Si le fait de découper les user stories commence à ressembler à un art obscur, ou qui requiert de multiples niveaux de compétence avancés, faites marche arrière. Essayer plutôt d'utiliser des cadres de travail simples et regardez comment vous faites. Autorisez-vous à le faire et prenez confiance en vous.

J'espère que ça vous aide.

(*) Utiliser SPIDR pour Découper N'importe quelle Story, Mike Cohn (2017)
https://www.betteruserstories.com/training/videos/2