Tu te demandes pourquoi il est important de faire un Release Plan, quand il faut le faire, qui doit y participer, comment le construire et le mettre à jour, ainsi que des conseils pratiques à prendre en compte ? Dans cet article, nous allons répondre à toutes ces questions de manière simple et directe. On te donnera même quelques exemples concrets pour que tu puisses bien comprendre comment ça marche. Alors, commençons !
Avant de plonger dans la Release Plan, il est important de bien comprendre la différence entre la Release Plan et la Roadmap, car ce sont deux notions distinctes à ne pas confondre.
Attention !
Release Plan n’est pas la Road Map
Roadmap (Feuille de route)
- La Roadmap est une vision stratégique à plus long terme du projet ou du produit. Elle identifie les principales étapes, les objectifs, les jalons et les fonctionnalités prévues pour le projet sur une période prolongée.
- Elle peut couvrir plusieurs versions du produit et peut même s’étendre sur plusieurs années.
- La Roadmap ne précise généralement pas les détails de chaque itération ou version du produit, mais elle définit plutôt les grandes lignes de la vision à atteindre.
Release Plan (Plan de déploiement)
- Le Release Plan est une planification à plus court terme qui se concentre sur la livraison spécifique d’une version du produit à un moment donné.
- Il découle souvent de la Roadmap, en identifiant quelles fonctionnalités ou éléments du produit seront inclus dans chaque version du produit.
- Le Release Plan est plus opérationnel et détaillé que la Roadmap, car il prend en compte les itérations (sprints) spécifiques.
POURQUOI FAIRE UN RELEASE PLAN
Le Release Plan est un élément important dans le cadre agile, et ce, pour diverses raisons :
Planification des Sprints
Le Release Plan permet de découper le projet en Sprints, des périodes de développement courtes et focalisées, où les “User Stories” sont concrètement réalisées.
Communication des Objectifs
Le Release Plan assure une communication claire des objectifs du projet aux membres de l’équipe, en s’assurant que tout le monde comprend les “User Stories” et les “Epics” à réaliser.
Alignement avec la Vision
Le Release Plan garantit que l’équipe travaille en alignement avec la vision du produit, en choisissant les “User Stories” qui contribuent le plus à cette vision.
Gestion des Dépendances
Il identifie les dépendances entre les “User Stories” et les “Epics”, aidant ainsi à organiser le travail de manière à résoudre ces dépendances de manière efficace.
Priorisation des User Story / Epics
Le Release Plan aide à prioriser les fonctionnalités (User Story) et les “Epics”, c’est-à-dire les ensembles de fonctionnalités plus larges, en fonction de leur valeur pour les utilisateurs et du temps nécessaire pour les développer.
Gestion des Risques
Le Release Plan permet de gérer les risques en identifiant les dépendances entre les “User Stories” et en planifiant les “Sprints” en conséquence.
Représentation des Jalons
Le Release Plan représente les jalons majeurs et nécessaires de la vie du produit et du projet, ce qui permet à l’équipe de se concentrer sur les étapes cruciales pour le succès.
QUAND FAIRE UN RELEASE PLAN
Le moment idéal pour créer un Release Plan est lorsque vous avez une vision claire, une liste d’éléments prioritaires, une compréhension des contraintes et une implication des parties prenantes.
Fréquence
Tout au long du projet : Sprint 0, à chaque Product Backlog Review, à chaque Sprint Review
1
Durée
- 2h à 4h de préparation
- 2h à 4h d’atelier
- 1h de mise à jour
2
Entrants
- Product Backlog à jour
- Estimation des User Stories (une macro estimation peut être suffisante)
- Story Map et Impact Map (le cas échéant)
3
Sortants
- A chaque Product Backlog Review : modifier le Release Plan si modifications des User Stories (ajout / suppression / nouvelle estimation)
- A chaque Sprint Review : modifier le Release Plan selon la Vélocité de l’équipe.
4
Fréquence
Tout au long du projet : Sprint 0, à chaque Product Backlog Review, à chaque Sprint Review
1
Durée
- 2h à 4h de préparation
- 2h à 4h d’atelier
- 1h de mise à jour
2
Entrants
- Product Backlog à jour
- Estimation des User Stories (une macro estimation peut être suffisante)
- Story Map et Impact Map (le cas échéant)
3
Sortants
- A chaque Product Backlog Review : modifier le Release Plan si modifications des User Stories (ajout / suppression / nouvelle estimation)
- A chaque Sprint Review : modifier le Release Plan selon la Vélocité de l’équipe
4
Qui Participe à l’Elaboration d’un Plan de Release
La participation des acteurs ci-dessous garantit une planification équilibrée, alignée sur la vision du produit et en tenant compte des besoins des utilisateurs finaux et des contraintes du projet.
Product Owner
Responsable de la définition des priorités et de la gestion du Backlog Produit. Il joue un rôle central dans la création du Release Plan.
Parties Prenantes
Y compris les sponsors, les utilisateurs finaux et d’autres intervenants, sont consultés pour obtenir des informations sur les besoins et les attentes. Leurs commentaires influencent la priorisation des fonctionnalités.
Équipe de Développement
Participe activement à l’élaboration du Release Plan en fournissant des estimations de complexité et de temps pour les “User Stories” et en contribuant à la planification.
Scrum Master
Facilite le processus de planification et s’assure que l’équipe suit les principes et les pratiques de Scrum ou de la méthodologie agile choisie.
Architecte / Expert Technique
Peut donner des macro-estimations en séance.
Indique les dépendances techniques entre les items.
Peut remonter les éléments techniques nécessaires à la planification (Technical Debt, chantiers transverses, …)
Responsable Qualité
assure la qualité en identifiant les tests nécessaires pour chaque fonctionnalité et pour l’ensemble du produit.
COMMENT CONSTRUIRE ET METTRE À JOUR UN RELEASE PLAN
Avant de commencer l’élaboration du plan de Release, il est essentiel de vérifier la disponibilité des prérequis suivants:
Vision et Objectifs du Projet
Il est essentiel d’avoir une vision claire du projet et de ses objectifs avant de commencer à planifier la livraison des fonctionnalités.
Roadmap Établie
La Roadmap, qui définit la direction globale du projet sur une période plus longue, sert souvent de base à la création du Release Plan.
Liste Priorisée d'Éléments
Vous devez disposer d’une liste d’éléments à livrer, tels que des “User Stories” ou des “Epics”, qui ont été priorisés en fonction de leur valeur.
Compréhension des Contraintes
Il est important de comprendre les contraintes du projet, telles que les délais, les ressources disponibles et les dépendances entre les éléments.
Implication des Parties Prenantes
L’implication des parties prenantes, y compris l’équipe de développement et les sponsors, est nécessaire pour s’assurer que le Release Plan est réaliste et aligné sur les attentes.
Échéancier Connu
Il est souvent utile d’avoir une idée des délais ou des dates cibles auxquels les versions du produit doivent être livrées.
Une fois que les prérequis ont été confirmés, il est important de structurer ton travail en trois phases:
1-Préparation initiale
- Prévoir environ 2h à 4h
- Identifier les Epics ou les User Stories des prochaines Releases projet
- Réaliser une macro-estimation
- Préparer les post-its des fonctionnalités (utiliser des couleurs de post-it pour illustrer les domaines ou autres)
- Préparer la Timeline projet : Sprints, jalons importants, …
2- Atelier de création du Release Plan
- Prévoir environ 2h à 4h
- Le Product Owner place directement sur le mur les post-its pour les prioriser au sein de chaque Sprint
- Tout en respectant les contraintes (Sprints, dépendances et capacité de production)
- Tout le monde participe librement à l’atelier
- Le Scrum Master et la Dev Team estiment une capacité de production prévisionnelle.
3- Atelier de mise à jour du Release Plan
- Prévoir 1h environ
- Le Scrum Master apporte au Product Owner l’ensemble des informations mises à jour (items du backlog, Vélocité de l’équipe)
- Le Product Owner met à jour le Product Backlog en tenant compte des informations de Vélocité et des dépendances.
RECOMMANDATIONS
Bien préparer cet atelier : en particulier le premier !
- Il est plus simple de travailler avec des Epics ou des regroupements de User Stories dans un premier temps (moins de post-it à manipuler & Informations plus claires)
Time Box
- Tenir le délai de l’atelier : il est toujours possible de travailler encore sur la Roadmap suite à l’atelier.
Espace
- Privilégier une grande salle accessible de tous pour un meilleur partage de l’information à l’ensemble des équipes
Jalons
- Identifier les jalons et enjeux business du projet (Les dates de pilotes, de mise en prod et Go-Live)
- Identifier les dépendances techniques et les macro-fonctionnalités “découpables”
Equipe distante
- Faire le travail dans les locaux du Product Owner.
- Partager les résultats simplement avec une photo et répliquer les priorisations dans JIRA.
Méthode participative
- Le Product Owner est responsable des priorisations au sein des Releases mais tout le monde doit participer librement afin d’avoir un Release Plan partagé
Pour les équipes distantes, il est possible également d’avoir une représentation du Release Plan sur un autre format : ppt ou excel. L’intérêt est d’avoir une vue macro du projet avec les principales dépendances et jalons
0 commentaires