Skip to content
Méthode agile : Les histoires

En méthode agile, on appelle une « histoire » un ensemble de tâches et d’actions liées entre elles.

Méthode agile : Les histoires

Méthode agile : Présentation générale

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.

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. 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.

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 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.

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.
  • 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.
  • 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.

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.

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.

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.

Sources

Nous suivre
© 2020 Coppint Market Place Ltd, All rights reserved.