Méthode agile : Les histoires
Published: 2021-11-09 22:19:55

---
title: Méthode agile : Les histoires
published: true
date: 2020-03-16 15:12:35 UTC
tags: 
canonical_url: https://blog.limawi.io/fr-fr/posts/methode-agile-les-histoires/
---

Méthode agile : [Présentation générale](https://blog.limawi.io/fr-fr/posts/methode-agile-presentation-generale/)

Il y a plusieurs types d’histoires mais elles ont en commun d’avoir un objectif, de pouvoir être estimées (ou décomposée en éléments estimables) et d’avoir une définition du « _DONE_ » claire (une fin claire).

Ces unités permettent de décomposer un projet clairement afin de pouvoir être réalisé de la façon la plus efficace possible.

<video controls preload="auto" width="100%" poster="https://blog.limawi.io/fr-fr/posts/methode-agile-les-histoires/videos/les-histoires-les-grandes.png" playsinline><source src="https://blog.limawi.io/fr-fr/posts/methode-agile-les-histoires/videos/les-histoires-les-grandes.webm" type="video/webm">
</source></video>

<small>Ces unités permettent de décomposer un projet clairement afin de pouvoir être réalisé de la façon la plus efficace possible</small>

<video controls preload="auto" width="100%" poster="https://blog.limawi.io/fr-fr/posts/methode-agile-les-histoires/videos/les-histoires-les-petites.png" playsinline><source src="https://blog.limawi.io/fr-fr/posts/methode-agile-les-histoires/videos/les-histoires-les-petites.webm" type="video/webm">
</source></video>

<small>Chaque histoire doit avoir une définition claire du READY (ou TODO) et le plus souvent du DONE</small>

## Voici un panel (non exhaustif) des différents types d’histoire

- Tâche : Pas vraiment une histoire en tant que telle mais c’est l’unité atomique sur laquelle une histoire est construite. Elle doit être la plus simple possible. Par exemple, si l’histoire consiste à « rentrer dans une maison », la tâche est « poser la main sur la poignée de porte », la tâche suivante « tourner la poignée », etc.
- _Story_ : C’est le type d’histoire le plus connu en méthode agile. Elle est centrée sur l’interaction avec l’utilisateur final. Pour ne pas confondre histoire et _Story_ en anglais, le terme « _User Story_ » est préféré. Elle permet de réaliser une fonctionnalité.
- NFR : C’est le type d’histoire le plus dur à définir. NFR veut dire « _Non functional requirements_ ». Ce sont toutes les actions nécessaires à la bonne marche du projet mais qui n’affectent pas l’interaction de l’utilisateur final avec le projet. Par exemple, une refactorisation de code, un changement de licence, la mise en place d’un nouveau serveur de développement ou d’une machine à café pour l’équipe.
- Spike : Cette histoire permet de formaliser les étapes de recherche. Elle a une définition du DONE différente des autres car le principe de la recherche est qu’on ne sait pas ce qu’on va trouver.
- Epic : Cette définition varie suivant qui l’utilise. Généralement, elle définit une histoire dont l’estimation dépasse la possibilité d’un Sprint. Elle doit donc être découpée en histoires plus petites.
- Initiative : Utilisée par [JIRA](https://www.atlassian.com/agile/project-management/epics-stories-themes). Elle regroupe un ensemble d’Epics qui sont liées par un but commun.
- Thème : Cette histoire regroupe des Epics ou initiatives dont l’ensemble une fois fini forme un changement majeur pour une large portion de l’organisation (ou entreprise).
- Saga : Ce terme est peu utilisé (mais je l’aime bien) et peut se confondre avec le thème ou l’initiative. Il donne une note plus dans la continuité du terme « épique ». Il peut permettre de définir la racine du projet, de l’arbre des histoires. Du coup, je propose « _Yggdrasil_ » pour nommer l’arbre des histoires, pour rester consistant dans les termes.

![L'arbre des histoires, Yggdrasil](https://blog.limawi.io/fr-fr/posts/methode-agile-les-histoires/images/les-histoires-en-methode-agile.png)<figcaption><p>Les histoires en méthode agile</p>
    <small>L'arbre des histoires, Yggdrasil</small>
  </figcaption>

## Début et fin d’histoire

Chaque histoire doit avoir une définition claire du READY (ou TODO) et le plus souvent du DONE.

C’est à dire que le _[Product Owner](https://blog.limawi.io/fr-fr/posts/les-roles-dans-une-equipe-agile/)_ et l’équipe agile doivent s’accorder sur les prérequis nécessaires au démarrage de l’histoire (le READY). Pour le DONE, ils doivent définir le cahier des charges qui permet de s’assurer qu’une histoire est réellement finie. À noter que des histoires comme l’epic, le thème, l’initiative ou la saga n’ont pas de définition de DONE si ce n’est le DONE de toutes les histoires qui les composent.

## Certaines histoires en détail

### La User Story

L’histoire la plus connue de la méthode agile. Ce type d’histoires permet de créer de la valeur fonctionnelle pour l’[utilisateur final](https://dev.to/micheelengronne/le-user-persona-3jdc-temp-slug-3385429).

Une définition du READY : Une story doit avoir un départ clair selon l’acronyme INVEST ci-dessous :

- _Independent_: Chaque _Story_ doit être indépendante de tout autre tâche.
- _Negociable_: Chaque story doit pouvoir être discutée pour décrire au mieux le parcours utilisateur qu’elle fournit :
  - _Given a state_ (étant donné un état)
  - _When an action_ (quand une action)
  - _Then a result_ (alors un résultat)
- _Valuable_: Chaque _Story_ doit effectivement apporter de la valeur au produit du point de vue de l’[utilisateur final](https://dev.to/micheelengronne/le-user-persona-3jdc-temp-slug-3385429).
- _Estimable_: Chaque _Story_ doit pouvoir être estimée en tant que nombre de points de complexité qui aboutissent à une estimation du temps.
- _Small_: Chaque _Story_ doit être suffisamment petite pour pouvoir être réalisée par une ou peu de personnes dans un _[Sprint](https://dev.to/micheelengronne/le-sprint-et-le-scrum-266b-temp-slug-9950697)_.
- _Testable_: Chaque _Story_ doit pouvoir être testée dans un outil de test en intégration continue.

Une définition du DONE : Une _Story_ doit avoir une fin claire définie à l’avance avec un certain nombre d’objectifs à définir.

Exemple de DONE :

- Documentation générée
- Tests fonctionnels passés
- Tests de sécurité passés

### Le NFR

Le NFR est un type d’histoire agile qui ne s’occupe pas de l’[utilisateur final](https://dev.to/micheelengronne/le-user-persona-3jdc-temp-slug-3385429).

Le NFR signifie « _Non functional requirements_ » (requis non fonctionnels).

Il permet de résoudre les tâches nécessaires au bon déroulement du projet mais qui n’ont aucune visibilité pour l’[utilisateur final](https://dev.to/micheelengronne/le-user-persona-3jdc-temp-slug-3385429).

Exemple :

- Questions légales
- Questions de sécurité
- Questions d’organisation
- Questions de performances
- Questions d’infrastructures

Un NFR a peu de différence avec la _Story_ à l’exception de l’aspect centré sur l’[utilisateur final](https://dev.to/micheelengronne/le-user-persona-3jdc-temp-slug-3385429).

Un NFR doit être SMART  :

- _Specific_: compréhensible par tous
- _Mesurable_: avec un DONE (un objectif) clairement défini
- _Achievable_: réalisable
- _Relevant_: pertinente
- _Time-Boxed_: court dans le temps et estimable en points de complexité

Il doit avoir une claire définition du READY et du DONE.

### Le Spike

Quand on veut faire de la recherche en méthode agile, on utilise ça.

Le _Spike_ (la pointe) cherche à préciser les étapes, savoirs et temps nécessaires pour résoudre les _Stories_ et NFR.

Il doit être indépendant et testable ; mais il est, par essence, non estimable. En effet, quand on cherche on ne sait pas ce qu’on va trouver donc impossible d’estimer.

Pour pallier à ce manque d’estimation, il est time-boxé (avec un temps défini).

> Exemple : Rechercher un remplacement pour CouchDB en 24 heures (3 jours)

Un _Spike_ doit être SMART :

- _Specific_: compréhensible par tous
- _Mesurable_: avec un DONE (un objectif) clairement défini
- _Achievable_: réalisable
- _Relevant_: pertinente
- _Time-Boxed_: court dans le temps

Il doit avoir une claire définition du READY et du DONE.

Le DONE, dans ce cas, définit l’objectif, la direction de la recherche. Il permet d’estimer si la recherche est valable.

En effet, si l’objectif est de rechercher une nouvelle méthode pour faire une tarte à la framboise et que le résultat de recherche est un ensemble de méthodes pour créer ses croquettes pour chat, et bien ce n’est pas DONE.

![Chaque histoire doit avoir une définition claire du READY (ou TODO) et le plus souvent du DONE](https://blog.limawi.io/fr-fr/posts/methode-agile-les-histoires/images/histoires-estimables-en-methode-agile.png)<figcaption><p>Histoires estimables en méthode agile</p>
    <small>Chaque histoire doit avoir une définition claire du READY (ou TODO) et le plus souvent du DONE</small>
  </figcaption>

## Sources

- L’expérience Limawi
- [Scrum Expert](https://www.scrumexpert.com/knowledge/using-sagas-as-a-strategic-view-of-epics)
- [My Agile Partner](https://blog.myagilepartner.fr/index.php/2018/01/29/epic-agile/)
- [Atlassian](https://www.atlassian.com/agile/project-management/epics-stories-themes)

<video controls preload="auto" width="100%" poster="https://blog.limawi.io/fr-fr/posts/methode-agile-les-histoires/videos/story-les-histoires.png" playsinline><source src="https://blog.limawi.io/fr-fr/posts/methode-agile-les-histoires/videos/story-les-histoires.webm" type="video/webm">
</source></video>