Story A4 : format de user-story très efficace

Une question qui revient souvent dans le monde des Product Owner et surtout ceux qui découvrent le métier ont souvent une question essentielle : comment faire une bonne user-story ? Et c’est pour ça que je vous présente ce format que je trouve très intéressant : le story A4.

Vous pouvez aussi regarder la vidéo de la minute agile qui traite du sujet :

Une user-story

Tous les Product Owner sauront vous dire qu’écrire une user-story c’est « En tant que [persona], je souhaite [souhait] » (un éventuel Afin de en plus) ; cependant ce format ne répond pas à l’ensemble des problématiques et ce n’est d’ailleurs pas le but.

Si vous vous voulez voir comment découper une user-story qui est une des étapes essentielles à la création de celle-ci, je vous propose d’aller voir cet article avant de continuer : voir l’article.

Dans un déroulement normal, votre Coach Agile vous proposera de faire un Definition of Done (and Ready) des user-stories afin de déterminer ce que sera une user-story complète ; c’est à ce moment là d’ailleurs qu’on définira également le format de la user-story.

Voici un article sur la Définition of Done : voir l’article.

Un format efficace dans beaucoup de projets : story A4

Avant de vous parler de ce format très classique, je vous rappelle qu’il ne s’adaptera pas forcément à 100% des projets mais je pense qu’il est applicable et efficace dans une bonne majorité.

Maintenant que le message est passé, voilà ce que contiendra une story A4 :

• Un identifiant (celui du logiciel utilisé est pas mal)
• Un Type de story
• En tant que [persona], je souhaite [souhait] afin de [but]
• Règles de gestion
• Tests d’acceptance

Voilà ce que ça donnerait sur une jolie feuille A4 si on veut matérialiser notre user story. En affichant cela sur un mur, ça permet d’avoir une vision rapide de comment écrire notre user-story :

Des logiciels comme Jira peuvent parfaitement s’adapter à ce format, il vous suffira d’avoir des droits d’administrateur. Sur Trello, il faudra plutôt utiliser le champ description et de créer des démarcations comme un enchainement de ==== entre chaque partie.

Story A4 : règles de gestion ?

Pour ceux qui arrivent un peu dans le métier de chef de projet, AMOA ou Product Owner, voici ce que sont les règles de gestion.

Les règles de gestion sont les règles métiers essentielles pour le développement de cette user-story. Ces règles sont écrites en français avec comme but de mettre le minimum de phrase ; aller au plus simple permettra d’aller au plus efficace car les développeurs comprendront plus vite vos demandes.

Il ne faut pas hésiter également à utiliser des listes classiques pour faciliter la lisibilité voire des signes connus de tous. Voici un exemple ci-dessous sur un panier d’un site e-commerce :

Je rajoute un élément supplémentaire d'un produit dans mon 
panier.

    - si quantité > stock alors erreur "pas assez de stock 
      disponible"
    - si quantité < stock alors on ajoute +1 à la quantité

Avouez que c’est très facile à lire comme ça et que nous comprenons directement le travail à effectuer. Si ce cas est relativement simple, l’idée est de faire au plus simple surtout pour les cas les plus complexes.

Story A4 : tests d’acceptance

Cette partie est un peu plus complexe à comprendre. Nous allons créer des phrases de façon très structurée qui vont décrire des scénarios qui valident l’ensemble de la user-story.

La façon de l’écrire sera très importante car le jour où vous désirerez faire de la BDD (Behavior Driven Development) ou ATDD, tout sera déjà préparé.

Dans le monde informatique, on a tendance à utiliser l’anglais pour écrire les scénarios car certains outils automatiques vont prendre les phrases écrites par le Product Owner pour automatiser la création de fonctions dans le code ; et les codeurs n’aiment pas les fonctions en français.

Qu’est-ce que la BDD ?

Sans aller dans le détail, la BDD (Behavior Driven Development) est une pratique Agile créée par Dan North en 2003 qui a pour but de créer des tests fonctionnels avec un langage naturel compris de tous.

Cette pratique encourage vivement le rapprochement des équipes techniques, des équipes fonctionnelles voire des équipes métiers.

Pour faire simple, la BDD a comme principes :

• La participation des équipes non techniques au projet pour écrire nos tests fonctionnels
• Des scénarios automatisés pour décrire des comportements afin de faire de la non régression
• Mieux comprendre le comportement attendu pour les équipes techniques.

Story A4 : comment écrire les scénarios ?

Voici un premier exemple de 2 scénarios que nous allons écrire pour notre panier de notre site e-commerce (exemple précédent) :

Scénario:
  Etant donné que je suis sur mon panier
  Et que j'ai un produit d'id "1234" en quantité "1"
  Et que le stock restant sur ce produit est de "0"
  Quand j'ajoute "1" quantité sur mon produit
  Alors mon panier affichera une erreur

Scénario:
  Etant donné que je suis sur mon panier
  Et que j'ai un produit d'id "1235" en quantité "1"
  Et que le stock restant sur ce produit est de "10"
  Quand j'ajoute "1" quantité de mon produit
  Alors mon produit aura "2" quantités

Nous avons ici les deux scénario qui répondent aux règles de gestion que nous avions écrit précédemment.

Les guillemets sont essentiels car ils permettent aux logiciels d’automatisation de tests fonctionnels d’envoyer des variables aux fonctions qui permettront de coder les tests. Sachant que les phrases sont identiques mais que seuls ces éléments changent, les outils sauront qu’il faudra appeler la même fonction.

Donc en tant que Product Owner, ne changez pas vos phrases si on fait deux scénarios identiques a l’exception d’éléments spécifiques comme par exemple la quantité car c’est ce qui permettra de capitaliser au maximum sur vos tests.

Ce fameux langage connus par des outils de tests comme Behat ou Cucumber s’appelle le Gherkin.

Plus loin dans les scénarios

Si nous venons de voir un scénario simple, il est possible de faire des scénario en mode batterie de tests en prenant plusieurs cas possibles grâce à un concept de tableau d’exemple :

  Plan du Scénario: Ajouter x quantité d'un produit
    Etant donné que je suis sur mon panier
    Et que j'ai un produit d'id "<idProduct>" en quantité "<quantity>"
    Quand j'ajoute "<add>"en quantité
    Alors mon produit aura "<quantityFinal>" quantités

    Exemples:
      | idProduct | quantity | add | quantityFinal |
      | 0         | 10       | 10  | 20            |
      | 15        | 5        | 20  | 25            |
      | 35        | 5        | 40  | 45            |

Vous en savez déjà pas mal pour pouvoir commencer à écrire vos tests en tant que Product Owner. Je pense qu’à présent tous les Product Owner qui seront passé par cette page vont à présent vous impressionner.

Conclusion story A4

Maintenant que vous avez toutes les clés en main, je vous souhaite de réussir à écrire des user-story complètes et de qualité.