Feuille de route
Ci-dessous se trouve une description concise de la façon dont nous planifions et exécutons notre travail tout au long de l’année. Elle est destinée aux clients et partenaires qui souhaitent avoir une vue d’ensemble de notre approche trimestrielle, de nos sprints de deux semaines et de la manière dont nous gérons la PI (Program Increment) Planning deux semaines avant la fin de chaque trimestre.
Pourquoi est-ce important pour vous
- Jalons transparents : Vous saurez exactement quand les sprints commencent et se terminent, et à quel moment se déroulent les événements de planification majeurs (PI Planning).
- Contacts réguliers : Chaque sprint comprend une réunion de revue (ou démo) où vous pouvez voir les avancées, donner votre avis et demander des ajustements.
- Alignement proactif en fin de trimestre : Organiser la PI Planning deux semaines avant la fin du trimestre nous permet de nous adapter aisément aux priorités du trimestre suivant, sans précipitation.
Travailler ensemble
- Restez impliqués : Vos retours lors des revues de sprint et des sessions de planification guident nos décisions sur les fonctionnalités, les correctifs et les priorités.
- Anticipez : Grâce à des jalons répartis toutes les deux semaines (pour les sprints) et chaque trimestre (pour la PI Planning), vous pouvez adapter vos propres échéances métier ou de publication en conséquence.
Aperçu des éléments de travail
AI Smarttalk gère deux grands types d’éléments de travail entrants :
- Fonctionnalités (Features) – Nouvelles fonctionnalités ou améliorations de fonctionnalités existantes.
- Incidents (Bugs) – Défauts ou problèmes au sein de fonctionnalités existantes, nécessitant une correction.
Vous trouverez ci-dessous un aperçu rapide de la façon dont les fonctionnalités et les incidents (bugs) progressent généralement dans notre processus :
| Type d’élément | Moment de la revue | Flux de priorité typique | Cadence de planification |
|---|---|---|---|
| Fonctionnalités | Revues de priorisation bihebdomadaires | Accepté (vers backlog) / Reporté / Rejeté | Détaillé lors de la PI Planning (tous les 3 mois) |
| Incidents (Bugs) | Triage continu ; bugs critiques analysés dès que possible | Hotfix (si critique) / Bugfix (si moins critique) | Peut être inséré dans le sprint en cours ou le suivant |
Plan annuel – Aperçu
Nous divisons l’année en quatre trimestres (Q1, Q2, Q3, Q4). Chaque trimestre couvre généralement trois mois, et nous utilisons des sprints de deux semaines pour découper notre travail. Cette approche garantit :
- Des mises à jour régulières selon un calendrier prévisible.
- Des boucles de retour fréquentes, où vous pouvez partager vos idées et orienter le projet.
- Une adaptabilité en cas de changement de priorités en milieu de trimestre.
Principaux repères
-
Sprints (tous les 2 semaines)
- Nous menons une série de sprints de deux semaines tout au long du trimestre. Chaque sprint se termine par une revue du travail accompli et une planification de la suite.
-
PI Planning (2 semaines avant la fin de chaque trimestre)
- Deux semaines avant la clôture de chaque trimestre, nous organisons une session de PI Planning.
- Pourquoi 2 semaines avant ? Ce calendrier nous permet de disposer de suffisamment d’informations, de retours utilisateurs et de disponibilité de l’équipe pour finaliser les objectifs du trimestre suivant, sans perturber le tout dernier sprint.
-
Transition de trimestre
- À la fin de chaque trimestre, nous compilons les conclusions des revues de sprint, intégrons les derniers retours et préparons les objectifs du prochain trimestre.
Comment se déroule généralement un trimestre
Un trimestre (par exemple, Q1, du 1er janvier au 31 mars) comporte 6 sprints d’environ 14 jours chacun. Voici le déroulement habituel :
- Du Sprint 1 au Sprint 5 – Cycles de développement normaux, chacun durant deux semaines.
- PI Planning – Se tient vers le cinquième ou sixième sprint, environ deux semaines avant la fin du trimestre.
- Sprint final & clôture – Nous utilisons le dernier sprint pour finaliser les livrables et traiter d’éventuels points en suspens. À la fin du trimestre, vous disposez d’une vision claire des fonctionnalités terminées, des problèmes résolus et des étapes à venir.
- Q1 s’étend du 1er janvier au 31 mars (environ 90 jours).
- Q2 s’étend du 1er avril au 30 juin, etc.
- Chaque trimestre inclut un jalon (PI Q1, PI Q2, etc.) deux semaines avant la fin du trimestre (par ex., Q1 se termine le 31 mars, PI Q1 est fixée au 17 mars).
Remarque : Cette structure (6 sprints par trimestre, 2 semaines chacun) peut légèrement varier selon le calendrier réel, les jours fériés ou les besoins spécifiques du projet. Néanmoins, la cadence de sprint bihebdomadaire et la PI Planning avant la fin du trimestre restent constantes pour vous offrir des jalons prévisibles.
Lexique
Voici un lexique des termes couramment utilisés dans notre méthodologie de développement :
Sprint
- Définition : Période de temps (généralement 1 à 2 semaines) durant laquelle l’équipe se concentre sur un ensemble d’objectifs (user stories, tâches) afin de livrer un incrément de produit fonctionnel.
- Objectif : Permettre des itérations rapides, une visibilité fréquente sur l’avancement et une capacité d’ajustement à chaque fin de sprint.
PI (Program Increment)
- Définition : Intervalle de temps plus long (souvent un trimestre, ~8 à 12 semaines) regroupant plusieurs sprints.
- Objectif : Planifier et aligner les équipes sur des objectifs stratégiques plus larges, tout en laissant place à des ajustements à plus long terme que le sprint.
Backlog
- Définition : Liste priorisée de fonctionnalités, d’améliorations et de corrections à mettre en œuvre. Elle est maintenue par le Product Owner ou l’équipe produit.
- Objectif : Garantir que l’équipe travaille en priorité sur les éléments à plus forte valeur ajoutée pour le produit ou le projet.
User Story
- Définition : Description concise d’une fonctionnalité, du point de vue de l’utilisateur (« En tant que [type d’utilisateur], je veux [capacité], afin de [bénéfice] »).
- Objectif : Se focaliser sur la valeur utilisateur et clarifier les besoins fonctionnels.
Epic (Épopée)
- Définition : User Story de grande ampleur, généralement décomposable en plusieurs stories plus petites.
- Objectif : Gérer et structurer des fonctionnalités complexes ou des projets de grande envergure.
Release
- Définition : Livraison d’une version stabilisée du produit vers l’environnement de production ou vers les utilisateurs.
- Objectif : Mettre à disposition de la valeur utilisable et recueillir des retours concrets.