Méthodes Agile

SUPPORT DE FORMATION
Mthodes Agile
Formation Mthodes Agile
Page 1
Table des matires
1.
Introduction: .................................................................................................................... 7
2.
Concepts de gestion de projets ................................................................................ 9
2.1.
Qu'est-ce qu'un projet? .......................................................................................... 11
2.1.1.
Caractristiques d'un projet .............................................................................. 11
2.1.2.
Projets par opposition aux oprations .......................................................... 13
2.1.3.
Projets et planification stratgique ................................................................ 14
2.2.
Qu'est-ce que le management de projet? ....................................................... 14
2.3.
Vue d'ensemble des domaines de connaissance en management de
projet et des processus de management de projet ................................................... 16
2.4.
Prsentation Microsoft Project: ........................................................................... 20
3.
Mthodologie Agile ....................................................................................................... 23
3.1.
Une approche agile de gestion de projet ......................................................... 23
3.2.
Limites des approches traditionnelles............................................................... 23
3.2.1.
Modle en cascade ................................................................................................ 23
3.2.1.1. Les failles dune approche en cascade .............................................. 25
3.2.2.
Modle en V ............................................................................................................. 26
3.2.3.
Approches plus rcentes Modle itratif ...................................................... 28
3.2.3.1. Modle en spirale ............................................................................................... 28
3.2.3.2. Modle incrmental ou par incrments ..................................................... 31
3.3.
Le manifeste Agile .................................................................................................... 32
3.4.
La place de Scrum dans le monde des mthodes Agiles .......................... 35
3.4.1.
Les principales mthodes Agiles ..................................................................... 35
3.4.1.1. Scrum ..................................................................................................................... 35
3.4.1.2. EXtreme Programming (XP) .......................................................................... 35
3.4.1.3. Rational Unified Process (RUP) .................................................................... 36
3.4.1.4. Feature Driven Development (FDD) .......................................................... 36
3.4.1.5. Rapid Application Development (RAD) ..................................................... 36
3.4.1.6. Dynamic systems development method (DSDM) ................................. 36
3.4.2.
Pratiques communes l'ensemble des mthodes agiles ...................... 36
3.4.3.
Pratiques diffrenciatrices des mthodes agiles ....................................... 37
3.4.4.
Synthse des mthodes Agile .......................................................................... 38
4.
TOUR DHORIZON ........................................................................................................ 40
4.1.
Naissance de Scrum ................................................................................................ 40
4.2.
Scrum en quelques mots ....................................................................................... 42
4.2.1.
Lquipe ..................................................................................................................... 42
4.2.2.
Les vnements (crmoniaux) ...................................................................... 43
4.2.2.1. Sprint ...................................................................................................................... 43
4.2.2.2. Runion de planification de Sprint .............................................................. 44
4.2.2.3. Le Scrum Meeting .............................................................................................. 44
4.2.2.4. La revue de Sprint ............................................................................................. 44
4.2.2.5. La rtrospective de Sprint .............................................................................. 45
4.2.3.
Les artefacts ............................................................................................................ 45
4.2.3.1. Product Backlog .................................................................................................. 45
4.2.3.2. Sprint Backlog ..................................................................................................... 45
4.2.3.3. Burn Down Chart ............................................................................................... 46
Page 2
4.2.3.4. Burn Up Chart ..................................................................................................... 47

4.2.3.5. Courbe de temprature ................................................................................... 47
4.3.
Le cycle de vie de Scrum ....................................................................................... 48
4.4.
Les 3 Piliers de SCRUM ........................................................................................... 49
4.5.
Cot, dlai, primtre ............................................................................................. 50
5.
LQUIPE .......................................................................................................................... 51
5.1.
Le Product Owner ..................................................................................................... 51
5.2.
Lquipe de Dveloppement ................................................................................. 52
5.2.1.
Taille de lquipe de Dveloppement ............................................................ 53
5.3.
Le Scrum Master ....................................................................................................... 53
5.3.1.
Le Scrum Master au service du Product Owner ........................................ 53
5.3.2.
Le Scrum Master au service de lquipe de Dveloppement ............... 54
5.3.3.
Le Scrum Master au service de lorganisation ........................................... 54
5.4.
Lenvironnement de travail ................................................................................... 54
6.
LES BESOINS : CRITURE DU PRODUCT BACKLOG ....................................... 56
6.1.
Sprint 0 ......................................................................................................................... 56
6.2.
Product Backlog ......................................................................................................... 57
6.3.
Grille INVEST .............................................................................................................. 58
6.4.
Rdiger les User Stories et Epics ........................................................................ 60
6.4.1.
Objectif granularit : les user stories............................................................ 60
6.4.1.1. User stories .......................................................................................................... 61
6.4.1.2. Cartographier le cheminement de lutilisateur ....................................... 63
6.4.1.3. le prototypage ..................................................................................................... 64
6.4.2.
Cadence de dveloppement fixe : les sprints ............................................ 66
6.4.3.
Approche plus globale : les epics ................................................................... 66
6.4.4.
Approche plus globale : les versions ............................................................. 67
6.5.
Les erreurs frquentes ............................................................................................ 67
6.6.
Les outils dcriture d'User Stories .................................................................... 68
6.6.1.
Les 3 C ....................................................................................................................... 68
6.6.2.
Le story Mapping ................................................................................................... 68
6.6.3.
Carte heuristique ................................................................................................... 69
6.6.4.
BDD et Gherkin ...................................................................................................... 70
7.
LES TESTS POUR LES USER STORIES.................................................................. 72
7.1.
La Pyramide de tests de Mike .............................................................................. 72
7.2.
Les tests dacceptation ........................................................................................... 72
7.3.
Les TDD et ATDD ...................................................................................................... 73
7.3.1.
Les TDD ..................................................................................................................... 73
7.3.2.
Les ATDD .................................................................................................................. 74
8.
PRIORISATION DU PRODUCT BACKLOG ............................................................. 75
8.1.
La Priorisation............................................................................................................. 75
8.2.
Dfinir la Valeur Mtier par le Priority Poker ................................................. 76
8.3.
Priorisation par le modle de Kano .................................................................... 78
8.4.
Priorisation par la mthode des poids .............................................................. 81
8.5.
Priorisation partir des Thmes ......................................................................... 82
8.5.1.
Avantages et limites. ........................................................................................... 82
8.5.2.
Le tri de cartes ouvert ......................................................................................... 83
8.5.3.
Le tri de cartes ferm .......................................................................................... 84
8.5.4.
Dmarche ................................................................................................................. 85
Page 3
8.5.5.
Prparation .............................................................................................................. 85
8.5.6.
Atelier de tri ............................................................................................................ 86
8.5.7.
Analyse ...................................................................................................................... 87
8.5.8.
Atelier de fusion ..................................................................................................... 87
8.5.9.
Priorisation en thmes en mode Agile .......................................................... 88
8.5.9.1. Premire phase : Ice Breaker ................................................................... 88
8.5.9.2. Deuxime phase : Le dveloppement dides .................................... 89
8.5.9.3. Troisime phase : La synthse ................................................................. 90
9.
ESTIMATION DE LA DURE ET PLANIFICATION D'UN SPRINT ................. 91
9.1.
quipe, Product Backlog et tableau de Sprint Backlog .............................. 91
9.2.
La runion de planification de Sprints .............................................................. 92
9.2.1.
Quest-ce qui peut tre termin au cours de ce sprint ? ....................... 92
9.2.2.
Comment sera effectu le travail choisi ? ................................................... 93
9.2.3.
Objectif du Sprint .................................................................................................. 93
9.3.
Estimation des User Stories .................................................................................. 94
9.3.1.
Quest-ce quun story point? ............................................................................. 94
9.3.2.
Pourquoi estimer ? ................................................................................................ 94
9.3.3.
Comment estimer ? .............................................................................................. 94
9.3.4.
Pourquoi ne pas estimer directement le temps ncessaire pour
dvelopper une fonctionnalit? .......................................................................................... 95
9.3.5.
Comment estimer en story points? ................................................................ 95
9.3.6.
Quelle chelle destimation? ............................................................................. 96
9.3.7.
Comment dterminer les cots de dveloppement ? ............................. 96
9.3.8.
Synthse de lestimation des user Stories ?............................................... 97
9.4.
Dfinition des User Stories pour le prochain Sprint .................................... 99
9.5.
Le dcoupage en tches ......................................................................................... 99
9.6.
Les Users Stories techniques ............................................................................. 100
9.6.1.
La user story technique et le planning meeting ...................................... 101
9.6.2.
Remettre la story technique dans son contexte ..................................... 101
9.6.3.
Refactoring ............................................................................................................. 102
9.6.4.
User story de type Spike .................................................................................. 102
9.6.5.
Quand utiliser le Spike? .................................................................................... 102
9.6.6.
Quel est le rsultat d'un spike ? .................................................................... 103
9.6.7.
Quel est le temps consacr un spike ? ................................................... 103
9.7.
Les Defect Stories ................................................................................................... 104
9.8.
La notion de Termin ( Done ) ..................................................................... 106
10. PLANIFICATION DES RELEASES ........................................................................... 108
10.1. Scrum et les Releases ........................................................................................... 108
10.2. Planification dune Release .................................................................................. 109
11. VIE DUN SPRINT ........................................................................................................ 112
11.1. Check-list ................................................................................................................... 112
11.2. Scrum Meeting/Daily Scrum ............................................................................... 113
11.3. Sprint Review ........................................................................................................... 114
11.4. Rtrospective de Sprint ........................................................................................ 115
11.5. Synthse : les timesboxes dans SCRUM ....................................................... 117
12. LE SUIVI ......................................................................................................................... 118
12.1. Planifier, itrer et assurer le suivi .................................................................... 118
12.1.1. Planification du sprint ........................................................................................ 118
Page 4
12.1.2. Itration .................................................................................................................. 118

12.1.2.1.
Revue d'itration .......................................................................................... 118
12.1.2.2.
Rtrospective ................................................................................................. 119
12.1.3. le suivi ..................................................................................................................... 119
12.1.3.1.
Mle quotidienne ( Stand Up quotidien) ......................................... 119
12.2. Estimer le Reste Faire ....................................................................................... 120
12.3. Connatre la valeur mtier pour arrter le projet ...................................... 121
12.3.1. Budget au niveau release ................................................................................ 122
12.3.2. Budget au niveau sprint ................................................................................... 123
12.3.3. Budget au niveau Backlog de produit ...................................................... 123
12.4. La motivation de lquipe .................................................................................... 123
13. LA CONDUITE DU CHANGEMENT.......................................................................... 126
13.1. Comment mener le changement vers Scrum ? .......................................... 126
13.1.1. Enjeux et enjeux ................................................................................................. 126
13.1.2. Le projet de transformation ............................................................................ 127
13.1.3. Dfinir le projet : le cadrage .......................................................................... 128
13.1.3.1.
Dvelopper la vision ................................................................................... 128
13.1.3.2.
Identifier le primtre ................................................................................ 129
13.1.3.3.
Identifier les moyens .................................................................................. 129
13.1.3.4.
EXPERIMENTER : Le pilote ....................................................................... 130
13.1.3.4.1.
Slection des projets pilotes et conditions de lancement ........ 131
13.1.3.4.2.
La transformation dune quipe de projet en quipe Agile ...... 132
13.2. Les 8 tapes du changement de Kotter et l'Agilit .................................... 133
13.3. La rsistance au changement ............................................................................ 134
14. MISE EN OEUVRE DES METHODES AGILE ........................................................ 136
14.1. Les outils agiles. ...................................................................................................... 136
14.2. Les tableurs, les outils spcialiss. .................................................................. 136
14.3. Prsentation des principales fonctionnalits offertes. .............................. 136
14.4. Spcialisation. Comment passer du cadre gnrique de l'offre agile
une dmarche adapte l'entreprise et au projet. ................................................. 136
14.4.1. QUEST-CE QUE LAGILIT DANS LENTREPRISE ? ................................ 136
14.4.1.1.
Manifeste Agile .............................................................................................. 136
14.4.2. lments cls de caractrisation de lAgilit en entreprise ................ 138
14.4.2.1.
Des promesses .............................................................................................. 138
14.4.2.2.
Organisation oriente sur la co-cration de valeur ........................ 140
14.4.2.3.
Maturit culturelle de lentreprise et de ses individus ................... 141
14.4.2.4.
Gouvernance adapte ................................................................................ 142
14.4.2.5.
Moyens, outils, processus et mthodes .............................................. 143
14.5. Les tapes de la transition d'une dmarche classique vers une
approche Agile ........................................................................................................................ 144
14.5.1. tat des lieux ........................................................................................................ 144
14.5.2. Rdaction dun document de synthse sur lexistant ........................... 144
14.5.3. Adoption de nouvelles pratiques ................................................................... 145
14.5.4. Btir un modle de maturit ........................................................................... 145
14.5.4.1.
Cration de Valeur ....................................................................................... 146
14.5.4.1.1.
DELIVERY AGILE, TIME TO MARKET ................................................. 146
14.5.4.1.2.
GESTION DU CYCLE DE VIE ................................................................. 146
14.5.4.1.3.
GESTION AGILE DU PORTEFEUILLE DES PRODUITS ................. 147
Page 5
14.5.4.1.4.
14.5.4.1.5.
14.5.4.1.6.
14.5.4.2.
14.5.4.2.1.
14.5.4.2.2.
14.5.4.2.3.
14.5.4.2.4.
14.5.4.3.
14.5.4.3.1.
14.5.4.3.2.
14.5.4.3.3.
14.5.4.3.4.
14.5.4.3.5.
14.5.4.4.
14.5.4.4.1.
14.5.4.4.2.
14.5.4.4.3.
14.5.4.4.4.
14.5.4.4.5.
14.5.4.5.
14.5.4.5.1.
14.5.4.5.2.
14.5.4.5.3.
GESTION DES NOUVEAUTS ET DES INNOVATIONSES ........... 147

RELATION DE LA DSI AVEC LE SHADOW IT .................................. 148
INTELLIGENCE COLLECTIVE ................................................................ 148
Architecture .................................................................................................... 149
MODLE DARCHITECTURE................................................................... 149
GESTION DU SYSTME DINFORMATION ....................................... 149
MODLE DINFRASTRUCTURE ............................................................. 149
DVELOPPEMENT, INTGRATION ET LIVRAISON ........................ 150
Organisation ................................................................................................... 150
SPONSORSHIP DE LAGILIT............................................................... 150
NIVEAU DE RACTIVIT ........................................................................ 150
PARTENARIATS ET SOURCING............................................................ 151
DCLOISONNEMENT DANS LENTREPRISE .................................... 151
RGLES DU MANIFESTE AGILE ........................................................... 152
Comptences ................................................................................................. 152
DVELOPPEMENT D'UN "FAIRE AGILE" ........................................... 152
ORIENTATION L'EXCELLENCE TECHNIQUE ................................ 153
GESTION D'UNE FONCTION SI PLUSIEURS VITESSES ......... 153
PROMOTION D'UN TAT D'ESPRIT AGILE ...................................... 153
GESTION HUMAINE DES COMPTENCES ........................................ 154
Culture.............................................................................................................. 155
PRISE DE RISQUE .................................................................................... 155
INNOVATION .............................................................................................. 155
FACTEUR HUMAIN .................................................................................... 155
Page 6
1. Introduction:
Les logiciels de gestion de projets permettent de mieux maitriser les diffrentes
tapes d'un projet :
Dfinition des projets :
Structuration du projet (dcoupage en phases/activits/tches,
affectations ressources & profils, cots)
Planification avance des projets (dates, priodes, affectations
assistes, gestion des taux de charge, contraintes, Gantt...) :
ordonnancement des tches
Suivi de l'avancement des projets (reste faire, dcalages,
expansion, chances, livrables...)
laboration de Reportings
Les 4 phases du management de projets sont:

PHASE 1: ANALYSE DES BESOINS- Phase danalyse des besoins et
de lancement du projet.
PHASE 2 : CONSTRUIRE ET PLANIFIER Phase de prparation du
projet et de planification des tches et des activits
PHASE 3 CONDUIRE ET PILOTER - Phase de ralisation du projet et
danimation de lquipe projet
PHASE 4 CLTURER ET VALUER - Phase de finalisation du projet et
de capitalisation de lexprience
Il existe de nombreux logiciels de gestion de projets.ces logiciels sont classs
en deux catgories :
Logiciels propritaires tels:
o Microsoft Project dit par Microsoft
o Primavera Enterprise Project Portfolio Management
rachet par Oracle
o FastTrack Schedule dAEC SOFTWARE
Page 7
Logiciels Open source.

La liste des principaux logiciels de gestion de projets est disponible l'URL
suivante:
http://fr.wikipedia.org/wiki/Logiciel_de_gestion_de_projets
Nous citerons , titre d'exemple , les logiciels suivants :
Open Workbench
http://sourceforge.net/projects/openworkbench/
ProjectLibre
http://www.projectlibre.org/
Page 8
2. Concepts de gestion de projets

"Un projet est un processus unique qui consiste en un ensemble d'activits
coordonnes et matrises, comportant des dates de dbut et de fin, entrepris
dans le but d'atteindre un objectif conforme des exigences spcifiques, telles
que les contraintes de dlais, de cots et de ressources." selon la norme NF
ISO 10006
Projet :
Ensemble de travaux interdpendants, mens pour la ralisation d'un ouvrage
dfini, ncessitant des ressources multiples, dans un contexte conomique
donn.
Travaux interdpendants :
Tches diffrentes lies entre elles, effectues en parallle ou en srie,
Ouvrage dfini
Produits, livrables, biens ou services, matriels ou immatriels, reconnus donc

valids, rpondant des exigences de qualit, structurs,
Ressources multiples
Ressources humaines, comptences multiples, disponibilit, outillage, matriels,
rles et affections,
Contexte conomique
Dlai, chances imposes, cots, budgets (charges),
Le management (ou la gestion) de projet est lapplication des connaissances,

des comptences, des outils et des mthodes, aux activits dun projet, en vue
datteindre ou de dpasser les besoins et les attentes des parties prenantes du
projet. Atteindre ou dpasser les besoins et les attentes des parties prenantes
signifie que lon trouve un quilibre entre les contraintes concurrentes, telles
que :
Contenu, cot, dlai et qualit
Besoins et attentes diffrentes entre les parties prenantes
Exigences identifies (besoins) et non identifis (attentes)
Un objectif est une contrainte que lon va imposer au projet afin quil se ralise
dans un cadre donn.
Un projet comporte 3 niveaux dobjectifs
Objectifs de qualit : Produire de la qualit
Objectifs de cots : Matriser les cots
Objectifs de temps : Respecter les dlais...
Un objectif est toujours SMART :
Page 9
Les 3 niveaux d'exigences sont dpendants les uns des autres et leurs
interactions est reprsente par le schma suivant dit "triangle magique de la
qualit- cot -dlais"
Page 10
2.1.
Qu'est-ce qu'un projet?
2.1.1.
Caractristiques d'un projet
Un projet est une entreprise temporaire dcide dans le but de crer un
produit, un service ou un rsultat unique.
Temporaire
Temporaire signifie que tout projet a un dbut et une fin dtermins. La fin
arrive lorsque les objectifs du projet ont t atteints ou lorsqu'il devient vident
que ces objectifs ne seront ou ne pourront pas tre atteints, ou bien lorsque le
projet n'est plus ncessaire et qu'il est abandonn. Temporaire ne veut pas
ncessairement dire de courte dure ; de nombreux projets durent plusieurs
annes. Mais, dans tous les cas, la dure d'un projet est limite. Les projets
ne sont pas des dmarches continues.
En outre le qualificatif de temporaire ne s'applique gnralement pas au
produit, au service ou au rsultat cr par le projet. La plupart des projets sont
entrepris pour crer un rsultat durable. Par exemple, le projet de construction
d'un monument national aboutira un rsultat prvu pour durer des sicles.
Volontairement ou non, les projets peuvent aussi avoir souvent un impact
social, conomique ou environnemental qui leur survit trs longtemps.
La nature temporaire des projets peut s'appliquer aussi d'autres aspects
de l'entreprise :
L'opportunit ou la fentre du march est gnralement temporaire ;
certains projets disposent d'un intervalle de temps limit pour produire leur
produit ou service.
Page 11
L'quipe de projet, en tant qu'unit de travail, survit rarement au projet ;

une quipe cre dans le seul but de raliser le projet va lexcuter puis
tre dissoute, et ses membres seront raffects une fois le projet termin.
Produits, services ou rsultats uniques

Un projet cre des livrables uniques qui peuvent tre des produits, des services
ou des rsultats. Les projets peuvent ainsi crer :
un produit ou un objet qui est produit et quantifiable, et qui peut aussi bien
tre un produit final qu'un composant,
une capacit de fournir un service, tel que des fonctions commerciales
destines soutenir la production ou la distribution,
un rsultat, tel que des aboutissements ou des documents. Exemple : un
projet de recherche dveloppe des connaissances utilisables pour
dterminer la prsence ou l'absence d'une tendance, ou pour savoir si un
nouveau processus sera utile la socit.
Le caractre unique est une caractristique importante des livrables d'un
projet. Par exemple des milliers d'immeubles de bureaux ont t difis, mais
chaque installation est unique: propritaires diffrents, conceptions
diffrentes, emplacements diffrents, entrepreneurs diffrents, etc.
L'existence d'lments rptitifs ne change pas le fait que le travail du projet
est fondamentalement unique.
laboration progressive
L'laboration progressive est une caractristique des projets qui intgre les
notions de temporaire et d' unique . L'laboration progressive signifie
un dveloppement par tapes et une progression par incrments. Par exemple
le contenu du projet sera dfini de manire peu dtaille au tout dbut du
projet et de faon plus explicite et dtaille au fur et mesure que l'quipe de
projet dveloppera une comprhension plus approfondie des objectifs et des
livrables. L'laboration progressive ne doit pas tre confondue avec la drive
du contenu .
L'laboration progressive des spcifications d'un projet doit tre soigneusement
coordonne avec une dfinition prcise du contenu du projet, notamment si ce
dernier est ralis sous contrat. Une fois que le contenu du projet (le travail
raliser) est correctement dfini, il doit tre matris lors de l'laboration
progressive du projet et des spcifications du produit.
Les exemples suivants illustrent cette laboration progressive dans deux
champs d'application diffrents:
Le dveloppement d'une usine de produits chimiques commence par
l'ingnierie des procds pour dfinir les caractristiques du processus.
Ces caractristiques sont utilises pour concevoir les principales units
de traitement. Ces informations deviennent la base des tudes de
conception dfinissant d'une part le plan dtaill de l'usine, d'autre part
les spcifications mcaniques des units de traitement et des
installations auxiliaires. On en tire des plans de conception conduisant
aux plans de fabrication et aux plans de construction. Pendant la
construction, des interprtations et des adaptations sont faites selon les
besoins et soumises approbation. Cette laboration supplmentaire
des livrables est officialise par des plans conformes l'excution, et
des ajustements finaux de fonctionnement sont effectus durant les
essais et la mise en service.
Page 12
Le produit d'un projet de dveloppement conomique peut initialement

tre dfini comme suit : Amliorer la qualit de vie des rsidents aux
revenus les plus faibles de la communaut X . Durant l'avancement du
projet, on peut dcrire les produits plus spcifiquement, par exemple:
Offrir dans la communaut X l'accs lalimentation et l'eau aux
500 rsidents faibles revenus . L'tape suivante de l'laboration
progressive peut se concentrer exclusivement sur l'augmentation de la
production agricole et la commercialisation des denres, le
ravitaillement en eau devenant une priorit secondaire, considrer
une fois que la ralisation du composant agricole aura largement
progress.
2.1.2.
Projets par opposition aux oprations
Les organisations ralisent des travaux pour atteindre un ensemble d'objectifs.
En gnral, ces travaux entrent dans la catgorie des projets ou des oprations,
les deux pouvant quelquefois se chevaucher. Les oprations et les projets ont
de nombreuses caractristiques communes :
Ils sont raliss par des personnes.
Ils subissent les contraintes de ressources limites.
Ils sont planifis, excuts et matriss.
Les diffrences tiennent en premier lieu au fait que les oprations sont
continues et rptitives, alors que les projets sont temporaires et
uniques
Les objectifs des projets et des oprations sont fondamentalement diffrents.
Le but d'un projet est d'atteindre son objectif et par l mme de se terminer.
En revanche l'objectif d'une opration continue est de soutenir l'activit de
l'entreprise. Un projet est diffrent parce qu'il se conclut lorsque ses objectifs
spcifiques sont atteints, alors que les oprations adoptent une nouvelle srie
d'objectifs et que le travail continue
Des projets sont entrepris tous les niveaux d'une organisation et peuvent
occuper autant une seule personne que plusieurs milliers. Leur dure peut
s'taler de quelques semaines plusieurs annes. Les projets peuvent impliquer
une seule unit organisationnelle ou un grand nombre, comme dans le cas
d'entreprises en coparticipation et de partenariats. On peut citer, parmi d'autres,
les exemples de projet suivants :
dveloppement d'un produit ou d'un service nouveau,

mise en place de modifications de la structure, des ressources humaines
ou du style d'une organisation,
conception d'un nouveau vhicule de transport,
dveloppement ou acquisition d'un nouveau systme d'information ou
modification d'un systme existant,
construction d'un btiment ou d'une installation,
construction d'un rseau d'alimentation en eau pour une communaut,
conduite d'une campagne lectorale,
mise en place d'une nouvelle procdure ou d'un nouveau processus
d'entreprise,
rponse un appel d'offres pour un contrat.
Page 13
2.1.3.
Projets et planification stratgique
Les projets sont un moyen d'organiser des activits qui ne peuvent pas tre
traites dans le cadre du fonctionnement habituel de l'organisation. Ils sont, par
consquent, souvent utiliss pour raliser le plan stratgique d'une organisation,
que l'quipe de projet soit employe par l'organisation elle-mme ou soit un
prestataire de services sous contrat.
Gnralement les projets sont autoriss en conclusion d'une des considrations
stratgiques suivantes, voire plusieurs :
une demande du march (exemple : une compagnie ptrolire autorise un
projet de construction d'une nouvelle raffinerie en rponse des pnuries
chroniques de carburant),
un besoin organisationnel (exemple: une entreprise de formation autorise
un projet de cration d'un nouveau cours pour accrotre ses revenus),
une demande de la clientle (exemple: une compagnie d'lectricit autorise
le projet de construction d'une nouvelle sous-station lectrique qui
desservira un nouveau parc industriel),
une avance technologique (exemple: un concepteur de logiciels autorise
un nouveau projet de dveloppement pour une nouvelle gnration de jeux
vido suite la mise sur le march de nouvelles consoles de jeu par des
socits d'lectronique),
une exigence juridique (exemple: un fabricant de peinture autorise un
projet pour l'laboration de directives concernant la manipulation d'un
nouveau produit toxique).
2.2.
Qu'est-ce que le management de projet?
Le management de projet est l'application de connaissances, de comptences,
d'outils et de techniques aux activits du projet afin d'en respecter les
exigences. Le management de projet est accompli par l'application et
l'intgration des processus de management de projet groups en : dmarrage,
planification, excution, surveillance et matrise, et clture. Le chef de projet
est la personne responsable de latteinte des objectifs du projet.
Le
management de projet comprend les points suivants:

dterminer les exigences,
dfinir des objectifs clairs et ralisables,
quilibrer les exigences concurrentes de qualit, de contenu, de dlai et de
cot,
adapter les spcifications, les plans et l'approche aux diffrentes
proccupations et attentes des diverses parties prenantes.
Les chefs de projet parlent souvent de triple contrainte (contenu du projet,

dlai et cot) pour le management d'exigences concurrentes d'un projet. La
qualit du projet dpend du bon quilibre entre ces trois facteurs. Des projets
de haute qualit dlivrent le produit, le service ou le rsultat exig en
respectant le contenu, les dlais et le budget. La relation entre ces trois facteurs
est telle que si l'un des facteurs varie, il affectera vraisemblablement au moins
l'un des deux autres. Les chefs de projet grent galement des projets pour
Page 14
rpondre des incertitudes. Le risque d'un projet est un vnement ou une

condition incertains qui, s'ils surviennent, ont un effet positif ou ngatif sur au
moins l'un des objectifs de ce projet.
L'quipe de management de projet a une responsabilit professionnelle envers
les parties prenantes parmi lesquelles les clients, l'entreprise ralisatrice et le
public. Les membres de PMI adhrent un Code de dontologie et ceux
ayant la certification de Professionnel en management de projet (PMP) un
Code de conduite professionnelle . Les membres de l'quipe de projet qui
sont membres du PMI et/ou certifis PMP sont tenus d'adhrer aux versions
actuelles de ces codes.
Il est important de noter que de nombreux processus composant le
management de projet sont itratifs en raison de l'existence et de la ncessit
d'une laboration progressive tout au long du cycle de vie d'un projet. En
d'autres termes, plus une quipe de management de projet connat le projet,
mieux elle pourra le grer de manire plus dtaille.
Le terme management de projet est parfois employ pour dcrire une
approche organisationnelle ou de gestion gnrale du management des projets
et de certaines oprations courantes qui peuvent s'apparenter des projets;
cette approche est aussi connue sous le nom de management par projets .
Une organisation qui adopte cette approche dfinit ses activits comme des
projets conformment la dfinition d'un projet .La tendance ces dernires
annes a t d'appliquer le management de projet de plus en plus d'activits
dans de plus en plus de domaines d'application. Le management par projets
connat un succs grandissant dans le monde des organisations. Ceci
n'implique pas que toutes les activits oprationnelles peuvent tre organises
comme des projets ou quelles devraient ltre. L'adoption du management
par projets est galement lie l'adoption d'une culture organisationnelle
adapte,. Bien que la comprhension du management de projet soit essentielle
pour une organisation qui utilise le management par projets ,.
Page 15
2.3.
Vue d'ensemble des domaines de connaissance en
management de projet et des processus de management de
projet
Le PMI, dans son PMBOK (Project Management Body of Knowledge), recense et

classifie les techniques de gestion de projet en neuf domaines de connaissance
et en groupes de processus
Tableau Vue densemble des neuf domaines de connaissance
Management de lintgration
du projet
laboration de la charte du
projet
laboration de lnonc
prliminaire du contenu du projet
laboration du plan de
management du projet
Direction et pilotage de
lexcution du projet
Surveillance et matrise du
travail du projet
Matrise intgre des
modifications
Management du contenu
du projet
Planification du contenu
Management des dlais du

projet
Identification des activits
Dfinition du contenu
Squencement des activits
Cration de la structure de
dcoupage du projet
Estimation des ressources

ncessaires aux activits
Estimation de la dure des
activits
Vrification du contenu
Matrise du contenu
laboration de lchancier
Matrise de lchancier
Page 16
Clture du projet
Management des cots du
projet
Estimation des cots
Budgtisation
Matrise des cots
Management de la qualit
du projet
Planification de la qualit
Mise en uvre de
lassurance qualit
Mise en uvre du contrle
qualit
Management des
communications du projet
Management des risques

du projet
Planification des
communications
Diffusion de linformation
Planification du
management
des
risques
Identification
des
risques
tablissement du rapport
davancement
Management des parties
prenantes
Analyse qualitative des

risques
Analyse quantitative des
risques
Planification des rponses
aux risques
Surveillance et matrise des
risques
Management des ressources

humaines du projet
Planification des ressources
humaines
Formation de lquipe de projet
Dveloppement de lquipe de
projet
Diriger lquipe de projet
Management des
approvisionnements du
projet
Planification des
approvisionnements
Planification des contrats
Sollicitation des offres ou des
propositions des fournisseurs
Administration du contrat
Clture du contrat
Page 17
INTGRATION
4.1
PARTIES PRENANTES
laborer la charte
du projet
RESSOURCES HUMAINES
Identifier les
parties prenantes
13.1
9.2
PLANIFICATION
5.1
Constituer lquipe de
projet
7.1 Planifier le management

des cots
CONTENU
Diriger et grer
le travail du projet
4.3
COMMUNICATIONS
7.2
Recueillir les exigences
PARTIES PRENANTES
Grer les
communications
13.3
Grer lengagement
des parties prenant
Estimer les cots
COTS
Dfinir le contenu
7.3
QUALIT
Dterminer le budget
8.1
RESSOURCES HUMAINES
Planifier le
management de la qualit
CONTENU
5.4
Procder aux
12.2 approvisionnements
COTS
CONTENU
5.3
9.4 Diriger lquipe de projet
INTGRATION
COTS
Planifier le
management du contenu
RESSOURCES HUMAINES
Dvelopper lquipe de
projet
APPROVISIONNEMENTS
Mettre en oeuvre
lassurance qualit
10.2
5.2
9.3
QUALIT
8.2
CONTENU
RESSOURCES HUMAINES
INTGRATION
4.2
Crer la SDP
DLAIS
9.1 Planifier le management des

ressources humaines
6.2
laborer le plan de
management du projet

des approvisionnements
DLAIS
6.4
DLAIS
6.5
RISQUES
Estimer les ressources

ncessaires aux activits
11.2
DLAIS
Estimer la
dure des activits

des parties prenantes
RISQUES
Dfinir les activits
Organiser les
activits en squence
PARTIES PRENANTES
Planifier le
11.1 management des risques
DLAIS
6.3

des communications
APPROVISIONNEMENTS
DLAIS
6.1 Planifier le management de

lchancier
COMMUNICATIONS
6.6
RISQUES
Identifier les risques
11.3 Mettre en oeuvre lanalyse

qualitative des risques
RISQUES
laborer lchancier
RISQUES
11.4 Mettre en oeuvre lanalyse

quantitative des risques
Planifier les
rponses aux risques
11.5
CLTURE
INTGRATION
4.6 Clore le projet ou la phase
SURVEILLANCE ET MATRISE
Clore les
QUALIT
CONTENU
APPROVISIONNEMENTS
5.5
8.3
Valider le contenu
Mettre en oeuvre
le contrle qualit
COMMUNICATIONS
INTGRATION
Page 19
CONTENU
5.6
4.4
Matriser le contenu
Surveiller et matriser
le travail du projet
6.7
4.5
Matriser lchancier
COTS
7.4
Matriser les cots
Matriser les
communications
RISQUES
INTGRATION
DLAIS
10.3
Mettre en uvre la
matrise intgre
des
modifications
11.6
Matriser les risques
APPROVISIONNEMENTS
Matriser les
PARTIES PRENANTES
13.4 Matriser lengagement des
parties prenantes
2.4.
Prsentation Microsoft Project:
Les principales fonctionnalits de Microsoft Project sont :

Planification et pilotage des projets
Gestion des ressources
Gestion des cots
Analyse et communication des informations du projet
Gestion de projet: Microsoft Project vous aide planifier des projets

simplement et collaborer avec dautres personnes. Restez organis et
suivez de prs votre projet avec lunique systme de gestion de projet
conu pour fonctionner parfaitement avec dautres applications Microsoft
et les services en nuage.
tre organis
Livrer des projets avec succs
Amliorer la collaboration quotidienne
Gestion de portefeuille de projets: La nouvelle version de Project

offre votre organisation un moyen de dmarrer rapidement des projets,
de hirarchiser les investissements en matire de portefeuille de projets
et de produire des rsultats la hauteur de la valeur commerciale
attendue. Elle est la solution flexible en ligne pour la gestion de
portefeuille de projets et le travail de tous les jours. La nouvelle version
de Project est galement disponible pour les installations locales.
Aligner la vision et leffort
Renforcer la collaboration quotidienne
Grer efficacement les ressources
Microsoft Projet est disponible en deux ditions, Standard et Professionnelle.

Les deux ditions sont disponibles en 32 bits ou en 64 bits. L'dition
Professionnelle comprend toutes les fonctionnalits de la version Standard,
avec en plus des fonctionnalits supplmentaires comme les outils de
collaboration d'quipe et la capacit de se connecter Microsoft Project
Server.
Microsoft Project inclut l'interface utilisateur Fluent connu sous le nom de
ruban.
Interoprabilit
Page 20
Les capacits de Microsoft Project ont t tendues avec l'introduction

de Microsoft Office Project Server et Microsoft Project Web Access.
Project Server stocke les donnes de projet dans une base de donnes SQLcentral, permettant plusieurs projets indpendants d'accder un pool de
ressources partages. Web Access permet aux utilisateurs autoriss d'accder
une base de donnes Project Server travers l'Internet, et comprend des
feuilles de temps, l'analyse graphique de la charge de travail des ressources
et des outils d'administration.
Planification contrle par l'utilisateur
Lordonnancement contrl par l'utilisateur offre des choix flexibles pour
le dveloppement et la gestion de projets.
Vue chronologique
La vue chronologique permet l'utilisateur de construire un aperu
graphique de base, de style VISIO, de l'chancier du projet. La vue peut tre
copie et colle dans PowerPoint, Word ou toute autre application.
Synchronisation de la liste SharePoint
Les mises jour des statuts des tches au niveau de SharePoint
Foundation et de Project Professional peuvent tre synchronises pour les
membres de l'quipe.
Tches inactives
Aide avec les plans de projet et la ralisation des analyses de simulation
La vue du planificateur de l'quipe
Le nouveau planificateur d'quipe prsente les ressources et le travail au fil
du temps, et permet de dtecter et de rsoudre les problmes
Microsoft Project est dclin en deux versions :
Microsoft Project standard :
o Version destine aux utilisateurs qui grent leurs projets sur leur
poste de travail sans partage de donnes sur tches et les
ressources avec dautres utilisateurs.
o Les projets sont enregistrs dans des fichiers individuels sur des
mdias de stockage locaux ou accessible via le rseau de
lentreprise.
Microsoft Project Professionnel :
o Version destine aux utilisateurs travaillant dans un contexte de
travail collaboratif
o Les projets sont enregistrs dans une base de donnes MS SQL
Server
o Pour utiliser ce mode, il est ncessaire de se connecter MSProject Server pour accder aux donnes des projets
Les fichiers de plannings dvelopps avec les deux versions standard et
professionnelle sont entirement compatibles
Page 21
Par ses amliorations visuelles et ses mises jour, Project Standard fournit
de puissants moyens visuels pour grer une large gamme de projets et de
programmes. Project Professional inclut toutes les fonctions de Project
Standard, et y ajoute des fonctionnalits comme la gestion des ressources en
un coup dil et des outils de collaboration dquipe bass sur Microsoft
SharePoint Foundation. En ajoutant Microsoft Project Server Project
Professional, vous bnficierez des avantages dune gestion de projet et de
portefeuille unifie.
Page 22
3. Mthodologie Agile
3.1.
Une approche agile de gestion de projet
Depuis des dcennies, les projets sont grs avec une approche classique, le
plus frquemment en cascade ou son adaptation en V , base sur des
activits squentielles : on recueille les besoins, on dfinit le produit, on le
dveloppe puis on le teste avant de le livrer au client.
Ces mthodologies se caractrisent par un attachement farouche tout
planifier, tout doit tre prvisible , en tout dbut de projet. Voil
pourquoi on les qualifie dapproches prdictives . Un plan de management
du projet dcrit comment et quand le travail sera ralis, les modalits de
planification, dexcution, de suivi et de clture du projet.
Cette volont persistante de vouloir piloter le projet par les plans (plan-driven
development) a conduit les acteurs dun projet redouter, voire sopposer
systmatiquement tout changement : changement dans le contenu ou le
primtre du projet, dans le processus de dveloppement, au sein de lquipe,
bref toute modification des plans initiaux, auxquels on doit rester conforme.
Fort du constat que les plans initiaux sont finalement toujours modifis et que
les besoins voluent en permanence pour rpondre aux changements du
march, ces approches prdictives se sont rvles trop rigides parfois,
exposant les organisations trop peu de ractivit dans le contexte de
nouveaux projets stratgiques.
Sont alors apparues, dans les annes 1990, des mthodes moins prdictives,
plus souples face aux besoins dadaptation, facilitant ainsi lagilit des
organisations face aux contraintes du march Ce sont les mthodes dites
agiles.
3.2.
Limites des approches traditionnelles
3.2.1.
Modle en cascade
Le cycle en cascade se caractrise par des phases squentielles, qui se

succdent aprs la validation des livrables produits lors de la phase prcdente
:
Tous les besoins sont exprims et recueillis lors de la premire
phase, puisque lanalyse dtaille de ces besoins, puis la conception du
systme qui rpondra ces besoins, en dpendront.
La conception du systme, bien que textuelle ou reprsente sous
forme de diagrammes, doit tre valide avant le dmarrage des
dveloppements.
Les dveloppements doivent tre achevs pour permettre lquipe de
testeurs de lancer ses campagnes de tests fonctionnels et techniques.
Page 23
Enfin, une fois, et seulement une fois, que les anomalies ont t
corriges, on peut procder lintgration globale finale et la mise en
production du systme.
Chaque phase se termine une date prcise par la production de certains

documents ou livrables.
Les rsultats sont dfinis sur la base des interactions entre tapes et
activits, ils sont soumis une revue approfondie.
On ne passe la phase suivante que s'ils sont jugs satisfaisants
On travaille chaque tape l'une aprs l'autre : la moindre erreur cote cher
Page 24
3.2.1.1. Les failles dune approche en cascade

La rigidit de lapproche
On dplore que la nouveaut, la marge de manuvre laisse, juste titre, au
client pour prciser ou faire voluer ses attentes, la non-prvisibilit de tous
les vnements soient difficilement compatibles avec une approche prdictive
comme celle du cycle en cascade.
En fait, une fois le plan de management du projet valid, il constitue la rfrence
de base. La proccupation majeure du chef de projet devient alors de coller au
plus prs au plan, quels que soient les vnements ; tout cart constat,
concernant la dure des activits, la productivit ou la disponibilit des
ressources ou encore les risques imprvus, est peru comme un chec, vcu
par certains comme une incomptence ou une incapacit anticiper.
Lapproche en cascade est par consquent trop rigide pour permettre des
retours en arrire ; elle suppose que lon fasse bien du premier coup. Une
dcision ou une anomalie dtecte dans une phase aval de la cascade peuvent
remettre en cause partiellement ou totalement des travaux valids
prcdemment et considrs comme dfinitifs
Leffet tunnel
Leffet tunnel est une autre des caractristiques de lapproche en cascade :
Si un projet dure X mois, et la phase de recueil des besoins dure Y mois, le
client ne voit le rsultat que, tardivement, quelques mois plus tard.
Que sest-il pass entre-temps ?

Que va-t-il sortir de la bote ? , Mais, ce nest pas ce que lon attendait
! ou bien
Cest ce que nous voulions mais notre besoin a un peu volu depuis !
La longueur des phases techniques auxquelles le client nest pas associ rend
celui-ci dubitatif sur le rsultat venir. Ce qui ne favorise pas la collaboration
efficace entre dveloppeurs et utilisateurs
Dautant plus si le rsultat livr nest pas conforme ce qui est attendu.
Une mauvaise communication
Labsence de jalons intermdiaires prohibe la validation de ce que sera la version
finale du produit. Il faut attendre que la phase de dveloppement soit bien
avance pour dcouvrir les premiers rsultats. Les mauvaises surprises en fin de
cycle de vie et le refus du changement par les quipes de dveloppement
pnalisent la qualit des relations avec les utilisateurs. Elles en deviennent mme
parfois conflictuelles ; les uns sattachent ferme- ment leurs plans initiaux pour
livrer ce qui tait convenu lchance prvue, mme si le rsultat ne correspond
plus ou pas totalement ce qui est rellement attendu ; les autres ressentent
cette rigidit comme un dsintrt pour la valeur ajoute du produit final.
La leve tardive des facteurs risques
Page 25
Dans un cycle de vie en cascade , les facteurs risques sont levs

tardivement, puisque les tests de performance ou dintgration, par exemple,
sont reports aprs les dveloppements, tout comme lapprciation des IHM
(Interface homme-machines).
Limpact des risques augmente avec lavancement du projet, puisque plus une
anomalie est dtecte tardivement, plus le retour arrire est complexe, plus sa
correction cotera cher et plus les effets de bords seront menaants
Une documentation en grande quantit
Afin de se prmunir contre ces risques, lapproche en cascade sattache
fortement la production dune documentation importante.
La documentation permet de repousser le moment o il va falloir aborder la
phase de dveloppement, phase irrversible.
Elle rassure et, sil en tait ncessaire, elle apporte la preuve que la ralisation
progresse ; elle matrialise lavancement et engage les parties prenantes. En
effet, il est plus ais de sopposer au changement en brandissant un document
contractuel valid prcdemment !
Malheureusement, cette documentation, souvent trop plthorique, ne reflte pas
la ralit des dveloppements : on a beau valider un document darchitecture,
celle-ci reste thorique et conceptuelle tant quelle nest pas implmente et
teste dans des conditions relles ; on a beau prsenter des maquettes
papier au client, celui-ci est plus sensible au produit fini
3.2.2.
Modle en V
Le modle du cycle en V a t imagin pour pallier le problme de ractivit

du modle en cascade. Ce modle est une amlioration du modle en cascade
qui permet en cas d'anomalie, de limiter un retour aux tapes prcdentes.
Les phases de la partie montante doivent renvoyer de l'information sur les
phases en vis--vis lorsque des dfauts sont dtects afin d'amliorer le
logiciel.
De plus le cycle en V met en vidence la ncessit d'anticiper et de prparer
dans les tapes descendantes les attendus des futures tapes montantes :
ainsi les attendus des tests de validation sont dfinis lors des spcifications,
les attendus des tests unitaires sont dfinis lors de la conception, etc.
Le cycle en V est devenu un standard de l'industrie du dveloppement de
logiciel et de la gestion de projet depuis les annes 1980.
Les caractristiques de ce modle sont :
Facile utiliser
Les tests sont effectus chaque tape
Le contrle se fait progressivement chaque tape
Les phases de validation sont prises en main trs tt dans le processus
de dveloppement
Page 26
Cependant, les inconvnients majeurs de ce modle sont

Une mauvaise prise en compte des vnements concurrents
Le processus nest pas itratif
Une mauvaise prise en compte des changements de la spcification des
besoins
Ne contient pas les activits danalyses de risques
Pour utiliser ce modle
Les spcifications de besoins doivent tre bien faites
Page 27
La solution dvelopper et la technologie utiliser doivent tre

parfaitement connues
Les changements doivent tre faits avant lanalyse
Excellent pour les systmes requrant une grande sret
Hormis le traitement des tests diffrents niveaux des tapes de
dveloppement, ce modle les mmes failles que le modle en cascade :
Leffet tunnel
Une mauvaise communication
La leve tardive des facteurs risques
Une documentation en grande quantit
3.2.3.
Approches plus rcentes Modle itratif
L'itration est le processus par lequel le rsultat souhait est dvelopp par
des cycles rpts
Une approche itrative permet la rvision et lajout, tape par tape, des
produits de travail
Diffrents types de modles itratifs supportent :
La rvision et lajout des exigences
La rvision et lajout de design
La rvision et lajout de fonctionnalits
Le test dune partie du systme
et ainsi de suite
Les objectifs de dveloppement itratif sont les suivants :
frquentes dmonstrations de la progression
alerte prcoce des problmes
capacit dintgrer les changements de faon lgante
Quatre types de modles de dveloppement itratif :
Construction-incrmentale
agile : satisfaire aux exigences oprationnelles itrativement
volutif : le dveloppement exploratoire
spirale : la gestion des risques
Le modle agile sera trait en abondance dans ce cours. Nous prsentons les
modles les plus usuels : Le modle en spirale et le modle par construction
itrative
3.2.3.1. Modle en spirale
Propos par B. Boehm en 1988, ce modle est beaucoup plus gnral que le
modle en V. Il met l'accent sur l'activit d'analyse des risques : chaque cycle
de la spirale se droule en quatre phases :
Dtermination, partir des rsultats des cycles prcdents, ou de l'analyse
prliminaire des besoins, des objectifs du cycle, des alternatives pour les
atteindre et des contraintes.
Page 28
Analyse des risques, valuation des alternatives et, ventuellement

maquettage.
Dveloppement et vrification de la solution retenue, un modle
classique (Cascade ou en V) peut tre utilis ici ;
Revue des rsultats et vrification du cycle suivant.
L'analyse prliminaire est affine au cours des premiers cycles. Le modle
utilise des maquettes exploratoires pour guider la phase de conception du cycle
suivant. Le dernier cycle se termine par un processus de dveloppement
classique.
Le processus de dveloppement en spirale est un modle de mta-niveau

pour les modles de dveloppement itratif
Des activits antrieures sont revisites, rvises, et raffines
chaque passage de la spirale
Chaque cycle d'un modle en spirale comporte quatre tapes:
Etape 1 - dterminer les objectifs, les alternatives, et des
contraintes
tape 2 - identifier les risques pour chaque alternative et choisir
l'une des alternatives
tape 3 - mettre en uvre la solution (lalternative) choisie
tape 4 - valuer les rsultats et le plan pour le prochain cycle
de la spirale
Page 29
Les cycles continuent jusqu ce que les objectifs souhaits soient atteints
(ou jusqu' ce que le temps et les ressources sont utilises)
Modle itratif
Des incrments sous forme de cycle
A la fin de chaque cycle on dtermine les objectifs du cycle suivant
Chaque cycle est compose des mme activits que du modle en
cascade
inclut l'analyse de risque et le prototypage
Phases :
Dtermination des objectifs

o En terme de fonctionnalit, de performance, de cout,...etc.
o Dterminer les alternatives : dvelopper, rutiliser, acheter,
sous-traiter...etc.
o Contraintes : cots, plannings, ... etc.
Identification et valuation de risques
o Etudier les alternatives de dveloppement
o identification des risques : technologie non maitrises, quipe
peu exprimente, planning trop serr, ...etc.
o Evaluation des risques : voir si les risques peuvent impacter le
projet et quel degr
Dveloppements et tests
o Contient pratiquement la plupart des activits :

conception, dveloppement, test, ... etc.
Planification de la prochaine itration
o Le planning de l'itration
o Le plan de tests
Avantages
identification rapide des risques

Impacts minimaux des risques sur le projet
Fonctions critiques dveloppes en premier
Feedback rapide du client
Une valuation continue du procd
Inconvnients
L'valuation des risques peut prendre beaucoup de temps

Le modle est trs complexe
La spirale peut s'terniser
Les dveloppeurs doivent tre raffects pendant les phases de
non-dveloppement
Les objectifs ne sont pas souvent faciles formuler
Quand est-ce que l'utiliser ?
Quand le prototypage est exig
Page 30
Quand le risque du projet est considrable

Quand les spcifications ne sont pas stables
Pour les nouveaux produits
Quand le projet implique de la recherche et de l'investigation
3.2.3.2. Modle incrmental ou par incrments

Dans les modles prcdents un produit est dcompos en composants
dvelopps sparment et intgrs la fin du processus.
Dans les modles par incrment, un seul ensemble de composants est
dvelopp la fois : des incrments viennent s'intgrer un noyau de logiciel
dvelopp au pralable. Chaque incrment est dvelopp selon l'un des
modles prcdents (Cascade ou V).
Les avantages de ce type de modle sont les suivants :
chaque dveloppement est moins complexe.
les intgrations sont progressives.
il est ainsi possible de livrer et de mettre en service chaque incrment.
il permet un meilleur lissage du temps et de l'effort de dveloppement
grce la possibilit de recouvrement (paralllisation) des diffrentes
phases.
Les risques de ce type de modle sont les suivants :
Remettre en cause les incrments prcdents ou pires le noyau.
Ne pas pouvoir intgrer de nouveaux incrments.
Les noyaux, les incrments ainsi que leurs interactions doivent donc tre
spcifis globalement, au dbut du projet. Les incrments doivent tre aussi
indpendants que possibles, fonctionnellement mais aussi sur le plan du
calendrier du dveloppement.
Chaque incrment est une construction partielle du logiciel

Trie les spcifications par priorits et les regroupent dans des
groupes de spcifications
Chaque incrment implment un ou plusieurs groupes jusqu'
ce que la totalit du produit soit finie
Page 31
Avantages
Dveloppement de fonctionnalits risque en premier

Chaque incrment donne un produit fonctionnel
Le client intervient la fin de chaque incrment
Utiliser l'approche diviser pour rgner
Le client entre en relation avec le produit trs tt
Inconvnients
Exige une bonne planification et trs bonne conception

Exige une vision sur le produit fini pour pouvoir le diviser en
incrments
Le cot total du systme peut tre cher
Quand l utiliser ?
Quand la plupart des spcifications sont connues lavance et

vont tre sujettes de faibles volutions
Quand on veut rapidement un produit fonctionnel
Pour des projets de longues dures
Pour des projets impliquant de nouvelles technologies
3.3.
Le manifeste Agile
Au milieu des annes 90, un groupe d'expert en Cycles de vie de logiciels

voulaient proposer de nouveaux modles
Les nouveaux modles sont plus lgers : moins de documentation
et moins de contrle sur le procd
Ces modles sadressent des projets de petite ou moyenne taille avec une
quipe rduite
Ces modles permettent de s'ajuster rapidement aux changements des
spcifications tout en garantissant des livraisons frquentes
Ces modles sont qualifis de modles agiles
Les mthodes Agiles consacrent une philosophie de travail volutive et
pragmatique reposant sur quatre valeurs et douze principes noncs par le
Manifeste Agile, rdig en 2001 par plusieurs experts de lingnierie logicielle,
en partant du constat selon lequel une part importante des checs industriels
en matire informatique est due une trop grande rigidit mthodologique et
juridique.
Page 32
Manifeste pour le dveloppement Agile de logiciels

Nous dcouvrons comment mieux dvelopper des logiciels par la pratique
et en aidant les autres le faire.
Ces expriences nous ont amens valoriser :
Les individus et leurs interactions plus que les processus et les
outils
Des logiciels oprationnels plus quune documentation exhaustive
La collaboration avec les clients plus que la ngociation
contractuelle
Ladaptation au changement plus que le suivi dun plan
Nous reconnaissons la valeur des seconds lments, mais privilgions les
premiers.
URL : http://agilemanifesto.org/iso/fr/
Principes
INDIVIDUS ET INTERACTIONS AU LIEU DE PROCESSUS ET
OUTILS
o Les collaborateurs sont la cl du succs
o Les seniors choueront s'ils ne collaborent pas en tant qu'quipe
o Un bon collaborateur n'est pas un forcment un bon
dveloppeur. C'est quelqu'un qui travaille bien en quipe
o Une surabondance d'outils est aussi mauvaise que le manque d'outils
o Dmarrer petit et investir peu au dmarrage
o Construire l'quipe c'est plus important que construire l'environnement
LOGICIEL FONCTIONNEL AU LIEU DE DOCUMENTATION
MASSIVE
o Un code sans documentation est un dsastre
o Trop de documents est pire que pas de documents
o Difficult produire et synchroniser avec le code
o Souvent les documents sont des mensonges formels
o Le code ne ment jamais sur lui-mme
o Produire toujours des documents aussi courts que possible
COLLABORATION DU CLIENT AU LIEU DE LA NGOCIATION
DE CONTRATS
o Trs difficile de dcrire la totalit du logiciel depuis le dbut
o Les projets russis impliquent les clients d'une manire frquente et
rgulire
o Le client doit avoir un contact direct avec l'quipe de dveloppement
RAGIR AUX CHANGEMENTS AU LIEU DE SUIVRE UN PLAN
o Un logiciel ne peut pas tre planifi trs loin dans le futur
o Tout change : technologie, environnement et surtout les besoins
o Les chefs de projets classiques fonctionnent sur la base de GANTT,
PERT et le systme de tches
Page 33
o Avec le temps, les diagrammes se dgradent car des tches s'ajoutent

et d'autres deviennent non ncessaires
o Une meilleure stratgie est de planifier trs court (02 semaines 01
mois)
o Plannings dtaills pour la semaine venir, rigoureux pour les trois
mois et trs vagues au-del
Principes sous-jacents au manifeste

Nous suivons ces principes:
1. Notre plus haute priorit est de satisfaire le client en livrant rapidement et
rgulirement des fonctionnalits grande valeur ajoute.
2. Accueillez positivement les changements de besoins, mme tard dans le
projet. Les processus Agiles exploitent le changement pour donner un
avantage comptitif au client.
3. Livrez frquemment un logiciel oprationnel avec des cycles de quelques
semaines quelques mois et une prfrence pour les plus courts.
4. Les utilisateurs ou leurs reprsentants et les dveloppeurs doivent travailler
ensemble quotidiennement tout au long du projet.
5. Ralisez les projets avec des personnes motives. Fournissez-leur
lenvironnement et le soutien dont ils ont besoin et faites-leur confiance pour
atteindre les objectifs fixs.
6. La mthode la plus simple et la plus efficace pour transmettre de
linformation l'quipe de dveloppement et lintrieur de celle-ci est le
dialogue en face face.
7. Un logiciel oprationnel est la principale mesure davancement.
8. Les processus Agiles encouragent un rythme de dveloppement soutenable.
Ensemble, les commanditaires, les dveloppeurs et les utilisateurs devraient
tre capables de maintenir indfiniment un rythme constant.
9. Une attention continue l'excellence technique et une bonne conception
renforce lAgilit.
10.La simplicit cest--dire lart de minimiser la quantit de travail inutile
est essentielle.
11.Les meilleures architectures, spcifications et conceptions mergent
d'quipes auto organises.
12. intervalles rguliers, l'quipe rflchit aux moyens de devenir plus efficace,
puis rgle et modifie son comportement en consquence.
URL : http://agilemanifesto.org/iso/fr/principles.html
LES DOUZE PRINCIPES AGILES
1. Toujours satisfaire le client travers des livraisons rapides et continues

2. Bien accueillir tous les changements mme les tardifs
Page 34
3.
4.
5.
6.
Livrer frquemment un systme fonctionnel

Les clients et les dveloppeurs doivent collaborer
Conduire le projet autour d'quipes motives
La meilleure mthode de faire circuler l'information c'est le contact direct
entre collaborateurs
7. La premire mesure d'avancement c'est un logiciel fonctionnel
8. Le dveloppement doit tre durable et un rythme constant
9. La bonne conception et l'excellence technique augmentent l'agilit
10.
Simplifier au maximum
11.
Les meilleures architectures, besoins et conceptions proviennent
d'quipes qui s'organisent d'elles-mmes
12.
L'quipe s'amliore d'une manire autonome et rgulire
3.4.
La place de Scrum dans le monde des mthodes Agiles
3.4.1.
Les principales mthodes Agiles
On parle quelquefois de mthode agile (au singulier) ou de mthodes agiles (au pluriel). Si le
premier terme dsigne le concept qui a t dcrit ci-dessus, il existe des dclinaisons en termes de
plan de mise en uvre, de vocabulaire et de prconisation. Ce sont les mthodes agiles (au
pluriel) dont voici les principales :
3.4.1.1. Scrum
Scrum (qui signifie mle au rugby) est aujourdhui la mthode agile la plus
populaire. Elle se caractrise par itrations (appeles sprints) assez courts
(maximum 1 mois) et un formalisme rduit : rles (Product Owner,
ScrumMaster, quipe), timeboxes (planification de release, planification de
sprint, scrum quotidien, revue de sprint, introspection) et artfacts (backlog
de produit, plan de produit, plan de sprint, burdown/burnup de release,
burdown/burnup de sprint)
3.4.1.2. EXtreme Programming (XP)
Lobjectif principal de cette mthode est de rduire les cots du changement.
Elle met laccent sur la revue de code (faite en permanence par un binme),
sur les tests (ils sont faits systmatiquement avant chaque dveloppement),
la conception continue (refactoring), la simplicit, la traduction des besoins en
mtaphores.
XP est souvent pratiqu conjointement avec Scrum.
Page 35
3.4.1.3. Rational Unified Process (RUP)

Cette mthode qui peut tre considre comme la moins agile des mthodes
prsentes ici, est un mlange des pratiques issues des mthodes
traditionnelles et des mthodes agiles. Le principe est de parcourir un cycle de
vie (inspection, laboration, construction, transition) durant une itration.
Chaque phase du cycle de vie est trs prcisment dtaille.
Son approche assez lourde et le cot dinvestissement de cette mthode la
rserve des projets de grande ou moyenne taille.
3.4.1.4. Feature Driven Development (FDD)
Moins connue que les 2 mthodes prcdentes, FDD est essentiellement ax
sur le design et le dveloppement. Pour cela elle sappuie sur une formalisation
du modle objet laide de diagrammes UML, un dcoupage par fonctions qui
seront dveloppes par des petites quipes responsables dune ou deux
fonctions. Elle accorde un aspect trs important la qualit du produit fini, et
saide doutils pour suivre le droulement du projet.
3.4.1.5. Rapid Application Development (RAD)
Cest la mthode agile la plus ancienne et celle qui a t la premire tre en
rupture avec les mthodes traditionnelles. Elle a introduit les notions ditration
et dincrment. Elle vise adopter la solution la plus stratgique (en termes
de dlais), la moins risque, la plus fiable et la moins coteuse. Son cycle de
dveloppement est simple : cadrage, design, construction et finalisation dans
le respect absolu dune dure comprise entre 90 et 120 jours.
3.4.1.6. Dynamic systems development method (DSDM)
DSDM est mthode agile dveloppe en Angleterre au milieu des annes 90.
Elle reprend les principes dj vus dans les autres mthodes (implication des
utilisateurs, autonomie de lquipe, visibilit et adquation du rsultat,
dveloppement itratif et incrmental, rversibilit des modifications, tests
continus, coopration des acteurs).
3.4.2.
Pratiques communes l'ensemble des mthodes
agiles
Les pratiques communes lies aux ressources humaines
o Participation de lutilisateur final aux groupes de travail.
o Groupes de travail disposant du pouvoir de dcision.
o Autonomie et organisation centralise de lquipe (motivation).
o Spcification et validation permanente des Exigences.
Les pratiques communes lies au pilotage du projet
o Niveau mthodologique variable en fonction des enjeux du projet.
Page 36
Pilotage par les enjeux et les risques.

Planification stratgique globale base sur des itrations rapides.
Ralisation en jalons par prototypage actif itratif et incrmental.
Recherche continue damlioration des pratiques.
Les pratiques communes lies la qualit de la production
o Recherche dexcellence technique de la conception.
o Vision graphique dune modlisation ncessaire et suffisante.
o Vision de la documentation ncessaire et suffisante.
o Normes et techniques raisonnables de qualit du code (mtrique).
o Architecture base de composants.
o Gestion des changements automatiss
o
o
o
o
3.4.3.
Pratiques diffrenciatrices des mthodes agiles
Seules quelques techniques complmentaires entre elles, ou mieux adaptes
des typologies et des tailles de projets donnes, diffrencient les
mthodes agiles. Les pratiques diffrenciatrices les plus marquantes sont :
La mthode RAD prconise lors de la phase de Construction de
l'application des techniques similaires celles d'XP mais non extrmes
dans leur mise en uvre : des revues de code personnelles, puis
collectives et l'intgration avant chaque focus (ou show). Par contre, le
RAD limite la programmation en binme aux parties les plus
stratgiques. Toute mthode de conduite de projet devrait inclure un
mode opratoire pour les arrts d'urgence (Go/NoGo). Sur ce point la
force du RAD se situe dans la prsence d'un animateur-facilitateur. Cette
ressource, de prfrence externe, doit tre neutre en regard des autres
intervenants. Elle rpond une autorit suprieure tous les
participants du projet. Ainsi, lorsque le contexte stratgique,
conomique ou technique d'un projet volue, ou si les conditions de
ralisation se dgradent, l'animateur reporte le problme au dirigeant
qui l'a mandat. Ce dernier peut alors prendre, dans les meilleurs dlais,
et avec des informations objectives les dcisions qui s'imposent.
Le RAD dans sa version 2 recommande la variabilit de la taille et de la
maturit des groupes de travail en fonction des phases du projet afin
d'optimiser l'engagement des ressources et de prserver leur intrt par
un travail adapt leurs proccupations. Le plus srieux apport de RAD2
la communication de projet et la formalisation des exigences
applicatives est le groupe d'animation et de rapport (GAR). Avec RAD
2, l'organisation performante des runions est base sur un mode
opratoire des entretiens et sur des techniques de validation
permanente. Le RAD propose des techniques de pilotage stratgique
comme la livraison en fonctionnalit rduite ou la livraison par thmes.
La mthode DSDM (nom donn au consortium commercialisant la
mthode RAD en Angleterre) se particularise par la spcialisation des
acteurs du projet dans une notion de rles . Ainsi, l'on trouvera dans
les runions DSDM des sponsors excutifs, des ambassadeurs, des
utilisateurs visionnaires, des utilisateurs conseillers, sans oublier
l'animateur-facilitateur et des rapporteurs.
Page 37
La mthode scrum affirme sa diffrence dans la gnralisation d'un

crmonial bas sur des pratiques de courtes runions chaque tape
de la vie du projet (rtrospectives). Ces temps de travail commun ont
pour objectifs d'amliorer la motivation des participants, de synchroniser
les tches, de dbloquer les situations difficiles et d'accrotre le partage
de la connaissance.
Pour FDD, la particularit nomme mission focused rside dans une
forte orientation vers un but immdiat mesurable guid par la notion de
valeur mtier. C'est en fait l'ambition globale d'une itration qui se
trouve ainsi renforce. Cet aspect se retrouve aussi dans la mthode
RAD sous la forme des objectifs de Focus ou dans Scrum dans la notion
d'objectifs de Sprint.
XP (extreme programming) est trs ax sur la partie Construction de
l'application. Une de ses originalits rside dans lapproche de
planification qui se matrialise sous la forme dun jeu intitul planning
game et qui implique simultanment les utilisateurs et les dveloppeurs.
On notera aussi des techniques particulires lies la production du code
comme le test driven development (TDD), la programmation en
binme (Pair programming), l'appropriation collective du code, la
refactorisation (refactoring) et l'intgration continue.
3.4.4.
Synthse des mthodes Agile
Malgr leurs spcificits, les projets ont longtemps t conduits sur la base
d'un cycle de vie linaire -expression du besoin-cadrage-conceptionralisation-tests-. A l'issue de ce processus (d'une dure rarement maitrise)
l'utilisateur dcouvrait le rsultat plus ou moins conforme ses attentes.
Au dbut des annes 1980 sont apparues dans le monde du dveloppement
de nouvelles mthodes de management de projet censes supprimer cet effet
tunnel et corriger les drives de dlai. Aujourd'hui regroupes sous l'intitul
de "mthodes agiles" elles ont en commun de mettre l'utilisateur au centre
de la dmarche, de privilgier le respect du dlai et de fonctionner suivant un
cycle itratif.
Les principes de base
Une organisation "plate" non hirarchise
Une quipe rduite (4 8 personnes) engage, multidisciplinaire,
solidaire et autogre
Un lieu ddi (war-room) consacr aux travaux de groupe
Une communication troite et frquente avec le Client
Une architecture systme modulaire
La livraison trs tt puis rgulirement de parties du systme
fonctionnelles qualifies
Des itrations courtes (2 3 semaines)
La priorit donne au respect du timing sur toute autre
proccupation
Des points quotidiens de dure courte (15 30 mn)
Page 38
Le culte de la simplicit et de l'adaptation permanente

Les principales mthodes agiles et leur vocabulaire spcifique
RAD (Rapid Application dveloppement) "Focus de visibilit" "quipe
swat" "timebox" "GAR (groupe d'animation et de rapport)"
XP (Extrem Programming)
UP (Unified Process) et RUP (Rational Unified Process)
SCRUM (mle en anglais) "scrum master" "user storie" "backup
produit" "daily scrum" "backlog du sprint" "sprint burnout chart"
DSDM (Dynamic Software DevelopmentMethod)
Le cycle itratif du projet "agile"

inspir de la roue de Deming
(PDCA)
A chaque tour la livraison d'une
fonctionnalit du systme
http://scrum.aubryconseil.com/
http://www.rad.fr/
http://www.entreprise-agile.com/
http://www.agilemanifesto.org/
http://www.agilealliance.com/
Page 39
4. TOUR DHORIZON
4.1.
Naissance de Scrum
Une tude parue en Avril 2009 (Chaos Report du Standish Group) montre que
seuls 32% des projets sont raliss dans les dlais et budgets initialement
dfinis. Ce faible taux de russite illustre la difficult quont les entreprises
figer leur besoin dans sa globalit, au dbut du projet.
Ne en 1986, la gestion de projet de dveloppement itratif permet dapporter
une rponse leffet tunnel souvent gnr par les cycles de ralisation projet
classiques. Le besoin fonctionnel est alors dcoup et prioris pour crer
plusieurs petits projets appels itrations. Le primtre fonctionnel et
technique de chaque itration est rduit pour quune solution complte et de
qualit soit dveloppe, mise en place et teste, la fin de chaque itration et
puisse partir en production.
Lobjectif de la mthode est de permettre la rduction des dlais de mise sur
le march des produits ou services, de sadapter en temps rel aux besoins
des utilisateurs en ayant la possibilit de modifier les spcifications chaque
livraison et permet de limiter leffet tunnel induit dans une mthode en V ou W
en donnant de la visibilit frquemment aux commanditaires du produit.
Le RAD, n en 1991 est lanctre de lAgile.
James Martin, son crateur, propose une mthode de dveloppement rapide
dapplications (RAD) se basant sur une nouvelle structure itrative,
incrmentale et adaptative. Les utilisateurs sont, pour la premire fois,
responsabiliss et leur validation permanente est requise. Trs vite, cette
mthode sera reprise et adapte pour donner naissance de multiples
variantes : XP (eXtrem Programming), Scrum, FDD (Features Driven
Development).
La mthode Scrum a, par exemple, ajout de courtes runions
quotidiennes la mthode RAD afin de motiver les participants, de
stimuler la communication, de synchroniser les tches et de rsoudre les
difficults rencontres.
La mthode XP, trs axe sur la partie construction de lapplication, se
distingue notamment par son approche de planification ludique.
La mthode FDD a quant elle mit laccent sur la finalit de litration
avec un but immdiatement mesurable et rsolument tourn vers la
notion de valeur mtier.
Le terme Agile napparatra quen 2001 suite la publication du Manifeste
Agile, rdig la lueur des expriences de 17 personnalits du dveloppement
logiciel. Ce terme unificateur regroupe les diffrentes mthodes
pralablement dfinies.
Dans le cadre de cette srie darticles, nous avons choisi de prsenter la
mthode Scrum car elle est de loin la plus utilise. De plus, cette mthode
rcente a fait ses preuves, elle est documente, simple comprendre et nous
lavons dj pratique. Mais, attention, derrire cette simplicit thorique se
cache une mise en application complexe qui exige rigueur et implication.
Page 40
Assurez-vous de la volont de russir vos projets lancs en mthode Agile, car

le niveau dnergie dploy par les quipes dans cette mthode est si lev
que les dceptions en cas dabandon sont dautant plus grandes.
Laugmentation significative du nombre dchecs des projets mens suivant
des mthodes traditionnelles sexplique par trois raisons majeures :
Manque dimplication des utilisateurs finaux
Spcifications incompltes
Changement de spcifications en cours de projet
Lapproche Agile permet dapporter une rponse ces problmatiques en
supprimant leffet tunnel, en offrant plus de visibilit et en impliquant le
client tout au long du projet. Cependant, pour y parvenir, un minimum de
rgles doivent tre respectes .
La mthode Agile nest pas une mthode :
Qui permet de russir dans nimporte quelles conditions tous ses projets
Qui permet de gagner du temps
Adaptable tous les contextes projet
En revanche, la mthode Agile permet :
De lever leffet tunnel des projets de grande envergure
De rduire les dlais de mise sur le march
De revoir son besoin initial en fonction des besoins des utilisateurs
Dapporter de la souplesse la ralisation
Tous ces lments sont organiss autour dune gestion de projet particulire
et adapte la mthode qui a dvelopp son propre langage et ses propres
rgles de fonctionnement. Pour approfondir la mthode, rendez-vous ds la
semaine prochaine pour connaitre quels sont les protagonistes dun projet
Agile.
Littralement, Scrum signifie mle de rugby en anglais. Dans les
annes 1990, Ken Schwaber utilise le mot pour donner naissance une
mthode de gestion de projet utilise notamment en dveloppement logiciel.
Alors que les mthodes agiles ne sont nes quen 2001 avec la cration du
Manifeste Agile,
1995 peut tre considre comme lanne officielle de naissance de Scrum o
Ken Schwaber dcrit les fondements de la mthode avant de les publier
conjointement avec Mike Beedle en 2001 dans leur ouvrage "Agile Software
Development With Scrum"
En 1995, Ken Schwaber (en) (avec l'aide de Jeff Sutherland (en)) prsente une
courte communication dcrivant les fondements de ce qui deviendra la mthode
scrum l'OOPSLA, Austin, aux tats-Unis.
En 2001, Ken Schwaber fait quipe avec Mike Beedle pour dcrire la mthode dans
le livre Agile Software Development With Scrum.
En 2004, publication de Agile Software Management with Scrum de Ken Schwaber.
En 2011, Jeff Sutherland et Ken Schwaber dcrivent les principes de la mthode
dans le Scrum Guide.
Page 41
4.2.
Scrum en quelques mots
Scrum est bel et bien considre comme une mthode agile. Avec Scrum, le
dveloppement est effectu par itrations appel sprint. Un sprint a une
dure fixe (1 4 semaines). Une release est dcoupe en plusieurs
itrations. Le premier sprint (ou sprint 0) est particulier : il a pour objet de
dfinir le backlog initial de la Release c'est--dire la liste des fonctionnalits
raliser. Pour chacun des sprints, lobjectif est de fournir un produit fini,
mme sil est partiel.
Les principes crits de la mthode Scrum ont dj quinze ans. Il ne sagit
donc pas dune "nouvelle mthode" ou dun effet de mode. Les principes ont
t prouvs.
4.2.1.
Lquipe
Avoir un projet, cest bien. Pouvoir le raliser, cest mieux. Sans tre humain,
il est bien difficile dimaginer sa ralisation. Scrum ncessite donc la prsence
dune quipe qui est compose de trois rles :
Le Product Owner
Le Scrum Master
Lquipe de dveloppement (aussi appele lquipe ou les quipiers).
Le Product Owner possde la vision du produit. Son rle principal est de la
retranscrire travers la rdaction d"histoires" que nous appellerons par la
suite User Stories. Lensemble des User Stories constitue alors une liste de
besoins formant ce qui est appel le Product Backlog. Bien entendu, les
responsabilits du Product Owner ne se limitent pas cela.
Page 42
La fonction du Scrum Master peut tre rsume celle de "facilitateur".

Cest en effet le Scrum Master qui a pour mission de lever les obstacles
que peuvent rencontrer les membres de lquipe, tout en sassurant que
la mthode Scrum soit correctement applique. Attention cependant ne
pas confondre Scrum Master et chef de projet, ces deux fonctions sont
antinomiques.
Enfin, lquipe de dveloppement, constitue de fonctions et expriences
htrognes (architecte, concepteur, designer, dveloppeur) a pour rle de
dvelopper les User Stories contenues dans le Product Backlog afin de
fournir un livrable de qualit. Malgr lhtrognit des profils, Scrum
ne fait pas de diffrence entre les diffrents membres de lquipe. Un
architecte sera donc appel dveloppeur, tout comme un concepteur.
Lquipe de dveloppement est auto organise, cestdire que personne na
lautorit sur la faon dont elle doit raliser son travail ni sur ce quelle doit
raliser.
Un des points majeurs que nous pouvons dores et dj relever aprs cette
lecture est la suppression du lien de subordination. En effet, la mthode
Scrum ne fait nullement rfrence la notion de "chef", ce qui se traduit
notamment par la suppression du rle connu de tous : le chef de projet.
4.2.2.
Les vnements (crmoniaux)
La notion de runion que lon connat dans une gestion de projet traditionnelle
se traduit dans la mthode Scrum par la prsence dvnements appels
crmoniaux.
Vivre un projet Scrum, cest vivre dans un environnement o tout a une dure
dfinie (time box). Il nest donc pas question de raliser des runions
interminables comme nous pouvons le connatre au quotidien dans une gestion
de projet traditionnelle, mais de dfinir une dure maximale chaque
vnement. Cette dure doit tre scrupuleusement respecte, ce qui permet
une meilleure gestion du temps et un gain de productivit.
Les vnements prconiss par Scrum sont au nombre de cinq :
Sprint
Runion de planification de Sprint
Scrum Meeting
Revue de Sprint
Rtrospective de Sprint
4.2.2.1. Sprint
Page 43
Le Sprint nest pas une runion au sens o nous pouvons lentendre. Dune
dure maximale dun mois, un Sprint correspond une priode de temps dans
laquelle un incrment du produit ltat termin, utilisable et potentiellement
livrable dans lenvironnement de production est ralis. Il sagit donc dune
grande runion reprsentant le quotidien de lquipe sur une dure dfinie.
4.2.2.2. Runion de planification de Sprint
Le contenu dun Sprint se prpare lors de la runion de planification qui ne

doit pas excder huit heures pour un Sprint dun mois ou quatre heures pour
des Sprints de deux semaines .
Durant cette runion qui convie lensemble de lquipe Scrum, lobjectif du
Sprint et les tches raliser sont dfinis.
4.2.2.3. Le Scrum Meeting
Ralise quotidiennement par lquipe de dveloppement sur une dure de
15 minutes, cette runion a pour but de raliser un point de synchronisation
sur les tches de dveloppement en cours et de permettre la planification
des prochaines 24 heures. Ce crmonial est galement appel Daily Scrum,
"Point debout", Stand up meeting, mle quotidienne.
4.2.2.4. La revue de Sprint
Dune dure maximale de 4 heures pour un Sprint dune dure dun mois (2
heures pour un sprint de deux semaines), cet vnement runit lensemble
des membres de lquipe Scrum autour dune dmonstration du livrable
fourni en fin de Sprint.
Page 44
Lobjectif de la dmonstration est de prsenter le travail ralis par lquipe

de dveloppement et de prciser les ventuels ajustements effectuer dans
le Sprint suivant.
4.2.2.5. La rtrospective de Sprint
Enfin, la rtrospective de Sprint permet danalyser lquipe Scrum ellemme afin denvisager si ncessaire la mise en place dun plan damlioration
(notion dintrospection). Dune dure maximale de 3 heures pour un
Sprint dun mois, cest ce moment-l que lensemble de lquipe peut
sexprimer sur son ressenti, sur les points amliorer ou maintenir.
4.2.3.
Les artefacts
La mthode Scrum comporte cinq artefacts que nous allons prsent

dcouvrir.
4.2.3.1. Product Backlog
Le Product Backlog, aussi appel Backlog, contient lexpression de besoins du
Product Owner traduite sous forme de User Stories. Chaque User Story
possde une valeur mtier (Business value) permettant ainsi dordonner le
Product Backlog par Business value dcroissante.
Lordre dcroissant des Business Values des User Stories a son importance car
celle ayant une Business Value plus importante sera traite en premier. Ceci
permet dobtenir rapidement une application forte valeur mtier.
Vous laurez compris, le Product Backlog est un pr-requis tout projet Scrum.
4.2.3.2. Sprint Backlog
Le Sprint Backlog est la liste des User Stories issues du Product Backlog devant
tre traite durant le Sprint.
Chaque User Story y est dcoupe en tches devant tre ralises par
lquipe de dveloppement et organise selon les trois tats suivants : "
faire", "En cours", "Termine".
Afin de donner un aspect visuel au Sprint Backlog, ce dernier est reprsent
sous forme de tableau coll au mur sur lequel sont ajouts des post-it
correspondant aux User Stories et tches associes.
Page 45
Un Sprint Backlog
4.2.3.3. Burn Down Chart

Toujours dans un souci de communication de linformation aux membres du
projet Scrum, une rflexion a t mene afin de permettre de visualiser
rapidement le reste faire pour le Sprint courant.
Cette visualisation sopre grce la ralisation du graphique appel Burn
Down Chart qui vient sajouter au tableau du Sprint Backlog.
En abscisse est reporte la dure du Sprint et en ordonne la somme des
complexits de chaque User Story contenue dans le Sprint. Vient ensuite
sajouter une courbe linaire permettant dapprcier le reste faire idal
jour par jour du dbut la fin du Sprint.
Aprs chaque Scrum Meeting, lquipe reporte le reste faire sur ce
graphique et le compare avec le reste faire idal afin den dduire les actions
entreprendre (il se peut que lquipe soit en avance ou en retard).
Le Burn Down Chart
Page 46
4.2.3.4. Burn Up Chart

Le Burn Up Chart permet quant lui de visualiser la valeur mtier dveloppe
et de dcider de continuer ou non le projet.
En abscisse, nous retrouvons la dure prvue de ralisation et en ordonne les
diffrentes valeurs mtier de chaque User Story contenue dans le Product
Backlog.
Linformation est mise jour chaque fin de Sprint et consiste indiquer
sur le graphique la somme des valeurs mtier traites durant le Sprint
(courbe ayant des carrs en guise de point sur le graphique, lautre courbe
montrant la valeur mtier devant idalement tre produite).
Ce graphique va connatre une forte croissance du fait que les User Stories
forte valeur ajoute seront traites en premier (Cf lordonnancement des
User Stories dans le Product Backlog). Ds lors que 80% de la valeur
mtier globale du projet est atteinte, il est intressant de se poser la
question de continuer le projet pour les 20 % restants.
Le Burn Up Chart
4.2.3.5. Courbe de temprature

Rarement employ dans la mthode Scrum, ce graphique peut savrer tre
un bon outil pour le Scrum Master.
La courbe de temprature permet de connatre le moral de lquipe afin de
remdier rapidement tout problme.
Ralis une frquence dfinie par lquipe, ce graphique comporte en
abscisse les diffrents moments choisis par lquipe et en ordonne le moral
de chaque personne constituant lquipe (pouvant tre reprsent par un
smiley, un chiffre de satisfaction).
Le principal inconvnient de ce graphique est quil joue sur la notion de
transparence vis--vis de lensemble de lquipe. Il nest pas facile de montrer
Page 47
que nous sommes en difficult dans une quipe car nous avons toujours peur
dtre jugs, sanctionns. Il convient donc au Scrum Master dinstaurer un
climat de confiance permettant la mise en place de ce type de graphique qui
peut savrer trs utile.
La courbe de temprature
4.3.
Le cycle de vie de Scrum
Le cycle de vie est le suivant :

1. Le Product Owner (appel propritaire du produit sur lillustration)
rdige les User Stories et les place dans le Product Backlog
2. Le Product Owner priorise ensuite ces User Stories en fonction de
leur Business value.
Page 48
3. Lquipe Scrum se runit lors du crmonial de planification de

Sprint afin de dterminer les User Stories pouvant tre traites
durant le Sprint. Celles ayant t lues sont ensuite places dans le
Sprint Backlog puis dcoupes en tches.
4. Le Sprint peut alors commencer pour une itration de 2 , 3 voire 4
semaines.
5. Lquipe se runit quotidiennement pour raliser le Scrum Meeting.
6. lissue du Sprint, nous possdons un produit potentiellement livrable
qui fait lobjet dune dmonstration lors de la revue de Sprint.
7. Le cycle se termine enfin par la rtrospective de Sprint non
mentionne sur lillustration mais infiniment primordiale.
4.4.
Les 3 Piliers de SCRUM
Scrum est un processus empirique : il se base sur l'exprience du terrain.

Il s'appuie sur trois piliers
Transparence
Scrum met l'accent sur le fait d'avoir un langage commun entre l'quipe
et le management. Ce langage commun doit permettre tout
observateur d'obtenir rapidement une bonne comprhension du projet.
Les aspects importants du processus doivent tre visibles ceux qui sont
responsables des retombes. La transparence requiert la dfinition dun
standard commun pour ces aspects afin que les observateurs partagent
une comprhension commune de ce qui est observ.
titre dexemple :
o Un langage commun dcrivant le processus doit tre partag par
tous les participants ; et,
o Ceux qui effectuent le travail et ceux qui en acceptent le rsultat
doivent partager une dfinition commune de Termin .
Inspection
intervalle rgulier, Scrum propose de faire le point sur les diffrents
artfacts produits, afin de dtecter toute variation indsirable.
Ces inspections ne doivent pas tre faites trop frquemment, ou par un
inspecteur mal form : cela nuirait l'avancement du projet.
Les utilisateurs de Scrum doivent frquemment inspecter les artfacts
Scrum et ltat davancement par rapport un objectif de Sprint (Sprint
Goal) afin de dtecter les carts indsirables. La frquence de ces
inspections ne devrait pas gner le travail en cours. Ces inspections sont
Page 49
bnfiques lorsquelles sont effectues de manire diligente sur les lieux

du travail par les personnes qualifies.
Adaptation
Si une drive est constate pendant l'inspection, le processus doit alors
tre adapt. Scrum fournit des rituels, durant lesquels cette adaptation
est possible. Il s'agit de la runion de planification de sprint, de la mle
quotidienne, de la revue de sprint ainsi que de la rtrospective de sprint.
Si un inspecteur dtermine quun ou plusieurs aspects du processus
drivent hors des limites acceptables, et que le produit qui en rsulte
sera inacceptable, le processus ou le matriel utilis par le processus doit
tre ajust. Un ajustement doit tre fait ds que possible afin de
minimiser le risque dautres drives.
Scrum prescrit quatre occasions formelles dinspection et dadaptation,
tel que dcrit dans la section Evnements Scrum de ce document :
o Planification de Sprint (Sprint Planning)
o Mle quotidienne (Daily Scrum)
o Revue de Sprint (Sprint Review)
o Rtrospective de Sprint (Sprint Retrospective)
4.5.
Cot, dlai, primtre
Nous allons prsent aborder un point important de la mthode Scrum
qui est la notion de cot, dlai et primtre.
Dans une gestion de projet classique, seul le primtre est fix, les cots et
les dlais tant quant eux variables. En effet, si une entreprise souhaite
dvelopper une application de relation clientle, le primtre du projet est fix
mais les inconnues sont le temps de ralisation. Ces inconnues influent sur
le cot global du projet car rien ne nous indique que les cots et dlais seront
respects (Cf. effet tunnel).
En Scrum, cest tout fait loppos. Les cots et dlais seront respects
mais le primtre peut varier. Il sagit l dune notion parfois difficile
faire comprendre au management (ainsi quau client) et souvent propice
la rflexion suivante :
Page 50
"Il se peut donc que je naie pas toutes les fonctionnalits attendues ?
Comment cela est-il possible ? Lapplication ne sera pas utilisable !! "
ces questions il est important de rpondre que les fonctionnalits
forte valeur mtier seront dveloppes en premier mais que, certes,
celles ayant une faible valeur seront peut-tre cartes. Cest donc au Product
Owner de sassurer que le Product Backlog soit correctement prioris.
Les cots et dlais seront quant eux respects du fait que la dure dun sprint
est toujours constante et que le nombre de personnes travaillant durant un
sprint est galement constant.
.
5. LQUIPE
Lquipe Scrum comprend un propritaire de produit (Product Owner), une
quipe de Dveloppement (Development Team) et un Scrum Master. Les
quipes Scrum (Scrum Teams) sont auto-organises et pluridisciplinaires. Les
quipes auto-organises choisissent la meilleure faon daccomplir leur travail,
au lieu dtre diriges par des personnes externes lquipe. Les quipes
pluridisciplinaires ont toutes les comptences ncessaires pour effectuer le
travail sans dpendre de personnes nappartenant pas lquipe. Scrum
dfinit un modle dquipe optimisant la flexibilit, la crativit et la
productivit
Les quipes Scrum livrent des produits de manire itrative et
incrmentale, maximisant ainsi les occasions de rtroaction. Les livraisons
incrmentales dun produit Termin assurent la disponibilit dune version
fonctionnelle et potentiellement utile du produit.
5.1.
Le Product Owner
Le Product Owner est responsable de maximiser la valeur du produit et du

travail de lquipe de Dveloppement. La faon de jouer ce rle peut varier
grandement selon les entreprises, les quipes Scrum et les individus.
Le Product Owner est la seule personne responsable de grer le carnet de
produit (Product Backlog). La gestion du Product Backlog comprend :
Exprimer clairement les items du Product Backlog ;
Ordonner les items du Product Backlog pour mieux raliser les objectifs
et missions ;
Page 51
Optimiser la valeur du travail effectu par lquipe de Dveloppement

;
Sassurer que le Product Backlog est visible, transparent, et clair pour
tous, et quil montre ce sur quoi lquipe de Dveloppement
travaillera prochainement ; et,
Sassurer que lquipe de Dveloppement comprend adquatement
les items du Product Backlog.
Le Product Owner peut lui-mme accomplir les tches susmentionnes ou
les dlguer lquipe de Dveloppement. Toutefois, le Product Owner
demeure responsable de ces dernires.
Le Product Owner est une personne, et non un comit. Le Product Owner
peut reprsenter les dsirs dun comit dans le Product Backlog, mais ceux
qui veulent changer la priorit dun item du Product Backlog doivent
consulter le Product Owner.
Afin que le Product Owner russisse dans sa dmarche, tous les intervenants
de lentreprise doivent respecter ses dcisions. Les dcisions du Product
Owner sont visibles dans le contenu et lordonnancement du Product
Backlog. Nul nest permis de demander lquipe de Dveloppement de
travailler partir dun autre ensemble de besoins, et il nest pas permis
lquipe de Dveloppement de suivre les instructions dune autre personne.
5.2.
Lquipe de Dveloppement
Lquipe de Dveloppement est constitue de professionnels qui livrent

chaque Sprint un incrment termin et potentiellement livrable du
produit. Seuls les membres de lquipe de Dveloppement crent
lincrment.
Les quipes de dveloppement sont structures et habilites par lentreprise
organiser et grer leur propre travail. La synergie rsultante optimise
lefficience et lefficacit globale des quipes de dveloppement.
Lquipe de Dveloppement possde les caractristiques suivantes :
Elle est auto-organise. Nul (mme pas le Scrum Master) nindique
lquipe de Dveloppement comment transformer les items du
Product Backlog en incrments de fonctionnalits potentiellement
livrables.
Elle est pluridisciplinaire, avec toutes les comptences ncessaires pour
crer un incrment du produit ;
Scrum ne reconnat aucun titre aux membres de lquipe de
Dveloppement autre que celui de dveloppeur, indpendamment du
travail effectu par cette personne ; il ny a pas dexception cette rgle
;
Scrum ne reconnat pas dquipes lintrieur de lquipe de
Dveloppement indpendamment des domaines spcifiques qui
Page 52
doivent tre couverts tels que lexcution de tests ou lanalyse

fonctionnelle ; il ny a pas dexception cette rgle ; et,
Les membres de lquipe de Dveloppement peuvent dtenir
individuellement des comptences et des centres dintrt spcifiques,
mais cest lquipe de Dveloppement dans son ensemble qui est
tenue responsable.
5.2.1.
Taille de lquipe de Dveloppement
La taille optimale de lquipe de Dveloppement est suffisamment
petite pour que lquipe soit flexible et ractive tout en tant
suffisamment grande pour quelle soit en mesure daccomplir un travail
significatif durant le sprint. Lorsque lquipe de Dveloppement est
compose de moins de trois personnes le niveau dinteraction est rduit
et les gains de productivit moins importants. Une telle quipe peut
rencontrer des difficults livrer un incrment de logiciel en raison de
comptences limites. loppos, une quipe de plus de neuf membres
implique trop de coordination. Les grandes quipes de dveloppement
engendrent des interactions trop complexes pour tre gres
efficacement par un processus empirique. moins quils ne fassent
galement partie de lquipe de Dveloppement, le Scrum Master et
le Product Owner ne sont pas pris en compte dans la taille de lquipe.
5.3.
Le Scrum Master
Le Scrum Master est responsable de sassurer que Scrum est compris et mis
en uvre. Les Scrum Masters remplissent leur rle en sassurant que
lquipe Scrum adhre la thorie, aux pratiques et aux rgles de Scrum.
Le Scrum Master est un leader au service de lquipe Scrum. Le Scrum
Master aide ceux qui sont externes lquipe Scrum comprendre
lesquelles de leurs interactions avec lquipe Scrum sont bnfiques et
lesquelles ne le sont pas. Le Scrum Master aide tout le monde changer ces
interactions pour maximiser la valeur cre par lquipe Scrum.
5.3.1.
Le Scrum Master au service du Product Owner
Le Scrum Master sert le Product Owner de plusieurs faons. Ses services
consistent :
Trouver des techniques de gestion efficace du Product Backlog ;
Aider lquipe Scrum comprendre la ncessit davoir des items de
Product Backlog clairs et concis ;
Comprendre la planification de produit dans un contexte empirique ;
Sassurer que le Product Owner sait comment constituer le Product
Backlog pour maximiser la valeur du produit ;
Comprendre et mettre en uvre lagilit ; et,
Page 53
Faciliter les vnements Scrum lorsque requis ou demand
5.3.2.
Le Scrum Master au service de lquipe de
Dveloppement
Le Scrum Master est au service de lquipe de Dveloppement. Ses
services consistent :
Aider lquipe de Dveloppement dvelopper son auto-organisation
et sa pluridisciplinarit ;
Aider lquipe de Dveloppement crer des produits de grande
valeur ;
liminer les obstacles au progrs de lquipe de Dveloppement ;
Faciliter les vnements Scrum lorsque demand ou requis ; et,
Accompagner lquipe de Dveloppement dans les environnements
organisationnels o Scrum nest pas encore entirement adopt et
compris
5.3.3.
Le Scrum Master au service de lorganisation
Le Scrum Master rend service lorganisation de plusieurs faons. Ses
services consistent :
Accompagner lorganisation dans son adoption de Scrum ;
Planifier les mises en uvre de Scrum dans lorganisation ;
Aider les employs et parties prenantes comprendre et mettre en
uvre Scrum et le dveloppement empirique de produit ;
Causer des changements qui augmentent la productivit de lquipe
Scrum ; et,
Collaborer avec dautres Scrum Master pour amliorer lefficacit de
lutilisation de Scrum dans lorganisation.
5.4.
Lenvironnement de travail
Un concept fort de Scrum est la qualit de l'environnement de travail de

l'quipe. Cela inclut :
pas de changements imposs pendant un sprint ;
War room
toute l'quipe dans une mme pice ;
Page 54
Le lieu clef, ce sont les bureaux de lquipe, pas ceux du product owner
Utilisez les murs
un tableau blanc et/ou en lige ;
un bon outil de suivi du projet ;

prvenir des interventions extrieures (tlphone, irruption dans la
pice, etc.) ;
Page 55
tout ce qui peut rendre l'quipe plus sereine et efficace.

Dtente oui, mais pas de parasitage sur le plateau
Ladministration technique ne doit pas tre un problme (Saas autant
que possible)
Rythme durable
Lenvironnement de travail compte
Chacun donne son avis sur les outils utiliss.
La pression des pairs est bien plus efficace que celle dun chef
6. LES BESOINS : CRITURE DU PRODUCT BACKLOG

6.1.
Sprint 0
Le sprint 0, litration 0 ou lexploration est un lment important pour mettre
les bonnes bases dun nouveau projet Agile et pour permettre une nouvelle
quipe de se former et dapprendre travailler ensemble. Dune dure
variable, entre une et quatre semaines, il ne se termine pas forcement par une
livraison. Ceci est un des lments qui le diffrencie par rapport aux autres
itrations. Voici les objectifs impratifs de cette phase du projet :
- prparer lenvironnement de dveloppement. En le faisant maintenant
nous pouvons nous concentrer 100% dans les prochaines itrations sur
les aspects fonctionnels et techniques vraiment spcifiques au projet ;
Page 56
- partager une vision claire du projet. Lquipe a besoin de savoir les

objectifs du client, le primtre de lapplication, les contraintes, les
intervenants dans le projet, les utilisateurs finaux, une premire version
de larchitecture technique, le mode de travail sur le projet, le budget, le
planning global etc.
- produire une premire version du backlog du produit avec des
estimations et des priorits associes aux tches. Cest difficile davoir
une image complte du produit, mais nous pouvons diviser le backlog en
deux parties : une premire partie dtaille, qui couvre les premires
itrations de dveloppement, et une deuxime partie ayant une
granularit moins fine qui sera dtaille pendant les itrations suivantes;
- rflchir et se mettre daccord sur une architecture globale du projet.
On dfinit les grandes lignes darchitecture, nous dcidons les outils et
les technologies qui seront utiliss dans toutes les couches de
larchitecture
- roder lquipe sur une partie du backlog initial. Le but est de faire un
premier exercice pour les estimations, la division en tches, la
ralisation, une premire dmonstration etc.
Une partie importante du Sprint 0 est ralise pendant la mission pivot
organise au dmarrage du projet. Le Plan Qualit Projet livr en fin de
cette mission doit couvrir la plus part des informations ci-dessus mentionnes.
Le Sprint 0 napporte pas de valeur immdiate. Il faut le voir comme un
investissement essentiel dans lavenir du projet Agile, qui va dmarrer sur
des bases solides, permettant dviter beaucoup de problmes et de rcuprer
rapidement cet investissement initial.
Les travaux spcifiquement agiles qu'on y fait, c'est laborer le backlog initial
et planifier la release. Pour cela on y mettra en uvre des pratiques comme la
vision du produit, la priorisation du backlog, l'identification des risques, la
dcomposition en user stories, l'estimation en points, la dfinition de fini et de
la dure des itrations, le planning de la release, la formation de l'quipe,
l'organisation de l'espace de travail.
6.2.
Product Backlog
Le Product Backlog est une liste ordonne de tout ce qui pourrait tre requis
dans le produit et est lunique source des besoins pour tous les changements
effectuer sur le produit. Le Product Owner est responsable du Product
Backlog dans son contenu, sa disponibilit et son ordonnancement.
Un Product Backlog nest jamais complet. Ses toutes premires moutures ne
font quesquisser les besoins tels quinitialement connus et compris. Le
Product Backlog volue au fur et mesure que le produit et le contexte dans
lequel il sera utilis voluent. Le Product Backlog est dynamique ; il change
constamment pour identifier ce que le produit requiert pour tre appropri,
comptitif et utile. Tant et aussi longtemps quun produit existe, son Product
Backlog correspondant existe.
Le Product Backlog liste toutes les fonctionnalits, besoins, amliorations et
correctifs correspondant aux changements devant tre appliqus au produit
Page 57
lors de livraisons futures. Les items du Product Backlog incluent une

description, un ordre, une estimation de leffort et de la valeur.
mesure quun produit est utilis, que sa valeur augmente et que lon
commence recevoir des retours sur son utilisation, le Product Backlog
grossit et devient plus exhaustif. Les besoins narrtent jamais de changer, ce
qui fait du Product Backlog un document vivant. Les changements au niveau
des besoins utilisateurs, des conditions du march ou de la technologie peuvent
impacter le Product Backlog.
Il arrive souvent que plusieurs quipes Scrum travaillent sur le mme
produit. Un seul Product Backlog est utilis pour dcrire le travail faire sur
ce produit. On peut alors ajouter une proprit aux items du Product Backlog
pour les regrouper.
Laffinage du Product Backlog consiste en lajout de dtails, destimations et
de lordonnancement des items du Product Backlog. Il sagit dune activit
rgulire dans laquelle le Product Owner et lquipe de Dveloppement
collaborent pour dtailler les items du Product Backlog. Durant laffinage du
Product Backlog, les items sont revisits et rviss. Lquipe Scrum dcide
comment et quand laffinage est effectu. Laffinage noccupe gnralement
pas plus de 10% de la capacit de lquipe de Dveloppement. Toutefois, les
items du Product Backlog peuvent tre modifis nimporte quel moment par
le Product Owner ou sa discrtion.
Les premiers items du Product Backlog sont gnralement plus dtaills que
les suivants. Leur estimation est plus prcise d une plus grande clart et un
niveau de dtail accru. Les items qui sont placs plus loin dans le Product
Backlog sont moins dtaills. Les items qui occuperont lquipe de
Dveloppement durant le prochain Sprint sont affins au point que nimporte
lequel peut tre raisonnablement Termin dans un Sprint. Ces items sont
rputs Prts pour leur slection dans une planification de Sprint. Les
items du Product Backlog acquirent ce degr de transparence grce aux
activits daffinage dcrites plus haut.
Lquipe de Dveloppement est responsable de toutes les estimations.
Le Product Owner peut influencer lquipe de Dveloppement en laidant dans
sa comprhension et le choix des compromis, mais les personnes qui
effectueront le travail ont le mot final sur les estimations.
6.3.
Grille INVEST
La grille des critres INVEST permet de juger de la qualit d'une User
Story; elle conduira ventuellement reformuler son nonc, voire
modifier en profondeur la Story (ce qui se traduit souvent physiquement: on
dchire la fiche ou le Post-It correspondant et on en crit une autre). Une
bonne User Story est:
Indpendante des autres
Ngociable initialement, plutt qu'un engagement ferme
Verticale, ou ayant de la valeur en soit
Evalue en termes de complexit relative
Suffisamment petite (en anglais Small)
Testable en principe, ce qu'on vrifie en crivant un test
Page 58
Plus en dtail, une bonne User Story:

Pour rpondre au critre I, doit pouvoir tre implmente avant ou
aprs n'importe quelle autre; une erreur classique tant par exemple
d'argumenter que "la Story sur la prise de commande implique d'avoir
ouvert un compte, donc il faut raliser en premier celle concernant
l'identification (login) de l'acheteur". C'est un peu comme supposer qu'on
ne peut crire le chapitre 2 d'un roman qu'aprs avoir achev le chapitre
1: plus facile, mais avec un peu d'imagination on arrive trs bien
inverser cette squence. Dans notre exemple l'quipe de dveloppement
mettra en place les "bouchons" ncessaires pour simuler un utilisateur
identifi.
Pour rpondre au critre N, ne formuler dans un premier temps que
l'essentiel, savoir l'objectif fonctionnel recherch; on vitera par
exemple de spcifier dans une User Story des lments techniques, par
exemple "En tant qu'acheteur, lorsque j'cris dans le champ texte puis
que je clique sur le bouton Recherche, la liste gauche du champ de
recherche est renseigne avec les articles correspondants". Ces dtails
d'implmentation feront l'objet d'une discussion permettant d'identifier
la meilleure solution; initialement, une formulation du type "L'acheteur
peut chercher des articles par mot-cl" est suffisante pour l'estimation
et la planification.
Pour rpondre au critre V, reprsenter un incrment rellement utile
pour l'utilisateur final ou du point de vue du client. Par exemple, "raliser
le schma de la base de donnes pour la facturation" n'est pas un
incrment ayant de la valeur en soi, mais une tche technique. A
contrario, "mettre une facture pour les achats d'articles en Maroc" en
laissant pour plus tard une seconde Story dont l'nonc serait "mettre
une facture pour des achats livrs depuis l'tranger" reprsente un
meilleur dcoupage: chaque incrment permet de raliser une partie
distincte du chiffre d'affaires.
Pour rpondre au critre E, tre suffisamment comprise, mais
galement suffisamment prcise. Il arrive parfois qu'on formule des User
Stories qui reprsentent presque un projet part entire, par exemple
Page 59
"Optimiser le calendrier de livraison des achats". Les conditions de

satisfaction doivent tre suffisamment prcises et restreintes pour que
l'quipe de dveloppement puisse quantifier l'effort d'implmentation,
sinon dans l'absolu du moins en termes de complexit relative. (L'quipe
estime par exemple que "Livrer en deux fois lorsque des carts
suprieurs une semaine sparent les dates de livraison de deux articles
du panier" reprsente deux fois l'effort requis pour "Emettre la facture",
cette dernire servant en quelque sorte d'talon.)
Pour rpondre au critre S, ne pas dpasser quelques jours-hommes.
La granularit exacte est fonction du nombre de personnes dans l'quipe
de dveloppement et de la dure de l'itration, le critre dterminant
tant la possibilit de terminer au minimum une, et idalement cinq ou
six au minimum, User Stories dans une seule itration.
Pour rpondre au critre T, tre suffisamment bien comprise pour qu'il
soit possible de fournir un exemple dtaill: "Lorsque j'achte l'article X
au prix Y, sachant que la TVA sur la catgorie Livres est de Z, la facture
doit indiquer le montant total suivant:" La fonctionnalit envisage doit
entraner de la part du produit des consquences ou des comportements
observables. Ainsi "Amliorer la performance" n'est pas une bonne User
Story, il est prfrable de prciser: "La page contenant les rsultats de
recherche doit s'afficher en moins de 2 secondes".
6.4.
Rdiger les User Stories et Epics
Lorsqu'une quipe de dveloppement de logiciels quitte le cocon des projets
en cascade et autres styles traditionnels de gestion, elle a souvent du mal
structurer son travail. Heureusement, le dveloppement agile utilise, pour
structurer n'importe quel projet agile, quatre vecteurs de livraison
majeurs : les user stories, les sprints, les epics et les versions. Grce
eux, les quipes de dveloppement peuvent organiser leur travail de faon
pouvoir ragir au feedback des clients et adapter le plan de projet initial, sans
avoir l'impression que tout s'croule autour d'elles.
La possibilit de modifier et d'adapter les plans ultrieurs en fonction des
informations courantes est une marque d'agilit.
6.4.1.
Objectif granularit : les user stories
Dans un cadre de travail agile, les user stories constituent les units de travail
les plus petites. Leur objectif est de restituer au client une certaine valeur
ajoute. Remarque : les clients ne doivent pas forcment tre des
utilisateurs externes au sens traditionnel. Il peut s'agir de clients en interne ou
de collgues qui, au sein de votre entreprise, dpendent de votre quipe. Les
user stories dsignent une srie de phrases, rdiges dans un langage
simple, qui dcrivent le rsultat souhait. Elles n'entrent pas dans le dtail
Les user stories suivent souvent le modle suivant :
En tant que <type d'utilisateur>, je souhaite <objectif> pour pouvoir
<avantage vis>.
Utilisons un site Web comme exemple simple de cration d'une user story.
Page 60
En tant que client, je souhaite pouvoir crer un compte qui me

permettra de visualiser les achats que j'ai effectus au cours des
12 derniers mois et prvoir mon budget pour l'anne suivante.
Les user stories sont esquisses par le Product Owner, aprs quoi lquipe
de Dveloppement dtermine collectivement les exigences de faon plus
dtaille. Ces tches granulaires permettent de dfinir les tches de mise en
uvre de la user story et du futur sprint. Dans l'exemple ci-dessus, plusieurs
tches sont requises pour que la fonctionnalit du compte soit oprationnelle :
modifications au niveau de la base de donnes, nouvelle logique au niveau du
serveur, mais galement nouveaux composants au niveau de l'interface
utilisateur. Ces tches doivent tre toffes lors de l'estimation de la user
story et associes dans l'outil de suivi des tickets de l'quipe.
6.4.1.1. User stories
Crer les scnarios
Cration des users story
Page 61
Eclater les scnarios en user stories
Inclure linformation client dans la vision des user stories
Page 62
Catgoriser les user stories par thmes
Positionner les priorits sur les user stories
6.4.1.2. Cartographier le cheminement de lutilisateur

Cartographier le cheminement de lutilisateur
Page 63
6.4.1.3. le prototypage
Dessiner le prototype
Page 64
Le prsenter lors des Ateliers client
Synthse
Page 65
6.4.2.
Cadence de dveloppement fixe : les sprints
Dans Scrum, les quipes prvoient de raliser une srie de user stories
pendant une priode dfinie, connue sous le nom de sprint. Globalement, les
sprints ont une dure d'une, deux ou quatre semaines. C'est l'quipe qui
dtermine cette dure. Nous vous conseillons de commencer par deux
semaines. C'est assez long pour parvenir un rsultat, tout en permettant
l'quipe de recevoir un feedback rgulier. Une fois que la cadence du sprint a
t fixe, l'quipe opre toujours au rythme dfini. Les sprints dont la dure
est fixe renforcent les aptitudes d'estimation et permettent de prdire la
vlocit future de l'quipe au fur et mesure de leur progression dans le
backlog.
Deux aspects importants concernant les sprints :
Une fois que l'quipe a prvu une srie de user stories pour le sprint et
que celui-ci a dmarr, le Scrum Master est charg d'empcher toute
modification de ces user stories. Cela permet l'quipe de rester
concentre et de lutter contre toute drive des objectifs (lorsqu'une
quipe ajoute du travail dans le sprint une fois que celui-ci a dmarr).
L'ajout de tches mi-chemin du sprint met en pril la capacit de
l'quipe raliser des prvisions et des estimations prcises.
la fin de chaque sprint, l'quipe doit fournir un produit oprationnel.
Dans Scrum, cela s'appelle un incrment de produit potentiellement
livrable. Au final, le responsable produit dcide quel moment cet
incrment de produit est mis la disposition des clients. Toutefois, le
travail doit tre suffisamment complet pour pouvoir tre livr la fin du
sprint.
Les graphiques d'avancement sont des outils extrmement utiles toute
quipe Scrum. Ils montrent clairement l'avancement au sein du sprint : travail
restant sur l'axe Y et dates sur l'axe des X. Les graphiques d'avancement sont
une source de motivation pour l'quipe et permettent tous de rester
concentrs pendant un sprint. Surtout, ces graphiques fournissent les donnes
justificatives utiliser lors des discussions autour de la progression d'un sprint
6.4.3.
Approche plus globale : les epics
Les epics sont des corpus de travail beaucoup plus larges. Elles dcrivent des
fonctionnalits entires qui englobent de nombreuses user stories. Dans
l'exemple ci-dessus, une epic peut reprsenter la fonctionnalit entire de
gestion des comptes et la capacit de visualiser les achats prcdents.
Contrairement aux sprints, un changement de cahier des charges au niveau
des epics est un aspect naturel du dveloppement agile. La livraison des epics
couvre pratiquement toujours une srie de sprints. Au fur et mesure que
l'quipe approfondit ses connaissances sur une epic grce au dveloppement
et au feedback des clients, des user stories seront ajoutes et supprimes
afin d'optimiser le dlai de livraison de l'quipe. C'est l'unique libert que
confre un responsable produit un cadre de travail agile. En effet, il peut se
Page 66
concentrer sur l'quipe de dveloppement et s'assurer qu'elle travaille sur les

aspects les plus importants.
Les graphiques d'avancement servent galement visualiser les epics. Les
quipes restent motives et les responsables informs. S'il est efficace, le
graphique d'avancement montre la nature agile du dveloppement. Il affiche
clairement la progression de l'quipe et indique quels moments le
responsable produit a ajout ou supprim des user stories. Une telle visibilit
permet de synchroniser tout le monde et encourage tenir une discussion
ouverte sur l'volution du produit et les prvisions d'achvement. Sans parler
du fait que la transparence est gage de confiance !
6.4.4.
Approche plus globale : les versions
Les versions correspondent aux produits rellement livrs aux clients. A la fin
de chaque sprint, l'quipe doit pouvoir livrer le produit aux clients. Les versions
se rfrent aux modifications effectues que le responsable produit livre
rellement aux clients.
Comme pour les epics, le dveloppement des versions couvre souvent
plusieurs sprints. S'il est avis, le responsable produit peut dcider de livrer
une epic sur plusieurs versions. Une epic ne doit pas obligatoirement tre
compltement contenue dans une version. En livrant une epic sur plusieurs
versions, le responsable produit est en mesure de dterminer la raction du
march par rapport cette epic. Il peut alors prendre des dcisions en pleine
connaissance de cause quant l'orientation future, plutt que de proposer une
version gante.
Si l'on reprend notre scnario de gestion de comptes ci-dessus, le responsable
produit peut structurer sa stratgie de livraisons comme suit :
Version 1 : connexion, dconnexion, gestion des mots de passe
Version 2 : historique des achats
Version 3 : prfrences de sauvegarde
Etc.
La modification du cahier des charges des versions constitue galement un
composant naturel du dveloppement agile. Grce aux graphiques
d'avancement, l'quipe entire reste informe de l'volution d'une version dans
le temps. Les modifications apportes une version doivent faire l'objet d'une
discussion avec toute l'quipe afin de garantir la synchronisation de celle-ci.
6.5.
Les erreurs frquentes
une "erreur" classique consiste partir d'un cahier des charges rdig
en amont et le dcouper en User Stories en s'appuyant sur sa structure
textuelle; cela peut tre une bonne approche pour une quipe dbutante
mais ne constitue pas une pratique recommande
une User Story n'est pas un document; le terme dsigne l'intgralit des
activits qui sont ncessaires pour transformer une version V du produit
en une version V' qui a plus de valeur; en ce sens une User Story est un
objectif
Page 67
le niveau de dtail correspondant une User Story n'est pas constant,

mais volue au fil du temps, en fonction de l'horizon de planification: une
User Story dont la ralisation est prvue dans plusieurs semaines ne sera
dcrite que d'une brve phrase, alors qu'une User Story dont la
ralisation est imminente doit tre cadre par des tests de recette, des
exemples, etc.
une User Story n'est pas un Use Case; bien que la comparaison entre
les deux notions soit souvent utile, il n'est pas possible d'tablir un lien
simple et direct
une User Story ne correspond en rgle gnrale pas un quelconque
dcoupage technique: un cran, une bote de dialogue, un bouton ne
sont pas des User Stories
6.6.
Les outils dcriture d'User Stories
6.6.1.
Les 3 C
Utilisation des PostIT et

Tableaux
6.6.2.
Le story Mapping
Permet de cartographier les User Stories dans le temps et par priorit
Page 68
https://www.featuremap.co
6.6.3.
Carte heuristique
Une carte heuristique (ou carte cognitive, carte mentale, carte des ides1, etc.
ou, dans les pays anglophones et usuellement, mind map), est un schma,
suppos reflter le fonctionnement de la pense, qui permet de reprsenter
visuellement et de suivre le cheminement associatif de la pense.
Cela permet de mettre en lumire les liens qui existent entre un concept ou
une ide, et les informations qui leur sont associes.
La structure mme d'une Mind Map est en fait un diagramme qui reprsente
l'organisation des liens smantiques entre diffrentes ides ou des liens
hirarchiques entre diffrents concepts.
l'inverse du schma conceptuel (ou carte conceptuelle , concept map en
anglais), les mind maps offrent une reprsentation arborescente de donnes
imitant ainsi le cheminement et le dveloppement de la pense.
Page 69
6.6.4.
BDD et Gherkin
Le BDD (Behavior Driven Development) est une mthodologie agile
propose par Dan North pour aller au-del du TDD (Test Driven
Development). Cette mthodologie a pour objectif damliorer la
comprhension et la collaboration du mtier, du Product Owner, des
dveloppeurs, des testeurs et de toute autre partie prenante pertinente en les
rassemblant autour dun langage commun : le Gherkin.
Page 70
Pour chaque User Story, un ensemble de scnarios (de 1 environ 4 au

maximum) dcrit le comportement attendu en Gherkin :
Etant donn que contexte initial
Quand un vnement
Alors un certain rsultat
Page 71
7. LES TESTS POUR LES USER STORIES

7.1.
La Pyramide de tests de Mike
Dans la conception traditionnelle, la plupart sinon la totalit de l'effort tait

dans le dveloppement de tests fonctionnels interface utilisateur-centrique qui
ont explor l'application via l'interface graphique. Il pourrait y avoir des tests
de niveau infrieur et quelques tests unitaires, mais la plupart des quipes
guind l'tage suprieur.
7.2.
Les tests dacceptation
Les tests dacceptation est la technique qui consiste ne commencer le
dveloppement d'une story (sa conception, son code, ses tests unitaires) que
lorsqu'on dispose de ses tests d'acceptation.
Page 72
L'ATDD implique, pour une story, les tapes suivantes :

laboration des story tests de la story
dveloppement de la story
passage des story tests. En cas d'chec, correction des tests et/ou du
code.
A noter
Si la story est ralise dans l'itration n, cela implique que ces 3 tapes
s'y droulent, la premire pouvant tre anticipe dans l'itration n-1
Les 3 tapes ne sont pas ncessairement squentielles, l'ajout de
nouveaux tests peut se faire en parallle avec le dveloppement.
Pour vrifier la condition, il faut excuter le test sur la dernire version du
logiciel, le build courant. A chaque nouveau build, pour viter les rgressions,
il conviendrait de repasser tous les story tests de toutes les stories. On
comprend l'intrt de l'automatisation.
7.3.
Les TDD et ATDD
7.3.1.
Les TDD
Le terme TDD dsigne une technique de dveloppement qui entremle la

programmation, l'criture de tests unitaires et l'activit de remaniement.
Elle propose les rgles suivantes:
crer un seul test unitaire dcrivant un aspect du programme
s'assurer, en l'excutant, que ce test choue pour les bonnes raisons
crire juste assez de code, le plus simple possible, pour que ce test
passe
remanier le code autant que ncessaire pour se conformer aux critres
de simplicit
recommencer, en accumulant les tests au fur et mesure
La pratique est indissociable de la famille d'outils de tests xUnit, qui elle
doit son vocabulaire: "barre verte" signifie que l'ensemble des tests
unitaires accumuls passent avec succs, "barre rouge" signifie qu'au
moins un test est en chec. (L'chec d'un unique test suffit dclencher
l'affichage rouge, avec sa connotation d'alerte: cette tolrance zro reflte la
philosophie de l'outil et de la pratique.) .L'expression "drouler les tests"
dsigne le fait de lancer ou d'excuter tous les tests accumuls ("suite" ou
"batterie" de tests).
L'une des notions les plus importantes pour un dbutant est celle de granularit
d'un test. Supposons par exemple qu'on crive un correcteur orthographique.
Un test "gros grain" consisterait vrifier que lorsqu'il est appel avec un
mot mal orthographi, par exemple "importent", le correcteur renvoie la
Page 73
suggestion "important". Un test "grain fin" l'inverse vise vrifier la bonne

implmentation d'un aspect plus prcis de l'algorithme de correction: par
exemple qu'une fonction calculant la "distance" entre ces deux mots renvoie
bien 1 (une seule lettre a chang).
ERREURS COURANTES
Quelques erreurs courantes des programmeurs novices en dveloppement par
les tests:
oublier de drouler les tests frquemment
crire de nombreux tests la fois
crire des tests d'une granularit inadapte
crire des tests non probants, par exemple dpourvus d'assertions
crire des tests pour du code trivial, par exemple des accesseurs
Quant l'organisation de l'quipe autour de cette pratique, les cueils suivants
sont courants:
adoption partielle: seuls certains dveloppeurs plus motivs ou mieux
forms utilisent TDD; on ne peut pas attendre de bnfices collectifs
dans ce cas
mauvais entretien de la batterie de tests: en particulier, une batterie de
tests qui prend trop longtemps drouler
dlaissement de la batterie de tests: dcoulant parfois du mauvais
entretien, parfois d'autres facteurs tel un trop brusque renouvellement
de l'quipe
7.3.2.
Les ATDD
Couramment dsigne par l'acronyme ATDD ("acceptance test driven

development"), plus rarement STDD ("storytest driven development").
Sur le modle du dveloppement par les tests, cette pratique ajoute au
dveloppement de tests de recette automatiss une contrainte
supplmentaire: ceux-ci doivent tre raliss en amont des dveloppements
correspondants.
L'idal recherch (mais atteint relativement rarement) consiste ce que le
responsable du produit, client ou expert fonctionnel soit en mesure de dfinir
de nouvelles fonctionnalits sous la forme de tests de recette, sans que
l'intervention des dveloppeurs soit ncessaire.
ERREURS COURANTES
Plus encore que la simple utilisation de tests de recette automatiss, cette
pratique est lie des outils tels que Fit/FitNesse, Cucumber, etc
Il convient par consquent d'tre d'autant plus vigilant ce que le choix des
outils ne se fasse pas au dtriment de la facilit, pour les responsables produit,
dialoguer avec les dveloppeurs propos de la dfinition des exigences.
Page 74
8. PRIORISATION DU PRODUCT BACKLOG

8.1.
La Priorisation
Hirarchiser les besoins

Lun des motifs dchec de nombreux projets rside dans le fait que les
fonctionnalits ne sont pas dveloppes par ordre de priorit ; en effet, dans
une approche classique, le planning est tabli en amont du projet avec la
certitude que tous les besoins recenss seront satisfaits. Partant du principe
que le primtre est dfini et fig, lquipe hirarchise et planifie ses activits,
non pas en fonction de la valeur ajoute pour le client, mais de considrations
techniques. Si elle prend du retard (ce qui est, souvent le cas), elle sera tente
de faire limpasse sur certaines fonctionnalits, peut-tre plus importantes
pour le client que celles dj dveloppes.
Si lon admet que lon a rarement assez de temps pour tout faire, que des
changements surviennent invitablement au cours dun projet, il faut, ds
lors, qualifier et valoriser les besoins pour les prioriser afin de faciliter les
arbitrages sur les modifications de primtre.
Comment valoriser les besoins ?
On dispose de plusieurs modles, disponibles quelle que soit lapproche
retenue ; il y a cependant des questions incontournables se poser :
Quel est le bnfice financier dvelopper cette fonctionnalit ?
Quel est le cot de dveloppement ? De maintenance ? De formation
des utilisateurs ? ;
Quel est le cot dun changement ?
Limplmentation de cette fonctionnalit nous permet-elle dapprendre
ou de dvelopper de nouvelles comptences ?
Cette fonctionnalit nous expose-t-elle davantage de risques ? Ou,
au contraire, nous permet-elle de nous confronter au risque ?
Cette fonctionnalit va-t-elle impacter les processus mtier ?
Cette fonctionnalit va-t-elle amliorer la productivit de mon
personnel ?
Cette fonctionnalit va-t-elle susciter de la frustration ou de la
rsistance ?
Quel est le prjudice si cette fonctionnalit nest pas implmente ?
Un des points forts de Scrum est le backlog de produit, qui regroupe toutes
les exigences, ce qui facilite leur gestion. Il est -techniquement- simple de
dfinir les priorits entre les lments du backlog de produit. Mais sur quels
critres se baser ?
Dans Scrum, on voque principalement la valeur pour le client. C'est le product
owner qui fixe les priorits.
Dans la pratique, il est conseill de tenir compte de la position dans le cycle
de vie :
se baser sur les risques notamment techniques au dbut d'un projet,
Page 75
lorsque les principaux risques ont t rduits, de passer aux choix du

Product owner, bass sur la valeur apporte.
Ainsi, les fonctionnalits forte valeur ajoute seront prioritaires ; au sein de

ce groupe, celles qui sont le plus risques seront dveloppes avant celles qui
sont le moins risques.
Celles qui ont peu de valeur et sont trs risques seront reportes voire
limines.
Considrer chaque facteur indpendamment nest pas suffisant, il faut les
combiner entre eux et surtout trouver un consensus avec le client sur le
protocole de valorisation des exigences.
Des modles de hirarchisation proposent de combiner ces diffrents facteurs,
en confrontant la valeur dune exigence pour le client ou son niveau de
satisfaction avec le cot de dveloppement et le risque associ. Ce sont les
modles, de Kano, de Wiegers ou la mthode Moscow
Les estimations des
valeurs mtiers des user stories sont
effectues via une sance workshop (Priority Poker)
8.2.
Dfinir la Valeur Mtier par le Priority Poker
Dune part, on peut considrer que la valeur mtier dune user story est
proportionnelle aux nombre de parties prenantes qui la demandent, quils
soient utilisateurs, managers, commerciaux, dirigeants On peut ainsi
suggrer son Product Owner dinviter les diffrentes parties prenantes
faire un poker planning de business points. Dautre part on peut galement
estimer la valeur dune story en termes de risque de ne pas faire. Cette
dernire sapplique souvent pour les stories qui dcoulent dobligations
rglementaires, mais on peut ltendre nimporte quel type de stories.
Page 76
Le priority poker est une faon ludique de produire des estimations sur la
valeur mtier des fonctionnalits dvelopper . Cette pratique est surtout
utilise en informatique, en Scrum et dans les mthodes agiles en gnral pour
valuer les scnarios utilisateurs (user stories) du carnet de produit (product
backlog)
La suite de Fibonacci est utilise pour les valuations. Comme nous
cherchons un ordre de complexit, le message est clair : plus le scnario est
gros, moins l'valuation est prcise. Le paquet de cartes utilis pour le planning
poker doit donc comporter les valeurs suivantes : 1, 2, 3, 5, 8, 13, 21, 34,
55, 89. Certains simplifient les grandes valeurs en les transformant en 20, 40,
100.
La valeur d'un lment du backlog, c'est ce qu'elle rapporte l'organisation.

La valeur est un des facteurs utiliss pour dterminer la priorit du backlog.
C'est la responsabilit du directeur de produit de dfinir la valeur d'un
lment, fonctionnalit ou histoire d'utilisateur. Il peut se trouver face des
difficults pour valuer la valeur financire (en ), en particulier s'il ne s'agit
pas d'un produit commercial. C'est aussi une responsabilit qu'il est difficile
d'exercer en solitaire. C'est pourquoi il est plus efficace d'organiser une
runion, type workshop, pour estimer la valeur relative des lments du
backlog. Ce workshop, qui est le pendant du planning poker , est appel par
Mike Cohn priority poker.
Le droulement est le suivant :
chacun participant reoit un lot de cartes numrotes
chaque lment du Backlog est tudi successivement
Page 77
le premier vote porte sur l'intrt d'avoir l'lment, chaque participant

vote avec une carte, on fait le total des points
le deuxime vote porte sur la pnalit relative de ne pas avoir
l'lment, chaque participant vote galement
on donne un poids de 2 au premier et le poids 1 au premier, par exemple,
on obtient la valeur de l'lment
Avec l'hypothse que chaque lment possde galement un attribut de cot

et que la priorit est dtermine simplement par le rapport valeur sur cot, il
est possible de continuer :
pour obtenir la valeur relative, il faut rapporter cette valeur au total de

l'ensemble des lments
avec l'estimation de cot de dveloppement d'un lment rapport au
cot total, on calcule de la mme faon le cot relatif
la priorit d'un lment s'obtient en divisant la valeur relative par le cot
relatif
8.3.
Priorisation par le modle de Kano
Le modle de Kano propose de classifier les exigences en trois catgories :
obligatoires, exprimes et latentes, et de mesurer leur corrlation avec la
satisfaction du client
Les exigences obligatoires ou forfait de dpart : souvent
implicites, ces exigences sont basiques et doivent imprativement tre
satisfaites. Une impasse sur ces exigences crera, assurment, une
frustration et un mcontentement chez le client. En revanche,
amliorer la qualit ou la performance de cette exigence aura peu
deffet positif, et la satisfaction du client ne dpassera pas le point
central de la matrice (exemple : Sur un site de recrutement, je peux
consulter des offres demploi. )..
Page 78
Les exigences exprimes : le besoin est exprim par le client ; sa

satisfaction est proportionnelle au niveau de performance de la
fonctionnalit ; le prix aussi, dailleurs. Si la fonctionnalit ne rpond pas
prcisment son besoin, le client sera insatisfait (exemples : Sur ce
mme site de recrutement, je peux consulter des offres demploi
rcentes. ; Je peux rechercher des offres avec plusieurs critres. ).
Les exigences latentes : les exigences latentes correspondent des
besoins mergents, pas vraiment exprims voire inconscients, qui
crent lheureuse surprise et ont un effet trs positif sur la
satisfaction du client. En revanche, la satisfaction ne diminuera pas si
ces besoins ne sont pas satisfaits (exemple : Sur ce mme site de
recrutement, je peux directement consulter des offres cibles en
fonction de mon profil et de lhistorique de mes recherches. )
La priorit doit porter sur les exigences obligatoires (pas ncessairement dans
les premires itrations mais dans la premire version du produit), puis sur les
exigences exprimes, qui ont des consquences directes sur la satisfaction du
client, et enfin sur quelques exigences latentes.
Comment dterminer le type de chaque exigence ?
On ne doit pas prsumer de limportance de telle ou telle fonctionnalit pour
lutilisateur ; son apprciation est essentielle. Par consquent, il est fortement
conseill de mener une enqute auprs dun chantillon reprsentatif
dutilisateurs pour obtenir cette chelle de valeur, en leur posant deux
questions sur chacune des fonctionnalits : Que pensez-vous du produit sil
contient cette fonctionnalit ? (Question fonctionnelle) et Que pensez-vous
du produit sil ne contient pas cette fonctionnalit ? (Question
dysfonctionnelle).
Cinq rponses sont possibles :
Cela me ferait plaisir.
Page 79
Ce serait un minimum.
Je nai pas davis.
Je laccepterais.
Cela me drangerait.
Une fois les rponses de tous les utilisateurs consolides, la synthse donne,
pour chaque exigence, la frquence de chaque catgorie et fournit un outil
daide la dcision quant lordre dimplmentation des fonctionnalits :
toutes les exigences obligatoires doivent tre implmentes, le maximum
dexigences exprimes ainsi que quelques exigences latentes, pour sduire le
client, ds les premires livraisons.
Page 80
8.4.
Priorisation par la mthode des poids
Une autre approche est intressante, celle de Karl Wiegers, nomme la
mthode des poids relatifs (Relative weighting).
Le principe de lapproche est dvaluer, pour chaque item (exigence, story),

dune part le bnfice relatif de son implmentation, sur une chelle de 1 9
(1 = peu de valeur, 9 = bnfice maximal), dautre part le prjudice relatif
si la fonctionnalit nest pas implmente (1 = faible prjudice, 9 =
prjudice maximal).
Les deux valeurs (A + B) sont additionnes pour dterminer la valeur dune
exigence.
Chaque exigence a donc un poids dans la valeur globale du produit (poids =
valeur exigence/valeur totale, soit D = C/C).
La colonne suivante (E) nous donne une estimation du cot de dveloppement
de chaque exigence, qui reprsente galement un certain pourcentage par
rapport au cot global de dveloppement de toutes les fonctionnalits (poids
= cot exigence/cot global, soit F = E/E).
La dernire colonne est calcule en divisant le pourcentage de la valeur par le
pourcentage du cot de chaque exigence (priorit = % valeur/% cot, soit
Page 81
D/F). Les chiffres les plus levs reprsentent les plus hautes priorits, car
elles crent davantage de valeur quelles ne cotent au projet.
Des variantes la mthode proposent de prendre galement en compte le
risque associ chaque exigence et de linclure dans la formule finale
(valeur/(cot + risque)), ou encore de pondrer chaque valeur (on peut
considrer que le bnfice client est deux fois plus important que le prjudice).
8.5.
Priorisation partir des Thmes
La priorisation par thme est base sur le Card sorting ou tri de cartes :
cest une technique issue des sciences humaines et sociales. Elle tait au
dpart principalement employe pour modliser la faon dont les
connaissances sont structures chez ltre humain.
Principe
Le principe de base du tri de cartes est simple:
recopiez vos contenus sur des cartes.
demandez vos utilisateurs de les classer dans des groupes.
demandez-leur de nommer les groupes constitus.
8.5.1.
Avantages et limites.
La principale limite du tri de cartes rside dans le fait quil sintresse
uniquement au contenu et non la tche de lutilisateur.
En effet, la technique ne tient pas compte de la faon dont les utilisateurs
atteignent leurs objectifs
Vous avez identifi toute une panoplie de contenus et de services que vous
souhaitez organiser de manire logique pour vos utilisateurs..
Mme si le tri de cartes permet parfois didentifier des contenus inutiles ou
manquants, son objectif principal est de structurer des contenus existants.
Page 82
Le tri de cartes permet damliorer la capacit dune structure tre comprise

et de faire en sorte que les informations quelle met disposition soient mieux
trouves (en anglais, on parle dinformation findability).
Dune manire gnrale, lapproche centre sur lutilisateur est toujours
bnfique, car elle favorise ladquation des solutions aux attentes des
utilisateurs et leurs usages. Elle assure lacceptation du produit.
Le tri de cartes se dcline en diffrents types que vous pourrez associer votre
guise en fonction de vos objectifs. Notamment :
ouvert : les utilisateurs classent les cartes dans des groupes quils
dfinissent eux-mmes ;
ferm : les utilisateurs classent les cartes dans des groupes dj dfinis ;
q sorts : on demande aux utilisateurs de dfinir un ordre de classement ;
invers (inverse card sort) : on demande aux participants dessayer de
localiser un contenu spcifique dans une structure complte (une approche
complmentaire consiste demander quels sont les contenus que les gens
verraient derrire tel titre de catgorie).
8.5.2.
Le tri de cartes ouvert
Le tri de cartes ouvert est principalement utilis pour dfinir une nouvelle
structure de linformation. il consiste demander aux utilisateurs de classer
les contenus dans des catgories quils dfinissent eux-mmes.
La procdure est la suivante
demandez aux participants de crer des groupes de cartes selon leur
logique.
demandez aux participants de nommer les groupes dfinis.
Page 83
8.5.3.
Le tri de cartes ferm
Le tri de cartes ferm peut tre utilis pour valuer une structure dinformation
existante. Il permet notamment dvaluer la pertinence ou la comprhension
de catgories existantes
Il consiste demander aux utilisateurs de classer les contenus dans des
catgories dj dfinies.
La procdure est la suivante.
demandez aux participants de classer les cartes dans les groupes
prdfinis.
Page 84
8.5.4.
Dmarche
Le tri par carte peut tre conduit individuellement ou en groupe (le focus
groupe) et conduit par un ergonome, facilitateur de la sance. En pratique, le
tri individuel fournit des rsultats plus riches et plus prcis que le tri collectif
qui peut tre biais par leffet de groupe. Cependant, en veillant ce que tous
les participants sexpriment spontanment et que chaque groupe soit compos
de manire homogne, les rsultats dun tri en groupe sont quasiment
similaires ceux obtenus par une srie de tris individuels. Lintrt de mener
le tri en groupe est daboutir plus rapidement des rsultats car les sessions
sont moins nombreuses.
Selon la manire de mettre en uvre le tri par cartes, les spcialistes
s'accordent sur huit dix sessions individuelles et deux trois sessions en
groupe avec au maximum cinq participants
8.5.5.
Prparation
Inventaire des contenus : Dans un premier temps, l'ergonome prend
connaissance du produit existant ou des spcifications du futur produit ou
encore de l'expression de besoins formule. Autrement, une phase
prparatoire d'entretiens ou de focus groupe sera ncessaire.
Entretiens : Des entretiens individuels permettent dchanger des vues sur
ltat de la situation et les besoins des utilisateurs et de dfinir les contenus
crer ou supprimer. Ces entretiens individuels sont raliss afin de :
prendre connaissance du mtier et du contexte de travail des
utilisateurs ;
recueillir les attentes et besoins des utilisateurs vis--vis du produit ;
obtenir un maximum de donnes afin de diriger la conception du produit.
Page 85
Le jeu de cartes : l'issue des entretiens, une analyse des entretiens permet
de faire ressortir l'ensemble des besoins et fonctionnalits prendre en compte
dans le futur produit. Ces diffrents termes, mots-cls et actions sont lis aux
objectifs d'utilisation que devra couvrir le produit.
Les cartes doivent tre de prfrence de la taille dune grande carte de visite
(si possible cartonnes pour faciliter les manipulations). Chacune symbolise
une information prsente dans le produit. Elle est compose d'un titre (un ou
deux mots-cls) rapide lire et comprendre, et d'une ou deux phrases
dcrivant plus en dtail linformation en question. Ce texte descriptif doit tre
rdig avec soin afin de ne pas induire de regroupement lorsquil est lu par les
participants. Dans certains cas, il peut tre intressant daccompagner le texte
dune image, par exemple celle du produit concern.
Il est recommand de ne pas dpasser les 50-60 cartes, car le tri risque d'tre
fauss par la difficult prendre en considration l'ensemble des cartes. Audel, il est prfrable de travailler dans un premier temps sur les grandes
rubriques, chaque carte reprsentant un ensemble de caractristiques relatives
un thme donn, puis de structurer l'intrieur de chaque thme par une
nouvelle srie de tris.
8.5.6.
Atelier de tri
L'atelier de tri, ralis individuellement ou en groupe, est effectu en 3 tapes :
validation des libells, regroupement et dnomination des groupes.
Aprs avoir prsent les objectifs de la sance, lanimateur distribue
alatoirement les cartes sur une table.
1. Validation des libells : il est demand aux participants de relire
chacune des cartes et de vrifier que le titre qui leur a t attribu leur
parat cohrent avec le contenu tel quil est prsent dans le texte
descriptif situ en dessous. Si ce nest pas le cas, les participants peuvent
modifier le titre de la carte en employant un libell qui leur semble mieux
adapt.
2. Le regroupement : lanimateur demande aux participants de regrouper
les cartes qui se ressemblent . Il leur demande de construire
des familles . Le tri par carte est l'occasion de vrifier si le contenu
du produit correspond la demande des utilisateurs. Lutilisateur pourra
corriger les libells qu'il ne comprend pas en proposant une autre
formulation directement sur la carte. Il pourra galement ddoubler une
carte afin de la faire apparatre dans diffrents groupes..
3. Dnomination des groupes : Finalement, les participants donnent un
nom chacun des groupes quils viennent de construire. ventuellement,
ils peuvent galement dcider de regrouper certains groupes pour former
un groupe de groupes auquel il donne galement un nom.
Pour les ateliers individuels, chaque participant fait son tri individuellement.
Par la suite, il prsente son tri lanimateur qui lui fait expliciter ses choix.
Pour un atelier collectif, la sance se droule ainsi :
1. chaque utilisateur classe ses cartes ;
2. les groupes ainsi que les noms sont affichs au tableau ;
Page 86
3. le groupe change sur les variations constates pour parvenir un

consensus ;
4. sil y a des cartes restantes, le groupe explicitera pourquoi elles nont
pas t classes et essayera de leur trouver une place dans
larborescence.
Au cours de la sance, lanimateur reste le plus neutre possible et incite les
participants verbaliser : "Pourquoi avez-vous mis ces cartes ici ? En
quoi se ressemblent-elles ?". Les rponses des utilisateurs vont lui
permettre de mieux comprendre le modle mental quils se construisent du
produit. Cette mthode est appele tri ouvert (ou tri montant) car elle part
du contenu pour constituer des groupes. Le tri peut tre conduit de manire
inverse, en proposant une arborescence prdfinie, au sein de laquelle
les participants doivent placer les cartes prsentes. Cette seconde
mthode de tri est appele tri ferm. Elle est gnralement employe pour
valider une arborescence issue dun tri ouvert. Il est intressant de
combiner les techniques de tri ouvert et de tri ferm pour trier
progressivement un grand nombre de cartes. En effet, il est difficile de
conduire une sance de tri avec plus de cent cartes. Dans ce cas, il est
prfrable de procder par tapes en construisant a priori des groupes de
premier niveau qui seront valids par un tri ferm, puis en conduisant des
tris ouverts pour chacun des groupes, de manire limiter le nombre de
cartes traiter chaque fois.
8.5.7.
Analyse
Lanalyse des rsultats du tri par carte consiste identifier les regroupements
les plus frquemment effectus par les utilisateurs. Pour cela, des logiciels
permettent de raliser un traitement statistique partir des diffrentes
arborescences issues des sances de tri, comme les dendrogrammes ou les
matrices de similarit. Cependant, comme le tri par carte est une mthode
qualitative ralise sur un petit nombre dutilisateurs, on ne peut pas sappuyer
uniquement sur une analyse statistique. Les logiciels danalyse doivent aider
lorganisation des informations, mais larchitecture rsultant du tri doit
galement sappuyer sur les observations ralises lors des sances de tri.
Cest pourquoi il est important dassister directement aux sances de tri.
8.5.8.
Atelier de fusion
l'issue de l'analyse, lanimateur propose aux utilisateurs larborescence quil

a pralablement construite et leur demande dy mettre les cartes. Il anime un
travail dchange avec un groupe reprsentatif afin de :
prsenter les rsultats des tris prcdents ;

valider avec les participants les points sur lesquels les autres utilisateurs
taient daccord ;
Page 87
travailler avec le groupe sur les points sensibles (divergences, cartes non
classes) pour parvenir un consensus.
8.5.9.
Priorisation en thmes en mode Agile
En mode Agile, nous utilisons principalement cette technique pour alimenter le
backlog (liste des thmes dvelopper) fourni aux quipes en charge de
limplmentation. Cela permet dobtenir un ensemble de user stories (thmes
utilisateurs) classes par priorit.
Ainsi, plutt que de dmarrer dune feuille blanche et de nombreuses
hypothses non vrifies, cette technique va vous permettre de mieux cerner
les attentes relles des utilisateurs avec une premire feuille de route des
scnarios dvelopper. videmment cette feuille de route nest quune
premire vue des besoins utilisateurs et aura besoin dtre complte.
Lanimateur, en intervenant tout au long du projet, va la faonner et lenrichir.
Elle sera galement amliore par lquipe technique en charge de la
ralisation du produit, en ajoutant les contraintes lies la technologie.
Les bases de la technique
Votre objectif va tre de collecter des donnes trs prcises auprs des
utilisateurs finaux. Pour cela, vous allez devoir guider vos participants
travers une rflexion qui leur permettra de comprendre le but de votre
produit et crer une atmosphre propice lidation (mergence dides
cratives).
Pour une mise en immersion efficace, nous utilisons les techniques issues de
lanimation de groupe par le jeu.
Comme dans toutes les techniques didation, le focus group Agile UX
sorganise en trois grandes phases :
une phase Ice Breaker ;
une phase de dveloppement ;
une phase de synthse.
8.5.9.1. Premire phase : Ice Breaker
Lobjectif de lIce Breaker est de mettre les participants en condition et
dinstaurer une atmosphre propice la gnration dides. Cette phase
doit vous permettre dtablir un lien entre toutes les personnes prsentes
pour quelles forment un groupe soud.
Le principe du Ice Breaker est en soi trs simple : il consiste introduire
lobjet de latelier et demander chaque personne de se prsenter au reste
du groupe. Pour crer une relation entre les membres du groupe, il faut
quil y ait contact.
Gnralement, nous procdons de la sorte :
nous demandons tous les participants de se mettre ensemble autour
dune table ;
nous leur proposons de se dcrire brivement par crit ;
ensuite nous invitons chaque participant transmettre sa description
son voisin de droite ;
Page 88
chaque participant dcouvre en silence la fiche de son voisin et lannote

dune question ;
enfin chaque participant reprend sa fiche, se prsente au reste du
groupe et rpond la question pose.
Cette procdure trs simple permet littralement de briser la glace et de
crer un climat de confiance et dchange propice lidation.
8.5.9.2. Deuxime phase : Le dveloppement dides

La phase de dveloppement consiste faire merger des ides. Pour cela vous
devrez diriger votre sance en plusieurs tapes qui guideront vos participants
vers la construction dides structures.
Prsentez votre vision
Tout dabord, vous devez exposer le sujet dtude aux participants du focus
group. Nous vous conseillons de le faire sous forme de vision.
La vision est un moyen de prsenter votre produit de manire prcise et
structure afin que les participants disposent des lments ncessaires pour
commencer la rflexion ( qui sadresse le produit, comment il sappelle, quels
sont ses objectifs, les bnfices quil procure par rapport des produits
concurrents, etc.). La vision peut se prsenter de diffrentes manires, par
exemple sous la forme dun poster, dun slide, etc.
Veillez ce que la vision soit consultable par les participants tout au
long du focus group, cest essentiel pour le bon droulement de la sance.
Une fois la vision expose, nous vous conseillons de procder en deux tapes :
tout dabord le World Caf (brainstorming amlior), puis la rdaction de user
stories.
Organisez un Word Caf Brainstorming itratif
Plus vous allez faire des sessions en groupe, plus vous allez vous rendre
compte que certains participants vont simposer et monopoliser le temps de
parole. Cest un biais frquent. Ltape prcdente du Ice Breaker va entre
autres vous permettre dobserver les comportements et de dceler les
personnalits de vos participants. Un des moyens pour mieux matriser
linfluence de certaines personnes est dorganiser le brainstorming sous la
forme dun World Caf.
Cela consiste runir les participants en petits groupes (essayez de faire des
groupes homognes en termes de personnalits), chacun autour dune table,
et nommer un secrtaire par groupe pour formaliser les rflexions.
Aprs un temps imparti, demandez chaque groupe, sauf au secrtaire, de
rejoindre une autre table et de continuer la rflexion avec le secrtaire de la
table quil a rejoint. Chaque secrtaire fait un debrief des rflexions menes
par sa table, et lon permet aux gens denrichir leurs rflexions.
Une fois que les groupes ont rencontr tous les secrtaires de table, ces
derniers tablissent un premier bilan des rflexions ralises. Ces
prsentations nont pas besoin dtre trop formalises, elles servent poser
les premires briques pour une rflexion plus structure (user stories).
Page 89
Rdaction des user stories

ce stade de la sance, chaque participant est fortement imprgn de la vision
du produit tablie par vos soins et des nombreuses ides changes en groupe.
Il est temps dsormais que chaque participant sapproprie les ides les plus
importantes selon lui et les documente sous la forme de user stories.
Chaque participant va dcrire sous forme dhistoire (cest pour cela que lon
parle de user stories) cinq ides quil juge importantes selon le formalisme
suivant : En tant que, je souhaite que le produit permette de car cela
apporterait lavantage de.
Une fois les users stories rdiges, chaque participant les prsente au reste de
lassemble et les affiche sur un tableau commun. Puis les user stories
identiques ou similaires sont regroupes.
ce stade, vous devrez vous assurer que les users stories exprimes sont
comprises par tous mais galement par lquipe qui sera en charge de leur
ralisation. En tant quanimateur du groupe, vous tes responsable de la clart
des user stories.
lissue de cette phase, vous tes en possession des prmisses dun backlog
initial avec des groupements de user stories. Vous pouvez alors passer la
phase de synthse.
8.5.9.3. Troisime phase : La synthse
De trs nombreuses ides ont t avances, il est difficile dy voir clair.
Lobjectif dsormais est dessayer de rduire le nombre dlments, de les
fdrer et de les regrouper en thmes communs.
Regroupement des user stories en thmes
Pour rduire le nombre dlments, vous allez demander aux participants de
regrouper les user stories en thmes. ce stade, vous pouvez aisment
employer la technique du card sorting. Mme si vous ne respectez pas tous les
prrequis, vous pouvez largement vous en inspirer. Pour entretenir la
dynamique du groupe, nous prfrons que les participants ralisent ce
regroupement ensemble.
Ici, cest lanimateur qui impacte les regroupements au tableau. Il sassure que
tous les participants interprtent correctement les user stories et les
regroupements de thmes raliss.
Ca y est, vous disposez dsormais de la liste des thmes qui constituent votre
feuille de route. Il ne vous reste plus qu solliciter vos utilisateurs pour
dterminer une priorit de ralisation.
Classer des thmes en fonction de leur priorit
Pour dfinir un degr de priorit, vous pouvez utiliser la technique du
MOSCOW planning.
Pour raliser cette technique, vous pouvez utiliser un tableau en quatre
colonnes sur lequel les participants placent les thmes : la premire colonne
reprsente le Must have (M) (ie. Doit tre fait), la deuxime colonne le Should
Page 90
have (So) (ie. Devrait tre fait), la troisime le Could have (Co) (ie. Pourrait
tre fait) et la dernire le Wont have (W) (Ne sera pas fait).
Chaque participant place les thmes identifis sur les colonnes de son choix,
tour tour, sur le mme tableau. Chaque participant suivant se base sur le
classement du participant prcdent. Bien videmment, il y a un effet dordre
qui risque de biaiser les rsultats, cest pourquoi, chaque passage, le
changement propos par un participant doit tre argument et ncessite
lapprobation du groupe entier. Cest lexercice le plus complexe.
Ainsi, lorsque le dernier participant passe au tableau, on disposera dune
priorisation qui aura vcu plusieurs cycles de changements issus dune
rflexion collective.
la fin du MOSCOW planning, vous obtiendrez probablement beaucoup
dlments dans la colonne Must have (M) et peu, voire aucun, dans la colonne
Wont have (W) ( vrai dire, cest normal car les user stories sont cres par
vos participants, ils vont les dfendre ardemment). Vous devez donc aller
encore plus en profondeur pour dfinir la squence de dveloppement des
thmes pour lquipe de la ralisation : cest l quintervient la technique du
vote par point.
Distribution des points
Permettez aux participants de distribuer autant de points quil y a de thmes.
Tous les participants se rendent en mme temps au tableau et rpartissent
leurs points comme bon leur semble sur lensemble des thmes affichs. Ils
peuvent rpartir ces points quitablement ou dcider de tous les placer sur un
seul thme.
Cette tape est intressante car elle permet de rquilibrer les premiers
classements faits par les participants dans les quatre colonnes.
Une fois tous les points distribus, vous pouvez appliquer une pondration (en
associant un facteur par colonne).
Faites le compte de points en appliquant le facteur dfini pour chaque colonne
et ordonnez vos thmes du plus grand score au plus petit.
Votre feuille de route utilisateur est dfinie !
Conclusion
a y est, vous disposez dune feuille de route priorise des thmes
dvelopper par lquipe de ralisation.
9. ESTIMATION DE LA DURE ET PLANIFICATION D'UN SPRINT

9.1.
quipe, Product Backlog et tableau de Sprint Backlog
Dmarrage
Lquipe de dveloppement et le product owner dterminent ensemble la
dure des itrations ou Sprints (4 semaines maximum). Cette dure devra
tre la mme pour lensemble des sprints afin de maintenir un rythme rgulier
Page 91
propice aux automatismes et pouvoir construire des indicateurs de pilotage

fiables. Un projet dmarre gnralement par ce quon appelle souvent le
sprint 0 ddi aux travaux prparatoires du projet (ex : construction du
product backlog et de la vision du produit, prparation des
environnements, mise en place de lintgration continue, dfinition de
larchitecture gnrale du projet, initiation des acteurs Scrum, etc.).
Exceptionnellement, la dure de ce sprint 0 ne respecte pas forcment la
dure fixe prcdemment.
Larchitecture doit tre souple et merger au fil des sprints.
9.2.
La runion de planification de Sprints
Le travail effectuer durant le Sprint est labor la runion de planification

de Sprint. Ce plan est cr de manire collaborative par tous les membres
de lquipe Scrum.
La planification dun Sprint dun mois est limite 8 heures. Pour les
sprints plus courts, elle dure habituellement moins longtemps.
Le Scrum Master veille ce que lvnement ait lieu et que les participants
en comprennent le but. Le Scrum Master enseigne lquipe Scrum comment
respecter la limite de temps associe cet vnement.
La planification de Sprint rpond aux questions suivantes :
Quest-ce qui peut tre termin au cours de ce Sprint ?
Comment sera effectu le travail choisi ?
9.2.1.
Quest-ce qui peut tre termin au cours de ce sprint
?
Lquipe de Dveloppement collabore pour envisager la fonctionnalit qui
sera dveloppe durant le Sprint. Le Product Owner discute de lobjectif qui
devrait tre atteint durant le Sprint et des items du Product Backlog qui, sils
sont termins, permettront datteindre cet objectif. Lquipe Scrum dans son
ensemble collabore pour comprendre le travail requis.
La planification de Sprint a comme lments de dpart le Product Backlog,
le dernier incrment produit, la capacit de lquipe de Dveloppement pour
le prochain sprint et lhistorique de performance de lquipe de
Dveloppement. La quantit ditems du Product Backlog choisis pour le
Sprint dpend uniquement de lquipe de Dveloppement. Seule lquipe
de Dveloppement peut dterminer ce quelle peut accomplir durant le
prochain Sprint.
Page 92
Une fois que lquipe de Dveloppement a dtermin les items du Product

Backlog quelle prvoit de livrer, lquipe Scrum dtermine lobjectif du
Sprint. Il sagit dun objectif qui, travers limplmentation des items du
Product Backlog choisis, sera atteint durant le Sprint et qui fournit lquipe
de Dveloppement la raison pour laquelle elle dveloppe lincrment.
9.2.2.
Comment sera effectu le travail choisi ?
Une fois lobjectif du sprint fix et les items du Product Backlog choisis,
lquipe de Dveloppement planifie le travail pour transformer cette
fonctionnalit en un incrment termin du produit durant le Sprint. Ainsi,
les items du Product Backlog choisis et le plan conu par lquipe constituent
le Sprint Backlog.
L'quipe de Dveloppement commence gnralement par concevoir le
systme et le travail ncessaire afin de transformer le Product Backlog en un
incrment fonctionnel du produit. La taille ou leffort estim du travail peut
varier. Cependant, lors de la runion de planification, lquipe de
Dveloppement doit envisager suffisamment de travail pour quelle ait une
bonne ide de ce qu'elle pense pouvoir accomplir durant le Sprint. Avant la
fin de la runion, lquipe de Dveloppement dcompose le travail prvu pour
les premiers jours du Sprint, souvent jusqu' une granularit d'une journe
ou moins. L'quipe de Dveloppement s'auto-organise pour entreprendre le
travail consign au Sprint Backlog, la fois lors de la runion de planification
de Sprint et quand cela est ncessaire tout au long du Sprint.
Le Product Owner peut aider clarifier les items du Product Backlog choisis
et faire des compromis. Si lquipe de Dveloppement dtermine quelle a
trop ou pas assez de travail, elle peut rengocier les items du Product Backlog
choisis avec le Product Owner. Lquipe de Dveloppement peut galement
inviter dautres personnes la runion afin de recevoir des conseils
techniques ou lis au domaine.
la fin de la planification du Sprint, lquipe de Dveloppement devrait tre
en mesure dexpliquer au Product Owner et au Scrum Master comment elle
entend sorganiser pour raliser lobjectif du Sprint et crer lincrment
prvu.
9.2.3.
Objectif du Sprint
Lobjectif du Sprint est un but fix pour le Sprint et peut tre ralis par
limplmentation dune partie du Product Backlog. Il fournit lquipe de
Dveloppement la raison pour laquelle elle construit lincrment du produit.
Il est cr lors de la runion de planification du Sprint. Lobjectif du Sprint
fournit lquipe de Dveloppement une certaine flexibilit quant la
fonctionnalit implmente durant le Sprint. Les items du Product Backlog
slectionns offrent un fonctionnement cohrent, ce qui peut faire office
Page 93
dobjectif de Sprint. Par ailleurs, lobjectif de sprint peut tre toute autre
source de cohsion poussant lquipe de Dveloppement travailler
ensemble au lieu dentreprendre des initiatives distinctes.
Tout en effectuant son travail, lquipe de Dveloppement garde lesprit
lobjectif du Sprint. Afin datteindre lobjectif du Sprint, lquipe implmente
la fonctionnalit et la technologie ncessaire. Si le travail se rvle diffrent
de ce qui a t prvu, lquipe de Dveloppement collabore avec le Product
Owner et ngocie le primtre du Sprint Backlog durant le sprint.
9.3.
Estimation des User Stories
9.3.1.
Quest-ce quun story point?
Un story point sert estimer leffort ncessaire une quipe pour implmenter
une fonctionnalit (story pour les intimes).
Cette estimation prend en compte :
leffort pour le dveloppement
la complexit du dveloppement
Le risque / linconnu
Par abus de langage, on dit que le story point sert estimer la taille dune
fonctionnalit.
9.3.2.
Pourquoi estimer ?
Il nexiste pas dunit de mesure de la taille dune fonctionnalit; donc
dterminer le cot dune fonctionnalit ncessite forcment des estimations.
9.3.3.
Comment estimer ?
Une estimation est souvent le rsultat direct ou driv dun calcul. Par exemple
pour estimer le cot ncessaire pour peindre une pice, il faut :
chercher une grandeur de mesure (la surface dune pice dans notre
exemple)
estimer le cot en fonction de la surface et du cot par mtre carr
En labsence dune grandeur de mesure (comme pour les fonctionnalits),
lestimation peut se faire comme suit:
chercher une unit de comparaison (une autre pice de rfrence dans
notre exemple)
estimer le cot en fonction du cot de la pice de rfrence multipli par
le rapport dune pice sur lautre
Lestimation est donc relative, la rendant ainsi plus facile raliser. En effet,
quand il sagit destimer, il est plus facile de raisonner en relatif. Prenons une
situation o il sagit de dterminer le poids dune bote A. Pour garder lanalogie
avec les tailles des fonctionnalits, disons que nous ne savons pas peser la bote
A. Dans ce cas-l, cest plus facile pour une personne de dire que la boite A pse
deux fois le poids de la boite B que de dire la boite A pse 2,37 Kg.
Page 94
9.3.4.
Pourquoi ne pas estimer directement le temps
ncessaire pour dvelopper une fonctionnalit?
Pourquoi estimer la taille dune fonctionnalit? Pourquoi ne pas prendre le
temps comme unit de comparaison et faire des estimations relatives? Ce
temps varie en fonction de la taille et de lexprience de lquipe. Prendre
en considration lexprience des membres de lquipe permet dobtenir des
estimations plus fines et donc fiables. En revanche, cette prise en considration
rend plus complexe le travail collgial destimation. Par exemple un
dveloppeur Junior peut estimer une tche 3 jours alors quun dveloppeur
avec plus dexprience (ou plus ancien sur le projet) estimera la mme tche
une journe de travail.
Disposer dune grandeur destimation qui soit propre la story est
donc ncessaire.
La notion de taille dune story est la grandeur propre la fonctionnalit.
Comme pour chaque grandeur, il y a besoin dune unit de mesure et dans
notre cas cest le story point.
9.3.5.
Comment estimer en story points?
Pour pouvoir estimer en relatif, lquipe commence par choisir une ou plusieurs
stories de rfrence en leur attribuant arbitrairement et dun commun accord
une taille chacune.
Ensuite, lors de la runion de Planning Poker (aussi appele runion de
chiffrage, destimation ou encore de cotation):
La nouvelle fonctionnalit est prsente.

Les membres de lquipe posent des questions pour avoir plus de
prcisions.
Chaque membre de lquipe estime la taille de la fonctionnalit
relativement aux tailles des stories de rfrence.
Les membres de lquipe dvoilent en mme temps leurs estimations
pour ne pas influencer les votes.
Si les estimations ne convergent pas, les membres de lquipe expliquent
les raisons de leurs choix
Le processus destimation est rpt jusqu ce que tous les membres
de lquipe se mettent daccord sur une estimation.
Se mettre daccord sur une estimation ne veut pas forcment dire que tous les
membres votent pour la mme taille. Il se peut quun des membres de
lquipe donne une estimation suprieure celles des autres. Dans ce cas,
aprs discussion avec lquipe et avec laccord de tous les membres,
lestimation la plus haute est retenue.
Page 95
9.3.6.
Quelle chelle destimation?
Plusieurs squences existent pour estimer la taille dune fonctionnalit. Les

plus utilises sont :
squence avec une taille numrique (varie de 1 10)
squence avec la taille des vtements (XS, S, M, L, XL, XXL) (souvent
utilis en Kanban)
squence de Fibonacci (1, 2, 3, 5, 8, 13, 20, 40, 100) : squence o
chaque numro est gal la somme des deux numros prcdents.
squence (1, 2, 4, 8): squence o chaque numro est gal au double
du numro prcdent.
Notons bien, que la squence de Fibonnaci est un peu modifie puisqu partir
dune certaine valeur la prcision na pas beaucoup dimportance. Se baser sur
des squences non linaires (comme les deux dernires) rejoint cette ide
aussi et permet dviter de longues discussions autour de la vraie valeur de
la taille dune story. Noublions pas quil sagit toujours destimations.
Peu importe la squence choisie, il faut que lquipe se sente laise avec celleci et quelle la conserv pour tous les chiffrages.
9.3.7.
Comment dterminer les cots de dveloppement ?
Comment les estimations en story points peuvent nous aider dterminer les
cots de dveloppement des fonctionnalits? Pour le comprendre, il faut
introduire la notion de vlocit.
La vlocit est une mesure de la capacit dune quipe raliser des
fonctionnalits sur une priode donne. Elle est calcule en sommant les story
points des fonctionnalits termines. Par exemple, une quipe qui termine le
dveloppement de deux stories estimes 5 points et une story estime 3
points aura une vlocit de 13 points.
Ayant la vlocit de lquipe, il est facile de dduire une estimation du temps
ncessaire partir de lestimation des tailles des stories.
Page 96
9.3.8.
Synthse de lestimation des user Stories ?
Page 97
Page 98
9.4.
Dfinition des User Stories pour le prochain Sprint
9.5.
Le dcoupage en tches
Les estimations en temps sont gnralement plus facile faire (et plus
prcises) si une histoire (User story) est dcoupe en tches . Ou
activits
Cela est aussi agrable et facile faire avec les fiches. Vous pouvez avoir
l'quipe qui dcoupe une histoire en tches, pour pouvoir travailler
paralllement dessus.
Physiquement, des petits post-it sont ajouts sous chaque histoire, chaque
post-it correspondant une tche de cette histoire.
Chaque tche possde un nombre de points qui correspond la taille de son
exigence en termes de travail et de complexit.
Les diffrents acteurs participent sur lattribution des points de toutes les
tches et se mettent daccord
Le backlog du produit nest pas mis jour avec le dcoupage en tches,

pour plusieurs raisons :
Le dcoupage en tches est gnralement tout fait phmre, i.e. les
tches sont frquemment modifies et raffines durant le sprint, de
telle sorte quil serait trop harassant de garder le backlog du produit
jour
Le Directeur de produit na pas besoin dtre impliqu ce niveau de
dtail.
Les tches vont tre de toute manire agrges dans luser story.
Page 99
Le problme de validation et des tests dacceptation des tches se pose

Sil y a des rgles de gestion et des tests dacceptation, il vaut mieux
intgrer les tches comme users stories dans le backlog du produit
De la mme faon que les fiches, les post-it des tches peuvent tre
directement rutilises dans le backlog de sprint
9.6.
Les Users Stories techniques
Une story technique est une story qui n'apporte pas de valeur directe aux
utilisateurs. Cela inclut les spikes (des tudes) , les travaux d'architecture,
d'infrastructure ou d'outillage de l'environnement de dveloppement, le
refactoring etc
Le refactoring est l'opration consistant retravailler le Produit ( en
dveloppement informatique : code source d'un programme informatique )
sans toutefois y ajouter des fonctionnalits ni en corriger les bogues de faon
en amliorer la lisibilit et par voie de consquence la maintenance, ou le
rendre plus gnrique (afin par exemple de faciliter le passage de simple en
multiple prcision) ; on parle aussi de remaniement . Cette technique utilise
quelques mthodes propres l'optimisation de code, avec des objectifs
diffrents.
Cest donc conjointement des user stories plus classiques que ces stories
techniques se prsentent en planning meeting.
Page 100
9.6.1.
La user story technique et le planning meeting
Mais si les user stories classiques sont traites assez efficacement, leurs
homologues techniques ncessitent environ plus de temps Sont en cause :
Une difficult cadrer la solution, car la finalit nest pas claire. Il
manque le contexte.
Impuissance dterminer le primtre de la story. Quand celle-ci serat-elle termine ? Quels sont les tests dacceptation ?
Mme avec plus de temps, le dcoupage en tches et lestimation savrent
moins satisfaisants. Mme si vous ntes pas fan du dcoupage en tches et
des estimations, il nen reste pas moins que ceux-ci savrent symptomatiques
de la comprhension de litem.
9.6.2.
Remettre la story technique dans son contexte
Basculer de la user story technique leurs quivalents fonctionnels est moins

difficile quil ny parait de prime abord. Il sagit surtout de se poser les
bonnes questions :
Pourquoi a-t-on besoin de faire cela ? Que se passe-t-il, ou quest-ce qui
se passe mal, si on ne fait pas cela ?
Dans quel contexte cela sera-t-il utilis ?
Dun point de vue externe, comment saurais-je que le systme possde
cette proprit ou cette capacit supplmentaire ?
Page 101
Cette liste nest pas exhaustive, et vous pourrez facilement imaginer dautres
questions. Le but est simple : remettre litem technique dans un contexte
fonctionnel.
9.6.3.
Refactoring
Le refactoring est une technique grce laquelle vous pouvez restructurer et
modifier votre code existant de telle sorte que son comportement reste
inchang. Le refactoring vous permet de rationaliser, de simplifier et
d'amliorer les performances et la lisibilit du code de votre application. Il faut
bien avoir l'esprit que lorsque l'on fait du refactoring nous devons faire des
volutions mais surtout pas de rvolutions.
On peut refactorer du code dans plusieurs optiques. La premire qui est
souvent la plus voque est la lisibilit du code. En effet, si votre code n'est
pas lisible par d'autre cela peut ajouter des risques lors de sa modification et
par consquent engendrer des bugs qui auraient pu tre vits.
La seconde raison est l'amlioration de la qualit du code. Lorsque nous codons
pour la premire fois une fonctionnalit celle-ci peut-tre trop longue en terme
de lignes de code ou encore avoir un algorithme compliqu. C'est pour cela
que nous pouvons refactorer cette fonctionnalit pour avoir par exemple un
algorithme trs simple. Cela peut encore tre fait dans le but de pouvoir
maintenir un code beaucoup plus simplement.
La troisime raison qui nous pousse faire du refactoring est la peur des bugs.
Nous ne sommes jamais labri de bug, de coquilles dans notre code. C'est
pour cela qu'il peut tre intressant de relire le code en l'amliorant et en
vrifiant que le rpond bien aux normes de dveloppement.
Enfin, la 4me et dernire raison de faire du refactoring est le fait de vouloir
ne pas tre dpendant d'une technologie.
9.6.4.
User story de type Spike
Pendant un sprint, une story est ralise en accomplissant un certain nombre

de tches.
Une story est dfinie par ses tests d'acceptation, qui permettront de vrifier
qu'elle est finie la fin du sprint
On utilise un spike pour mener des travaux d'tude, d'exploration technique
d'un lment (user story) du backlog
Cela revient dcomposer cet lment en 2 parties :
le spike proprement dit, qui est fait au sprint n
le dveloppement de l'lment qui sera inclus dans le sprint n+1 (ou
pas selon les rsultats du spike)
9.6.5.
Quand utiliser le Spike?
Le spike est utilis quand on ne sait pas estimer une user story. En
gnral, si on ne sait pas l'estimer, c'est qu'on ne connat pas de
solution technique pour cette story.
Le spike peut aussi tre utilis pour tudier plusieurs solutions
diffrentes. Dans notre produit, nous avons intgrer des donnes
Page 102
d'un dcisionnel et il y a plusieurs possibilits pour le faire, le spike va

permettre de les tudier.
Enfin le spike peut aussi tre utilis quand la story est trs grosse et
qu'elle ne peut pas tre finie en un seul sprint. Dans notre cas, c'tait
le cas pour la story portant sur la migration des donnes de l'ancienne
application dans la nouvelle. A noter que si la story n'a pas t
dcompose avant, c'est probablement parce que la solution technique
n'est pas connue ou mal matrise.
Le spike sert approfondir le comment (la conception), pas le quoi, qui est du
ressort du product owner. Donc si on ne sait pas estimer, il faut savoir si c'est
par manque de prcisons sur le quoi ou par mconnaissance du comment avant
de dcider de faire un spike.
9.6.6.
Quel est le rsultat d'un spike ?
On fait un spike pour comprendre comment dvelopper une story. A la fin du
sprint incluant un spike, on devrait :
avoir dfini une solution
tre capable d'estimer le cot de dveloppement, pour aider le product
owner dcider quoi faire de cette story.
Il arrive aussi que le spike amne dcomposer la story initiale en plusieurs
autres, plus petites.
9.6.7.
Quel est le temps consacr un spike ?
Un spike est normalement limit une dure fixe (principe du timeboxing)
au dbut du sprint. La pratique recommande veut qu'on ne passe pas plus
d'une journe de travail (8 heures) sur un spike.
Page 103
9.7.
Les Defect Stories
Une Defect Story est une correction dun bug ou une anomalie dune User
Story. Elle est troitement lie la dette technique
Lorsque, sur un projet informatique, il devient difficile d'ajouter de nouvelles
fonctionnalits et que la maintenance devient un vritable calvaire, cest le
signe que la dette technique sest accumule en excs et quil est temps de la
rembourser. Dans la majorit des cas, cette dette trouve son origine dans
des compromis faits sur les choix de conception et de ralisation, souvent
pour des raisons de temps.
La dette doit tre gre de manire permanente sur les projets
Tout dabord, quil soit clair quil sagit de dettes techniques. Oui, elles sont
trs frquentes. Oui, il est probablement impossible de les grer entirement
dans les itrations prcdentes, au moment o les fonctionnalits ont t
codes. Nanmoins, elles sont la preuve que le travail effectu dans des
itrations prcdentes ntait pas parfait. Il est donc utile de sintresser ces
problmes durant les rtrospectives.
Puisque ces lments sont des dettes techniques, ils ne devraient pas tre
estims laide de story points. Il faut rendre clair quil ny a pas de gain
fonctionnel sur la correction de bugs ou sur le refactoring de larchitecture
(attention, il peut y avoir un gain dans le sens o une fonctionnalit devient
utilisable; mais il ny a pas de gain additionnel pour cette fonctionnalit). Dans
la pratique, le nombre de story points que lon peut implmenter dans une
itration pourrait tre plus faible que dans le pass, cause du temps perdu
dans les corrections. Dune certaine faon, cest une bonne chose: cela rend
clair que la vlocit baisse, en raison dun travail non parfait dans les itrations
prcdentes. Il faut tre transparents l-dessus.
Il est recommand de :
ne pas les estimer avec des story points.
dimensionner litration qui arrive avec le mme nombre de points
quauparavant.
En gnral, avec laugmentation de la vlocit, il peut tre possible de passer
du temps sur les dettes techniques tout en maintenant une vlocit plus ou
moins constante. Si cela est clairement impossible, alors prenez des mesures
draconiennes, comme diviser par deux le nombre de points pour la prochaine
itration. Encore une fois, nous voulons tre transparents sur le fait que les
choses ne vont pas parfaitement bien.
Dans la plupart des cas les defect stories sont intgres au :
Product Backlog
Eventuellement un Bug Backlog
les membres de lquipe devraient corriger les bugs ds quils sont connus.
Cependant, lquipe de dveloppement est plus laise lorsquelle peut faire
rfrence un lment du Sprint Backlog. Le simple fait de dplacer un postit sur le mur la rend plus laise lors de la runion quotidienne.
Pour certaines tches, il est galement utile davoir des post-it pour rendre
clair quelles doivent tre traites. Cest en particulier pour un refactoring
darchitecture.
Page 104
Dans tous les cas, ces tches devraient tre estimes en heures idales de
travail. Gnralement, a nest pas un problme pour le refactoring
darchitecture. Pour les bugs, le mieux est de faire une estimation intelligente
en se basant sur la valeur de la veille dans le traitement des bugs)
Il est possible que les bugs soient en ralit bien plus complexes que prvus.
Dans ce cas, informez le Product Owner ds quil est clair que les objectifs de
litration ne pourront tre remplis, et voyez si quelques fonctionnalits
peuvent tre abandonnes.
Pour rsumer :
si les dettes techniques sont plus ou moins rcurrentes, contentez-vous
de les lister dans le Sprint Backlog, et ne changez pas (trop) votre
vlocit
si les dettes techniques sont complexes rgler, discutez avec le Product
Owner avant le dbut de litration (que penseriez-vous si nous passions
le Sprint entier corriger les bugs? ou la moiti du Sprint), ou pendant
litration (nous avions estim en dbut de Sprint quil y aurait une
certaine quantit de bugs, mais lvidence, il y en a beaucoup plus.
Quelles fonctionnalits pouvons-nous abandonner?)
dans tous les cas, menez toujours une rflexion lors de la Rtrospective
sur la faon damliorer la situation.
Page 105
9.8.
La notion de Termin ( Done )
Quand un item du Product Backlog ou un incrment est dit termin , tout
le monde doit comprendre ce que termin signifie. Mme si le sens varie
de faon importante dune quipe Scrum une autre, les membres doivent
avoir une comprhension commune de ce que signifie un travail termin, afin
dassurer la transparence. Ceci est la dfinition de termin pour lquipe
Scrum et celle-ci est utilise pour valuer si le travail est termin dans un
incrment de produit.
Cette mme dfinition aide lquipe de Dveloppement savoir combien
ditems du Product Backlog elle peut choisir durant la planification du Sprint.
Le but de chaque Sprint est de produire des incrments de fonctionnalits
potentiellement livrables qui correspondent la dfinition de termin en
vigueur de lquipe Scrum.
Page 106
Les quipes de dveloppement livrent un incrment de fonctionnalit de

produit chaque Sprint. Cet incrment est utilisable, de telle sorte que le
Product Owner peut choisir de mettre celui-ci en production immdiatement.
Si la dfinition de termin dun incrment fait partie des conventions,
standards ou lignes directrices de lorganisation de dveloppement, toutes les
quipes doivent au minimum la respecter. Si la dfinition de termin nest
pas une convention de lorganisation de dveloppement, lquipe de
Dveloppement de lquipe Scrum doit tablir une dfinition de termin
approprie pour le produit. Si plusieurs quipes Scrum travaillent sur le
systme ou la livraison du produit, les quipes de dveloppement de toutes les
quipes Scrum doivent mutuellement tablir la dfinition de termin .
Chaque incrment sadditionne tous les incrments prcdents et fait lobjet
de tests approfondis, assurant ainsi que tous les incrments fonctionnent
ensemble.
Au fur et mesure que les quipes Scrum prennent de la maturit, on sattend
ce que leur dfinition de termin inclue progressivement des critres plus
rigoureux, permettant un niveau de qualit plus lev. Tout systme ou produit
devrait avoir une dfinition de termin standard pour tous les travaux
effectus
Une dfinition de
Termin peut tre :

Fonctionnalit compltement implmente
Code finalis
Pas de dfauts connus
Fonctionnalit approuve par le Product Owner
Fonctionnalit prte tre dploye
Page 107
10. PLANIFICATION DES RELEASES

10.1.
Scrum et les Releases
Quand les quipes Scrum travaillent itrativement dans des sprints, ils se
focalisent plutt sur les Releases (ou version) que sur des projets.
Cest quoi une Release ? Il est, peut-tre plus facile, de dire quune Release
se produit lorsque les quipes Scrum fournissent quelquun, en dehors des
quipes Scrum, un livrable fonctionnel (Logiciel, produit ou service) pour son
pour ses propres besoins.
Ce nest pas une release si le livrable est fourni
aux quipes de tests
un autre groupe des fin dintgration.
Les Releases sont habituellement le rsultat de plusieurs sprints deffort de
dveloppement concentr, et ils marquent souvent un moment de march ou
d'une entreprise ou de l'impact de la clientle..
Alors qu'il est certainement possible pour une quipe (ou des quipes) pour
construire et diffuser des logiciels sans rien faire de plus compliqu que la
planification de sprints rguliers et la gestion du Product backlog , il est souvent
ncessaire de prendre en considration dautres aspects qui sont , peut-tre ,
en dehors des domaines de comptence de lquipe Scrum Pour cette raison,
faire une version ncessite souvent une planification plus globale avec une
perspective plus large.
la planification de Releases dans Scrum est une approche Agile pour la
cration de la vision plus large qui est souvent ncessaire la livraison, avec
succs, dune Release sur le march avec succs.
Comme toujours quand on parle de tout type de planification dans un contexte
Agile, il faut faire attention garder notre approche itrative (et non
restrictive) et supporter des quipes auto-organises et des contrles des
processus empiriques.
Typiquement, la planification de release est une tentative de rpondre la
question quand, au plus tard, serons-nous en mesure de dlivrer la version
X.X du produit , service ou logiciel concern par ces dveloppements? .
Page 108
10.2.
Planification dune Release
Dans tous les projets, on fait des plans, pour essayer de prvoir ce que va
contenir un produit ou quelle date il sortira sur le march. Avec Scrum, la
planification de release a les mmes objectifs : fournir l'quipe et aux parties
Page 109
intresses des informations sur le contenu des sprints constituant la release.

A cette tape, le Product Owner a en sa possession le backlog de produit
contenant les diffrentes tches raliser en priorit, ainsi que la capacit de
l'quipe (cest--dire le nombre de jours homme disponible dans le sprint). La
planification de release consiste alors dfinir quels sont les User Story qui
seront incluses dans cette release.
Une grande partie de l'effort ncessaire pour produire le plan de release est
consacre l'estimation. Avec Scrum et les mthodes agiles, celle-ci est
collective, elle s'labore lors de runions o toute l'quipe participe. C'est un
point fondamental que l'quipe s'occupe des estimations, car c'est elle qui va
par la suite excuter les tches de ralisation et s'est donc elle qui est la mieux
place pour en connatre les difficults.
La mthode de planification prconise par Scrum est elle seule significatrice
de l'esprit de cette mthode. Il n'est ici pas question d'estimer le temps
ncessaire au dveloppement de chaque tche, mais bien l'effort fournir pour
y arriver.
Bien que la technique ne soit pas impose par Scrum, la plus frquente est de
faire une estimation collective au cours dune sance appele planning poker
et d'estimer plutt la taille que la dure.
Dans une approche agile, on distingue cinq niveaux de planification, ils
correspondent aux diffrentes tapes qui rythment le projet : tablissement
de la vision, fixation des jalons, planification dune release, planification dune
itration, planification quotidienne.
Niveau 1 : vision du produit

Niveau 2 : roadmap ou jalon
Niveau 3 : plan de la release
Niveau 4 : plan de litration
Niveau 5 : cycle quotidien
Nous nous intressons ici uniquement au niveau 3
Niveau 3 : plan de la release
Page 110
Une release se dfinit par une date de dbut et une date de fin, un thme et
une slection de fonctionnalits implmenter. lintrieur dune release, on
dfinit des itrations, auxquelles sont affectes les diffrentes stories.
Il est en effet souhaitable davoir, au cours dun projet, des itrations de mme
longueur, afin de rythmer le projet et de faciliter ainsi la planification des
runions ou les validations pour toutes les parties prenantes. En outre, la
vlocit, cest--dire le nombre de story points dvelopps par lquipe au
cours dune itration, ne peut tre calcule et rutilise par lquipe que sur
des priodes comparables.
Planifier une release, cela revient par consquent ventiler des fonctionnalits
dans des itrations dont la taille a t dtermine. Au pralable, il est souvent
ncessaire de prciser ces fonctionnalits, voire de les dcouper pour les
affecter efficacement et logiquement aux itrations ; cette rpartition est
fonction de la vlocit. Au cours dune runion de planification (release
planning meeting), les fonctionnalits macroscopiques prioritaires sont alors
dtailles en units plus fines, qui sont estimes en nombre de points, selon
leur complexit, et rparties sur les itrations de la release, en fonction de la
vlocit de lquipe.
Les fonctionnalits des autres releases, de priorit moyenne
ou faible, ne sont pas traites, pour le moment.
On obtient ainsi le plan de la release (release plan), cest--dire, pour cette
premire release, le nombre ditrations, leurs dates de dbut et de fin, ainsi
que les fonctionnalits que lon envisage dy dvelopper, aprs calcul de la
vlocit de lquipe.
Ce plan de la release peut tre mis jour tout au long de la priode,
essentiellement la fin de chaque itration, si la vlocit estime de lquipe
se rvle tre errone ou si le client modifie ses priorits
Page 111
11.
VIE DUN SPRINT
11.1.
Check-list
Page 112
11.2.
Scrum Meeting/Daily Scrum
La mle quotidienne (Daily Scrum) est un vnement limit 15 minutes au

cours duquel lquipe de Dveloppement synchronise ses activits et cre un
plan pour les prochaines 24 heures. Pour ce faire, lquipe inspecte le travail
effectu depuis la dernire mle quotidienne et envisage le travail qui peut
tre ralis dici la prochaine.
La mle a lieu tous les jours la mme heure et au mme endroit afin de
rduire la complexit. Durant la runion, les membres de lquipe de
Dveloppement dcrivent :
Ce quils ont ralis hier qui a aid lquipe de Dveloppement atteindre
lobjectif du Sprint ;
Ce quils raliseront aujourdhui pour aider lquipe de Dveloppement
atteindre lobjectif du Sprint ;
Les obstacles qui, selon eux, les empchent ou empche lquipe de
Dveloppement datteindre lobjectif du Sprint.
Lquipe de Dveloppement utilise la mle quotidienne pour inspecter sa
progression vers lobjectif du Sprint et lachvement du travail prvu au Sprint
Backlog. La mle quotidienne augmente les chances que lquipe de
Dveloppement atteindra lobjectif du Sprint. Chaque jour, lquipe de
Dveloppement doit comprendre comment elle sauto-organise pour atteindre
lobjectif du Sprint et crer lincrment anticip dici la fin du Sprint. Lquipe
de Dveloppement ou un sous-ensemble de celle-ci se rencontre souvent juste
aprs la mle quotidienne pour des discussions plus dtailles ou pour
adapter, ou planifier nouveau le travail restant.
Le Scrum Master sassure que la mle quotidienne a lieu, mais cest lquipe
de Dveloppement qui est responsable de son droulement. Le Scrum Master
apprend lquipe de Dveloppement comment limiter la mle quotidienne
15 minutes.
Page 113
Le Scrum Master veille lapplication de la rgle stipulant que seuls les

membres de lquipe de Dveloppement participent la mle quotidienne.
Les mles quotidiennes amliorent la communication, liminent les autres
runions, rvlent les obstacles qui perturbent le dveloppement afin quils
soient supprims, mettent en avant et encouragent la prise de dcision rapide
et amliorent le niveau de connaissance de lquipe de Dveloppement. Il sagit
dun point cl dinspection et dadaptation.
11.3.
Sprint Review
Une revue de Sprint est tenue la fin du Sprint pour inspecter lincrment
ralis et adapter le Product Backlog si ncessaire. Pendant la runion de revue
de Sprint, l'quipe Scrum et les parties prenantes changent sur ce qui a t
fait durant le Sprint. En se basant l-dessus, et en considrant les
changements au Product Backlog effectus durant le Sprint, les participants
collaborent pour dterminer les prochains items ayant le plus de valeur qui
pourraient tre faits. Cette runion se veut informelle, pas une runion de
pilotage, et la prsentation de l'incrment est destine susciter des ractions
et favoriser la collaboration.
Cette runion est limite une bote de temps de quatre heures pour un Sprint
dun mois. Pour les Sprints moins long, la revue de Sprint dure gnralement
moins longtemps. Le Scrum Master sassure que la revue a lieu et que les
participants en comprennent le but. Le Scrum Master apprend tous comment
respecter la bote de temps.
La revue du Sprint comprend les lments suivants :
Les participants incluent lquipe Scrum et les parties prenantes cls que
le Product Owner a invit ;
Le Product Owner explique les items du Product Backlog qui ont t
termins et ceux qui ne lont pas t ;
Page 114
Lquipe de Dveloppement discute de ce qui sest bien droul durant

le Sprint, quels problmes ont t rencontrs, et comment ces problmes
ont t rsolus ;
L'quipe de Dveloppement dmontre le travail termin et rpond
aux questions sur l'incrment ;
Le Product Owner discute du Product Backlog tel qu'il est. Il dtermine
des dates probables dachvement en fonction des progrs ce jour ;
L'ensemble du groupe convient de ce qu'il faut faire pour la suite, de
sorte que la revue de Sprint fournisse une contribution prcieuse aux
runions de planification de Sprint subsquentes ;
Une revue de la faon dont les conditions de march ou un usage
potentiel du produit pourrait avoir dict ce quil conviendrait mieux de
faire dornavant ;
Une revue des dlais, budget, fonctionnalits potentielles et conditions
du march pour la prochaine livraison du produit.
Le rsultat de la revue de Sprint est un Product Backlog rvis qui dfinit les
items probables pour le prochain Sprint. Le Product Backlog peut galement
tre compltement revu pour rpondre de nouvelles occasions daffaires
11.4.
Rtrospective de Sprint
La rtrospective de Sprint (Sprint Retrospective) est une occasion pour
l'quipe Scrum de s'inspecter et de crer un plan d'amlioration qui sera mis
en place au cours du Sprint suivant.
La rtrospective de Sprint survient aprs la revue de Sprint et avant la
prochaine runion de planification de Sprint. Cest une runion limite trois
heures pour les Sprints dun mois. Pour les Sprints moins longs, la runion
dure habituellement moins longtemps. Le Scrum Master sassure que la
runion a lieu et que les participants en comprennent le but. Le Scrum Master
apprend tous comment respecter la bote de temps. Le Scrum Master
participe en tant que membre de lquipe Scrum et y amne le point de vue
du responsable du processus Scrum.
Le but de la rtrospective de Sprint est :
Dinspecter la manire dont le dernier Sprint s'est droul en ce qui
concerne les personnes, les relations, les processus et les outils ;
Didentifier et ordonner les lments majeurs qui se sont bien drouls

et les amliorations potentielles ;
De crer un plan pour amliorer les processus de travail de l'quipe
Scrum.
Page 115
Le Scrum Master encourage l'quipe Scrum amliorer, dans le cadre Scrum,

son processus de dveloppement et ses pratiques afin de les rendre plus
efficaces et agrables pour le prochain Sprint. Lors de chaque rtrospective de
Sprint, l'quipe Scrum planifie des moyens adquats d'accrotre la qualit du
produit, en adaptant sa dfinition de termin .
la fin de la rtrospective de sprint, l'quipe Scrum devrait avoir identifi les
amliorations qu'elle mettra en oeuvre durant le prochain sprint. La mise en
oeuvre de ces amliorations au cours du prochain sprint est l'adaptation
l'inspection de l'quipe de Dveloppement elle-mme. Bien que des
amliorations puissent tre mises en oeuvre tout moment, la rtrospective
de sprint fournit un vnement ddi et ax sur l'inspection et l'adaptation.
Page 116
11.5.
Synthse : les timesboxes dans SCRUM
LES TIMEBOXES DANS SCRUM

Sprint
Habituellement entre 2 et 4 semaines.
Sprint Planning Meeting
Pour 2 3 semaines de sprint : gnralement 1 journe,
dont la moiti pour dfinir le contenu du sprint,
et l'autre moiti pour dfinir comment les fonctionnalits
slectionnes vont tre dveloppes.
Sprint review
Gnralement 4h< (la moiti de la dure du Sprint
Planning Meeting). Plutt 1 2h.
Sprint retrospective
Gnralement 4h< (la moiti de la dure du Sprint
Planning Meeting). Plutt 1 2h.
Daily Scrum
15Mn
Page 117
12.
LE SUIVI
12.1.
Planifier, itrer et assurer le suivi
12.1.1.
Planification du sprint
Participants
Obligatoire : quipe de dveloppement, Scrum Master, responsable produit
Quand : au dbut d'un sprint.
Dure : gnralement une heure par semaine d'itration (par exemple, un
sprint de deux semaines dmarre par une runion de planification de deux
heures).
Cadre Agile : Scrum. (Les quipes Kanban planifient galement, bien
entendu, mais elles ne fonctionnent pas selon un calendrier d'itrations fixe
avec une planification formelle des sprints.)
Objectif : la planification du sprint garantit la russite de ce dernier dans son
ensemble et pour toute l'quipe. En arrivant la runion, le Product Owner
disposera d'un backlog de produit hirarchis. Il discutera de chaque lment
avec l'quipe de dveloppement. Le groupe fera une estimation, de faon
collective, des efforts que cela implique. L'quipe de dveloppement procdera
ensuite une prvision du sprint, en dterminant la quantit de travail
ralisable par l'quipe partir du backlog de produit. Cet ensemble de tches
deviendra alors le backlog du sprint.
Astuce : profitez de la runion de planification du sprint pour prciser les
dtails des tches effectuer. Encouragez les membres de l'quipe baucher
les tches pour l'ensemble des stories, bogues et tches qui interviennent dans
le sprint. Favorisez les discussions et parvenez un consensus autour du plan
d'action. Une planification efficace augmente sensiblement les chances de
russite de l'quipe pour remplir les engagements du sprint.
12.1.2.
Itration
12.1.2.1.
Revue d'itration
Participants
Facultatif : parties prenantes du projet
Quand : la fin d'un sprint ou d'un jalon.
Dure : entre 30 et 60 minutes.
Cadre Agile : Scrum et Kanban. Tout comme la planification, la revue doit,
pour les quipes Kanban, s'aligner sur les jalons de l'quipe, plutt que sur
une cadence fixe.
Objectif : la revue d'itration est le moment o l'on prsente le travail de
l'quipe. Le format peut tre informel ou adopter une structure de runion plus
formelle. C'est l'occasion, pour l'quipe, de clbrer ses russites, de prsenter
les tches termines dans le cadre de l'itration et d'obtenir un feedback
immdiat de la part des parties prenantes du projet. N'oubliez pas, les tches
doivent tre compltement prsentables et rpondre aux critres de qualit de
l'quipe pour tre considres comme termines et prtes pour la revue.
Page 118
12.1.2.2.
Rtrospective
Participants
Quand : la fin d'une itration.
Dure : 60 minutes.
Cadre Agile : Scrum et Kanban. Les quipes Scrum ralisent la rtrospective
de sprint selon une cadence fixe. Les quipes Kanban peuvent galement
bnficier de rtrospectives occasionnelles.
Objectif : Agile vise obtenir un feedback rapide pour amliorer la culture de
dveloppement et le produit. Les rtrospectives permettent l'quipe de
comprendre ce qui a fonctionn ou pas.
Les rtrospectives ne doivent pas uniquement servir se plaindre, sans agir.
Profitez des rtrospectives pour dterminer ce qui fonctionne afin que l'quipe
puisse continuer se concentrer sur ces points. Voyez galement ce qui ne
fonctionne pas, recherchez des solutions cratives et laborez un plan d'action.
L'amlioration continue favorise le dveloppement et la prennit de l'quipe
agile, et les rtrospectives en sont un lment cl.
Astuce : mme si tout se passe bien au sein de l'quipe, ne renoncez pas aux
rtrospectives. Elles donnent l'quipe l'orientation ncessaire pour que tout
continue bien se passer.
12.1.3.
le suivi
12.1.3.1.
Mle quotidienne ( Stand Up quotidien)
Participants
Facultatif : parties prenantes de l'quipe
Quand : une fois par jour, gnralement le matin.
Dure : pas plus de 15 minutes. Ne rservez pas une salle de confrence
pour y tenir cette runion debout en position assise. La position debout
permet de raccourcir au maximum la runion.
Cadre Agile : Scrum et Kanban.
Objectif : le stand-up a pour but d'informer rapidement tous les participants
de ce qui se passe au sein de l'quipe. Il ne s'agit pas d'une runion
d'avancement dtaille. Le ton doit tre lger et ludique, tout en restant
informatif. Invitez chaque membre de l'quipe rpondre aux questions
suivantes :
Qu'ai-je termin hier ?
Sur quoi vais-je travailler aujourd'hui ?
Y a-t-il quelque chose qui bloque mon travail ?
Rendre compte aux autres des tches que vous avez accomplies la veille
comporte une forme de responsabilisation implicite. Personne ne souhaite
devenir le membre de l'quipe qui travaille constamment sur les mmes
tches et qui ne progresse pas.
Page 119
12.2.
Estimer le Reste Faire
Dans Scrum, lEquipe est auto gre, et pour russir, elle doit savoir
sorganiser. Chaque jour, les membres de lEquipe actualisent leurs estimations
du reste faire pour les tches en cours du Sprint Backlog.
Il est courant qu la suite une personne additionne les efforts restants pour
lensemble de lEquipe, et le trace sur le Sprint Burndown Chart (Ce
graphique montre, chaque jour, une nouvelle estimation du reste faire estim
pour terminer les tches de lEquipe. Ce graphique se prsente idalement
sous la forme dune courbe incline vers le bas, suivant une trajectoire visant
atteindre zro effort restant le dernier jour du Sprint. Cest pour cela que
ce graphique se nomme un burndown chart [graphe de combustion].
Et si parfois la trajectoire est bonne, parfois elle lest moins; cest la ralit du
dveloppement. Limportant est que cela montre lEquipe sa progression vers
son but, non pas en fonction de combien de temps a t consomm dans le
pass (ce qui a peu dintrt en termes de progression), mais en fonction de
combien de travail il reste faire dans le futur cest dire ce qui spare
lEquipe de son objectif. Si la courbe ne suit pas linclinaison ncessaire pour
Page 120
lachvement des travaux lapproche de la fin du Sprint, alors lEquipe doit

sadapter, par exemple en rduisant le primtre du travail faire ou en
trouvant un moyen de travailler plus efficacement tout en gardant un rythme
soutenable.
Bien que le Sprint Burndown Chart peut tre cr et diffus sous la forme dune
feuille de calcul, beaucoup dEquipes estiment quil est plus efficace de lafficher
au format papier sur un mur de lespace de travail. Les mises jour sont alors
ralises au feutre; cette solution faiblement technologique / hautement
humaine est rapide, simple, et souvent plus visible quun graphique au
format lectronique.
12.3.
Connatre la valeur mtier pour arrter le projet
Scrum est entirement pilote par la valeur mtier la gestion des risques,
en particulier, est ralis au travers de ce prisme.
Page 121
Le Product Owner doit s'assurer que des dcisions budgtaires pertinentes sont
prises en permanence au niveau d'une release, du Backlog de produit et de
chaque sprint
12.3.1.
Budget au niveau release
Au niveau d'une release, le Product Owner effectue sans cesse des arbitrages
en termes de primtre fonctionnel, de date de livraison, de budget et de
qualit, afin de tirer profit du flux d'informations significatives au niveau
budgtaire qui arrive au cours du dveloppement. Les arbitrages effectus en
dbut de cycle peuvent ne plus s'avrer pertinents suite l'arrive d'une
nouvelle information pendant la release.
Prenons un exemple : nous avons dj progress de plusieurs semaines dans
un effort de dveloppement date fixe sur six mois. Nous constatons alors
qu'est apparue une opportunit d'augmenter le chiffre d'affaires de 50 % si
nous acceptons de consacrer une semaine de plus (4 % de dcalage) pour
ajouter une nouvelle fonction cette release. Devons-nous repousser la sortie
d'une semaine et supporter le cot correspondant pour augmenter le CA ? C'est
au Product Owner de trancher, ce qu'il peut faire en gnral de faon
unilatrale. Parfois, il peut recommander une dcision tout en travaillant avec
les autres personnes pour s'assurer de leur soutien dans l'excution (et parfois
de leur approbation).
En fin de sprint, le Product Owner dirige la prise de dcision pour financer ou
non le sprint suivant. La rponse sera positive s'il constate une progression
correcte en direction du but de la release ou si le sprint suivant possde une
autre justification conomique. Si la progression est insuffisante ou si le budget
ne suffit plus, l'effort prvu peut tre annul.
Un Product Owner peut galement dcider de stopper le financement des
dveloppements ultrieurs la fin d'un sprint s'il est satisfait du produit et qu'il
le juge prt tre livr, les complments ne se justifiant plus. Supposons par
exemple que nous ayons prvu une release sur dix sprints. Au bout du sprint
7, le Product Owner passe en revue les lments restants dans le Backlog de
produit et en conclut que le cot de production de ces lments est suprieur
au complment de valeur qu'ils vont rapporter. Il peut donc dcider de lancer
le produit au lieu de laisser se poursuivre le plan d'origine en dix sprints. Cette
souplesse permettant d'courter un dveloppement n'est possible que si on a
pris soin de faire produire les lments apportant le plus de valeur en premier,
en les plaant en haut du Backlog de produit. Cela suppose galement que
l'quipe ait vraiment achev le travail lors de chaque sprint en conformit avec
une dfinition d'achvement rigoureuse.
Le Product Owner peut galement dcider d'arrter le financement la fin d'un
sprint du fait que le profil financier fondamental a volu. Citons l'exemple de
la cration d'un produit spcifique un pays. Un beau jour, le gouvernement
de ce pays vote une loi qui te tout espoir de rentabilit au produit ou mme
Page 122
le rend illgal. Dans une telle situation, le Product Owner peut envisager l'arrt
immdiat de l'effort de dveloppement, mme si tout se droulait
correctement.
12.3.2.
Budget au niveau sprint
Le Product Owner est galement en charge de la gestion budgtaire au niveau

des sprints, car il doit s'assurer d'un bon retour sur investissement (ROI) pour
chaque sprint. Un Product Owner srieux gre les finances de son entreprise
comme si c'tait son propre argent. Normalement, il connat le cot du
prochain sprint (puisque la dure et la composition de l'quipe ont t
dfinies). Il peut donc s'interroger pendant la planification du sprint : "Suis-je
prt faire un chque personnel du montant de ce sprint pour obtenir les
fonctions que nous avons prvu de produire ?" En cas de rponse ngative, le
Product Owner srieux ne dpensera pas non plus l'argent de son entreprise.
12.3.3.
Budget au niveau Backlog de produit
J'ai indiqu dans le Chapitre 6 que le Product Owner devait crer des priorits
entre les lments du Backlog de produit (les PBI). Ces priorits doivent
pouvoir voluer lorsque les conditions budgtaires changent.
Imaginons par exemple qu'en dbut de release, le Product Owner considre
une fonction comme trs attrayante pour un fort pourcentage des utilisateurs
viss. Paralllement, l'quipe a considr que sa production demanderait peu
d'efforts. Au bout de quelques sprints, l'quipe change d'avis en constatant
que l'effort pour produire la fonction sera bien suprieur. Par un malheureux
concours de circonstances, il s'avre que cette fonction va intresser bien
moins d'utilisateurs que prvu. Le rapport cot-bnfice de la fonction a donc
normment chang. Le Product Owner doit la repousser dans le Backlog de
produit, en allant ventuellement jusqu' supprimer les lments PBI associs
cette fonction.
12.4.
La motivation de lquipe
Parfois, l'obsolescence du mode organisationnel se constate sur le terrain, au
sein mme de l'entreprise : des process hirarchiques trop lourds, une
organisation par services (autrement dit en silos, sans transversalit), le
manque de visibilit sur le projet global de la socit... Autant de choses qui,
au final, impactent la motivation des collaborateurs et donc la performance.
Sans attendre la dgradation totale du moral des quipes et la chute libre des
rsultats, une solution : l'anticipation.
Fruit de cette rflexion commune, le constat principal est le suivant : il faut
faire la part belle l'auto-organisation et renverser les rapports hirarchiques
classiques. C'est la mthode Scrum, qui repose sur un nouveau partage des
rles et des responsabilits.
Pratiques indites et diffrents "rituels", comme de rapides runions matinales
pour faire le point. Au final, l'tat d'esprit de la mthode Scrum, base sur la
communication, la transparence et le partage des responsabilits, est un
succs.
Page 123
L'auto-organisation, la responsabilisation,
maintenant partie du travail au quotidien
l'envie
de
s'amliorer
font
Les fondements de la mthode Scrum

La mthodologie dcoupe l'activit en cycles courts (des itrations de deux
semaines) l'issue desquels les briques fonctionnelles dveloppes sont
testes. De quoi ajuster tout de suite ce qui ne convient pas. De plus, chaque
dveloppeur fait ses propres choix techniques afin d'atteindre l'objectif dont il
devient responsable. Au global, cette organisation repose sur le fait que tout
le monde s'implique et s'approprie le projet, responsabilits comprises.
Scrum est certes une mthode de gestion de projets qui a fait ses preuves.
Mais au-del des questions dorganisation, cest bien de la motivation et des
responsabilits des salaris dont il sagit, dans un contexte o les approches
traditionnelles butent souvent sur les limites des rapports hirarchiques
classiques. Auto-organisation, responsabilisation et visibilit sont lordre du
jour. Mle ouverte.
Les modes organisationnels traditionnels montrent leurs limites dans un
contexte conomique ralenti, o la ractivit doit tre de mise pour sadapter
aux changements du march. Lorsque les processus habituels (hirarchiques)
sont trop lourds, lorsque les diffrents services fonctionnent en silos, les
collaborateurs ne disposent plus dune visibilit claire sur les objectifs globaux
de lentreprise. Consquence, ils ne trouvent plus dans les projets de sources
de motivation et leurs performances sen ressentent instantanment. Cest
souvent le problme de la direction de lentreprise qui ne donne plus envie
davoir envie .
Pour fournir un produit de bonne qualit, les dveloppeurs doivent se sentir
concerns et pas seulement dplacer des post-it sur un tableau. Il doit y avoir
dans lquipe le sentiment dappartenance quelque chose de plus grand
que le dveloppement de leur tche. Cest ce qui entrane intrt pour le travail
sur la motivation et la dynamique de groupe.
Les piliers de la motivation sont :
Un but pour tre inspir, Il permet davoir au sein de son quipe :
o Inspiration,
o Motivation,
o Succs.
Un Contexte pour tre dynamique,
Un Alignement pour tre collaboratif Le but de ce pilier est davoir dans
lquipe :
o un sentiment dunit,
o de la confiance,
o de lengagement.
Les valeurs de transparence, dinspection et dadaptation doivent rester
au centre des proccupations de lquipe.
Page 124
Le but des rituels est de rappeler ces valeurs et de les remettre au cur du
processus du dveloppement chaque moment cl. Ils nont pas de valeur
intrinsque!
En SCRUM, il est demand lquipe de dveloppement de
sautogrer au quotidien, de conserver un il critique, dtre force
de proposition et de sengager sur ses capacits couvrir le besoin.
Cest pourquoi, afin de rester motiv et focalis, lquipe de
dveloppement doit tre ddie au projet.
Dautre part, afin de conserver cette motivation et cette focalisation,
lquipe doit travailler sur un rythme humainement tenable et stable
: charge normale et constante.
Ces composantes doivent tre garanties par le duo SCRUM Master et
Product Owner. La maturit du SCRUM Master et du Product Owner
rejailli donc directement sur la motivation et lefficacit de lquipe
de dveloppement
Page 125
13.
LA CONDUITE DU CHANGEMENT
13.1.
Comment mener le changement vers Scrum ?
Pour une organisation, le fait de devenir Agile participe crer la capacit

dadaptation, rapide et permanente, au contexte dans lequel elle volue.
Souvent confine aux quipes techniques, voire limite aux quipes de
dveloppement logiciel, la mise en uvre des valeurs et des principes Agiles
doit tre tendue bien au-del de ces horizons pour apporter la valeur
attendue.
Ce type de projet doit tre envisag de faon systmique : lorganisation,
les ressources humaines, la technologie, les processus de
dveloppement et certains processus support sont concerns.
Une fois la transformation dcide, et pour en garder lesprit et le rythme, la
vision de lobjectif doit tre dfinie et porte par le bon niveau de
lorganisation (sponsor). La transformation doit tre mene comme un projet
(stratgie, acteurs et indicateurs). Le projet de transformation lui-mme
est gouvern de faon Agile (itrations, frquents retours dexprience,
solutions mergentes, etc.).
Finalement, le rsultat des expriences successives est prennis et amplifi
(dissmination des leons apprises, formation de coachs internes, mise
en place de communauts).
13.1.1.
Enjeux et enjeux
Un projet de transformation, quel quil soit, remet en cause des organisations,
des processus, mais surtout remet en cause la faon dont les hommes et les
femmes travaillent, collaborent, spanouissent et adhrent aux projets de
lentreprise.
Dans les transformations dampleur, la priode dincertitude et dinstabilit
peut tre longue et difficile supporter : les motifs et les enjeux de la
transformation doivent tre clairs et solides.
Les enjeux et les motivations de la transformation vers lAgilit sont particuliers
chaque entreprise, ils sont tablis sur la base dlments objectifs (parts de
march, rductions de cots, meilleure ractivit, qualit des applications) et
Page 126
subjectifs (satisfaction des clients, qualit des relations dans les quipes, par
exemple).
un niveau de dtail plus fin, on citera par exemple :
rduire le dlai entre lexpression dune demande et la mise
disposition de la solution,
augmenter la qualit des applications, afin de matriser la charge de
maintenance et de support,
limiter les allers-retours entre la matrise douvrage et la matrise
duvre loccasion des tests de validation,
rendre lavancement des projets plus visible pour les directions
oprationnelles en particulier, afin dadapter les documentations
techniques produites aux besoins rels, pour contenir les cots et les
dlais,
faciliter les modifications de planning et de primtre de livraison, en cas
denvironnement trs mouvant (produit innovant, besoins instables).
13.1.2.
Le projet de transformation
Une transformation Agile est avant tout un projet de conduite du changement,
dont les ingrdients peuvent tre identifis comme :
une vision (ambition, objectifs, horizon temporel, primtre, stratgie
de changement),
une trajectoire (connaissance de ltat actuel, tapes intermdiaires,
cible),
un sponsor (de prfrence au plus haut niveau de lorganisation),
une quipe pluridisciplinaire (pour la conduite et limplmentation du
changement),
des moyens (budget, infrastructure),
un pilotage (progrs de la transformation, valuation des effets par
rapport aux objectifs).
Page 127
13.1.3.
Dfinir le projet : le cadrage
Dans les approches Agiles, la dfinition dun projet est porte par le Product
Owner.
Par similarit, le projet de transformation doit tre port par un sponsor,
assist dautant dexperts de terrain que ncessaire pour dfinir un projet
ambitieux, raliste et viable parce quaccept et comprhensible par toutes les
parties prenantes.
Le cadrage du projet de transformation vers lAgilit est une activit
stratgique. Il est port par la direction qui en est le sponsor.
Une approche combine et concurrente en top-down et bottom-up est
prconise.
13.1.3.1.
Dvelopper la vision
Page 128
La vision dtermine ltat atteindre en fin de projet, mais galement des

tats intermdiaires (court, moyen et long terme) qui permettent de mesurer
les progrs durant tout le dploiement.
13.1.3.2.
Identifier le primtre
Une quipe de projet de dveloppement logiciel ne travaille pas isolment du
reste de lentreprise et de son environnement : les clients, les utilisateurs, le
matre douvrage, les sous-traitants ventuels sont parties prenantes du
projet.
Ds lors, cet environnement est affect par le rythme itratif du projet, et
par la ncessit de relations de collaboration plus troites. Lapproche Lean
propose doptimiser le systme globalement, et ce nest pas sans raison
13.1.3.3.
Identifier les moyens
En dehors des moyens organisationnels ddis au projet de transformation
(sponsor global qui porte la vision, pilote le projet de transformation, planifie
le dploiement et en value les progrs et les rsultats), la transformation
Agile ncessite un accompagnement par des experts qui permettent de
dpasser rapidement le stade du faire Agile pour parvenir au stade
du tre Agile .
Ces experts, gnralement externes, ont pour vocation intervenir :
auprs du sponsor, pour la mise au point de la vision et la qualification
des objectifs gnraux,
auprs de la direction informatique, et autres directions fonctionnelles
(directions mtier, marketing, achats, etc.), pour la quantification des
Page 129
moyens, la planification du dploiement, le choix des moyens daction,

les rorganisations potentielles,
auprs des niveaux de management intermdiaires (responsables
dquipe, de dpartement), pour faciliter leur transition vers les
nouvelles modalits de suivi et les nouvelles modalits daction (meneurfacilitateur au lieu de dcideur-gestionnaire),
auprs des quipes de dveloppement, ils sont en charge de la
transformation sur les aspects processus et sur les pratiques de
planification, destimation, de suivi davancement et de communication
au sein de lquipe,
auprs des quipes de dveloppement, pour la mise en uvre des
pratiques techniques telles que les tests unitaires, la spcification par les
tests, lintgration en continu,
auprs du responsable de produit (Product Owner) et des utilisateurs,
pour les accompagner dans leurs nouveaux rles et faciliter la
communication et la collaboration avec les quipes de dveloppement,
auprs des entits responsables des processus support (mthodes et
outils, production), pour faciliter les transformations ncessaires.
Des moyens internes doivent galement tre mobiliss pour amplifier et

prenniser la transformation :
des champions locaux sont recruts sur la base du volontariat,
pour entraner les projets pilotes. Ce sont des oprationnels qui ont la
fibre Agile, une exprience pralable et qui souhaitent participer
activement la transformation
des communauts Agiles, constitues dacteurs en provenance des
diverses organisations. Lobjectif des communauts est de recueillir et
formaliser les expriences ralises par les diffrents projets, en extraire
les meilleures pratiques, partager les observations et rsultats et
ventuellement proposer de nouveaux axes damlioration.
des coachs Agiles internes, forms par exemple loccasion des
premiers projets par les coachs externes, ils ont vocation amplifier le
mouvement de transformation. Leur connaissance intime de lentreprise
est un atout mais ils doivent avoir la capacit de remettre en cause les
processus tablis. Comme pour tout programme de transformation, la
communication est un lment essentiel toutes les tapes. Le sponsor
global et les sponsors locaux sont responsables de la communication de
cet aspect.
13.1.3.4.
EXPERIMENTER : Le pilote
La dclinaison rapide du changement au niveau oprationnel, pour le rendre
palpable est essentielle : ltape pilote doit dmarrer assez rapidement,
mme si tous les dtails dimplmentation ne sont pas connus.
La ralisation des projets pilotes est ncessairement une priode
daccompagnement fort et de mutations progressives : il faut exprimenter,
adapter les solutions, vaincre les rsistances, recueillir les rsultats.
La priode pilote est loccasion de mettre en place les structures de relais
internes (communauts, sponsors locaux) et les moyens ddis (wiki, forum,
Page 130
sminaires priodiques) pour le partage des expriences et la propagation des

nouveaux savoir-faire.
Ltape pilote permet de dtecter concrtement les apports positifs et les
difficults dues lorganisation et aux processus en place, ces informations
sont utilises pour affiner le plan projet (quel processus ou organisation
modifier en premier lieu, comment)
La phase pilote stend sur quelques mois, et peut concerner plusieurs projets
de dveloppement.
13.1.3.4.1.
Slection des projets pilotes et conditions
de lancement
La slection des projets pilotes et des quipes de ralisation de ces projets doit
favoriser la russite de lexprimentation, et tre reprsentative de la ralit
de lactivit de lorganisation. Les critres de slection incluent :
Page 131
13.1.3.4.2.
La transformation dune quipe de projet
en quipe Agile
Schmatiquement, la transformation se droule selon les tapes suivantes :
Il est essentiel que tous les acteurs du projet participent ensemble la

formation initiale pour assurer que les valeurs et principes soient connus et
partags partous5; en intra-entreprise, ces sessions sont, en outre, riches
dchanges sur les modes de fonctionnement courants, et les pistes de
transformation commencent y tre labores avec lensemble des parties
prenantes.
A lchelle dun projet pilote, la dmarche de transformation est pilote de
faon Agile : au dmarrage de la transformation, puis la suite de chaque
Page 132
rtrospective ditration, lquipe et le coach tablissent un backlog de

transformation qui a toutes les caractristiques dun backlog de projet (les
items sont estims, dcomposs si ncessaire, prioriss, transforms en
tches). Pour faciliter la dmarche, les itrations de transformation sont
calques sur celles du projet lui-mme.
13.2.
Les 8 tapes du changement de Kotter et l'Agilit
Kotter est l'auteur du best-seller international "Leading Change", qui dcrit
les 8 tapes mettre en place pour transformer une entreprise
John Paul Kotter, professeur la Harvard Business School , est considr
comme une autorit sur le leadership et le changement.
Les huit tapes de la conduite du changement La conduite :

1. Establishing a Sense of Urgency (Crer un sentiment d'urgence)
2. Creating the Guiding Coalition (Crer une quipe de pilotage)
3. Developing a Vision and Strategy (Dvelopper une vision et une
stratgie)
4. Communicating the Change Vision (Communiquer la vision du
changement)
5. Empowering Employees for Broad-Based Action (Responsabiliser
les employs pour une large action)
6. Generating Short-Term Wins (Gnrer des victoires rapides)
7. Consolidating Gains and Producing More Change (Consolider les
gains et produire plus de changements)
8. Anchoring New Approaches in the Culture (Ancrer les nouvelles
mesures dans la culture d'entreprise)
Ces huit tapes s'accompagnent d'outils stratgiques servant :
reprer les diffrentes personnalits au sein de l'entreprise,
communiquer efficacement des messages en travaillant le ct
motionnel,
travailler les aspects comportementaux qui aboutiront une
modification d'attitude du personnel.
Page 133
Rapprochement entre principes et pratiques Agile et les 8 tapes de

changement organisationnel
8 tapes du changement
Principes / Pratiques Agile
organisationnel
Dveloppement itratif
Backlog de produit prioris
Crer le sentiment d'urgence
Rtroaction rapide
Crer une quipe de pilotage

Dvelopper une vision et une
stratgie
Communiquer la vision du
changement
quipe multidisciplinaire, autonome

Propritaire du produit (Product owner)
ScrumMaster
Backlog de produit
Planification du sprint
Backlog de sprint
Backlog de produit
Mle quotidienne (Daily Scrum Meeting)
Responsabiliser les employs

pour une large action
Gnrer des victoires rapides
Consolider les gains et
produire plus de changements
Ancrer les nouvelles mesures
dans la culture d'entreprise
13.3.
quipe autonome et responsable

ScrumMaster
Rtrospective
Dveloppement itratif, incrmental
Retour sur l'investissement rapide
Inspection and Adaptation
Rtrospective
Visibilit des progrs rel (succs)
Flot continu et soutenu du travail
La rsistance au changement
Ladoption des mthodes agiles est indniablement porteuse de

changement, or ltre humain naturellement tendance rsister ce dernier.
Consciemment ou inconsciemment. Le changement implique la perte de
repres suivi dune priode chaotique jusqu la mise en place des nouveaux
repres. Plus il est profond, plus la priode de transformation peut savrer
chaotique. Voir lAgilit comme un processus ou une mthodologie, sans
considrer sa dimension culturelle (cf. manifeste Agile), peut se rvler
dangereux et provoquer lchec de sa mise en uvre en sein dorganisations
dont la culture est trop loigne de la philosophie Agile et trop conservatrice.
Cest pour cette raison que russir sa transformation Agile peut faire lobjet
dun vritable dfi.
Page 134
Distinguons deux grandes catgories de rsistances au changement. Les

rsistances humaines et les rsistances organisationnelles.
Voici quelques facteurs de rsistances humaines :
Renoncer la croyance que lon peut spcifier intgralement un logiciel
lavance.
Renoncer la croyance que lon peut laborer un plan prcis lavance
sans revenir excessivement dessus.
Accepter de piloter par les dlais et considrer le primtre comme la
principale variable dajustement.
Parler quotidiennement debout devant ses collgues de son travail et de
ses difficults.
Renoncer lillusion de lefficacit du mode de management classique
( command and control ) sur des projets complexes.
Peur de perdre ses responsabilits dans le cadre dun changement de
son rle.
Peur de ne pas tre la hauteur face aux nouvelles faons de travailler.
Ces facteurs peuvent gnrer des comportements sceptiques voire saboteurs,
au mieux suiveurs
Ct organisationnel, nous pouvons notamment avoir faire face aux
rsistances suivantes :
Processus dvaluation annuel et systme de prime privilgiant la
performance individuelle plutt que collective.
Le rglement intrieur empchant lamnagement de lespace de travail
(disposition des bureaux, affichage sur les murs, etc.) ou lutilisation dun
logiciel de tchat.
Services Achats qui refuse de renoncer au contrat au forfait classique
fixant primtre, dlais et cot, rendant obligatoire la validation de
lintgralit des spcifications du logiciel avant le dmarrage des
dveloppements.
Page 135
14. MISE EN OEUVRE DES METHODES AGILE

14.1.
Les outils agiles.
14.2.
Les tableurs, les outils spcialiss.
14.3.
Prsentation des principales fonctionnalits offertes.
14.4.
Spcialisation. Comment passer du cadre gnrique de
l'offre agile une dmarche adapte l'entreprise et au projet.
14.4.1.
QUEST-CE QUE LAGILIT DANS LENTREPRISE ?
Lagilit dans son sens premier est synonyme dadresse et de vivacit. Ce sont
des caractristiques que les entreprises, souvent considres comme des
gants incapables dinnover, souhaitent intgrer dans leur fonctionnement
quotidien.
Les concepts de lagilit ont dabord trouv leurs lettres de noblesses dans les
dveloppements de logiciels. Ils sont dsormais adapts pour lensemble de
lentreprise.
14.4.1.1.
Manifeste Agile
Lagilit trouve son concept premier au sein du Manifeste pour le

dveloppement Agile de logiciels. Il sagit dun manifeste cr par des experts
de dveloppement logiciel qui vise mettre en avant des critres pour dfinir
une nouvelle faon de dvelopper des logiciels. En voici le texte original :
Nous dcouvrons comment mieux dvelopper des logiciels
par la pratique et en aidant les autres le faire.
Ces expriences nous ont amens valoriser :
Les individus et leurs interactions plus que les processus et les outils, Des
logiciels oprationnels plus quune documentation exhaustive,
La collaboration avec les clients plus que la ngociation contractuelle,
Ladaptation au changement plus que le suivi dun plan.
Nous reconnaissons la valeur des seconds lments, mais privilgions les
premiers.
Les mthodes agiles prnent 4 valeurs fondamentales (entre parenthses, les
citations du manifeste). Trois valeurs concernent lhumain et lquipe, et une
valeur se focalise sur le rsultat :
L'quipe ( Les individus et leurs interactions, plus que les processus
et les outils ) : dans l'optique agile, l'quipe est bien plus importante
que les outils (structurants ou de contrle) ou les procdures de
fonctionnement. Il est prfrable d'avoir une quipe soude et qui
communique plutt qu'une quipe compose d'experts fonctionnant
chacun de manire isole.
La collaboration ( La collaboration avec les clients, plus que la
ngociation contractuelle ) : le client (ou lutilisateur) doit tre
Page 136
impliqu dans le dveloppement. On ne peut se contenter de ngocier

un contrat au dbut du projet, puis de ngliger les demandes du client.
L'acceptation du changement ( L'adaptation au changement, plus

que le suivi d'un plan ) : la planification initiale et la structure du
produit ou service doivent tre flexibles afin de permettre l'volution de
la demande du client tout au long du projet.
Le produit ou le service ( Des logiciels oprationnels, plus qu'une
documentation exhaustive ) : il est vital que le produit fonctionne ! Le
reste, et notamment la documentation technique, est une aide
prcieuse mais non un but en soi.
Ces quatre valeurs se dclinent en 12 principes gnraux communs toutes

les mthodes agiles :
1. La plus haute priorit est de satisfaire le client en livrant rapidement et
rgulirement des fonctionnalits forte valeur ajoute.
2. Le changement est accept, mme tardivement dans le dveloppement, car
les processus agiles exploitent le changement comme avantage concurrentiel
pour le client.
3.
La livraison sapplique une application fonctionnelle, toutes les deux
semaines deux mois, avec une prfrence pour la priode la plus courte.
4. Le mtier et les dveloppeurs doivent collaborer rgulirement et de
prfrence quotidiennement au projet.
5.
Le projet doit impliquer des personnes motives. Donnez-leur
l'environnement et le soutien dont elles ont besoin et faites leur confiance
quant au respect des objectifs.
6.
La mthode la plus efficace pour transmettre l'information est une
conversation en face face.
7. Lunit de mesure de la progression du projet est un logiciel fonctionnel
(ce qui exclut de comptabiliser les fonctions non formellement acheves).
8.
Les processus agiles promeuvent un rythme de dveloppement
soutenable (afin dviter la non qualit dcoulant de la fatigue).
9. Les processus agiles recommandent une attention continue l'excellence
technique et la qualit de la conception.
10. La simplicit et l'art de minimiser les tches parasites sont appliqus
comme principes essentiels.
11. Les quipes s'auto-organisent afin de faire merger les meilleures
architectures, spcifications et conceptions.
12. intervalle rgulier, l'quipe rflchit aux moyens de devenir plus efficace,
puis accorde et ajuste son processus de travail en consquence.
Une mthode qualifie d'agile doit donc se composer d'un ensemble de
pratiques instrumentant le cadre dcrit par les 12 principes gnraux agiles
et en consquence s'inscrire dans le respect des quatre valeurs fondamentales
ayant inspir le Manifeste agile.
Page 137
14.4.2.
lments cls de caractrisation de lAgilit en
entreprise
Les mthodes agiles doivent dsormais inspirer la majorit des projets mens
en entreprise. Elles ont un certain nombre de caractristiques identifies, qui
viennent conforter le manifeste Agile dans une utilisation plus large que les
dveloppements informatiques : les parties prenantes de lentreprise
(tat desprit, processus de dlgation...). Ces caractristiques sont
les suivantes :
14.4.2.1.
Des promesses
Lagilit est un concept trs la mode dans les entreprises car il semble tre
une rponse un grand nombre de problmatiques poses par la
transformation numrique, et la recherche accrue
de
performance
conomique. Elle est donc porteuse de nombreuses promesses
damlioration :
Page 138
Page 139
14.4.2.2.
valeur
Organisation oriente sur la co-cration de
Comme le mentionne le manifeste, lagilit est base en premier lieu sur des
valeurs de partage. Lentreprise trouvera un grand gain de performance et
dinnovation dans le travail commun
entre
les
diffrentes
parties
prenantes. Pour cela, plusieurs lments caractristiques cls peuvent
tre mis en avant :
Page 140
14.4.2.3.
Maturit culturelle de lentreprise et de ses
individus
La question de lagilit est galement une question culturelle. Il faut savoir
passer de la culture dentreprise traditionnelle pour saventurer sur ce nouveau
terrain, travers les valeurs suivantes :
Page 141
14.4.2.4.
Gouvernance adapte
Il ne faut pas confondre Agilit avec Anarchie . Dj, la premire erreur

serait de considrer que faire de lagile cote moins cher. Sil y a une promesse
de matrise des cots, il nempche que la transformation ncessaire
travailler de manire agile nest pas gratuite. Dailleurs, comme tout processus
dans lentreprise, lagilit repose sur une gouvernance adapte selon les
caractristiques suivantes :
Page 142
14.4.2.5.
Moyens, outils, processus et mthodes
La mise en uvre des principes agiles peut commencer par des ilots, et dans
ce cas ne requrir que des moyens limits. Mais pour tre intgrs dans
lensemble de lentreprise, un effort doit tre men en mettant en place des
outils et des processus adapts.
Page 143
14.5.
Les tapes de la transition d'une dmarche classique vers
une approche Agile
Ltude dopportunit de ladoption de lAgilit par une organisation est le
moyen idal pour sinitier en douceur au monde de lAgilit. Base sur lcoute
et lchange.
Lobjectif de cette tude nest pas de faire un audit projet, mais plutt
didentifier les pertes dnergie et les ventuels effets dinertie de lorganisation
projet, ainsi que didentifier de nouvelles pratiques plus efficaces.
Les tapes de cette phase sont les suivantes :
tat des lieux des pratiques en cours,
rdaction dun document de synthse sur lexistant,
adoption de pratiques adaptes au contexte de lentreprise,
rdaction et soutenance des pratiques retenues.
14.5.1.
tat des lieux
Cette tape se droule sous forme dentretiens et de sances de travail qui

visent tablir la cartographie des pratiques en cours auprs dun chantillon
de personnes intervenant sur tout le cycle de vie dun projet (matrise
douvrage, matrise duvre, cellule qualit, formateurs...).
Cette collecte dinformations est organise par type dactivit projet telles que
:
le recueil du besoin,
la gestion de projet,
le transfert de connaissances,
les spcifications logicielles (dossier danalyse),
la conception et limplmentation,
le test logiciel,
la qualit logicielle,
le dploiement et la mise en production.
14.5.2.
Rdaction dun document de synthse sur lexistant
Le document de synthse des interviews a pour but de mettre en vidence de

faon objective et anonyme les diffrentes remontes dinformations
effectues lors de ltape prcdente.
La synthse contient:
la description des primtres technique, fonctionnel et organisationnel
du projet ou du service, candidat lAgilit,
la description des rles et responsabilits de chaque personne
interviewe au sein de lorganisation projet ou service,
la description de ltat des lieux de chacune des activits prcdemment
cites,
la liste des acclrateurs ventuels ladoption de lAgilit,
lidentification des freins ventuels,
les incontournables manquants (pratiques indispensables et pourtant
absentes).
Page 144
14.5.3.
Adoption de nouvelles pratiques
Les pratiques identifies prcdemment sont synthtises dans un document

o :
les risques et incontournables manquants sont rappels avec les
pratiques Agiles associes,
les conditions dentre pour la mise en place de toutes les pratiques
sont identifies,
la description et le mode opratoire de chaque pratique sont dtaills,
les ventuels Artefacts produits par chaque pratique sont identifis,
les consquences et impacts sur lorganisation et les processus actuels
sont dcrits,
les attendus oprationnels de la pratique sont dcrits.
14.5.4.
Btir un modle de maturit
Le modle de maturit peut tre bti autour de cinq axes reprsentant les
lments fondamentaux qui permettent lentreprise dadopter une vraie
dmarche agile et den tirer les fruits.
Dans la suite du document, les axes sont dtaills, et des questions sont
rpertories pour chacun, visant identifier les points dvolution pour passer
dun niveau de maturit au niveau suprieur dans chaque dimension. Les
Page 145
pratiques sont alors donnes selon une chelle allant de 1 5 ; 1 dsignant

les pratiques les moins matures et 5 dsignant celles qui le sont le plus sur le
sujet de lagilit.
14.5.4.1.
Cration de Valeur
14.5.4.1.1.
DELIVERY AGILE, TIME TO MARKET
Votre entreprise prsente-t-elle une dmarche de Time To Market
et/ou de delivery Agile ?
14.5.4.1.2.
GESTION DU CYCLE DE VIE
Adaptez-vous le cycle de vie des produits en fonction de la valeur pour
le client ?
Page 146
14.5.4.1.3.
GESTION AGILE DU PORTEFEUILLE DES
PRODUITS
Comment grer vous votre portefeuille de projets / produits ?
14.5.4.1.4.
GESTION DES NOUVEAUTS ET DES
INNOVATIONSES
Comment grez-vous les nouveauts et les innovations ?
Page 147
14.5.4.1.5.
RELATION DE LA DSI AVEC LE SHADOW IT
Comment la DSI gre-t-elle la relation avec le Shadow IT ?
14.5.4.1.6.
INTELLIGENCE COLLECTIVE
Comment grez-vous la co-cration de valeurs avec vos mtiers ?
Page 148
14.5.4.2.
Architecture
14.5.4.2.1.
MODLE DARCHITECTURE
De quel modle darchitecture se rapproche le plus le systme
dinformation de votre entreprise/entit ?
14.5.4.2.2.
GESTION DU SYSTME DINFORMATION
Comment est gr votre systme dinformation ?
14.5.4.2.3.
MODLE DINFRASTRUCTURE
Quel est le modle dinfrastructure privilgi au sein de votre
entreprise/entit ?
Page 149
14.5.4.2.4.
DVELOPPEMENT, INTGRATION ET
LIVRAISON
Quels moyens de dveloppement / intgration sont majoritairement
utiliss dans votre entreprise/entit ?
14.5.4.3.
Organisation
14.5.4.3.1.
SPONSORSHIP DE LAGILIT
Avez-vous un sponsor pour votre dmarche agile ?
14.5.4.3.2.
NIVEAU DE RACTIVIT
Quel est le dlai moyen de mise en service dun produit ? Quelle est la
frquence de livraison dune nouvelle release volutive ?
Page 150
14.5.4.3.3.
PARTENARIATS ET SOURCING
Avez-vous mis en place des partenariats avec des start-ups ou des
acteurs du monde acadmique (coles, laboratoires de recherche) ?
14.5.4.3.4.
DCLOISONNEMENT DANS LENTREPRISE
Quel est le nombre de strates pour une dcision concernant le produit
?
Page 151
14.5.4.3.5.
RGLES DU MANIFESTE AGILE
Mettez-vous en pratique les rgles du manifeste Agile ?
Les individus et leurs interactions plus que les processus et les outils
;
Des logiciels oprationnels plus quune documentation exhaustive ;
La collaboration avec les clients plus que la ngociation contractuelle
;
Ladaptation au changement plus que le suivi dun plan.
14.5.4.4.
Comptences
14.5.4.4.1.
DVELOPPEMENT D'UN "FAIRE AGILE"
Quelles mthodes de suivi de projet sont utilises dans lentreprise ?
Page 152
14.5.4.4.2.
ORIENTATION L'EXCELLENCE
TECHNIQUE
Comment lentreprise favorise-t-elle lexcellence technique ?
14.5.4.4.3.
GESTION D'UNE FONCTION SI
PLUSIEURS VITESSES
Votre
entreprise
gre-t-elle
de
manire
diffrencie
projets/produits suivant leur type ?
les
14.5.4.4.4.
PROMOTION D'UN TAT D'ESPRIT AGILE
Votre entreprise promeut-elle un "tat d'esprit agile" ?
Page 153
14.5.4.4.5.
GESTION HUMAINE DES COMPTENCES
Votre entreprise gre-t-elle humainement les comptences ?
Page 154
14.5.4.5.
Culture
14.5.4.5.1.
PRISE DE RISQUE
Comment lentreprise prend-elle en compte la prise de risque et le
droit lerreur ?
14.5.4.5.2.
INNOVATION
Quelles pratiques dinnovation lentreprise met-elle en oeuvre ?
14.5.4.5.3.
FACTEUR HUMAIN
Quel est le niveau de prise en compte de lhumain dans les processus
de lentreprise ?
Page 155

Méthodes Agile

Transféré par

Droits d'auteur :

Formats disponibles

Méthodes Agile

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Méthodes Agile

Transféré par

Droits d'auteur :

Formats disponibles

SUPPORT DE FORMATION

Formation Mthodes Agile

Table des matires

Formation Mthodes Agile

4.2.3.4. Burn Up Chart ..................................................................................................... 47

Formation Mthodes Agile

Formation Mthodes Agile

12.1.2. Itration .................................................................................................................. 118

Formation Mthodes Agile

GESTION DES NOUVEAUTS ET DES INNOVATIONSES ........... 147

Formation Mthodes Agile

Les 4 phases du management de projets sont:

Formation Mthodes Agile

Logiciels Open source.

Formation Mthodes Agile

2. Concepts de gestion de projets

Produits, livrables, biens ou services, matriels ou immatriels, reconnus donc

Le management (ou la gestion) de projet est lapplication des connaissances,

Formation Mthodes Agile

Formation Mthodes Agile

Qu'est-ce qu'un projet?

Formation Mthodes Agile

L'quipe de projet, en tant qu'unit de travail, survit rarement au projet ;

Produits, services ou rsultats uniques

Formation Mthodes Agile

Le produit d'un projet de dveloppement conomique peut initialement

dveloppement d'un produit ou d'un service nouveau,

Formation Mthodes Agile

management de projet comprend les points suivants:

Les chefs de projet parlent souvent de triple contrainte (contenu du projet,

Formation Mthodes Agile

rpondre des incertitudes. Le risque d'un projet est un vnement ou une

Formation Mthodes Agile

Le PMI, dans son PMBOK (Project Management Body of Knowledge), recense et

Management des dlais du

Squencement des activits

Estimation des ressources

Formation Mthodes Agile

Management des risques

Analyse qualitative des

Formation Mthodes Agile

Management des ressources

7.1 Planifier le management

Recueillir les exigences

Estimer les cots

9.4 Diriger lquipe de projet

9.1 Planifier le management des

12.1 Planifier le management

Estimer les ressources

13.2 Planifier le management

Dfinir les activits

10.1 Planifier le management

6.1 Planifier le management de

Identifier les risques

11.3 Mettre en oeuvre lanalyse

11.4 Mettre en oeuvre lanalyse

Formation Mthodes Agile

Matriser les cots

Matriser les risques