Méthodologie de conception Objet DSI3.

Chapitre 3: les Méthodes Agiles

La méthode SCRUM Exemple

I. L'approche Agile:

Les méthodes agiles caractérisent un mode de gestion des projets informatiques

privilégiant le dialogue entre toutes les parties prenantes, clients, utilisateurs,
développeurs et autres professionnels du projet, la souplesse en cours de réalisation, la
capacité à modifier les plans et la rapidité de livraison. Il s'agit de rompre avec les
pratiques plus traditionnelles bien trop rigides et trop exigeantes en matière de
spécifications (contractuelles). Pour cela il est important d'accorder la priorité au
relationnel et à la communication étendue sur les processus de développement.

Le terme "méthode" est trop réducteur pour parler de cette façon d'aborder la gestion
de projet. Il s'agit de bien plus qu'une méthode. On parle plutôt de paradigme agile,
d'état d'esprit agile, de philosophie agile, de culture Agile ou encore d'approche
agile, de mouvement agile, de courant agile, etc

On parle cependant de "méthodes agiles" pour définir les méthodes qui relèvent de ce

courant.

Une approche dite "traditionnelle" attend généralement du client une expression

détaillée et validée du besoin en entrée de réalisation, laissant peu de place
au changement. La réalisation dure le temps qu'il faut et le rendez-vous est repris
avec le client pour la recette. Cet effet tunnel peut être très néfaste et conflictuel.

L'approche Agile, tout comme les méthodes Unifiées, propose au contraire de réduire
considérablement voire complètement cet effet tunnel en donnant davantage de
visibilité, en impliquant le client du début à la fin du projet et en adoptant
un processus itératif et incrémental. 

NB: voir vers la fin du chapitre une comparaison entre PU et méthode Agile

Elle considère que le besoin ne peut être figé et propose au contraire de s'adapter aux
changements de ce dernier. Mais pas sans un minimum de règles.

1
II. Le fonctionnement des méthodes Agiles
Les méthodes agiles partent du principe que spécifier et planifier dans les détails
l'intégralité d'un produit avant de le développer (approche prédictive) est contre-
productif.

Cela revient à planifier dans les détails un long trajet "ville A –Ville B" en voiture par
les petites routes. Spécifiant chaque ville et village traversés, l'heure de passage
associée, chaque rue empruntée dans les agglomérations, litres d'essence consommés,
kilomètres parcourus, etc. Les imprévus ne manqueront pas d'arriver : embouteillages,
déviations, travaux, sens de circulation inversés, voire la panne, etc. Rendant votre
planification et vos spécifications très vite obsolètes. Combien de temps aurez-vous
passé à planifier cet itinéraire, comment réagirez-vous face à vos frustrations de ne pas
pouvoir appliquer votre plan à la lettre ?

L'idée consiste à se fixer un premier objectif à courts termes (une grande ville par
exemple) et se lancer sur la route sans tarder. Une fois ce premier objectif atteint, on
marque une courte pause et on adapte son itinéraire en fonction de la situation du
moment. Et ainsi de suite jusqu'à atteindre la destination finale.
On parle donc d'une approche empirique.

Dans le cadre d'un projet de développement logiciel, le client élabore sa vision du

produit à réaliser et liste les fonctionnalités ou exigences de ce dernier. Il soumet
cette liste à l'équipe de développement, communique directement avec elle (plutôt
que par papier) qui estime le coût de chaque élément de la liste. On peut ainsi se faire
une idée approximative du budget global.
L'équipe sélectionne ensuite une portion des exigences à réaliser dans une portion de
temps courte appelée itération. Chaque itération inclut des travaux de conception, de
spécification fonctionnelle et technique quand c'est nécessaire, de développement et de
test. A la fin de chacune de ces itérations, le produit partiel mais utilisable est montré
au client. Ce dernier peut alors se rendre compte par lui même très tôt du travail
réalisé, de l'alignement sur le besoin.
L'utilisateur final quant à lui peut se projeter dans l'usage du produit et émettre des
feedbacks précieux pour les futures itérations. La visibilité ainsi offerte est clef. Cette
transparence peut également apporter davantage de confiance et de collaboration dans
la relation client/fournisseur. Les risques quant à eux sont levés très tôt.
Si le client a priorisé avec soin son besoin, il peut saisir l'opportunité d'accélérer
le "time to market" si il estime que le produit en l'état (partiel) peut aller en
production. Économisant ainsi son budget et récoltant un premier retour sur
investissement. Il a aussi la possibilité de changer en cours de route la priorité des
fonctionnalités qui n'ont pas encore été développées (prévues pour les itérations
futures). Afin de retarder une fonctionnalité dont le besoin n'est pas mûr, ajouter une
nouvelle fonctionnalité cruciale en échange du retrait d'une autre (respectant ainsi
budget et délais), etc.

2
 Cette souplesse ainsi offerte est donc un véritable atout pour le client.

III. Historique
 La première approche de gestion de projet de développement itératif date de 1986. La
première mise en œuvre de la méthode Scrum (la méthode Agile la plus utilisée,
documentée et éprouvée aujourd'hui) date de 1993.

La seconde concerne un événement majeur rassemblant, en 2001, dix sept figures

éminentes du développement logiciel pour débattre du thème unificateur de leurs
méthodes respectives. De cet événement est né le Manifeste Agile 
Aujourd'hui ces méthodes ont fait leurs preuves. Tout le monde (dans le monde de
l'informatique) ou presque a au moins entendu parler d'une méthode
Agile (Scrum, eXtreme Programming, RAD, Chrystal Clear,...). L'outillage associé
est maintenant disponible sur le marché y compris dans le secteur Open Source. Les
formations, certifications, conférences, livres, blogs se sont multipliés. 

En 2012, le Gartner (organisme GP) invite à abandonner le Cycle en V.

IV. Le manifeste Agile: un changement culturel

Le manifeste Agile contient l'essence et la philosophie de l'approche en question. Il

illustre à lui seul le changement culturel profond.

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les
autres à le faire. Ce qui nous permet de valoriser:

 Les individus et leurs interactions plus que les processus et leurs outils
 Des logiciels opérationnels plus qu'une documentation exhaustive
 La collaboration avec le client plus que la négociation contractuelle
 L'adaptation au changement plus que le suivi d'un plan

ATTENTION aux idées reçues :

La dernière phrase a son importance car si on néglige sa lecture, on peut tomber dans les idées
reçues très répandues du style : "Sur un projet agile, il n'y a pas de spécifications, de plan, de
processus, d'outil et même pas de contrat".
Au passage, passons en revue d'autres idées reçues "Un projet Agile ne fonctionne que sur des
projets de développement web, qu'avec une dizaine de personnes maximum, qu'avec des super
développeurs" ou encore "sur un projet agile, le client change d'avis tout le temps et on tourne
en rond à faire et défaire des choses".

3
V. Agile vs RUP
Témoignages d'enseignants à travers le monde :

 En 1999, c’était un cycle en V avec plan qualité qui était appliqué.

 A partir de 2000, on a introduit le RUP puis des variantes allégées. Les étudiants
pratiquent un développement itératif et incrémental.
 A partir de 2005, on est progressivement passés d’une approche style RUP à une
approche plus agile type Scrum.

Beaucoup de principes des méthodes agiles existent dans le RUP cependant ils sont moins ,
noyés dans la masse d’informations et donc ne sont pas bien appliqués. Quelles sont les
différences constatées effectivement dans les projets des étudiants lorsqu’ils appliquent une
méthode agile ?

 les itérations sont de durée fixe (time boxed) et plus courtes qu’avec le RUP, cela donne
un rythme régulier satisfaisant pour l’équipe et facilite le suivi par les enseignants
 on a clairement un produit avec des exigences testées à la fin de chaque itération, alors
que c’est plus flou pour le RUP
 les rôles individuels sont moins marqués avec les méthodes agiles, l’accent est mis sur
l’équipe et sur le travail collaboratif. Une équipe agile s’autogère et produit de
l’intelligence collective.
 il y a moins de documentation (inutile) produite
 les estimations ne se font pas que sur des tâches mais aussi sur des exigences
 le suivi porte sur le reste à faire uniquement, ce qui évite les compte-rendus où les il
faudra présenter pour chaque tâche l’effort estimé au départ et l’effort réel. Cela n’a
pas grand intérêt et je trouve même cela contre-productif, cela a tendance à pousser les
membres de l'équipe de développement à se conformer à l’estimation initiale plutôt
qu’à produire un résultat de qualité
 la mesure de l’avancement est bien plus objective : elle se fait sur les exigences
réalisées et pas sur les documents produits

En revanche, cela demande une participation et un suivi des chefs de projets bien plus
conséquents

VI. SCRUM
Inspirée du privé et de la gestion des projets informatiques, la méthode SCRUM est devenue
de nos jours de plus en plus adoptée dans les équipes de développement. Cette méthode
"agile" permet la réalisation de projets complexes en favorisant l’interaction avec les membres
de l’équipe et les managers, la collaboration du client et la réactivité face aux changements.
Le terme SCRUM fait référence à la mêlée de rugby.
4
Les projets qui suivent la méthode agile SCRUM sont divisés en plusieurs cycles de travail
relativement courts que l’on appelle « sprints
».
Ces derniers permettent aux membres de l’équipe de mieux planifier les prochaines étapes de
développement du projet mais aussi d’évaluer régulièrement les progrès liés au projet. Les
sprints peuvent durer d’une à quatre semaines. Ils permettent également de réajuster ou
réorienter la direction prise par le projet si besoin.

SCRUM se base avant tout sur un socle fixe de rôles, responsabilités et réunions qui ne
changent jamais, tout en assurant une gestion flexible et adaptative des projets.

Parmi les entreprises utilisatrices de cette méthode, de grands noms apparaissent comme
Microsoft, Yahoo, Google, Electronic Arts, Nokia...

La répartition des rôles

Les projets qui utilisent la méthode SCRUM se forment autour d’une équipe auto organisée
et multifonctionnelle.
L’équipe est auto organisée dans la mesure où il n’y a pas de chef d’équipe qui décide des
rôles de chacun, ou de la manière dont un problème est résolu, puisque ces problématiques
sont traitées par l’équipe dans son ensemble ;
L’équipe est multifonctionnelle car chaque membre de l’équipe est partie prenante dans le
développement de chaque fonctionnalité, de l’idée à l’implémentation finale.

Il existe trois rôles principaux à « pourvoir » : le responsable produit, le SCRUM Master, et

les membres de l’équipe.
 Le responsable produit product owner : Ce dernier définit les spécifications
fonctionnelles et communique la vision globale du produit à l’équipe. Il établit la
priorité des fonctionnalités à développer ou à corriger et valide les fonctionnalités
développées. Il se doit de jouer le rôle client final, se mettre à sa place et donc de
prioriser ses besoins. Celui qui tient ce rôle est celui qui a le plus de responsabilités et
d’autorité. Le responsable (produit) est en effet celui qui est en première ligne lorsque
quelque chose se passe mal ; ce qui nécessite de trouver le juste équilibre entre autorité
– responsabilité et engagement.
 Le SCRUM Master : Ce dernier agit en tant que facilitateur entre le responsable
produit et l’équipe. Son rôle principal est d’éliminer tous les obstacles qui peuvent
empêcher l’équipe d’atteindre les objectifs fixés pour chaque sprint de travail. Il
s’assure que les principes et les valeurs Scrum sont respectés. Il facilite la
communication au sein de l’équipe et cherche à améliorer la productivité et le savoir-
faire de son équipe. Le Scrum Master conseille aussi le responsable produit sur la
façon de maximiser le Return On Investment général de l’équipe.
 Les Membres de l’équipe development team : Dans la méthode SCRUM, l’équipe est
responsable de la réalisation opérationnelle des tâches. L’équipe est d’ailleurs
généralement composée de 6 à 10 personnes mais pouvant aller jusqu'à 200 personnes.
C’est toute l’équipe qui est responsable du résultat final de chaque sprint. La manière

5
 dont sont exécutées les tâches est très libre mais cette liberté doit être néanmoins
cadrée par l’obligation de répondre aux objectifs du sprint

Les piliers de la méthode

Les trois piliers de la méthode SCRUM sont les suivants :

La transparence : les aspects importants du processus doivent être visibles à tous.
C’est pour cela que SCRUM insiste sur le fait de créer un langage commun entre les membres
de l’équipe et le management, ce qui permettra une compréhension commune du projet.
L’inspection : un bilan régulier sur les résultats produits est réalisé afin de détecter les écarts
indésirables. Il est important que ces inspections soient faites par un inspecteur bien formé et
cela de manière adaptée car cela pourrait nuire à l’avancement du projet.
L’adaptation : lorsqu’un écart est constaté pendant l’inspection, le processus devra être
adapté grâce à des actions visant à améliorer la situation

Comment ça marche ?

La méthode SCRUM implique que le projet progresse à travers la mise en place de séries de «
sprints ». À chaque lancement d’un sprint, une réunion de planification est organisée nafin
que chaque membre de l’équipe puisse s’engager sur le nombre de tâches qu’il pourra
exécuter, ainsi que sur la création du « sprint blacklog », qui est la liste globale des tâches à
réaliser lors du sprint.
Chaque jour du sprint, tous les membres de l’équipe (ainsi que le responsable produit et le
SCRUM Master) doivent assister à la réunion SCRUM quotidienne. Cette dernière ne doit pas
durer plus de 15 minutes, et permet aux membres de l’équipe de partager avec les autres ce
qu’ils ont fait la veille, ce sur quoi ils travaillent le jour même, ainsi que l’identification de
tout problème pouvant entraver le bon déroulement du sprint. Cette réunion permet ainsi de
synchroniser tous les membres de l’équipe. La fin d’un sprint est marquée par une session de
débriefing permettant de présenter le travail achevé au responsable produit, et de partager des
informations pouvant influer sur le sprint suivant.

Fonctionnement général du SCRUM

6
Les fonctionnalités à implémenter sont contenues dans le backlog du produit. Au début de
chaque sprint, des fonctionnalités sont ajoutées dans le backlog du sprint, fonctions qui
devront être réalisées dans une durée fixe allant de 2 à 4 semaines. Tous les jours auront lieu
des mêlées quotidiennes afin de voir l'état d'avancement de chacun. À la fin de chaque sprint,
une version du produit, utilisable peut-être fournie au client. Toutes ces notions sont
expliquées plus en détail par la suite.

Les sprints/ Releases

Planification des sprints/ releases

Les sprints sont des itérations de durées fixes de une à quatre semaines. Chaque sprint
représentant des fonctions à réaliser.

L'esprit de Scrum est la participation forte du client (le responsable du produit) afin qu'il définisse la priorité de
chaque fonctionnalité et choisisse celles qui seront réalisées durant un sprint. De plus, il peut compléter ou
modifier la liste des fonctionnalités à venir mais pas celles en cours.
Ceci signifie qu'à la fin de chaque sprint, une version de l'application peut-être montrée au client. Il voit ainsi
l'évolution de l'application et ne la découvre pas à quelques jours de la deadline. Le produit fourni à la fin de
chaque Sprint est codé et testé !
Les releases sont en fait un regroupement d'itérations afin de mieux identifier les versions du produit. Une
release permet d'aboutir à une version livrable et dont la mise en exploitation est possible.

Le Backlog Produit

Le backlog produit est un catalogue de toutes les fonctionnalités. Chaque item de ce

catalogue possède deux attributs.
Le premier étant une estimation en Points Relatifs, ce qui signifie que l'estimation n'est pas
faite en nombre de jours mais en termes de complexité. La complexité a généralement comme
valeur un nombre de la suite de Fibonacci ( 1 2 3 5 8 13 21 34 55 89 144 233 377 610...).
C'est l'équipe qui détermine la complexité de l'item. Pour cela, l'équipe se réunit lors de ce que
l'on appelle le Planning Poker, et chaque personne écrit la complexité qu'il juge sur un bout de
papier que tout le monde abat en même temps. Suite à cela, l'équipe débat sur ces valeurs et

7
chaque personne argumente. L'estimation se reproduit jusqu'à ce que la plupart soit d'accord.
Les items sont bien quant à eux estimés en points.
Une fois tous les éléments du backlog de produit estimés, on attribue à chaque sprint une
partie de ces éléments.
Ainsi, une fois un sprint terminé, on sait combien de points ont été réalisés et on peut calculer
ainsi la vélocité de l'équipe, c'est-à-dire le nombre de points réalisés en un sprint. À partir de
cette vélocité et du total de points à réaliser, on peut définir le nombre de sprints qui seront
nécessaires pour terminer le projet (ou la release en cours). Au fur et à mesure de
l'avancement du projet, on a une vision de plus en plus fiable de la date d'aboutissement du
projet, tout en permettant l'ajout de nouveaux items dans le backlog du produit en cours de
route.
Le second attribut est la valeur client qui est définie par le directeur du produit ( rôle détaillé
par la suite ) et qui correspond à la priorité de l'item. Cette valeur peut-être changée à
n'importe quel moment.

Le Backlog du sprint

Lors du démarrage d'un sprint, des items du backlog du produit sont choisis afin de constituer
ce sprint. Chaque item est alors divisé en petites tâches constituant ainsi le backlog du sprint.
Chaque tâche étant estimée en nombres d'heures et ne pouvant pas dépasser 2 jours. Celles-ci
sont prises au fur et à mesure par les membres de l'équipe, elles ne sont pas attribuées dès le
départ du sprint. Le backlog est ainsi mis régulièrement à jour avec les éléments restant à
faire.

Mise en place:

L'idéal est un open space afin de faciliter la communication au sein de l'équipe. Un tableau
blanc est utilisé afin d'avoir une vue sur les items du sprint en cours, restants, effectués,
chaque histoire étant écrite sur un post-it!. En plus du tableau blanc pour le sprint en cours, il
faut tout de même avoir une vue sur le projet. Des outils sont donc nécessaires pour le suivi
du projet mais aussi pour que l'équipe puisse s'organiser et suivre l'évolution de tout le travail.

Outils libres:
 Ice Scrum ( open-source et démo en ligne ).
 EPF Eclipse Process Framework intègre un plug-in Scrum ( open-source ).
 OpenERP OpenERP intègre un module Scrum ( open-source )

Outils propriétaires:

 ScrumDesk( gratuit pour 5 utilisateurs maximum ).

 Intra'Know PROJET ( cette solution collaborative intégre les grands principes de la
méthode AGILE ).
 ScrumWorks ( gratuit sous conditions ).
 VersionOne ( gratuit sous conditions ).
 RallyDev.

8
 • GreenHopper.
• Microsoft eScrum Version 1.0 pour Visual Studio Team Foundation Server.
• Scrumy ( Démonstration en ligne gratuite )
• Serena Agile On Demand Entièrement en mode SAAS. Aucune installation
nécessaire. Essai gratuit 60jours.
• Plugin for TFS web Access ( Essai gratuit 30 jours ).

Nous voyons donc qu'il ne faut pas grand-chose pour pouvoir utiliser Scrum.

Les évènements :

 Le Sprint
 La réunion de planification de sprint (Sprint Planning Meeting)
 La mêlée quotidienne (Daily Scrum)
 La revue du sprint (Sprint Review Meeting)
 La rétrospective du Sprint (Sprint Retrospective)

Les événements sont limités dans le temps (Boîtes de temps).

Chaque événement est une occasion pour inspecter et adapter.

Le Sprint :
 Un Sprint est défini pour réaliser un objectif de l’activité de développement liée à la
réalisation du produit attendu. Il a une durée bien limité (moins d’un mois).
 Il contient et est constitué de la planification du Sprint (Sprint Planning), des mêlées
quotidiennes (Daily Scrums), des activités de développement, de la revue du Sprint
(Sprint Review) et de la rétrospective du Sprint (Sprint Retrospective).
 Le sprint a un objectif fixe auquel est associée une liste d’éléments du Product
backlog, ce but est sans changements qui le remettent en cause. Les objectifs de
qualités sont maintenus. Son périmètre peut être renégocié par la product owner et la
development team.
 Les Sprints amènent de la prévisibilité en forçant une inspection et adaptation du
progrès vers l’atteinte d’un objectif au moins mensuellement.
 Les sprints se déroulent de façon séquentielle.

La réunion de planification de sprint (Sprint Planning Meeting)

Elle a pour but de planifier l’objectif du Sprint, en se basant sur les items du Product Backlog
priorisés (exigences les plus priorisées du client) par l’équipe et le product owner. Elle se
déroule en 2 temps :
1° partie : Qu’est-ce qui peut être terminé dans ce sprint
2° partie : Comment l’équipe va s’organiser pour réaliser ce travail
Lors de la 1ière partie, l’objectif du sprint est arrêté, et dans combien de temps il sera réalisé.
Lors de la 2ième partie, le travail est décomposé (développement, tests, livraison au client).
Le Sprint Blacklog est ainsi défini.
Les Sprint Backlogs constituent le Product Backlog.

9
Il est possible d' utiliser la méthode MoSCoW afin de prioriser les besoins ou les exigences
du product backlog. Votre objectif est que l'équipe s'accorde sur l'importance des
fonctionnalités à réaliser en respectant des délais raisonnables.

Il est aussi possible d'utiliser Jira Software qui fait partie d'une gamme de produits conçus
pour aider les équipes de tous types à gérer leur travail. À l'origine, Jira a été pensé comme un
outil de suivi des bugs et des tickets. Mais aujourd'hui, c'est devenu un puissant outil de
gestion du travail pour toutes sortes de cas d'usage, de la gestion des exigences et des cas de
test au développement Agile.

La mêlée quotidienne (Daily Scrum)

C’est une réunion quotidienne d’avancement qui ne dure pas plus de 15mn.
 Elle réunit tous les membres de l’équipe et permet d’examiner les tâches en cours et
les difficultés rencontrées (ce qui a été fait et ce qui va être fait).
 C'est ce qui permet de mettre au quotidien l’application des principes inspection-
adaptation de la méthode Scrum.
 le Scrum Master maintient un graphique (Sprint Burndown Chart) pour la
visualisation de la progression du travail.

La revue du sprint (Sprint Review Meeting)

 A la fin d’un Spint on fait une réunion (d’une durée respectant sa boîte de temps) pour
passer en revue l’Incrément du produit qui vient d’être « terminé », et ainsi le valider.
 C’est aussi l’occasion de faire un bilan, sur le fonctionnement de l’équipe et de trouver
des points d’amélioration.

10
  Cela permet de décider du prochain Item du carnet du produit à traiter dans le prochain
Sprint.

La rétrospective du Sprint (Sprint Retrospective)

 Elle fait suite à la réunion de revue du sprint.

 Elle a pour but de mettre en place un plan d’amélioration du processus de
développement lors de la prochaine itération (Sprint).
 Elle doit aider à l'adaptation aux changements qui surviennent au cours du projet et à
l'amélioration continue du processus de réalisation
 Elle alimente l’axe inspection / adaptation

Les artéfacts:

 Le carnet du produit (Product Backlog)

 Le carnet du sprint (Sprint Backlog)
 L’incrément (Increment)
 Les fonctionnalités (User Story)
 Le diagramme de progression (Sprint Burndown Chart)

Le carnet du produit (Product Backlog)

 C’est une liste ordonnée des besoins et de tout ce qui peut être requis.
 Le product owner est responsable de la gestion de son contenu.
 Il est soumis à une évolution constante (besoins, marché, technologie…). Il est
dynamique.
 Il contient des items du produit à réaliser.
 Lorsque ces derniers sont alors réalisés et validés, ils deviennent des incréments du
produit.
 Un carnet du produit est maintenu tout au long de la vie d’un produit.
 Les items sont hiérarchisés dans un carnet du produit. Les plus prioritaires sont
finement décrits.
 Les items réputés « Prêts » seront sélectionnés dans la planification du prochain
Sprint.
Le carnet du sprint (Sprint Backlog)

 Les items du produit sélectionnés pour être réalisés sont consignés dans un carnet du
Sprint.
 Le plan de réalisation de la fonctionnalité ciblée est indiqué dans ce carnet du produit,
ainsi que le travail nécessaire (temps, moyens…)
 Le carnet du sprint est mis à jour régulièrement, et est de la seule responsabilité de
l’équipe de développement.
 Les estimations des temps de travail sont mises à jour lors de chaque Daily meeting

L’incrément (Increment)
 L’incrément est constitué des éléments « terminés » lors de l’itération en cours (sprint
actuel) et des autres sprints déjà accomplis.
 L’incrément déclaré « terminé » doit être utilisable, même s’il n’est pas encore publié.

11
Les fonctionnalités (User Story)

 Les user stories décrivent les fonctionnalités.

 Chaque user story contient plusieurs informations (ID, Nom, Importance, Estimation,
Démo, Notes).

Le diagramme de progression (Sprint Burndown Chart)

Ces Burndowns indiquent le nombre d'heures restantes à faire avant la fin du Sprint. Ils permettent d'avoir une
vue globale sur l'avancement du Sprint.

Il exitse aussi Les relases Burndown Chart: Ces Burndowns montrent ce qu'il reste à faire en terme d'estimation
en nombre d'histoire à réaliser sur la release.

Ce burndown montre qu'il y a 200 histoires (fonctionnalités) à réaliser. Au fur et à mesure du

temps, on voit le nombre baisser mais il peut augmenter si de nouvelles fonctionnalités ont été
ajoutées.

Remarques générales :

12
  Scrum fonctionne en tant que conteneur pour d'autres techniques, méthodologies et
pratiques. Ses éléments (rôles, événements, artéfacts et règles) sont immuables.
 Srum ne fonctionne que dans son intégralité. Même si elle peut être utilisée
partiellement (ce n’est pas alors Scrum).
 La notion de « terminé » doit être bien perçue par tous les membres de l’équipe
Scrum.
 La Transparence des artéfacts est essentielles dans Scrum. Elle permet d’optimiser la
valeur du travail réalisé et contrôler les risques. La transparence ne se produit pas du
jour au lendemain, elle correspond plutôt à un cheminement.

Journée type:

9h : Arrivée au bureau de toute l'équipe.

9h05 : Premier café de la journée !
9h15 : Daily Scrum : mêlée quotidienne où trois questions sont posées à chaque membre :
• Qu'est-ce que j'ai fait hier ?
• Qu'est-ce que je compte faire aujourd'hui ?
• Quelles difficultés est-ce que je rencontre ?
Reste de la journée :
Alternance entre écriture des tests et code permettant de faire passer ceux-ci. Puisque l'équipe
a décidé de jumeler Scrum et XP, le développement se fait en TDD (Test Driven
Development) afin de fournir à chaque livraison du code testé et fonctionnel.

La mêlée quotidienne ne doit durer que 15 minutes et doit avoir lieu debout ( pour être sur de
ne pas dépasser les 15 minutes ), pour faire un tour rapide de l'équipe et la synchroniser. Ceci
ne signifie pas qu'il ne peut pas y voir de discussions en dehors pour éclaircir certains points
avec le ScrumMaster ou le responsable du produit.
Mais cette réunion n'est en aucun cas un compte-rendu fait au ScrumMaster, elle doit juste
servir de synchronisation

13
14
15
16