Débutant

Un nouveau jeu made in SOAT pour découper vos User Stories : Le Split Poker est sorti !

Le découpage fonctionnel est tout un art, une compétence que les Products Owners et autres rôles fonctionnels se doivent de maîtriser pleinement pour réduire la complexité du projet et ainsi réussir à tenir les grandes promesses de l’agilité (conditions nécessaires, mais insuffisantes, nous sommes d’accord) :

  • Livrer plus vite
  • Casser l’effet tunnel
  • Laver plus blanc que blanc
  • Améliorer la qualité
  • Diminuer les risques

Dans le cas d’une équipe de réalisation, cela passe ainsi par le découpage fonctionnel de l’applicatif à produire. Aujourd’hui l’une des grandes problématiques pour tous ces rôles fonctionnels est l’efficacité du découpage fonctionnel. Par chance, le découpage est une compétence et donc, peut se travailler. Oui, mais comment apprendre efficacement et s’exercer en minimisant le côté parfois rébarbatif ? Une solution : la gamification !

C’est dans cette optique que j’ai créé le Split Poker, un petit jeu de cartes qui ludifie les sessions de découpage fonctionnelles et rend celles-ci plus efficaces. Rendons à César ce qui est à César, pour créer ce jeu je me suis largement inspiré des travaux de Richard Lawrence et de son célèbre poster How To Split a User Story. Explications.

1 jeu, 12 Patterns, 25 cartes

Les cartes

Le jeu comprend 25 cartes réparties en 2 catégories :
– les cartes exemples (12) : chacune contient un exemple de découpage d’US en appliquant un pattern précis
– les cartes questions (13): chacune contient une suite de questions à se poser pour savoir si l’on peut appliquer un pattern donné.

Chaque carte question va de pair avec une carte exemple ; cette paire est associée à un pattern de découpage particulier. Les plus observateurs auront tout de suite remarqué qu’il y a 1 carte question de plus que de cartes exemples ; en fait, pour l’un des 12 patterns, il n’y a non pas une mais deux cartes questions (sûrement un axe d’amélioration pour le jeu, d’ailleurs)

Les 12 patterns

1 : étapes de workflow

Si l’US décrit un workflow, elle peut être découpée en un workflow simple (deux étapes : la première et la dernière) puis enrichie avec d’autres US.


2 : Variation des règles métiers

Si la story décrit plusieurs règles métiers, notamment dans les critères d’acceptation, on peut tenter d’alléger la liste des critères en créant des US dédiées pour certaines règles.

3 : Effort principal

Parfois, une story nécessite d’implémenter un mécanisme interne complexe et / ou nouveau. Elle peut être découpée en implémentant le mécanisme avec une fonctionnalité basique, enrichie par de futures US. Prenez l’exemple de l’ajout du paiement par CB sur un site web. Dans un premier temps, seul un type de CB sera géré, avec tout le mécanisme adéquat. Puis, d’autres US vont enrichir cette feature, avec d’autres types de CB.

4 : Simple vs Complexe

Une fonctionnalité perçue comme ‘basique’ par les clients l’est en fait rarement. On peut généralement identifier un noyau fonctionnel plus simple au sein de cette fonctionnalité, que l’on pourra alors décrire dans une US dédiée.

5 : Variation des données

Un même traitement peut s’appliquer sur des données issues de sources différentes, dans des formats hétérogènes. L’exemple typique ? L’importation de données ! On peut séparer les types de formats à gérer en autant d’US, c’est facile à faire et ça réduit la complexité de vos US.

6 : Variation d’interface

Parfois, on se lance corps et âme dans la réalisation d’une interface ultra design avec des UX designers débordant de créativité, sans avoir validé l’intérêt de la soi-disant killer feature avec un prototypage simple. Le risque que la fonctionnalité ne soit finalement pas retenue est réel, aussi pour démontrer au plus tôt la valeur apportée, il peut être intéressant de découper la User Story au niveau de l’interface : avant de montrer ce superbe nouveau widget de calendrier dernier cri, un simple champ texte peut suffire à démontrer la feature se cachant derrière.

7 : Performance en deux temps

Les standards actuels en matière de performance vont de plus en plus haut, en particulier au niveau du temps de réponse de l’interface, plus encore que sur le temps de traitement derrière. On parle de performance perçue. Ce critère de performance peut arriver dans un second temps, après avoir montré la fonctionnalité sous-jacente. ‘Charger une liste d’auto-complétion’ (fonction, pas de performance particulière) puis ‘réduire le temps de chargement en dessous de 100ms’ (fonction optimisée) est un cas typique de découpage selon les performances attendues.

8 : Opérations

Lorsqu’une US décrit de multiples opérations, comme dans le cadre d’une implémentation de CRUD par exemple, chaque opération peut être décrite dans une US dédiée.

9 : Rôles utilisateurs

Quand une story implique plusieurs rôles, une possibilité intéressante à expérimenter est de séparer les spécificités d’implémentation liées à chaque rôle dans une story dédiée par rôle.

10 : Happy / Unhappy

Un découpage que j’aime beaucoup car il peut s’appliquer très souvent et est assez efficace. Il s’agit de séparer les scénarios décrivant un comportement ‘idéal’ de ceux décrivant des situations anormales, souvent liées à des erreurs de saisie utilisateur ou des risques de sécurité (je pense notamment aux Evil User Stories). Une story pour le scénario ‘tout va bien’, et une story par scénario avec erreurs, et hop ! Simple et efficace.

11 : Variation de plateforme

Web, Mobile App, Desktop, etc. La plupart des applications clientes sont déclinées sur plusieurs plateformes. Mettre le focus sur une plateforme en particulier pour une feature permet de réduire la complexité d’une US.

12 : Etude et implémentation

Il se peut que le découpage soit particulièrement délicat lorsque le besoin est flou ou très complexe. Dans ce cas, il est nécessaire de se focaliser sur un scope fonctionnel plus réduit et de reprendre les patterns de découpage sur ce sous-ensemble. Si cette étape n’est pas possible, la Spike Story vient à la rescousse ! Il est alors temps de formuler des hypothèses et de faire un minimum d’expérimentations pour y répondre. Dès lors, l’exercice de découpage peut reprendre, en utilisant les différents patterns précédents.

Voilà donc 12 patterns de découpage décrits dans le jeu de cartes. Passons maintenant aux règles.

Règles du jeu

Je vous donne 2 façons d’animer ce jeu. Celui-ci étant très libre, vous pourrez tout à fait inventer vos propres règles ! N’hésitez pas d’ailleurs à partager et donner vos feedbacks.

Animation 1

Un backlog est affiché dans la salle de réunion. On distribue les couples de cartes bleues/vertes successivement à l’ensemble des participants. Une fois la distribution effectuée, on déroule le backlog : pour chaque US supérieure à un seuil de complexité défini (allez, par exemple > 5 points) chacun va proposer un découpage par rapport aux cartes qu’il a en main. Le plus rapide prend la main ! On découpe en direct la User Story. On recommence jusqu’à ce que sa complexité soit réduite à un niveau acceptable par les membres de l’équipe.

Animation 2

Le backlog est affiché, et chaque participant va tour à tour lire les questions de sa ou ses cartes. Si le pattern est applicable, go ! On découpe alors immédiatement.

Obtenir le jeu

Le jeu est sorti en licence Creative Commons et est disponible en pdf prêt pour impression sur le lien ci dessous !

http://www.soat.fr/publications/split-poker-soat

Vos feedbacks sont les bienvenus, n’hésitez pas à nous contacter pour nous faire part d’idées pour améliorer le jeu (nouveaux patterns, règles alternatives…)

Sur ce, je vous souhaite un bon découpage !

© SOAT
Toute reproduction interdite sans autorisation de l’auteur

Nombre de vue : 1375

COMMENTAIRES 3 commentaires

  1. Romain Deneau dit :

    Article bien écrit, jeu intéressant : on va l’essayer à la MAF avec Fabien.

    Remarques :
    – Petite coquille dans le § “12 : Etude et implémentation” : manque un R dans “paticulièrement”
    – Dans le même § : qu’est une “Spike Story” ? Un petit lien explicatif serait intéressant.

  2. DELAGRANGE dit :

    Clair et précis
    merci

  3. Leonetti dit :

    Bonjour,

    Très intéressant ton approche. De mon côté j’ai proposé aux PO d’évaluer si les valeurs business (théorique) des règles de leur user story sont toutes les mêmes sinon on découpe. En outre pour ce qui est du contenu je leur faire répartir les critères d’acceptation en 3 catégories ( générique, spécifique et d’erreur).

    Dans la même veine il serait intéressant de pouvoir aussi revoir les stories inadéquates (celles parlant du produit, celles qui sont liées entre elles,….).
    En tous les cas merci je vais tester ton jeux

AJOUTER UN COMMENTAIRE