Planifier et suivre les livraisons du produit

1. La planification existe en agile

Le Manifeste Agile précise que l’une des valeurs fondatrices de l’agilité est de "s’adapter au changement, plutôt que suivre un plan". Ces propos sont souvent interprétés comme le fait qu’il n’y a pas de planification en agile, et encore moins de planification à long terme.

Certes, l’agilité privilégie le court terme au travers des itérations courtes afin de livrer petit et souvent, mais il ne faut pas oublier que la planification à moyen et long terme est nécessaire et doit également être réalisée. Bien évidemment, comme toute planification, le "planning" sera certainement revu à plusieurs reprises au cours du projet agile.

Pourquoi nous intéressons-nous à la planification dans cet ouvrage dédié à l’expression du besoin en agile ? Tout simplement parce qu’il existe un lien fort entre les items du Backlog de produit, qui contient les histoires utilisateur, et l’activité de planification. Nous devons considérer que l’histoire utilisateur est à la fois un support à l’expression d’un besoin du point de vue d’un utilisateur, mais également un élément de planification. L’un ne va pas sans l’autre. Les items...

1. Présentation de la feuille de route

La feuille de route matérialise le chemin envisagé pour atteindre la vision du produit. C’est une représentation visuelle et chronologique de la croissance ou de la maturation d’un produit sur une période donnée. Elle décrit les principaux aspects du produit au travers de phases et de jalons importants.

L’intérêt de réaliser une feuille de route est de donner du sens et de la visibilité sur le long terme, généralement à un, deux ou trois ans, mais également de permettre la définition des priorités et l’identification des principaux risques et des opportunités pour l’organisation.

La feuille de route permet de planifier les différentes étapes de la création ou de l’amélioration d’un produit tout en intégrant une dimension flexible. Elle ne constitue pas un planning, elle est plus simple et reste très macroscopique.

Figure 3 - Feuille de route

2. Construction de la feuille de route

La démarche de construction d’une feuille de route se déroule en phase de préparation (appelée aussi phase de cadrage ou de framing en agile) et suit les principales étapes suivantes :

1. Notion de Release

Dans un projet agile, la notion de Release peut ne pas être utilisée et les équipes peuvent travailler uniquement sur des itérations courtes. Dans la dernière version de Scrum (datant de novembre 2020), par exemple, la notion de Release n’existe pas. Il y a au moins deux cas de figure dans lesquels l’absence de Release peut fonctionner.

Le premier est le cas des projets simples, qui ne nécessitent généralement pas de mise en production lourde et qui doivent délivrer rapidement des solutions opérationnelles, directement utilisables par les utilisateurs. L’autre cas est le cas d’organisations matures en agile, qui peuvent "releaser" à chaque incrément de produit, sans attendre plusieurs Sprints pour le faire. C’est ce qu’on appelle l’intégration continue. Dans le cas précis d’absence de Release, la phase de préparation consiste à élaborer directement un train d’itérations. Cette période est souvent appelée Sprint 0. La durée de ce Sprint 0 est variable et peut varier de 15 jours à quelques semaines.

Néanmoins, le concept de Release peut être intéressant dans les cas suivants. Dans le cas de projets où la livraison du produit ne peut être réalisée que par l’intermédiaire d’un processus de mise en production lourd, les différentes réalisations des itérations sont regroupées pour être livrées en une seule fois aux utilisateurs finaux.

Dans le cas où le client et les utilisateurs n’ont pas besoin d’une livraison fréquente du produit mais ont plutôt des attentes fortes par rapport à une criticité temporelle, par exemple la mise en conformité au regard d’une réglementation.

Dans ces cas, les équipes livrent une version majeure du produit, appelée Release (ou Super Sprint), constituée de plusieurs Sprints.

En théorie, il est nécessaire que chaque Release contienne toujours le même nombre de Sprints. Mais en pratique, cette règle peut être assouplie (comme par exemple en période de congés importants) et nous pourrions imaginer...

1. Sprint Planning

Chaque début de Sprint commence par un Sprint Planning. C’est lors de cette cérémonie que sont retenues les histoires utilisateur à réaliser dans le Sprint et que sont identifiées les tâches de réalisation du Sprint. La détermination des User Stories candidates au Sprint Planning doit être anticipée bien avant le Sprint Planning où elles devraient être "ready". Pour chaque User Story, la liste des tâches est identifiée. Une tâche est une unité de travail nécessaire pour réaliser une User Story.

Une tâche peut être effectuée par un seul membre de l’équipe, tandis que la réalisation d’une User Story est de la responsabilité de toute l’équipe.

Durant cette cérémonie, le Product Owner doit préciser l’objectif du Sprint et le partager avec l’équipe de réalisation.

Figure 16 - Planification d’un Sprint

Pour suivre l’avancement de la réalisation des User Stories, un tableau de type Kanban est souvent utilisé....