Méthodes agiles

SCRUM
Knidiri Zakaria
Lean management
• Le lean management est un mouvement de
pensée né au Japon, en particulier dans l’industrie
automobile chez Toyota.
• Il veille à la réduction des pertes générées à
l’intérieur d’une organisation (industrie,
services...), pour une production dite « au plus
juste » (just in time).
• Les objectifs sont la réduction des cycles de
production, la réduction des stocks,
l’amélioration de la productivité et
l’optimisation de la qualité.
• Mary et Tom Poppendieck ont appliqué ces idées
dans le monde du développement logiciel.
Quels sont les principes du lean,
applicables au développement logiciel ?
1. Réduire les stocks : la quantité de tâches non réalisées ou en cours de réalisation constitue les stocks.
2. Éliminer les sources de gaspillage : toutes les activités qui n’apportent pas de valeur ajoutée au client sont pure perte ; les
anomalies du produit, les blocages ou situations d’attente d’une décision, des fonctionnalités développées mais non utilisées par
le client… sont autant de gaspillages.
3. Favoriser l’apprentissage : adopter une démarche d’amélioration continue (kaizen en japonais) faite de petites corrections
constantes au quotidien.
4. Retarder l’engagement : il ne s’agit pas de procrastination, mais de reporter la prise de décision au moment où l’on disposera de
davantage d’informations ; une décision prise dans l’urgence ou sans les informations ou la connaissance nécessaires est une
mauvaise décision, sur laquelle il faudra revenir. Il faut planifier la prise de décision en considérant toutes les options possibles,
sans spéculation, en disposant d’une meilleure clairvoyance et s’y tenir.
5. Livrer vite mais à un niveau de qualité élevé : livrer rapidement permet d’obtenir un feedback. Plus le cycle de développement est
court, plus l’apprentissage est rapide et la prise de décision aisée.
6. Impliquer l’intelligence des individus : les personnes impliquées sont les mieux à même de savoir comment elles vont procéder ;
on ne peut prétendre que le management détient l’unique vérité. La combinaison des intelligences et des expériences –
l’intelligence collective – améliore le processus de prise de décision et la qualité de ces décisions.
7. Optimiser l’ensemble du système et non une partie seulement. Chaque expert a tendance à considérer son domaine comme le
plus important (IHM, base de données…). C’est la performance de l’ensemble du système qui doit être privilégiée.
 Le Jargon

Terme Description
Sprint Est une itération
Backlog Est une liste de tâches ouvertes
Product Backlog Est une liste d’items ouverts pour livrer le produit
Sprint Backlog Est une liste de tâches ouvertes attribuées au Sprint
L’ÉQUIPE ou la Development TEAM C’est l’équipe de développement
La Scrum Team C’est l’ÉQUIPE + le Scrum Master + le Product Owner
Estimation Meeting C’est la réunion d’estimation
Sprint Planning Meeting C’est la réunion de planification de Sprint
Daily Scrum ou Stand-up Meeting C’est la réunion journalière de 15’ où l’ÉQUIPE inspecte et adapte, coordonne son effort
C’est la réunion de fin de Sprint où tous les acteurs du projet se retrouvent pour inspecter les
Sprint Review ou Revue de Sprint
livrables du Sprint
Rétrospective C’est la réunion d’inspection et d’adaptation de la Scrum Team
Objectif Nous perdons
la course de relais
« L’approche “course de relai” du développement de produit…
peut entrer en conflit avec les objectifs de vitesse maximale et
de flexibilité. A contrario, une démarche holistique ou «rugby»
où une équipe essaie d’aller au loin comme une unité, passant la
balle en arrière, peut mieux servir aujourd’hui les exigences de la
compétitivité.»
Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, January
198614
Est-ce que le
développement
logiciel est un
processus défini?
 Le modèle empirique

Le modèle empirique est

dépendant de fréquentes
inspections et adaptations
pour atteindre l’objectif.
La théorie SCRUM
SCRUM

• Les racines de Scrum se trouvent dans la publication de « The New

Product Development Game » de Takeuchi et Nonaka ; paru en 1986
dans Harvard Business Review, démontre la fin des approches
classiques dans le développement de nouveaux produits et met en avant
les vertus des petites équipes pluridisciplinaires intégrées et soudées
dans une stratégie plus flexible.

• Inspirés par cette nouvelle approche et par le lean management, Ken

Schwaber et Jeff Sutherland (signataires du Manifeste) ont développé
Scrum, en 1993.

• Le Scrum symbolise la solidarité et la force qui lient les membres de

l’équipe pour le succès de l’itération.
D’où vient le terme Scrum ?

• Le Scrum ou « mêlée » est un terme emprunté au rugby.

• En rugby, la mêlée a pour objectif « de reprendre le jeu rapidement, en
toute sécurité et équitablement, après une faute mineure ou un arrêt de
jeu;
• Dans la méthode Scrum, le Scrum désigne la réunion quotidienne (daily
scrum meeting) qui réunit l’ensemble des acteurs du projet pour dresser,
en un temps limité à quinze minutes, le bilan de la journée passée,
planifier celle qui commence et repérer les éventuels obstacles
rencontrés par chacun. Le Scrum symbolise la solidarité et la force qui
lient les membres de l’équipe pour le succès de l’itération.
• Mais la métaphore du rugby a des limites. selon Chief Metaphor Officer
Gaël Renault préfère l’analogie avec le football américain et le huddle,
moment tactique où l’équipe qui attaque se regroupe autour du
quarterback.
• On peut en effet se demander si le rugby est proche de la culture
américaine !
Scrum est un processus empirique
Le cycle de
vie Scrum
• Le cycle de vie Scrum est rythmé par des itérations de
quatre semaines, les sprints ; la liste des exigences
initiales, dressée et hiérarchisée avec le client constitue
le référentiel, le product backlog.
 • Avant chaque sprint, au cours d’une réunion de
planification, le sprint planning meeting, on
sélectionne, dans le product backlog, les exigences
les plus prioritaires pour le client qui seront
développées, testées et livrées au client ; elles
constituent le sprint backlog, un sous-ensemble du

Le cycle de product backlog.

• Au cours du sprint, chaque jour, une réunion

vie Scrum d’avancement – le Scrum ou mêlée – est organisée

avec tous les membres de l’équipe pour s’assurer
que les objectifs du sprint seront tenus.
• À la fin du sprint, une démonstration des derniers
développements est faite au client (Sprint Review
Meeting), puis une revue de fin d’itération, une
retrospective, donne lieu à un bilan qualitatif sur le
fonctionnement de l’équipe.
Scrum repose sur 3 pieds
10 Pratiques de base

1. Vision claire et partagée

2. Product Backlog entretenu
3. Product Backlog priorisé en fonction de la valeur métier
4. Items de backlogtriés par l’équipe
5. Daily Scrums
6. Sprints non perturbés ni par le Management ni par le(s) client(s)
7. L’Equipe ne délivre que des items «terminés»
8. Revue de Sprint collaborative
9. Rétrospective concentrée sur l’amélioration du travail et du processus de l’équipe et de l’organisation
10. Burndown Charts(graphiques de reste-à-faire)
Scrum vs
Modèle en
“cascade”
CONTENU
DE SCRUM
CONTENU
DE SCRUM
• Scrum n'est pas une méthodologie.
• Scrum ne fournit pas les réponses à
la manière de construire des
logiciels de qualité plus rapidement.
• Scrum est un cadre dans lequel le
jeu du développement de produit est
joué.
• Votre équipe joue et, le bon ou le
mauvais deviennent très visibles.
• Votre équipe est dans un processus
d’amélioration continue.
Le principe Pull
(tirer)
Le principe Pull (tirer) est essentiel pour le
fonctionnement efficace des équipes agiles.
Ce principe se distingue de l’approche Push
(pousser) et repose sur l’idée que le travail
est tiré par l’équipe en fonction de sa
capacité et des priorités, plutôt qu’imposé
par une autorité externe.
 Équipes auto-gérées Organisation traditionnelle
Orientées client Pilotée par le management
Force de travail constituée de spécialistes
Équipes auto- Force de travail multi-compétence
isolés
Peu de description de poste Beaucoup de description de poste
gérées
Information largement partagée Information limitée
vs Peu de niveaux de management De nombreux niveaux de management
Orientée Ensemble du Métier Orientée fonction/département
Organisation
Objectifs partagés Objectifs séparés
traditionnelle D’apparence chaotique D’apparence organisée
Emphatique sur l’hypothèse d’atteindre le
Emphatique sur la résolution de problème
résultat
Très fort engagement des “développeurs” Très fort engagement du Management
Améliorations continues Améliorations incrémentales
Autorégulées Contrôlées par le Management
Basées sur des valeurs et des principes Basées sur des politiques et des procédures
Les Règles
Rôles, Artifacts
et Time-boxes
 Catégorie de Rôles Rôles

3 Rôles Scrum La Development Team

Team
plus Rôles de l’Équipe Scrum
Le Scrum Master

3 Rôles Le Product Owner

organisationnels Le Management

Rôles organisationnels Le Client

Les Utilisateurs
Rôles de
l’Équipe
Scrum
Le Scrum Master
Le Scrum Master : Sa
fonction

• Protège l’équipe des turbulences

• Il n’est pas un membre de l’Équipe
• Il optimise la productivité de l’Équipe
• Il contrôle l’Inspect-&-Adapt” de l’Équipe
• Il assure que les idéaux “agiles” soient bien
compris et respectés par tous les participants
au projet.
• Il n’est pas responsable des déliverables.
Le Scrum Master : Sa
fonction

• Protéger l’Équipe Scrum

• Lever les obstacles
• Exécuter le process
• Travailler avec le Product Owner
• Changer l’Organisation
Le ScrumMaster
Rôles de
l’Équipe
Scrum
Le Product Owner
Le Product Owner : Sa
fonction

• Il pilote le projet d’un point de vue métier

• Il communique une vision claire du produit et
défini ses caractéristiques
• Il accepte ou rejette le produit à la fin de
chaque Sprint
• Il s’assure que l’Équipe se concentre sur les
items du Backlog de plus forte valeur ajoutée
• Il a le même objectif que l’Équipe
• Il est responsable du Retour sur
Investissement et des livraisons.
Le Product Owner : Sa
Mission

• Se concentre sur le retour sur investissement

• Construit et communique la vision
• Entretien le Product Backlog
• Rend compte de l’acceptance des délivrables
• Établi et maintien le Plan de Livraison
… dans Scrum?

PRODUIT : PROCESS :
SOUS LA RESPONSABILITÉ SOUS LA RESPONSABILITÉ
DU PRODUCT OWNER DU SCRUMMASTER
Rôles de l’Équipe
Scrum :
L’Équipe
L’Équipe : Sa fonction

• Elle délivre le produit et elle est responsable de

sa qualité
• Elle travaille avec les utilisateurs-finaux, le
client, le Product Owner pour comprendre les
exigences-métier.
• Elle s’engage volontairement
• Elle travaille continuellement avec le Product
Owner pour définir la direction stratégique du
Produit.
L’Équipe : Constituer
l’Équipe

• 5/9 personnes
• Multidisciplinaire
• Autogérée
• Cross-fonctionnelle / transverse
• Plus orientée compétence que fonction
Comment optimiser le
travail de l’Équipe...

• Créer une règle de vie de l’Équipe

• Ne jamais utiliser le “VOUS”
• Être à l’heure
• Utiliser un “bâton de parole”
• Ne jamais être nominatif
Collaboration

• Le Product Owner n’est pas un ennemi

• D’autres équipes ont besoin de savoir que nous
avons besoin d’elles.
• Nous avons tous le même objectif
• Une Équipe = un espace dédié à l’Équipe
Sa Mission

• Garantir la Qualité
• Livrer
• Livrer
• Livrer
• Estimer
• Estimer
• Estimer
• S’engager
• S’autogérer
• S’organiser .... Elle-même
 Les Rôles
Organisationnels
Les Rôles
Organisationnels :
Le Client
Le client : sa fonction

• Il demande le produit
• Il contracte l’organisation pour le développement de son produit
• Typiquement, il s’agit d’un responsable qui achète un développement de produit par
un sous-traitant.
• Dans les projets internes, il s’agit principalement du sponsor au projet, c’est à dire la
personne validant le projet et le budget.
Le client : Sa Mission

• Il commande le produit
• Il paye le développement du produit
• Il donne des feed-back et des révisions
Les Rôles
Organisationnels :
Le Manager
Le Manager : sa fonction

• Le management, la gestion, est primordial dans tout projet Scrum. Il permet à

l’Équipe de constituer un environnement optimal pour le déroulement du projet
Scrum.
• Le manager donne de la structure et de la stabilité.
• Il travaille de concert avec le ScrumMaster pour réorganiser l’organigramme de
la structure et donner de la guidance si nécessaire.
Le Manager : sa mission

IL S’ASSURE QUE L’ORGANISATION IL CRÉE DES RÈGLES ET DES LIGNES

PUISSE SURVIVRE EN CAS DE DIRECTRICES.
DÉFAILLANCE.
Les Rôles
Organisationnels :
L’Utilisateur Final
L’Utilisateur Final : sa fonction

Ce rôle peut être joué par un grand nombre de L'Utilisateur final est celui qui connaît les besoins et
personnes. avec cette connaissance, il définit le produit en disant à
l'équipe ce dont il a besoin comme fonctionnalités.
L’Utilisateur Final : sa mission

Il connaît ses Il donne son Il participe au

besoins et ses feed-backlors Sprint
exigences des revues Planning
 Catégorie de Rôles Rôles

COMMENT La Development Team

CES RÔLES Rôles de l’Équipe Scrum Le Scrum Master

TRAVAILLENT-
Le Product Owner
ILS
ENSEMBLE? Le Management

20 min Rôles organisationnels Le Client

Les Utilisateurs
COMMENT CES RÔLES
TRAVAILLENT-ILS ENSEMBLE?

• Le ScrumMaster travaille avec le Product

Owner
• Le ScrumMaster travaille avec la Development
Team
• Le Product Owner travaille avec le client
• La Development Team travaille avec
l’utilisateur final
• Le Scrum Master travaille avec le Manager
• Le Product Owner a besoin de connaître ce
que le marché (l’utilisateur final) souhaite.
LES ARTEFACTS
 4 Artefacts

PRODUCT SPRINT RELEASE SPRINT

BACKLOG BACKLOG BURNDOWN BURNDOWN
User Stories

• En tant que [rôle Utilisateur]

• Je veux une [FONCTIONNALITE]

• De sorte que je reçois [BUSINESS VALUE]

User Story Card

• Une brève description textuelle des

exigences

• + Risques

• + critères d’acceptation
Les bonnes Stories sont INVEST
 User Stories : étude de cas
10 min

Quels enseignements pouvons-nous tirer de ces

témoignages ?
Le Product
Backlog?
Le Backlog est une liste de tâches ouvertes
comme :
• Les exigences
• Une liste de tous les travaux souhaités
pour le projet
• Idéalement exprimé de telle sorte que
chaque objet a une valeur pour les
utilisateurs ou les clients du produit
• Priorisé par le Product Owner
• Repriorisé au début de chaque Sprint
Le Product
Backlog?
Le Product Backlog répond aux questions
suivantes:
• Quoi?
• Quand?
• Pour Qui?
Un backlog de produit

Élément de Backlog Rôle Estimation (points)

Un invité peut faire une réservation Invité 3

En tant qu'invité, j'annule une réservation Invité 5

En tant qu'invité, je change les dates d'une réservation Invité 3

En tant qu'employé de l'hôtel, je produis les rapports de revenu Employé de l'hôtel 8

Améliorer la gestion des exceptions Développeurs / Système 8

Autres éléments (estimations non détaillées) - 23

Total 50
 Exemple de product backlog

Quelles sont les différences entre un use case (UC) et une user story ?
Sprint Backlog

Tâches pour transformer le Product Backlog en fonctionnalité-produit

Tâches estimées en heures

• Une tâche ne doit pas nécessiter plus d’un jour ou deux pour être Done.
• Les grandes tâches sont découpées ultérieurement dans le Sprint

Les membres de la Dev. Team s’engagent sur les tâches une fois que le Sprint a démarré
• Les tâches ne sont jamais assignées

Le Sprint Backlog est revu journellement

• De nouvelles tâches sont identifiées, d’autres sont modifiées ou supprimées
• Les heures restantes de travail pour chaque tâche sont mises à jour

Les équipes sont mesurées en fonction de leurs engagements

• Et pas sur le temps nécessaire pour les réaliser
Release Burn down
Chart
• Le Release burn down rend les tendances des progrès visibles.
• Le rapport est basé sur les informations suivantes:
• le reste-à-faire du Product Backlog pour transformer la
Vision en un produit gagnant.
• Le nombre de Sprints nécessaires ou restants.
• La vélocité.
• Le Release burn down regarde le passé pour comprendre ce
que l'avenir est susceptible de détenir. Nous déterminons le
taux d'avancement des sprints passés.
Sprint Burn-down
Charts
Le Sprint Burn-down Chart montre :
• la quantité d'effort déployée pour
travailler sur les tâches contenues
dans le Sprint Backlog
• ET compare cette progression à la
dépense idéale.
Ce tableau offre une tendance qui permet
d'indiquer si l'équipe est susceptible de
respecter son engagement, agissant ainsi
comme un indicateur prévisionnel.
LES TIME-BOXES
LES TIME-BOXES : Au
niveau stratégique
Estimation Meeting
Préparation du Sprint Planning.

Réalisation d'estimations formelles.

Organiser au moins deux réunions par Sprint.

Effectuer des estimations basées uniquement sur

la taille et le temps des tâches.

Constitue un input clé pour le Release Planning

LES TIME-BOXES : Au niveau
tactique
Les Meetings

• Le Quoi?

• Le Comment?

• La Synchronisation

• Les Résultats

• L’Amélioration
LES TIME-
BOXES : Au
niveau
tactique
Daily
Meeting
LES TIME-BOXES : Au niveau tactique
Sprint Planning Meeting

ORGANISATEUR: PARTICIPANTS: DURÉE:

PRODUCT OWNER L’ÉQUIPE (ACTIF), LE SCRUMMASTER 8 HEURES POUR UN SPRINT DE 4
(PASSIF) SEMAINES
 2 PARTIES:

• Le QUOI?
• Le COMMENT?

LES TIME-BOXES LE PRODUCT OWNER:

: Au niveau • Présente le Product Backlog priorisé par le client et/ou les utilisateurs
• Présente le Release Plan Initial
tactique • Présentation de la Vision

Sprint Planning L’ÉQUIPE:

Meeting • Estime le Product Backlog en fonction de sa faisabilité (estimation

fonctionelle)
• Découpe le Product Backlog en Sprint Backlogs avec le Product Owner
• Découpe le Sprint Backlog en tâches
• Estime le Sprint Backlog

LE PRODUCT OWNER ET L’EQUIPE:

• Définissent l’objectif du Sprint

• Valident la Definition of Done
LES TIME-BOXES : Au
niveau tactique
Sprint Planning Meeting

• Quelle interface devons-nous designer?

• Quelle architecture devons-nous créer?

• Quelles tables devons-nous actualiser?

• Quels composants devons-nous mettre à

jour ou créer?
Definition of Done
 • Le Code est conforme aux normes
• Le Code est
• Propre
• Refactoré

Definition of Done • Testé unitairement

• Validé (checked in)
: Level of Done • Intégré (Built)
• Dispose d'une suite de test unitaire qui lui est
appliquée.

Pour l’EQUIPE • Pour arriver à cela, l’environnement de développement

est constitué:
• D’une bibliothèque de code source
• De codes standards,
• Build automatisé,
• D’un environnement pour les tests unitaires.
 • Une Story/Item est “done” lorsque l’équipe a atteint
Definition of son Level of Done
• Le Sprint/itération est “done” lorsque
Done : Level • tous les items sont “done”
• et que le Sprint atteint son objectif
of Done • et queles critères d’acceptation sont adressés.
• •La Release est “done”
• “done” pour l’intégration
Pour SCRUM • “done” pour la production
LES TIME-BOXES : Au
niveau tactique
Daily Scrum

Synchronisation /
Engagement sur les
tâches
 LES TIME-BOXES : Au niveau tactique
Daily Scrum

Participants:
l’équipe (actif), le
Organisateur: Durée:
ScrumMaster (passif),
l’équipe 15 min
Product Owner
(passif)
LES TIME-BOXES : Au niveau tactique
Daily Scrum

C’est l’inspect-and-adapt de l’équipe: Les 3 questions:

synchronisation et engagement
Qu’est-ce que tu as fait hier ?

Quels sont les problèmes que tu as rencontrés ?

Qu’est-ce que tu as prévu aujourd’hui ?

 Organisateur:
Product Owner

LES TIME-BOXES
: Au niveau Participants:
l’équipe (actif), le ScrumMaster
tactique (passif), le Management (actif), le
La Revue de client (actif), les utilisateurs (actifs)

Sprint
Durée:
4 heures pour un Sprint de 4 semaines
LES TIME-BOXES : Au niveau
tactique
La Revue de Sprint
• C’est l’inspect-and-adapt des utilisateurs, du
client et du management
• L’équipe présente les résultats du Sprint
• Utilisateurs/Client/ Management expriment
leurs remarques et trouvent un compromis avec
l’équipe
• Le Product Owner valide ou rejète les items du
Sprint Backlog en fonction de la Definition of
Done
• C’est le Product Owner qui a toujours le dernier
mot...
Quand un membre de l'équipe dit « DONE », ça veut dire quoi?

DISPOSE D’UN ENVIRONNEMENT

LE CODE EST CONFORME AUX
DE DÉVELOPPEMENT, POUR CELA
NORMES, EST PROPRE, A ÉTÉ RE-
IL FAUT UNE BIBLIOTHÈQUE DE
FACTORÉ, A ÉTÉ TESTÉ
CODES SOURCE, DES NORMES DE
UNITAIREMENT, A ÉTÉ VÉRIFIÉE, A
CODAGE, DES BUILTS
ÉTÉ BUILT, ET A EU UNE SUITE DE
AUTOMATISÉS, ET UN
TESTS UNITAIRES QUI LUI EST
ENVIRONNEMENT DE TESTS
APPLIQUÉE.
UNITAIRES
LES TIME-BOXES : Au niveau tactique
Sprint Review

Présentation (par l’équipe)

Feedback (par l’utilisateur final)

C’est l’inspect-&-adapt de l’utilisateur

permettant la création ou le changement
des items du Product Backlog
La Rétrospective

Participants:
l’équipe (actif), le
Durée:
Organisateur: ScrumMaster (actif), le
3 heures pour un Sprint
ScrumMaster Product Owner (actif en
de 4 semaines
sa qualité de membre de
l’équipe)
La Rétrospective

• Analyse du Process Scrum:

• Comment cela c’est passé pendant le
Sprint
• Comment s’améliorer
• Points principaux de vérification:
• La communication dans l’équipe
• Les relations entre les membres de
l’équipe
• Les process et les outils
• Les besoins en formation
Rétrospective

Nous faisons un point après l’action Objectifs:

en nous posant deux questions:
Qu’est-ce qui a bien fonctionné? Apprendre du passé pour préparer l’avenir
Que devons-nous améliorer? Améliorer la productivité de l’équipe
Finalité de la
Rétrospective

Où allons-nous à partir d’ici?

• Debriefing
• Amélioration
• Comprendre la réalité
• Apprendre
• “Input” pour le Sprint Planning
Planifier avec une démarche agile
La planification entre démarche prédictive et agile
La planification
entre démarche
prédictive et agile
Dans une approche agile, on distingue cinq
niveaux de planification; ils correspondent aux
différentes étapes qui rythment le projet :
• Établissement de la vision,
• Fixation des jalons,
• Planification d’une release,
• Planification d’une itération,
• Planification quotidienne.
On ne croit pas aux plannings détaillés en
amont, au contraire, on s’attache à avoir un
niveau de détail adapté à notre niveau de
visibilité et de prévisibilité
Niveau 1 : vision du produit
• Il s’agit du niveau de planification global établi • À ce stade d’avancement, les
à partir de la vision du produit et du product fonctionnalités ou exigences ne sont
backlog ; il correspond au plan initial ou
enveloppe globale, évoqué précédemment, pas homogènes en granularité.
commun aux deux approches. La vision indique
la ligne d’arrivée.
• Il s’agit pour l’équipe d’évaluer très
grossièrement l’importance/la taille
• Dans cette démarche, on veille avant tout à
disposer d’une vision et d’un product backlog
des différentes fonctionnalités afin de
(PB) priorisé par le client. les positionner dans les différentes
• Rappelons que ce PB est la pièce maîtresse du versions (releases) du produit.
dispositif : c’est le référentiel ou « file d’attente »
contenant les fonctionnalités attendues et
toutes les exigences non fonctionnelles.
 1. Approche itérative et par étapes
• Livraison de versions successives du produit (releases).
• Releases basées sur les priorités définies par le client.
2. Caractéristiques d’une release
Niveau 2 : • Durée : Environ 3 à 6 mois.
• Ventilation des fonctionnalités selon :

« roadmap »
• Contraintes client.
• Événements marketing.
• Stratégie d’entreprise.

ou jalon 3. Visibilité et flexibilité à moyen terme

• Roadmap établie à titre indicatif, avec des priorités ajustables.
• Modifications possibles selon :
• Résultats des itérations.
• Demandes du client.
4. Facteurs externes influents
• Les dates des releases ne sont pas fixes.
• Facteurs externes (comme des contraintes ou opportunités)
influencent la durée et le contenu des releases.
Niveau 3 : plan de la
release

• Une release se définit par une date de début et

une date de fin, un thème et une sélection de
fonctionnalités à implémenter. À l’intérieur d’une
release, on définit des itérations, auxquelles sont
affectées les différentes stories.