Livre Blanc Methodes Agiles PDF

transition vers lagilit
lchelle dune organisation
deuxime edition - 2012
Avant-propos
Prsent linternational, Valtech est un groupe pionnier et leader dans le domaine
de lAgilit, des technologies, et du digital. Avec 1 500 collaborateurs, Valtech
accompagne et forme ses clients en mode Agile dans la conception, la ralisation et
loptimisation de projets et de plateformes digitales critiques pour leur croissance.
Sappuyant sur une expertise technologique reconnue, Valtech propose une vision
novatrice et une mise en uvre intgre sur toute la chane de valeur digitale avec
pour finalit lacclration du Time to Market , laccroissement des revenus et
du retour sur investissement pour ses clients.
3
Cr en 1993 et cot sur lEurolist dEuronext, Valtech est prsent dans 8 pays
(France, Royaume-Uni, Allemagne, Sude, Danemark, Etats-Unis, Inde et Core)
avec des nombreuses rfrences de mise en oeuvre de lAgilit, telles que : APEC,
AFPA, Banque de France, Club Med, Crdit Agricole, Dassault Aviation, EDF,
Mappy, Orange, Pernod Ricard, RTE, Socit Gnrale, Taliance, Thales ...
remerciements
Ce livre blanc est le fruit de la collaboration de la communaut Agile de Valtech.
Cette nouvelle mouture enrichit ldition 2008 avec de nombreux retours
dexprience lchelle dorganisations compltes. Elle tmoigne de lenvie
permanente des consultants de Valtech de partager leur expertise et leur savoirfaire sur les mthodes Agiles.
STEPHANE LABATI
4
// Responsable de loffre Agile

// Valtech
Merci en particulier Etienne Charignon, Hlne Granboulan, Nathalie LopezSaussier, Thomas Beaugrand, Hubert Gillon, Elisabeth Ducarre, Stphane Labati,
Patrick Le Go, Parijat Sinha, Craig Larman, Jean-Claude Grosjean et Laurent
Moulager, qui ont partag leurs retours dexprience Agiles dans les domaines
aussi varis que les pratiques dingnierie, la gestion des exigences, les tests,
le pilotage de projet, la conduite du changement et ses facteurs humains, la
contractualisation Agile, la qualit logicielle, le lean, la conformit aux standards,
loffshore, lExprience Utilisateur ou la cration graphique.
Lquipe ditoriale remercie galement tous les relecteurs qui, forts de leurs
propres expriences, ont largement contribu amliorer la qualit de ce livre
blanc.
Enfin, Valtech remercie ses clients qui lui ont fait confiance en lassociant leurs
dfis, renforant jour aprs jour son expertise et sa capacit les aider dans
ladoption de lAgilit.
sommaire
sommaire
SOMMAIRE
1.
2.
3.
Les mthodes Agiles pour les nuls
11
4.
La transformation vers lAgilit
61
1.1. Pourquoi adopter les mthodes Agiles ?
12
4.1. Enjeux et motivations
62
1.2. Qui est concern ?
14
4.2. Le projet de transformation
63
1.3. Quelles sont les pratiques Agiles les plus rpandues ?
15
4.3. Dfinir le projet: le cadrage
64
4.4. Experimenter : Le pilote
70
4.5. Transformer : Dploiement et optimisation en continu
74
Les difficults surmonter
81
LAgilit par la pratique
19
2.1. Tmoignage dun coach Agile Valtech
20
2.2. tude dopportunit
22
2.3. Recueil des besoins dans le Product Backlog
25
5.1. Les difficults couramment rencontres
82
2.4. Test Driven Requirement: la spcification par lexemple
28
5.2. La gestion du stress dans les quipes Agiles
84
2.5. TDD, le dveloppement sous contrle
32
5.3. La contractualisation Agile
86
2.6. Suivi et pilotage avec lIteration Backlog
34
5.4. Lexternalisation Agile
90
2.7. Retour dexprience sur la gestion de projet
36
5.5. LAgilit face aux autres standards
2.8. Retour dexprience sur lautomatisation des tests
40
5.6. Mettre de lAgilit dans une dmarche CMMI
2.9. Rsultats obtenus sur des projets raliss par Valtech
43
Le marketing digital Agile
45
3.1. La vision du produit
47
3.2. Personas, vous avez dit Personas?
48
3.3. La dmarche crative
49
3.4. Agilit et Exprience Utilisateur
56
5.
97

98
7
6.
7.
Glossaire des pratiques Agiles
105
6.1. Dfinitions
106
6.2. Abrviations
108
Rfrences bibliographiques
109
sommaire
sommaire
SOMMAIRE
Table des figures
Table des tableaux
Figure 1
Exemple de Burndown Chart
16
Tableau 1
TDR - Donnes initiales
29
Figure 2
Prsentation schmatique du processus de dveloppement

Agile bas sur Scrum
17
Tableau 2
TDR - Affaire versus Convention
30
Tableau 3
Exemple de pratiques dingnierie et de pilotage de projet
24
TDR - Affaire versus Convention
30
Figure 3
Tableau 4
Exemple de Product Backlog
26
TDR - Validation de convention
30
Figure 4
Tableau 5
Gestion des priorits et de la complexit dans le Product

Backlog
27
Contexte projet
36
Figure 5
Tableau 6
Dveloppement de la vision
65
Figure 6
Exemple de Burndown Chart
35
Tableau 7
Les cls de la transformation Agile
68
Figure 7
Planning dtaill dune itration
37
Tableau 8
Critres de slection dun projet pilote
71
Figure 8
Planning dtaill dune semaine
37
Tableau 9
Dispositif daccompagnement pour un projet
72
Figure 9
Planning dtaill dune journe
38
Tableau 10
Ordre dintroduction des pratiques Agiles
73
Figure 10
Exemple de Persona
48
Tableau 11
Dispositif daccompagnement
75
FIGURE 11
Les tapes dune transformation Agile
63
Tableau 12
110
Figure 12
Une quipe de projet en relation avec son cosystme
65
FIGURE 13
Laccompagnement dans la transformation Agile
72
FIGURE 14
Mesure de maturit Agile
73
Figure 15
Le plan de dploiement
74
Figure 16
Tableau de Scrum avec les diffrents types dhistoires

utilisateur
92
Figure 17
Product Owner en train dexpliquer les nuances des

fonctionnalits lquipe
94
Figure 18
Accueil dun membre de lquipe onshore par ses

homologues offshore Bangalore
95
Figure 19
Espace de travail ouvert entour de tableaux blancs
96
Figure 20
Cycle de Deming PDCA (Plan, Do, Check, Act)
98
Figure 21
Les pratiques Agiles issues de XP et Scrum
106
1
Les mthodes Agiles
pour les nuls
11
10
Ou en quoi consistent les mthodes Agiles

et pourquoi les adopter
Pourquoi adopter
les mthodes Agiles ?
Les mthodes Agiles consistent en un ensemble de pratiques
imagines pour pallier les difficults rencontres dans les cycles
de dveloppement en cascade ou en V, encore omniprsentes.
Les mthodes traditionnelles prnent un enchanement squentiel des
diffrentes activits, depuis les spcifications jusqu la validation du systme,
selon un planning prtabli. Elles visent mieux prdire la faon dont les choses
devraient se passer.Malheureusement, cette vision rassurante est bien loin
de la ralit des projets. Les activits dingnierie ne sauraient se succder
strictement sans quaucun changement ne vienne perturber un planning qui na
de dure de vie que le temps de le prononcer.
1. Les mthodes Agiles pour les nuls
1.1
A contrario, les mthodes Agiles prconisent:
Ladoption dun cycle

itratif et incrmental
Limplication du client
La dfinition dobjectifs
court terme
permettant
une
quipe de sadapter au
contexte ainsi quaux
changements qui ne
manquent
pas
de
survenir au cours dun
projet.
dans le dveloppement,
permettant au client et
lutilisateur de donner
leur feedback quant au
devenir de lapplication en
cours de dveloppement,
annulant ainsi tout effet
tunnel .
qui permet de maintenir

une pression constante
mais supportable sur
lquipe, alors quau
dbut dun cycle en V
chacun a limpression
davoir suffisamment de
temps devant lui et subit
finalement une pression
norme lapproche de
la livraison.
La consquenceest que plus de 80% des projets excuts selon ces mthodologies
connaissent des retards, des dpassements budgtaires, quand ils ne finissent pas
en chec total, pour navoir pas su satisfaire les attentes des clients.
Ces problmes sont lis plusieurs caractristiques fondamentales de ces

anciennes mthodologies:
aa
12
aa
aa
aa
le rle jou par le client: le client intervient principalement au moment

du lancement du projet, quelques jalons majeurs parfois espacs de
plusieurs mois, et surtout en fin de projet pour la rception et la recette du
systme. Cet effet tunnel conduit une solution souvent inadapte et de
pitre qualit.
le mode contractuel forfaitairequi:
durcit les relations entre client et fournisseur,

rend le passage de tmoin long et douloureux la fin du projet.
une trop grande standardisation des activits dingnierie, dont
lenchanement se rvle souvent inefficace. Formellement, les contrles
davancement et de qualit ne peuvent tre mens que sur la base de
documents dans les premires tapes, et bien des organisations sont
devenues des usines produire de la documentation au lieu de produire de
la valeur (fonctions logicielles) pour les clients et les utilisateurs.
le passage de relai entre les phases successives dans lesquelles uvrent
des quipes diffrentes, gnralise une relation de type client-fournisseur
et nencourage ni lempathie ni lesprit dquipe, bien au contraire. Chaque
transition se traduit par une perte de temps, de savoir, dinformations ou de
responsabilit.
La collaboration
entre les personnes
et lintgration des
quipes
qui combat les fameux
passages
de
relais
en rassemblant dans
un
mme
espace
toutes
les
nergies
et la comptence de
personnes centres sur
lapplication raliser.
Plus aucune barrire
et des tches dfinies
par lquipe au meilleur
moment,
cest--dire
quand on en a besoin,
plutt quau dbut du
projet.
La livraison dun
produit oprationnel
1313
de bonne qualit parce
que souvent test, dot de
la seule documentation
strictement ncessaire,
et rpondant coup sr
aux vrais besoins des
utilisateurs puisquil est
rgulirement soumis
leur feedback.
Hubert gillon
Qui est concern ?
Les pratiques Agiles les plus rpandues sont issues de ces diffrentes mthodes:
Le Manifeste Agile propose 4 principes fondamentaux :
Priorit donne aux personnes

et aux interactions
Priorit donne
la production de fonctions
plutt quau processus et aux outils
plutt qu la documentation
Priorit donne
la collaboration avec le client
Priorit donnE ladaptabilit

et laccueil dventuels
changements
plutt qu la ngociation
contractuelle
plutt quau suivi dun plan originel
Forts de ces principes, on voit quune organisation, un dpartement, une business

unit, un projet et mme une quipe peuvent adopter lAgilit avec succs.
14
Mais quen est-il dun projet dj dmarr ou en difficult ? LAgilit peut galement
dans ce cas amliorer les rsultats dj obtenus et faciliter la rsolution de bon
nombre des difficults vcues. Elle va amener les personnes impliques :
aa
aa
aa
aa
aa
aa
aa
aa
aa
aa
aa
mieux collaborer,
prendre du recul sur lapplication en priorisant les actions et en remettant
plat le chiffrage initial,
donner plus de visibilit aux clients et utilisateurs,
liminer leffet tunnel induit par le cycle en V, en le remplaant par des
itrations courtes et matrises.
hubert gillon
// Delivery Manager
// Valtech
Quelles sont les pratiques Agiles les

plus rpandues ?
Il existe de nombreuses mthodes Agiles (XP, Crystal, FDD, Scrum...pour les plus
connues) fondes sur les principes voqus ci-dessus. Chaque mthode apporte son
propre lot de techniques et de pratiques, les unes concernant plutt le pilotage de
projet, les autres, plutt lingnierie.
// Delivery Manager
// Valtech
1.2
1.3
Le succs des projets Agiles renforce jour aprs jour lengouement des DSI et des
quipes informatiques pour des pratiques remettant lapplication et lhomme au
centre du sujet. Un projet nest-il pas dabord une aventure humaine vcue par des
hommes pour dautres hommes ?
Lidal serait que toute lorganisation ait conscience de lintrt de fonctionner

diffremment et quelle mette dans sa stratgie ladoption dun ou plusieurs
des principes Agiles.
aa
aa
aa
aa
limplication forte du client travers le rle de Product Owner,

lutilisation dun Product Backlog pour grer dynamiquement les fonctions du
produit raliser, et les priorits mtier associes; le Product Backlog est
labor en dbut de projet, et rvis autant que ncessaire,
le Scrum Meeting, est une courte runion quotidienne (environ 15) qui
rassemble tous les membres de lquipe de dveloppement. Cette runion
permet aux personnes dchanger des informations sur lavancement des
tches, signaler les problmes rencontrs et demander de laide si ncessaire,
le Retrospective Meeting est une runion de fin ditration, focalise sur les
vnements survenus et lanalyse causale des dysfonctionnements, des pertes
de productivit et de qualit. Un ou deux axes damlioration seront privilgis
de faon consensuelle et se traduiront par des tches dans le backlog de
litration suivante,
lIteration Planning, en dbut ditration, permet lensemble de lquipe
projet de dcouvrir la liste des fonctions implmenter, didentifier et
destimer les tches de ralisation,
la Vlocit est un indicateur qui mesure le volume de logiciel produit par
lquipe au cours dune itration. Ce volume est estim pralablement pour
chaque fonction (ou User Story),
le Burndown Chart est une reprsentation graphique de lavancement des
travaux au cours dune itration: la courbe reprsente simplement le reste
faire (en charge) tel quil est estim chaque jour par lquipe. Le point initial
reprsente leffort total estim pour litration pour lensemble de lquipe,
gnralement en heures,
lIntgration Continue consiste compiler, assembler, vrifier et tester
lensemble du code source ds quun nouvel lment est mis disposition,
soit, idalement, une plusieurs fois par jour,
le Test Driven Development (TDD) consiste crire les programmes de tests
unitaires avant de programmer les fonctions elles-mmes, puis dadapter
le code source test unitairement jusqu obtenir un code de qualit
(Refactoring),
le Test Driven Requirement (TDR) permet de spcifier le logiciel par lexemple
i.e. les exigences logicielles sont exprimes sous forme de cas de test,
enfin le Pair Programming consiste programmer en binme dans le but dtre
plus efficace en termes de conception, de revue de code et de transfert de
comptences.
15
400
100
350
60
200
10
DEC
11
DEC
14
DEC
15
DEC
16
DEC
17
DEC
18
DEC
21
DEC
EFFORT BURNDOWN
TARGET BURNDOWN
COMPLETED TASKS %
Exemple de Burndown Chart (Source Valtech)
Lessentiel retenir
SPRINT BACKLOG
figure 1
>> Les mthodes Agiles mettent laccent sur limportance de dvelopper

le bon produit.
4 principes fondamentaux :
PRODUCT BACKLOG
>> LAgilit prne la collaboration entre les personnes et lintgration

des quipes.
>> priorit aux personnes et aux interactions,
>> accueil et adaptation au changement.
Scrum Team
>> priorit la collaboration avec le client,
Scrum Master
>> priorit au dveloppement des fonctions,

Customer
Product Owner
16
RELEASE PLANNING
MEETING
>> Les mthodes Agiles prconisent ladoption dun cycle itratif et

incrmental.
Prsentation schmatique du processus de dveloppement Agile bas sur Scrum (Source Valtech)
DEC
Figure 2
DEC
Sprint
14-30 days
DEC
Workday
One day
20
50
DAILY STATUS MEETING

(DAILY SCRUM)
100
COMPLETED TASKS %
40
150
WORKING SOFTWARE
OTHER DELIVERABLES
250
SPRINT DEMO AND

REVIEW MEETING
80
300
SPRINT PLANNING
MEETING
REMAINING WORKING HOURS
SPRINT #03 BURNDOWN
17
2
LAgilit
PAR la pratique
19
18
Ou le retour dexprience de Valtech
Tmoignage dun
coach Agile Valtech
Agile, cest pratique !
LAgilit peut tre vraiment applique au quotidien loccasion de la ralisation de
projets informatiques. Ce nest pas un doux rve inatteignable et dans bien des cas,
cest mme assez facile.
Etienne Charignon
Les sceptiques vous diront peut-tre que lAgilit nest quun concept, un rve
loign des ralits concrtes rencontres au quotidien. Nentendons-nous pas
souvent des Oui, mais chez nous, a nest pas possible !, ou des Oui, mais
dans la vraie vie, ce nest pas comme a ! ? Ah, oui, mais pourtant, jexiste ! Avant
de trouver des projets officiellement Agiles, jai fait pendant assez longtemps du
dveloppement logiciel Agile en sous-marin et, les pratiques que jai pu mettre
en place ont toujours apport normment au projet, voire le succs.
// Consultant senior
// Certified Scrum Master
// Valtech
Les pratiques comme le TDD (Dveloppement pilot par les tests : voir en annexe)
ou les tests de recette automatiss sont faciles mettre en place condition quon
veuille bien sen donner la peine.
La qualit est gratuite condition que lon veuille bien en payer le prix. Les pratiques
que vous voudrez mettre en place feront gagner du temps sur le long terme, mais
coteront quelque chose au dbut.
Mais le travail de spcification ne sarrte pas l. Au dbut de chaque itration,

nous choisissons les scnarios qui doivent tre raliss pendant litration
et en dfinissons les critres dacceptation. Cest de cette manire que nous
dtaillons les spcifications. Pour viter le gaspillage, les dtails ne sont pas
prvus entirement lavance (pas de stock), mais seulement au moment o les
dveloppeurs sont prts les recevoir.
Etienne Charignon
// Valtech
Ce flux tendu de spcification constitue

la sve du processus Agile .
War room
La premire chose faire est de runir les gens dans un mme lieu, ddi au
projet. La mise en place dautres pratiques sen trouve grandement favorise:
aa
aa
pour suivre le projet, on utilise les post-it sur les murs,

pour faciliter le travail en binme et la proprit collective du code, il est
prfrable davoir un ensemble dordinateurs non affects individuellement,
mais ddis un type de tche : dveloppement, bureautique... De plus, il
est indispensable que les postes de dveloppement soient homognes.
Ds que vous aurez mis en place tous ces lments, vous aurez votre war
room. Il est vident quil est plus difficile de le faire lorsque les dveloppeurs
sont parpills dans un open space.
Serveur dintgration continue
20
Spcifications incrmentales et TDR

Comme on pourrait sy attendre, les pratiques de dveloppement sont bien plus
simples mettre en place que celles qui font intervenir le client. Pour le faire lors dun projet sur lequel nous travaillons actuellement - nous avons planifi une
itration zro de mise en route dune semaine, durant laquelle nous avons entre
autres dfini la liste des scnarios dutilisation mais aussi mis en place FitNesse, un
outil de TDR (Test Driven Requirement) bas sur un wiki. Nous avons conseill au
client de ne plus dtailler toutes ses exigences fonctionnelles avant de dmarrer
les dveloppements. A la place, nous lui avons demand la liste des scnarios
dutilisation (le Product Backlog). Puis, pour chaque scnario, il a attribu une
valeur mtier note entre 1 et 3. Nous en avons alors estim la difficult technique
note de 1 13 suivant la suite de Fibonacci. Un tel Product Backlog est ensuite
plus facile manipuler que directement une spcification dtaille.
2. lAgilit PAR la pratique
2.1
Votre war room peut contenir une machine ddie lintgration continue, car
il est assez facile de librer une machine pour la ddier cette activit tant donn
que les dveloppeurs travaillent chaque fois que ncessaire en binme.
En quelques minutes, vous installez un logiciel comme Hudson ou CruiseControl.
Ce type de logiciel est capable daller lui-mme chercher le code source dans
le dpt de votre systme de gestion de version (par exemple Subversion ou
ClearCase), de le compiler et dexcuter une srie de tests et de mesures de
qualit avec des outils tels que CheckStyle ou Cobertura.
Il reste ensuite astreindre plusieurs fois par jours les dveloppeurs poster leur
travail sur le dpt central (commit du code dans loutil de gestion des sources).
21
tude dopportunit
La synthse contient:
aa
aa
aa
aa
aa
aa
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,
cette tude permet dapporter une solution personnalise et adapte aux attentes
et besoins du client.
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 tude sont les suivantes :
aa
aa
aa
aa
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).
Ce document sert de base une nouvelle sance de travail au cours de laquelle les
freins et incontournables manquants sont analyss en dtail. A ce stade, dautres
sances de travail plus cibles sont ralises pour identifier les pratiques les plus
utiles, en sappuyant sur un catalogue de pratiques Agiles.
rdaction dun document de synthse sur lexistant,

adoption de pratiques adaptes au contexte du client,
rdaction et soutenance des pratiques retenues.
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 :
22
la description des rles et responsabilits de chaque personne interviewe

au sein de lorganisation projet ou service,
tat des lieux des pratiques en cours,
tat des lieux des pratiques en cours
aa
aa
aa
aa
aa
aa
aa
aa
la description des primtres technique, fonctionnel et organisationnel du

projet ou du service, candidat lAgilit,
2.2
le recueil du besoin,
Il est important de prsenter les pratiques pressenties lensemble des acteurs

et de les dcrire. Mais il faut galement discuter des impacts possibles sur
lorganisation afin quun sous-ensemble de pratiques puisse tre retenu par le
client.
nathalie lopez-saussier
//Directeur Gnral Adjoint
// Valtech Technology
Adoption de nouvelles pratiques
la gestion de projet,
Les pratiques identifies prcdemment sont synthtises dans un document o :
le transfert de connaissances,
aa
aa
aa
aa
aa
aa
les spcifications logicielles (dossier danalyse),

la conception et limplmentation,
le test logiciel,
la qualit logicielle,
le dploiement et la mise en production.
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.
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.
23
>> Lobjectif de ltude dopportunit est didentifier les pertes dnergies,

les ventuels effets dinertie dune organisation projet ou dun service
ainsi que de nouvelles pratiques plus efficaces et plus Agiles.
Lessentiel retenir
>> Ltude dopportunit est base sur des interviews et des workshops
qui permettent de dfinir la cartographie des pratiques en cours. Cette
tude permet ensuite didentifier les freins ladoption de lAgilit, les
incontournables manquants et les pratiques Agiles les plus utiles.
>> Un plan daction et une proposition de planning finalisent ltude
dopportunit.
2.3
Figure 3
Exemple de pratiques dingnierie et de pilotage de projet (Source : Valtech)
Rdaction dun document de synthse sur les pratiques retenues
24
Valtech produit le document final de ltude synthtisant les attendus du client,

la dmarche, et enfin les pratiques retenues. Un plan daction et une proposition
de planning finalisent le document qui est prsent lensemble des acteurs
impliqus dans ltude.
A lissue de la soutenance, Valtech propose au client, au choix :
aa
aa
aa
Recueil des besoins

dans le Product Backlog
une prestation de production dArtefacts issus des pratiques Agiles retenues,

une mission daccompagnement dans la mise en uvre des nouvelles
pratiques Agiles sur le projet,
une formation lAgilit.
Le manque de visibilit sur le contenu final probable dun logiciel est prjudiciable
au client mais galement aux quipes projet.
Le Product Backlog contient cette description et permet entre autres :
aa
aa
aa
aa
aa
davoir une vision commune sur lensemble des fonctions ou cas dutilisation
dfinissant le primtre du logiciel dvelopper,
de comprendre lintrt et les enjeux des dveloppements pour les
utilisateurs (appels galement acteurs),
destimer lavancement du projet sur la base des fonctions ou cas
dutilisation livrs au client,
de raliser facilement des macro-estimations en utilisant, par exemple, la
mthode des Use Case points,
de prparer lidentification des tches du projet en les organisant autour des
fonctions ou des cas dutilisation.
Un Product Backlog a t labor, par exemple, chez un de nos clients dans le

domaine de lassurance, pour formaliser de faon synthtique lensemble des
fonctions attendues par les courtiers, et pour estimer la charge de ralisation de
lapplication.
La figure suivante prsente un extrait du tableau obtenu aprs deux jours de travail
avec la matrise douvrage et la matrise duvre, ainsi quavec deux courtiers en
assurance, futurs utilisateurs de lapplication.
25
Capa.
C1
C2
Figure 4
Functional
Capabilities
Quotation
management
(Lot 1)
Date import
(Lot 2)
FEATURES
FEATURES
Actors
Feat.
Features
Actors
Quotation creation from scratch
User
F1-1
Quotation creation from scratch
User
F1-2
Quotation creation from an existing

version of quotation (same year)
User
F1-2
User
F1-3
Quotation creation from an existing

version of quotation (previous year)
User
Quotation creation from

an existing version of
quotation (same year)
F1-4
Quotation creation from a Petrus Program
User
F1-3
User
F2-1
Select fields to import from loss files
User

an existing version of
quotation (previous year)
F2-2
Import Loss with developments - vertical
User
F1-4

a Petrus Program
User
F2-3
Import Loss with developments - horizontal
User
F2-1
F2-4
User
Select fields to import

from loss files
User
Import Loss files without

developments - vertical
F2-5
Import the LDFs
User
F2-2
Import Loss with

User
F2-6
Import the indexes from the

index database -European
User
F2-3
Import Loss with

developments - horizontal
User
F2-7
Import the indexes from the index database -US
User
F2-4
Import Loss files without

User
Lot
Feat.
F1-1
Features
Exemple de Product Backlog (Source : Valtech)
Figure 5
Les fonctionnalits de haut niveau (Functional Capabilities) de la future application

sont des regroupements de fonctions (User Features). Chaque fonction est
identifie de faon unique pour pouvoir ensuite tre facilement rfrence. Un type
dutilisateur est attribu chaque fonction.
Une fois ce premier travail ralis, une priorit de dveloppement a t dtermine

et affecte chaque fonction. Elle est calcule partir des estimations de
complexit et de valeur mtier (classes en High , Medium and Low ).
Cette dmarche permet de limiter les risques en traitant en priorit les fonctions
les plus complexes, et en majorant le ROI(Return on Investment), en livrant dabord
les fonctions apportant le plus de valeur aux utilisateurs. Lextrait du tableau
suivant donne une ide du rsultat.
Complexity
Priority
UCP
Medium
10
Medium
10
Medium
15
Gestion des priorits et de la complexit dans le Product Backlog

(Source : Valtech)
Un nombre de Use Case Points (UCP) a t attribu aux fonctions en raison de leur
complexit, ceci afin de servir de base une estimation globale du projet.
A la fin de cet exercice, les fonctionnalits de haut niveau sont groupes en lots de
livraison.
26
PRIORITY
Business
Value
CAPABILITIES
Finalement, nous avons t capables, en moins de 5 jours, de dcrire les besoins

client sous la forme dun Product Backlog, didentifier lensemble des acteurs au
sens UML, de dfinir les priorits dimplmentation, destimer la complexit des
cas dutilisation et de chiffrer le projet dont la taille reprsentait 3.000 hommes.
jours.
Hlne Granboulan
// Analyste senior
// Valtech
Lessentiel retenir
>> Le manque de visibilit sur le contenu final probable dun logiciel est
prjudiciable au client mais galement aux quipes projet.
>> Lutilisation du Product Backlog se rvle trs efficace condition
den matriser les concepts et de disposer des personnes
comptentes et habilites prendre les dcisions impactant le futur
projet.
27
Test Driven Requirement:

la spcification par lexemple
Le Test Driven Requirement (TDR) est fond sur le constat que dans bien des
cas, il est plus efficace dexpliquer un comportement en dcrivant des exemples,
plutt quen ralisant une spcification classique qui dcrit les mcanismes
implmenter.
Le Test Driven Requirement, ou spcification dirige par les tests, propose :
aa
aa
de centrer la description et la rdaction des besoins utilisateurs sur des

exemples qui constitueront autant de futurs cas de tests de validation,
de centrer la collaboration entre les quipes du projet sur la comprhension
et lenrichissement de ces exemples.
Le contexte documentaire et collaboratif

Pour un des leaders de services en ressources humaines, Valtech a mis en place la
pratique TDR pour un logiciel de gestion qui avait t spcifi en UML. La stratgie
de dveloppement avait t axe sur lefficacit court terme plutt que sur la
maintenabilit. Les activits de projet taient confies des quipes distinctes
(dveloppement / homologation / analyse-gestion de projet / MOA).
Aprs 6 mois dexploitation, le client a formul les remarques suivantes:
Les fonctions majeures du logiciel taient oprationnelles.
Chaque quipe disposait de ses propres documents, relatifs son activit,
sans les partager avec les autres quipes.
28
Les volutions apportes aprs la mise en production taient ralises

sans tre spcifies, engendrant un manque de visibilit sur le contenu
fonctionnel rel du logiciel et rendant difficile lintgration de nouveaux
besoins.
Le primtre de test dduit des spcifications tait incohrent avec les
fonctionnalits dj implmentes.
Lhomologation tait de moins en moins souvent ralise du fait de la
difficult produire les cas de tests, conduisant ainsi une baisse de
qualit.
La grande autonomie de chaque quipe se faisait au dtriment de la
communication.
Cest dans un tel contexte que Valtech a mis en place la pratique du TDR.
Les enjeux du client

Compte tenu du constat ralis pour parvenir matriser les volutions logicielles,
il a t dcid de modifier les pratiques de spcifications.
2.4
Valtech a amen le client privilgier la description concrte plutt que la

modlisation en incluant des exemples tels que ceux prsents ci-aprs.
Exemple de spcification TDR

Contexte de lvolution
Il sagit de modifier le cycle de vie dune affaire afin de mettre jour son tat
lorsquune convention est cre, sans tre valide.
Jusqu prsent, cest seulement lorsque la convention est valide que ltat de
laffaire est mis jour.
N.B. Une affaire est une opportunit commerciale dtecte pour un compte donn,
mais naboutissant pas immdiatement la signature dune convention avec ce
compte. Lorsque lopportunit commerciale se concrtise, laffaire est transforme
en convention. La convention est dfinitive partir du moment o elle est valide.
Cette volution met donc en vidence la fois le cycle de vie des affaires, celui des
conventions et celui des comptes.
Les donnes initiales

Les Comptes et Affaires suivants ont t crs :
COMPTES
Nom du Compte
Matricule
Responsable
Entit
Responsable
tat du Compte
Identifiant
du Compte
BONJOUR
0001
E1
1 (prospect
sur affaire)
COMPT 01
Nom de lAffaire
Matricule
Responsable
Identifiant
du Compte
tat du Compte
Commentaire
Affaire A
0002
COMPT 01
1 (ouverte)
Null
AFFAIRES
tableau 1
TDR - Donnes initiales (Source : Valtech)
Laffaire est cre dans ltat par dfaut Ouverte tandis que le compte est cr
dans ltat Prospect sur affaire.
29
Laction consiste pour le responsable (matricule 0002 li laffaire A) transformer

laffaire A en convention.
AFFAIRES RSULTAT
Nom de lAffaire
Matricule
responsable
Entit
responsable
tat du compte
Identifiant du
Compte
Affaire A
0002
E1
2 (ferme)
Transforme
en convention
tableau 2
TDR - Affaire versus Convention (Source : Valtech)
Laffaire est ferme car transforme en convention. Elle ne peut plus tre utilise
pour crer une convention.
COMPTES RSULTAT
Nom du Compte
Matricule
Responsable
BONJOUR
Entit
Responsable
tat du Compte
Identifiant du
Compte
E1
1 (prospect
sur affaire)
COMPT 01
0001
Nom de la Convention
Matricule
Responsable
tat du Contrat
Nom de lAffaire
Convention issue de lAffaire A
0002
4 (brouillon)
Affaire A
Valider une convention

Laction consiste pour le responsable (matricule 0002) valider la convention.
COMPTES RSULTAT
Nom du Compte
Matricule
Responsable
Entit
Responsable
tat du
Compte
Identifiant
du Compte
BONJOUR
0001
E1
2 (client)
COMPT 01
CONVENTIONS - RSULTAT
Nom de la Convention
Matricule
Responsable
tat du
Contrat
Nom de lAffaire
Convention issue de lAffaire A
0002
1 (en cours)
Affaire A
tableau 4
le passage de la convention de ltat brouillon en cours.
Une double nouveaut :

collaboration et format des exigences
Dornavant, la description des fonctionnalits est affine de faon collaborative
tout au long du processus de dveloppement :
aa
aa
aa
aa
aa
TDR - Affaire versus Convention (Source : Valtech)
La convention nest pas encore valide do sa cration dans ltat brouillon.

Ltat du compte reste inchang.
30
le changement dtat du compte qui passe de prospect sur affaire

client,
initiation par la MOA,

enrichissement par les analystes,
mise jour au fil des remarques des quipes de dveloppement et
dhomologation.
Cette description sappuie sur des cas dexemples qui sont :
CONVENTIONS - RSULTAT
tableau 3
aa
aa
La validation de la convention entrane donc :
Transformer une affaire en convention
TDR - Validation de convention (Source : Valtech)
les cas de tests des scnarios standards par la MOA,

les cas de tests des scnarios dexception (sans viser lexhaustivit mais
plutt la vraisemblance) par lhomologation.
Les tableaux utiliss pas pas dans notre exemple, suite diffrentes actions
oprateur, permettent de visualiser concrtement les changements dtat
successifs. Ils facilitent la fois la comprhension du fonctionnel mais galement
lidentification des scnarios de test les plus pertinents.
Finalement, lensemble des quipes projet a adhr la nouvelle approche TDR.
Cette adhsion a t favorise par le fait que les cas de tests dcrits sous forme de
tableaux taient lisibles par des non-informaticiens.
Une exprience riche denseignements

Pour en faciliter lappropriation par les quipes, la mthode TDR a t introduite
progressivement sans la nommer, en incluant des exemples dans les spcifications
existantes.
La dmarche TDR est lorigine des avances suivantes :
aa
Lquipe de dveloppement a pris le rflexe denrichir les exemples fournis

dans la spcification TDR. Ces exemples ont t utiliss en intgration
continue et en homologation.
31
Hlne Granboulan
// Analyste senior
// Valtech
Une grande partie des ambiguts dans la description des rgles mtier est
dsormais leve avant le dbut des dveloppements.
Le besoin se stabilise de plus en plus tt dans le cycle de cration dune
fonctionnalit.
Les erreurs de description ou dimplmentation sont dtectes plus tt et
sont donc plus faciles rsoudre.
Lhomologation se droule dsormais normalement.
La formalisation des spcifications selon lapproche TDR permet de produire

facilement des spcifications excutables. Coupl un outil tel que FIT,
FitNesse ou GreenPepper, chaque exemple devient ainsi un cas de test
automatique.
Lessentiel retenir
Le Test Driven Requirement (TDR) propose de :
>> centrer la description et la rdaction des besoins utilisateurs sur des
exemples,
>> centrer la collaboration entre les quipes du projet sur la
comprhension et lenrichissement de ces exemples,
>> privilgier la description concrte plutt que la modlisation dans une
dmarche TDR,
>> affiner la description des fonctionnalits de faon collaborative tout
au long du processus de dveloppement,
>> utiliser les tableaux pas pas, suite diffrentes actions oprateur,
permet de visualiser concrtement les changements dtat
successifs. Ils facilitent la fois la comprhension du fonctionnel mais
galement lidentification des scnarii de tests les plus pertinents.
32
Le projet de 3 hommes.an dont il sagit concerne le dveloppement dune

application Java stand alone avec une interface Swing et diverses autres parties
crites en C++.
Enjeux client
Lobjectif du client consiste amliorer la qualit et la scurit des applications
sans augmenter les cots de dveloppement.
Pratiques mises en uvre

Valtech a aid le client mettre en place :
aa
aa
une approche de dveloppement dirige par les tests (TDD),

une dmarche dautomatisation des tests de recette.
Difficults rencontres
Le projet de dveloppement a suivi le cycle classique en V. Valtech est intervenu
partir de la phase de dveloppement (le bas du cycle en V) et a ainsi hrit
dun document de spcification, fruit de plus dun an de travail. Il a, ds lors, t
impossible de faire raliser les tests par le client.
Certaines parties de lapplication tant dveloppes en Java et dautres en C++,
deux environnements de dveloppement diffrents et deux outils de tests unitaires
ont t utiliss - Eclipse et Visual Studio dune part, JUnit et CPPUnit dautre part.
Cela a induit un double effort de mise en place des frameworks de tests unitaires.
La couverture des tests unitaires sur la partie C++ sest avre difficile calculer.
33
Solutions apportes
Test Driven Development
2.5
TDD, le dveloppement sous contrle
Les composants crits en C++ tant des librairies utilises par le code Java et
JUnit tant plus facile utiliser, le code C++ a majoritairement t test depuis
lenvironnement Java avec JUnit. Malgr tout, certains tests ont d rester dans la
partie C++, de manire garder un feedback rapide.
Contexte
Tests de recette automatiss
Le contexte sannonce a priori dfavorable, voire hostile lAgilit : la mthodologie

interne prne le cycle en V, totalement ancr dans la culture industrielle de
lentreprise.
aa
aa
aa
aa
Lquipe de dveloppement a crit les tests de recette, au moyen dune librairie

externe uispec4j, permettant de scripter des scnarios dutilisation de
linterface graphique Swing. Par ailleurs, un simulateur sous MS Windows a permis
de simuler les interactions de lapplication avec un quipement propritaire. Loutil
AutoIt a t utilis pour piloter ce simulateur depuis la suite de tests en Java.
etienne charignon
// Valtech
Le projet a t livr le jour prvu, sans augmentation des cots. Lquipe de

dveloppement sest montre trs flexible vis vis des diverses modifications
de spcification, le tout sans perte de qualit ni apparition de rgression.
Chaque membre de lquipe projet renseigne quotidiennement le reste-faire pour les tches dont il a la charge1.
Le Burndown chart est mis automatiquement jour, imprim et affich
dans lespace de travail de lquipe, il est galement accessible distance
via un wiki (y compris par le client). Il prsente leffort restant accomplir en
heures, pour finir les tches alloues litration, le pourcentage de tches
termines et la courbe idale de reste--faire .
aa
aa
Bnfices obtenus
ITERATION PROGRESS
La mise en uvre des pratiques Agiles de TDD permet de :

>> rester matre de la complexit des dveloppements raliss,
>> livrer dans les temps et le budget impartis.
100
350
300
80
250
60
200
150
40
100
2.6
20
Suivi et pilotage
avec lIteration Backlog
50
AUG.
AUG.
AUG.
AUG.
10
AUG.
13
AUG.
14
AUG.
15
AUG.
16
AUG.
17
AUG.
20
AUG.
21
AUG.
22
AUG.
23
AUG.
24
COMPLETED TASKS %
REMAINING WORKING HOURS
Lessentiel retenir
AUG.
IT04 BURNDOWN
IT04 BURNDOWN COMPLETED TASKS %
IT04 BURNDOWN TARGET
34
LIteration Backlog a pour vocation de contenir lensemble des tches identifies et

estimes par lquipe de projet pour litration en cours. Grce lestimation initiale
et au reste--faire estim quotidiennement, une reprsentation graphique de
lavancement est disponible en permanence (Iteration Burndown Chart) Sur les
projets Valtech, les tches sont associes des fonctions ou des scnarios de
cas dutilisation.
aa
aa
figure 6
Exemple de Burndown Chart (Source Valtech)
En fin ditration, les mtriques suivantes sont releves et communiques

lquipe ainsi quau client :
aa
Les tches sont identifies pour prendre en compte de nouvelles priorits de

livraison et pour minimiser le nombre ditrations ncessaires la livraison
dune fonction ou dun cas dutilisation. La charge associe une tche est
gnralement comprise entre 4 et 16 heures.
aa
Chaque tche est dcrite par les informations suivantes :
le pourcentage du primtre de litration ralis. Il est calcul par le

rapport entre la taille du logiciel qui devait tre livr (poids Fibonacci) et la
taille livre rellement,
la Vlocit de litration, cest dire le cumul du nombre de points de
chaque fonction termine (codage, test, etc.), et livre (dmontre, accepte
par le client, prte pour un dploiement ventuel).
identifiant unique (pour la traabilit avec les fonctions ou cas

dutilisation),
nom explicite non gnrique mais spcifique au contexte et au sujet trait,

identification du membre de lquipe qui sest engag la raliser,
effort estim en heures par lquipe lors du planning ditration (exercice
etienne charignon
// Valtech
Le Burndown Chart est un outil trs puissant pour matriser lavancement des
travaux raliss par une quipe sur une priode courte dont les objectifs ont
t exprims en tches raliser.
collgial de planification ditration),
1.
Une alternative consiste nommer chaque semaine et tour de rle, un time tracker qui relve ces mtriques pour
lensemble de lquipe.
35
>> LIteration Backlog a pour vocation de grer court terme lensemble

des tches identifies et estimes par lquipe de projet sur chaque
itration. La mise en place de mesures pertinentes permet, jour
aprs jour, de suivre lavancement rel et de piloter le projet en
consquence.
2.7
Retour dexprience
sur la gestion de projet

Les pratiques mises en uvre sont :
aa
aa
aa
aa
Lessentiel retenir
utilisation de la mthode dorganisation et de suivi Scrum sur les parties

France et Inde (2 quipes Scrum),
mise en place dun Product Backlog commun aux deux quipes,
utilisation dun outil collaboratif (wiki) pour la communication entre les
quipes de dveloppement et le client,
mise en place dun mode de livraison Inde / France bas sur de lintgration
continue (cf. figure 8). Les diffrents points de synchronisation France / Inde
et MOA / MOE y sont identifis ci-aprs.
Contexte
Dveloppement dune application de gestion pour le suivi et la traabilit des
processus de fabrication pour un industriel franais de laviation.
Mode de dveloppement
Taille du projet
9 000 hommes.jour
Dure du projet
2 ans
Outils utiliss
36
Duoshore avec une quipe de 5 analystes Onshore

sur le site du client et 25 dveloppeurs offshore dans
notre centre de dveloppement de Bangalore (Inde).
tableau 5
WSAD, Wiki Confluence, Jira
figure 7
Planning dtaill dune itration (Source Valtech)

37
Contexte projet (Source Valtech)
Enjeux client
Les enjeux pour cette nouvelle application sont :
aa
aa
aa
aa
offrir un outil souple, robuste et facile dployer,

faciliter le travail des utilisateurs par une interface intuitive et simple
dutilisation,
apporter une solution permettant de mieux matriser la traabilit des
procds de fabrication,
accrotre linteroprabibilit du systme avec les autres applications de
gestion.
Figure 8
Planning dtaill dune semaine (Source Valtech)
Les difficults rencontres sont :
Figure 9
Planning dtaill dune journe (Source Valtech)
Principe de rpartition des responsabilits de la matrise duvre :
aa
relation avec le client,

recueil des besoins,
formalisation de documents danalyse,
suivi de la validation de ces documents,
transfert de connaissance vers les quipes offshore,
support fonctionnel aux quipes offshore,
mise en place et contrle des directives darchitecture du projet,
contrle des flux de traduction Franais-Anglais (documents danalyse) et
dveloppement de fonctionnalits qui ne peuvent tre dlocalises,
vrifications des scnarios de test,
coordination globale du projet.
aa
la contrainte dentre sur le site et la planification longtemps lavance ne

permettent pas de faire intervenir des ressources offshore sur le site client,
lobligation de planifier les runions et les workshops bien en amont,
la clture de la documentation Word pour le client : en contradiction avec
lapproche Wiki qui privilgie laccs en ligne pour tous,
la barrire de la langue (langlais) pour la matrise douvrage,
le souhait du client de raccourcir la prise en compte des demandes de
changement dune itration lautre,
le cycle initial de validation des livrables documentaires est trop lourd et pas
du tout adapt lapproche itrative,
les quipes onshore et MOA ne communiquent que par mails.
Solutions apportes
Onshore (France) :
Anglais-Franais (document de conception),
38
aa
aa
aa
aa
aa
aa
aa
Offshore (Inde) :
formalisation des documents de conception,

travaux de dveloppement,
laboration des scnarios de tests,
automatisation des tests,
excution des tests manuels et automatiques,
excution des contrles de qualit du code (PMD, RSA et FindBugs).
Les solutions apportes sont :
aa
aa
aa
aa
aa
face limpossibilit de traiter les volutions : la mise en place dun volant

de jours pour traiter les volutions : systme denveloppe,
pour rduire le nombre danomalies : mise en place dun circuit
dintgration continue entre les dveloppements raliss en Inde et la plateforme dintgration sur le site du client,
lacclration de la prise en compte des demandes client : identification
dune provision de charges pour traiter les demandes de changement en
cours ditration (jusqu la mi-itration),
la rduction du backlog danomalies : constitution dune provision de
charges pour laisser le temps lquipe en Inde de corriger ses anomalies
(interne / client) tout en produisant du fonctionnel,
le rapprochement physique des quipes onshore avec la matrise douvrage.
Bnfices obtenus
Les bnfices obtenus sont :
aa
aa
aa
le volant de jours : fin des tensions concernant la qualification des

anomalies / volutions,
la confiance accrue du client en la qualit des dveloppements,
la visibilit totale sur le contenu du produit et des itrations qui permet
de planifier lavance les avenants contractuels pour traiter les nouvelles
fonctionnalits majeures,
39
aa
aa
le respect des engagements vis--vis des autres quipes impliques dans

le processus dingnierie (autres quipes de dveloppement, intgration,
qualification, tests de performances...),
rduction du nombre danomalies grce une meilleure comprhension
du fonctionnel par les quipes indiennes et la dcouverte au plus tt des
anomalies (intgration continue),
Enjeux client
La dure des campagnes de tests de non-rgression risque de masquer leffet
positif du dploiement des mthodes Agiles. Il est donc impratif de raccourcir la
dure des campagnes et den augmenter la frquence.
aa
nouvelles prises de commandes.

Lessentiel retenir
>> Les pratiques Agiles peuvent tre appliques dans un environnement

non Agile mme si celui-ci a de fortes contraintes. Il faut adapter ces
mthodes au contexte du client et les adapter progressivement : une
ducation pralable montrant les bnfices attendus et une mise en
vidence rgulire des gains obtenus sont impratives.
Les pratiques mises en uvre sont :
aa
aa
>> Les pratiques Agiles choisies et mises en place avec justesse

permettent de prserver un des facteurs cls du succs du projet :
la bonne collaboration entre les quipes du fournisseur et celles du
client. Noublions pas que cette collaboration entre quipes est au
centre des pratiques Agiles!
automatisation des tests utilisateurs de non-rgression (tests fonctionnels

sollicitant linterface graphique),
mise en place de tests automatiss dans le processus dintgration continue
sur tous les niveaux de tests, depuis les tests unitaires jusquaux tests
utilisateurs. Les niveaux de tests sont dclenchs diffrentes tapes du
cycle de construction (build) pour offrir un niveau de ractivit optimal aux
quipes de dveloppement : chec dintgration dtect en moins de 2 min,
chec de tests unitaires en moins de 5 min, chec de tests fonctionnels en
moins dune heure.
aa
2.8
40
Retour dexprience
sur lautomatisation des tests
aa
Contexte
aa
LAgilit permet de nombreuses livraisons intermdiaires. Chacune de ces

livraisons doit tre intgralement teste ; dans le cas contraire, la perte de
contrle sur la qualit crot de manire exponentielle chaque itration.
aa
Un dpartement de la DSI dune grande banque de finance souhaite mettre

en place lAgilit au sein de ses quipes de dveloppement. Le dpartement
a la responsabilit du dveloppement et de la maintenance dun ensemble
dapplications avec des technologies htrognes. Toutes les applications sont
dployes en production simultanment, trimestriellement. Chaque dploiement
en production est prcd dune campagne de tests utilisateurs de 2 3 semaines
visant sassurer de labsence de rgression dans lensemble des applications.
Les tests utilisateurs de non-rgression, ceux qui sollicitent linterface

graphique, sont gnralement coteux automatiser et maintenir. La
moindre modification dune interface peut conduire lchec dun script
automatis, mme si les services sous-jacents nont pas t modifis : les
quipes de dveloppement nont pas toujours conscience de cette contrainte
et introduisent des modifications sur linterface, sans reporter cette
modification dans les scripts de tests automatiss,
les tests sont automatiss trop tt sur des pans fonctionnels non stables, ce
qui en gnral entrane des cots prohibitifs de maintenance des scripts de
tests,
linterface graphique utilise des composants qui se prtent difficilement
lautomatisation des tests. Ceci est dautant plus vrai que certains
composants proviennent dditeurs qui ne fournissent pas le procd de test
de leurs composants,
le rfrentiel de donnes de lenvironnement de tests est difficile
contrler, les donnes proviennent de copies de la base de production. Les
donnes de tests peuvent donc tre perdues ou altres et impacter le bon
fonctionnement des tests de non-rgression.
41
Valtech sest focalis sur :
aa
aa
aa
ltude de compatibilit technique entre linterface graphique et

loutil dautomatisation, afin didentifier les composants graphiques
problmatiques et damener les dveloppeurs concevoir des interfaces
testables,
ltude de ROI, destine vrifier lintrt conomique de lautomatisation
(plus un test est excut, plus lautomatisation est rentable court terme),
la dfinition de la stratgie dautomatisation visant :
choisir quels tests automatiser pour maximiser la valeur des tests de

non-rgression par rapport leffort investi,
dfinir la faon de grer le rfrentiel de donnes.

etienne charignon
// Valtech
Lautomatisation des tests dans un contexte itratif et incrmental nest pas

une option. Quel quen soit le prix, cest une obligation.
Le fait ditrer implique de rejouer systmatiquement certains tests de nonrgression. Cela rend conomiquement intressante lautomatisation de ces tests,
condition toutefois que leffort dautomatisation li la technologie utilise ne
soit pas rdhibitoire, do la ncessit de sen assurer.
N.B.
Rsultats obtenus sur

des projets raliss par Valtech
2.9
Solution apporte
Valtech est la premire socit en France avoir propos en 2002 une formation de
conduite de projet dans un contexte itratif et incrmental ( lpoque sur la base de
Unified Process). Mais trs vite, cette dmarche utilise sur les projets de lpoque
a t remplace par la dmarche Scrum, plus Agile et moins contraignante du
point de vue de la documentation projet et des livrables.
Cette adoption a t renforce par lintervention, en 2003, en France

mais galement en Inde, dans notre centre de dveloppement
Bangalore, de Craig Larman, auteur de nombreux ouvrages
de rfrence en matire de processus dingnierie logicielle et
dAgilit.
Valtech a eu la responsabilit de dployer lensemble des principes Agiles sur la
totalit des projets, jusqu la rorganisation complte des bureaux prcdemment
organiss en cubicles et transforms en espaces de travail ouverts. Il a galement
certifi Scrum Master lensemble des chefs de projet et a initi la mise en place
de nouveaux outils tels que Valtech Cockpit, la plate-forme collaborative Valtech,
utilise sur les projets aujourdhui.
Bnfices obtenus
42
Les campagnes de tests utilisateurs sont progressivement passes dune

frquence trimestrielle une frquence quotidienne. La dure dun cycle de tests
utilisateurs a t rduite de 1 semaine 2 heures.
La notion de campagne de tests perd progressivement de son sens pour
laisser place la notion de tests en continu .
Lessentiel retenir
>> Les tests manuels peuvent tre compars une force de frottement:
plus la vitesse et la pression saccentuent sur un corps en
mouvement, plus importants sont les frottements, rduisant
lefficacit des efforts concds pour acclrer le mouvement.
>> Lautomatisation des tests rduit ces forces de frottement et vite
ainsi lchauffement et lusure du dispositif.
43
Cet lectrochoc a t rellement salutaire car les rsultats sur les projets ont t
grandement amliors sur diffrents plans:
Le respect des dlais
La qualit des
livraisons
La confiance
de nos clients
Le time boxing et le
fait de procder par
itrations
successives
a permis aux quipes
projet daugmenter leur
productivit.
Les anomalies tant

corriges au fur et
mesure, avec une priorit
plus importante que les
fonctionnalits livrer, la
charge de gestion de ces
anomalies a diminu pour
laisser place plus de
fonctions implmentes.
Tout nos clients sont

rests fidles et possdent
des quipes Bangalore,
dont le nombre saccrot
chaque anne. De plus,
de nouveaux clients
intresss par loffshore
et lAgilit nous ont mis en
comptition sur des Proof
of Concept, avec la clef
de nouveaux projets sur
des domaines jusque l
inexplors par Valtech,
comme, par exemple,
celui de testeur de puces
lectroniques.
3
Le marketing
digital Agile
45
44
La satisfaction de nos
collaborateurs
Un certain confort sur

les projets
Le fait de collaborer
plus troitement avec
des quipes distantes et
dune culture diffrente
a motiv de nombreux
consultants, les incitant
aller plus souvent en Inde
ou faire des missions de
conseil sur ladoption de
lAgilit dans un contexte
onshore mais galement
offshore.
Souvent le terme projet

est synonyme de stress,
dinsatisfaction, de pertes
financires Avec la mise
en place des pratiques
Agiles, la matrise des
projets
saccrot,
le
feedback du client et des
utilisateurs est rel, la
qualit des livraisons et la
productivit augmentent
nettement.
Ou pourquoi et comment mettre de lAgilit

dans la dmarche de cration graphique
La Vision du Produit
3. le digital marketing Agile
3.1
tout produit est ncessairement associe une vision, fixant le cap, donnant du
sens et dcrivant ce quon entrevoit pour le produit court, moyen ou long terme.
La vision du produit est donc cruciale, structurante; elle sera le socle de toute
lExprience Utilisateur du produit.
Le monde sacclre. Proposer le bon produit ou service la bonne personne,

dans le bon contexte dachat, au bon moment est la cl de russite dun projet de
marketing digital. Support par des plates-formes technologiques de plus en plus
complexes et des supports dexpriences de plus en plus riches et sophistiqus, le
marketing digital est un vecteur de rentabilit fort pour les annonceurs et sinscrit
clairement dans leur exigence de retour sur investissement et dimage.
Lubomira rochet
// Valtech
46
Le marketing digital personnalis en temps rel sinscrit aujourdhui dans la ralit

des usages et des attentes, la fois des marques et de leurs clients. Mais qui dit
temps rel et Web 2.0, dit dialogue continu avec les diffrentes publics, intgration
continue des feedbacks des utilisateurs, adaptation constante des objectifs et
des stratgies marketing en fonction des changements dans lcosystme de la
marque. Cette ncessaire ractivit en temps rel impose une vraie rflexion sur
les mthodologies de gestion des projets marketing et plus gnralement sur
lorganisation du dpartement marketing lui-mme. LAgilit, qui place lutilisateur
au cur de sa mthodologie, privilgie loprationnel sur la documentation
plthorique, favorise lchange et la collaboration avec lcosystme et prne
la ractivit permanente plutt que le suivi strict dun plan, prend tout son sens
dans ce contexte. Lapplication des principes et des pratiques Agiles au mtier
du marketing vient donner aux directions marketing les outils de leur efficacit
et de leur pertinence, en les aidant dvelopper leurs produits et excuter
leurs campagnes plus vite et de manire plus volutive. Les quipes marketing
organises en mode Agile peuvent ainsi travailler de manire ultra collaborative au
dveloppement et lamlioration des sites web, des produits ou des services, en
tenant compte du feedback des utilisateurs.
Parfois peu dtaille, souvent pose en raction un problme et pilote en termes

dobjectifs,la vision du produit naura de sens que si elle est porte et partage
avec les quipes, pour tre en mesure de fdrer et de se projeter efficacement
dans le futur.
Construire la vision, la partager puis la porter: trois vrais challenges relever,
notamment pour les Product Ownersdes projets Agiles, qui utilisent des pratiques
hautement collaboratives.
La vision synthtique est indispensable et, de surcrot, facile mettre en uvre.
On peut, selon les contextes et les objectifs, laccompagner de lune voire des deux
techniques Product Box.
La vision synthtique ou Elevator Statement (daprs Moore)est la technique
simple et efficace par excellence. Elle permet de structurer, en peu de temps, la
vision du produit. Son format est le suivant:

POUR : [ public concern par le produit ]
QUI SOUHAITENT : [ formulation du besoin des cibles ]
NOTRE PRODUIT EST : [ ce quest le produit ]

QUI : [ le bnfice majeur, lutilit de la solution ]
LA DIFFERENCE DE : [ pratique actuelle, concurrence ]

PERMET DE : [ lments diffrentiateurs majeurs ]
Lue voix haute, la vision synthtique ne doit pas excder deux minutes. Elle trouve
facilement sa place au sein du radiateur dinformations du projet. La mthode des
Personas (cf. Encart) pourra venir complter admirablement les deux premiers
lments de la vision, ceux relatifs la cible ( Pour ) et leurs buts ( Qui
souhaitent).
aa
La Product Vision Box (daprs Highsmith) qui permet au dmarrage

dun projet de construire la vision et la partager, de manire ludique,
avec lquipe charge de concevoir le produit mais aussi ceux chargs de
le vendre. Lquipe cre une bote, reprsentation visuelle, concrte du
logiciel ou du service quelle est cense dvelopper: un nom, une image,
un slogan, quelques arguments pour vendre le produit puis sur lautre face,
par exemple, le dtail contenant plus de fonctionnalits ou encore les prrequis.
47
3.2
Personas, vous avez dit Personas?

Un Persona, cest un utilisateur-type, une reprsentation fictive des utilisateurs
cibles, quon peut utiliser pour fixer des priorits, guider nos dcisions de
conception dinterface et tester les scnarios dinterface les plus prioritaires.
Cette mthode, invente par Alan Cooper en 1999 dans son best-seller The
Inmates Are Running the Asylum, permet doffrir une vision commune et partage
par lquipe des utilisateurs dun produit, en insistant sur leurs buts, leurs attentes
et leurs freins potentiels, et en proposant un format des plus engageants. Les
Personas suscitent en effet de lempathie, un vritable investissement motionnel:
ils prennent trs vite une place de choix sur le radiateur dinformations du projet
Agile.
3.3
La dmarche crative
Les paragraphes suivants ont pour but de clarifier le rle de la cration graphique
dans un projet. En effet, la phase de cration ne consiste pas simplement mettre
en couleur des lments prfabriqus pendant les spcifications fonctionnelles
ou ergonomiques. La rponse graphique a un primtre plus large, qui complte
et enrichit le projet grce des solutions daffichage, de prsentation ou de
composition.
Conception de linterface
Elle est constitue gnralement de:
aa
aa
aa
Exemple : En tant que recruteur, je

peux dposer une offre demploi pour
recevoir plus de candidatures.
Sur la base de grandes catgories
dutilisateurs (rles ou segments
marketing pralablement identifis),
puis dateliers de travail et dentretiens
utilisateurs, la mthode des Personas
va donc plus loin, en affinant, en
dtaillant puis en personnifiant les
rles utilisateurs.
Des lments de contexte, les buts et comportements et leurs impacts sur le

produit: voici au final les constituants de base dun Persona, travaills de manire
collaborative dans un mode Agile
La conceptualisation de linterface est avant tout la reprsentation visuelle

dun concept. Ce concept est labor par plusieurs personnes qui travaillent en
collaboration. La taille de cette quipe est bien entendu variable selon la complexit
du projet.
Les rles Utilisateurs , lmentscls des user stories, adoptent

volontairement un format trs
synthtique, et restent avant tout sur
la relation utilisateur / systme : ni
lments fictifs, ni scnario, ni travail
denqute.
48
sur des donnes issues dentretiens (parties prenantes et futurs utilisateurs)

voire de lobservation directe des cibles, et sur lpluchage de diverses sources
(support, presse, tudes externes, concurrence ): cest la spcificit et la force
de la mthode!
La Product Box (daprs Hohmann) qui offre une forte connotation

Exprience & Etude Utilisateurs. Latelier de travail Product Box est
rsolument orient clients, tourn vers les utilisateurs du produit final dont
on rcolte le feedback. Ils creront en groupe une bote pour le produit dont
ils simuleront ensuite la vente. Latelier se joue gnralement dans une
dynamique collective. Plus il y aura de botes, mieux ce sera!
aa
Un directeur artistique (DA) et/ou un directeur de cration (DC),

Un ergonome,
Un consultant fonctionnel ou, consultant mtier, dans certains cas.
Ateliers de conception
Conception en ateliers
Figure 10
Exemple de persona
(Source Jean-Claude Grosjean www.qualitystreet.fr)
La cible du futur produit va donc trs vite merger au travers dun nombre restreint
de Personas et surtout dun Persona primaire, celui pour qui on construit le
produit.
La mthode des Personas est une dmarche avant tout collaborative qui va
mobiliser toute lquipe: les Personas se construisent collectivement au cours de
plusieurs ateliers de travail. Cette construction devra imprativement sappuyer
Le concept gnral de linterface nest pas labor de manire cloisonne. Lquipe

de conception sassocie au Scrum Master et au Product Owner pour travailler
en ateliers. Il est galement souhaitable dassocier, lorsque cest possible, des
utilisateurs finaux de loutil ou lapplication qui seront raliss.
Ces ateliers sont organiss comme des runions Agiles, cest--dire que toutes
les personnes prsentes sont reprsentatives de lquipe et chacune a droit la
parole.
49
Ces ateliers ont 3 objectifs:
aa
aa
aa
aider concevoir le concept visuel et graphique grce au directeur

artistique,
orienter linterface vers les besoins utilisateurs et selon les attendus clients
grce la prsence des deux reprsentants,
contrler, orienter ou comprendre la faisabilit pour le Scrum Master et le
Product Owner.
Ensemble, ils vont dfinir les points qui permettront de concevoir le concept et
passer en revue:
aa
aa
aa
aa
aa
la comprhension mtier,
les fonctionnalits,
la comprhension de lutilisateur,
aa
aa
aa
aa
les reprsentions visuelles et graphiques.
Par exemple, durant ces ateliers, on va concevoir des Personas, donner une
attention particulire une reprsentation graphique, dessiner les liens entre les
actions pressenties, ou certaines interactions particulires
Les points traits en atelier le sont avec un niveau de dtail variant selon la nature
des projets. Ainsi, sur certains projets, les quipes peuvent tre amenes traiter
des points particuliers lis la technologie (applications mobiles, interfaces
tactiles...) ou des contextes particuliers (niveaux dexprience des utilisateurs,
contexte dutilisation)
le type dinterface attendu (aspects graphiques, style),

la simplification de linterface, notamment dans le cas de refontes
(raccourcis envisags, simplification des tches),
les interactions attendues avec lutilisateur (mthode de saisie,
environnement de saisie, niveau de prcision),
les impacts techniques (faisabilit).
Dans un second temps, chaque point trait est hirarchis, et des priorits sont
attribues:
aa
aa
lExprience Utilisateur attendue,
Ces ateliers, organiss trs tt dans le projet, permettent de proposer une

reprsentation visuelle et graphique trs rapidement, et cela augmente le niveau
de comprhension pour toute lquipe.
50
Dans un premier temps, plusieurs thmes sont abords, tels que:
On dtermine les priorits en fonction de tous les paramtres qui impactent

le projet: dveloppements techniques, planning, budget, complexit de
ralisation
On hirarchise selon les mmes paramtres, et on prend en compte la
faisabilit, les risques sur les innovations, et tous les points particuliers lis
aux contraintes graphiques.
Une fois cette tape termine, la conception des cinmatiques et les travaux de
cration graphique lis lergonomie peuvent dbuter.
Dcomposer en cinmatiques
On distingue 3 types de composants ergonomiques pour lesquels la cration
graphique va tre reprsente.Du plus dtaill au plus gnral:
aa
aa
aa
Dans tous les cas, ils sont grs par des priorits et un niveau de complexit
associ.
une tche: cest une action utilisateur, compose dune ou plusieurs actions
simples, permettant daccomplir un objectif unique,
un scnario dusage (ou cas dusage): cest un ensemble de tches
dpendantes qui permettent lutilisateur datteindre un objectif identifi,
une cinmatique: cest un ensemble de scnarios permettant
laccomplissement de tches dans des cas dusage. Ces actions utilisateurs
peuvent tre transversales et/ou interdpendantes les unes avec les aux
autres. lintrieur dune cinmatique, on retrouve plusieurs scenarios, et
plusieurs tches dans chacun des scnarios.
Donner des priorits et les piloter

Lobjectif principal est bien entendu de rpondre de manire positive
lutilisateur final. Tout doit tre mis en uvre pour lui proposer une interface
simple comprendre, intuitive. Il ne faut jamais perdre de vue que cette interface
devra offrir lutilisateur une rponse efficace et adapte son besoin
Le groupe de travail constitu pour ces ateliers est amen envisager diffrentes
hypothsesde reprsentation et de modlisation de linterface.
Nanmoins, cest gnralement le consultant ou lergonome qui dirige les ateliers.
Lobjectif de dcomposition en cinmatiques est didentifier et de rpertorier les

scenarios dusage les plus importants. Le scnario est simul sur un document de
story-board et sert identifier une ou des tches que lutilisateur doit accomplir.
les cinmatiques peuvent intgrer un certain nombre de tches qui comportent
des niveaux de priorit diffrents.
N.B.
51
Exemple: une cinmatique de saisie et denregistrement dun profil utilisateur,

comporte des lments de faible niveau de complexit (les coordonnes, le nom),
mais elle peut aussi comporter des tches plus complexes (interfaage avec un
annuaire, vrifications diverses )
Cette tape est capitale pour la reprsentation des donnes, elle est immdiatement
suivie de la ralisation de la reprsentation graphique.
Limportance davoir une vision graphique

La reprsentation graphique donne tous les acteurs du projet accs une
reprsentation proche de la ralisation finale. Elle a de limportance:
aa
aa
aa
52
pour le client, afin de valider ses hypothses et la conformit avec ses

attentes,
pour lutilisateur, afin danticiper la prise en main et participer
lamlioration,
pour lquipe de dveloppement, afin de conceptualiser le rsultat final.
La reprsentation graphique apporte naturellement des solutions

visuelles et interactives qui orientent les solutions techniques et
modifient les dveloppements ou les fonctionnalits. Lassociation
des interactions avec linterface est primordiale pour la ralisation
dune application efficace.
Intgrer la cration graphique dans les projets Agile.

La cration graphique est une tape risque dans un projet:
aa
aa
aa
aa
risque motionnel li la qualit de la cration,

risque de valider une ligne graphique non approprie, ce qui bloquera les
dveloppements,
difficults de ralisation des interactions complexes,
difficults de mise en production de certaines solutions et les retards que
cela peut engendrer.
Dans tous les cas, ce risque se matrialise souvent par une dsynchronisation
entre les tches de production graphique et les tches de production technique.
Obtenir une reprsentation graphique de linterface trs tt dans le projet permet :
Avec une approche Agile, ces risques sont limits pour 3 raisons:
aa
aa
aa
aa
aa
aa
dapporter une dimension rarement anticipe par les quipes au dpart du

projet: elle cristallise des ides, des concepts, des intentions, grce la
mise en forme et la reprsentation visuelle de formes, de couleurs, de styles
qui seront employs.
la cration est prpare et planifie en amont du dveloppement,

les tches de ralisation et de conception de la cration graphique
sont dcomposes dans le backlog au mme titre que les tches de
dveloppement (dfinition des priorits, indice de complexit),
de donner un style, un aspect visuel qui aura un impact sur le niveau de

qualit. Ce style pourra tre ludique ou plus technique, comporter des
orientations plus textuelles, simuler ou sinspirer dinterfaces tactiles. Ce
style, formalis graphiquement, est la synthse visuelle de toutes les ides
qui sont issues des ateliers.
aa
de contribuer faire voluer les besoins, grce lapport dides innovantes

et diffrenciatrices.
Le processus de cration graphique
de fournir des rponses visuelles des complexits fonctionnelles: une

image vaut parfois mieux quun long discours!
La cinmatique est matrialise par un story-board qui prsente les crans de

manire filaire, sans habillage graphique (wireframe). Cette reprsentation donne
des indications sur les contenus et la position des lments de la page. Une
attention particulire est donne aux cinmatiques et aux scnarios qui prsentent
des priorits diffrentes.
lintervention des quipes graphiques est itrative et permanente tout au

long du dveloppement (et pas simplement au dbut).
Ce processus comporte quatre phases qui sont pralablement prsentes au

donneur dordre et aux quipes. Chacune des phases apporte un lot de rponses
aux problmes de linterface et permet de progresser vers la phase dacceptation.
Pour assurer la russite du projet, des compromis sont ncessaires: il faut choisir
les lments raliser parmi ceux proposs. Nanmoins, il ne faut pas perdre
de vue que cette approche doit permettre aussi de fournir des rponses plus
facilement.
53
Conserver une interface graphique homogne
La dmarche de cration consiste raliser successivement:
Cependant cette dcomposition entrane une fragmentation de la ligne graphique

et limite la vue globale de linterface.
Des pistes
graphiques
Une ligne
graphique
Un concept
graphique
La charte
graphique
Les pistes graphiques

Ces pistes servent avant tout dfricher des concepts ou des ides, et ne sont
pas forcement complmentaire entre elles. (On ne recompose pas une interface
avec plusieurs pistes diffrentes). Elles sont matrialises par des planches de
recherche sur des crans type ou des crans qui font tat du processus. Ces
crans contiennent la reprsentation des objets ou des interactions envisages.
La ligne graphique
La ligne graphique est avant tout un choix dides, de concepts et dtats desprit
plutt que rellement une des pistes prsentes initialement. Ainsi le DA ne va pas
ncessairement recomposer une ligne finale par association des pistes initiales,
mais plutt recomposer et enrichir une rponse en tenant compte des remarques
reues.
Le concept graphique
54
Avec le concept graphique, on aborde une dimension plus technique car les objets
crs sont destines tre utilises par les infographistes pour produire les
lments ncessaires aux dveloppements.
La charte graphique
La charte graphique est un document de synthse qui est finalis lissue du
projet. Une charte nest par dfinie en amont, mais de manire itrative au cours
du dveloppement.
Des points de contrle

Il est important malgr cette dcomposition structure, de se rserver des points
de contrle qui vont agir comme des garde-fous de la cration.
Le processus itratif permet une dcomposition de la cration graphique

dans le projet Agile. Cest un point positif qui facilite son intgration avec les
dveloppements.
La reprsentation graphique entrane ncessairement des jugements de valeur

parfois assez tranchs, il est pourtant indispensable, ce stade, de suivre le
cheminement qui sera propos par le directeur artistique. Les choix dinterfaces
doivent dpasser les prises de position trop motives (Jaime, je naime pas).
Pour cette raison, il est indispensable danticiper le rsultat final en positionnant

des tapes de consolidation et dhomognisation. Ces tapes seront intgres
durant toute la ralisation.
On peut anticiper ces tapes de consolidation ds la premire restitution et de
manire planifie, mais il est tout fait possible de se rserver des consolidations
sur demande, en fonction de lavancement ou face un problme rencontr.
Ce travail de consolidation de linterface graphique ne doit pas attendre lultime
itration. La consolidation rgulire permettra en revanche de se replacer dans
le contexte des scnarios et den vrifier la cohrence, tant du point de vue de
linterface graphique, que des interactions qui en dcoulent.
Rythmer la progression
Avec le jeu des priorits et des ajustements tout au long du processus Agile, il est
ncessaire de faire concider les tches du backlog avec les avances relles des
dveloppements pendant litration.
Les cratifs ne sont pas prsents plein temps avec lquipe de projet, les points
de synchronisation cration/dveloppements techniques doivent tre positionns
lors de la planification des itrations.
Des interlocuteurs graphiques qui voluent selon les projets

Comme nous lavons vu dans les paragraphes prcdents, les phases amont sont
prises en charge par le directeur artistique, avec pour rsultats un concept et
une ligne graphique globale.Les tches de dclinaisons graphiques sont ensuite
confies aux infographistes, sous le contrle du directeur artistique.
Le DA reste linterlocuteur privilgi pour la partie graphique. Une fois la production
graphique dmarre, il est aussi linterlocuteur qui travaille en tandem avec
lergonome pour mettre au point les solutions appropries lies aux interactions
ou aux reprsentations graphiques.
Lorsque le projet le ncessite et notamment sur les interfaces riches, il est
intressant davoir un ergonome possdant une double comptence technique et
graphique pour la ralisation des dclinaisons et des interactions de linterface. La
double comptence facilite les changes avec les membres de lquipe en charge
du dveloppement.
Exemple : dans le cas dun projet trait en Flash ou Flex, lergonome ralise
linterface graphique sur la base des lments produits par les infographistes, tout
en sinterfaant avec les donnes du socle technique.
55
Le concept est indispensable pour bien apprhender linterface au sens large.

Le concept graphique dfinit des formes, des styles, des couleurset tous les
lments indispensables au bon fonctionnement des interactions entre lutilisateur
et le systme.
Mais bien que la reprsentation soit purement graphique, elle influence les
solutions techniques.
Le concept graphique ne sapplique pas en fonction de pages isoles, mais en
fonction de chemins utilisateurs dans lesquels il agit, interagit et progresse.
Design dinterface et design dinteraction

La cration graphique est une reprsentation visuelle. Mais la finalit nest pas une
reprsentation fige et statique. Quelle que soit la technologie ou la plate-forme
choisie, ce sont bien les interactions avec lutilisateur qui prvalent.
Il est donc indispensable de penser la cration graphique du systme de manire
itrative, y compris au niveau de chaque tche utilisateur.
En effet, une action sur la page nentrane pas forcement un enchanement vers
une autre page Lutilisateur peut tre amen actionner diffrents items sur
lcran pour accomplir son action. Ce sont ces tats et ces interactions que la ligne
graphique devra aussi anticiper.
Dautre part il est frquent que des rponses graphiques apportent des solutions
dorganisation lies au fonctionnel ou la technologie et entranent des
changements durant une itration. Graphistes et dveloppeurs doivent donc tre
particulirement lcoute lun de lautre et ne pas hsiter faire voluer leurs
tches pour servir le projet.
56
3.4
Agilit et Exprience Utilisateur

Des points de convergence vidents
LAgilit et lExprience Utilisateur ont beaucoup de points communs, dont le plus
important est le facteur humain. Autre exemple : la recherche permanente du
feedback (au travers notamment des pratiques tests) mais aussi la dfense de la
simplicit, sont communes aux mthodes Agiles et la dmarche ergonomique.
La conception centre utilisateur peut ainsi bnficier des conditions trs
favorables offertes par lAgilit (des conditions rarement prsentes dans les cycles
de dveloppement traditionnels).
Ces leviers forts sur lesquels les praticiens de lExprience Utilisateur vont pouvoir
asseoir leur action sont les suivants:
aa
aa
aa
aa
aa
les livraisons frquentes (toutes les deux ou trois semaines),
Le concept graphique impacte le design du systme
lactivit de validation en continu,

le travail collaboratif,
la coopration et limplication forte des clients et utilisateurs, tout au long du
projet,
laccent mis sur la simplicit.
Malgr tout, Scrum et les mthodes Agiles laissent encore largement de ct

les lments relevant de lingnierie des exigences, de lergonomie ou encore de
lExprience Utilisateur.
Ce manque incontestable peut vite se transformer en faiblesse, tant ces dimensions
sont devenues cruciales pour assurer une bonne acceptation des produits par
les utilisateurs finaux. Lintgration efficace des spcialistes de lExprience
Utilisateur dans les projets Agile est donc aujourdhui plus que ncessaire. Celleci passe en premier lieu par:
aa
aa
aa
la diffusion de lExprience Utilisateur au sein de lquipe,

la dfense des utilisateurs, de leur activit et de leurs buts (notamment
grce la technique des Personas),
un rel effort autour de la vision du produit.
Ce nouvel lan vers lExprience Utilisateur passe aussi par la dfinition de

guidelines et recommandations ergonomiques, et par lutilisation doutils de
prototypage lgers. Autant dlments source de valeur pour lquipe, les clients
et les utilisateurs finaux.
57
Vers une dmarche Agile UX

Mme si leffort relatif lExprience Utilisateur se poursuit tout au long du projet,
notamment au travers de laccompagnement des quipes de dveloppement et
des tests utilisateurs, lessentiel de lactivit Agile UX doit senclencher ds les
premires itrations.
Ces premires itrations seront le moment idal pour dfinir les cibles de
lapplication concevoir, avec la technique des Personas, dans le prolongement
des user stories.
Une fois la cible dfinie, la conception graphique et ergonomique de lapplication
pourra se poursuivre au fil de leau, essentiellement autour des cinmatiques
(enchanement des crans de lapplication) et dune activit de storyboarding,
cest--dire le prototypage rapide des crans, dans une approche toujours plus
collaborative, au plus juste, et avant tout en support du Product Owner.
Celle-ci va donc se faonner autour de six rgles essentielles:

1 soutenir le travail danalyse et de
priorisation du reprsentant des
utilisateurs ou de lquipe mtier
(Product Owner),
4 proposer plus de ractivit, sur le

recueil et la restitution du feedback
(par des tests moins formels,
progressifs et adapts),
2 faire juste ce quil faut de recherche

utilisateur, de modlisation et de
travail sur linterface, notamment au
dbut du projet,
5 faire du prototypage rapide (adapt

au contexte et aux destinataires,
toujours au plus juste et toujours
source de valeur),
3 travailler sur plusieurs modes la

fois:
6 jouer un maximum sur le volet

participatif et sur la facilitation en
multipliant les ateliers de travail
collaboratifs.
a. lanticipation et la conception
du contenu des itrations futures
(le plus souvent une ou deux
itrations maximum),
b. laccompagnement de lquipe
sur le contenu, les user stories en
cours, que lquipe doit livrer la
fin de litration,
c. le test auprs dutilisateurs
finaux, par exemple du contenu
de litration prcdente, livr par
lquipe,
58
Lide, dornavant, est daller au devant des utilisateurs, et des clients, et de profiter
de toutes les situations dans un contexte o la mobilit gagne du terrain tant
donn que les situations dusage voluent, y compris pour les applications
professionnelles.
Augmenter la frquence des tests, multiplier les Feedbacks

Moins de participants, moins de tches mais plus de tests en variant les
techniques utilises, celles qui ncessitent des participants, sans oublier celles
dites expertes (benchmark, valuationsexpertes, activits dexploration). Dans
cette approche, on garde lesprit Agile en privilgiant les notions: Action , Juste
ce quil faut de formalisme et Collaboration , notamment en passant plus de
temps avec les quipes (workshops, pair designing).
La Guerilla Usability se propose par exemple dinitier la dmarche de test
en interne avant de sorienter trs vite vers la cible du produit en utilisant les
contacts clients, lentourage, les rseaux sociaux, les mailing lists, et ou profitant
de formulaires placs sur le site ou de toutes ces occasions au cours desquelles on
peut croiser ses clients, comme les salons professionnels.
Comment faire des tests dergonomie avec de vrais utilisateurs dans un contexte
Agile? Utiliser le RITE (Rapid Iterative Testing and Evaluation).
Lide est simple: les modifications sont effectues ds quun problme est dtect
avec certitude et que la solution est claire. Autrement dit, une modification peut
soprer suite au passage du premier participant et tre teste, vrifie avec les
suivants: une valeur relle et immdiate.
Ne chez les quipes de dveloppement Microsoft (Games Studio), la mthode
RITE innove dans la pratique des Tests Utilisateurs et rpond parfaitement aux
exigences et la ralit des projets daujourdhui.
Des Tests Utilisateurs plus efficaces

Le RITE se distingue des Tests Utilisateurs classiques sur la restitution du feedback
mais aussi, et surtout, sur son traitement et sa vrification.
Tester toujours plus lExprience Utilisateur

Tester, mesurer, tester encore Tester lExprience Utilisateur en permanence,
cest se lancer dans une dmarche damlioration continue, et laffiner au fur et
mesure du cycle projet ou du cycle de vie produit (logiciels, applications web,
mobiles, sites internet). Cest ainsi sinspirer de nouvelles mthodes, comme le
Guerilla Usability Testing, pour plus de feedback et de valeur.
Les pages daccueil, les parcours clients et tunnels de conversion, les fiches
produit, les processus mtier, le design, tout est testable, quel que soit leur degr
de maturit: version oprationnelle, concepts, esquisses, pistes graphiques,
prototypes haute fidlit ou mme prototypes papier Et lAgilit avec ses cycles
itratifs et ses livraisons incrmentales et rgulires offre des contextes trs
appropris (ex: RITE encadr) pour ces mesures ponctuelles.
Le cycle de vie Agile impose pour autant aux spcialistes de lExprience Utilisateur
dadapter leur dmarche.
Des Tests Utilisateurs moins monotones

Une srie de tests avec 8, parfois 12 ou jusqu 16 participants, sur une mme
application, selon un mme protocole peut devenir lassante. La mthode RITE, en
rupture avec ce modle fig, permet de se sortir dune routine dans laquelle on
peut vite tomber.
Des Tests Utilisateur tout aussi valides

De la rigueur sur le choix des profils tests, un plan de test bien cadr, des
scnarios de test, un protocole verbal (Penser voix haute), un facilitateur la
mthode RITE na rien envier aux Tests Utilisateurs classiques .
RITE repose sur une chelle de dcision pour qualifier les problmes rencontrs,
et dterminer sils seront rsolus et tests immdiatement.
59
4
La transformation
vers lAgilit
61
60
Ou pourquoi et comment gnraliser les pratiques

Agiles lensemble de lentreprise
un niveau de dtail plus fin, on citera par exemple:
aa
aa
aa
aa
Fort de lexprience de projets ambitieux de transformation vers lAgilit,

Valtech considre que 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).
aa
4.2
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,
4. La transformation vers lAgilit
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.
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).
Le projet de transformation
Au-del de la transformation des quipes de dveloppement, ce chapitre fait le

point sur la transformation grande chelle dune organisation.
Une transformation Agile est avant tout un projet de conduite du changement, dont
les ingrdients peuvent tre identifis comme:
peter senge
// Extrait tarduit de langlais
// The Fifth Discipline: The art and
practice of the learning organization
62
4.1
Une organisation apprenante est une organisation qui se nourrit de la varit

des expriences, des comptences et des savoirs individuels, grce une
culture qui encourage les dbats, les dfis et les mises en doute, au travers
dune vision commune ou dune intention partage.
Enjeux et motivations
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
subjectifs (satisfaction des clients, qualit des relations dans les quipes, par
exemple).
aa
aa
aa
aa
aa
aa
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).
CADRAGE
DFINIR LE PROJET
RECUEILLIR DES MOTIVATIONS
CLARIFIER LES OBJECTIFS
DVELOPPER LA VISION
SLECTIONNER LE PRIMTRE
IDENTIFIER LES MOYENS
CHOISIR LA DMARCHE
FIXER LES PRIORITS
PILOTE
DPLOIEMENT ET
OPTIMISATION EN CONTINU
EXPRIMENTER
SLECTIONNER LES PROJETS ET
ACTEURS
RALISER LES PILOTES
ANALYSER LES RETOURS
DEXPRIENCE
... ET AJUSTER LA DFINITION DU
PROJET
TRANSFORMER
PLANIFIER LE DPLOIEMENT
STRUCTURER ET DPLOYER LES
PROCESSUS ET LES MOYENS
(PILOTAGE, FORMATION, SUPPORT,
OUTILS, ETC.)
RALISER LES PROJETS
ANALYSER LES RETOURS DEXPRIENCE
PARTAGER LES EXPRIENCES
GRER LES ATTENTES ET LES
RSISTANCES
OPTIMISER LES PROCESSUS, LES
MOYENS ET LES OUTILS
FIGURE 11
Les tapes dune transformation Agile (Source : Valtech)
63
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. Valtech
prconise une approche combine et concurrente en top-down et
bottom-up.
La vision labore durant le cadrage doit rpondre aux interrogations suivantes 2:

Interrogations
Les managers sont-ils

capables dimpulser
le changement ?
Quel est le degr

de changement
souhaitable, raliste?
64
Quelles sont les

connaissances et
les comptences
disponibles et celles
acqurir ?
Quelles sont les

rsistances et les
contraintes?
2.
Ces critres sont directement issus des enjeux et des

objectifs formuls; le dveloppement de la vision doit
aboutir la quantification de ces critres.
Comment maintenir
la dynamique de
transformation
dans le temps?
Capitaliser les leons apprises durant les projets et partager les

expriences en organisant des communauts internes. Impliquer
fortement les organisations transverses (mthodes et outils, QA,
PMO) qui deviennent, terme, les promoteurs du changement.
Tableau 6
Dveloppement de la vision (Source Valtech)
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.
Identifier le primtre
Dvelopper la vision
Le sponsor a-t-il le
pouvoir de porter
le changement ?
Quels sont les critres

de russite ou dchec?
4.3
Envisager la transformation vers lAgilit de manire systmique
lments de rponse
Le sponsor doit tre conscient de lensemble des enjeux. Un sponsor
membre de la direction gnrale est un facteur de succs. Sil nen nest
pas directement dtenteur, le sponsor doit au moins avoir la possibilit
dintervenir sur le budget associ au projet de transformation.
Marketing
Client
Autres
quipes
support
Les managers doivent tre les premiers convaincus, ils doivent :

organiser des sminaires dinformation,
Utilisateurs
tre forms aux nouvelles techniques de management.

PMO
Lanalyse de la chane de valeur (analyse des processus)

est un bon outil pour cerner le primtre souhaitable.
La transformation concerne les processus de travail, mais
galement lorganisation: il est en effet souvent ncessaire de
remettre en cause les silos organisationnels constitus.
Ressources
humaines
Raliser une tude dcart entre le niveau actuel de

comptence des quipes en place et la cible, du point
de vue managrial, fonctionnel et technique.
Rechercher les rsistances auprs des personnes. Une
transformation est une priode dinstabilit qui suscite
toujours des craintes et des rsistances (perte de qualification,
changement de rle et de responsabilits, etc.)
EQUIPE
PROJET
Achats
figure 11
Exploitation
Help Desk
Mthodes
et outils
Soustraitants
Une quipe de projet en relation avec son cosystme (Source Valtech)
Communiquer largement et au plus tt sur les objectifs,

qui ne doivent pas uniquement tre financiers!
Quel style de conduite

du changement
adopter?
Assurment le plus collaboratif possible: le changement est

bas sur un certain volontariat au dbut (phase pilote), avant
dtre tendu ventuellement de faon impose si ncessaire.
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.
Quelle est la dmarche

adopter?
Un dploiement en big-bang est difficilement envisageable. Valtech

propose de raliser le dploiement selon un cycle itratif, dans un
esprit damlioration continue. A lchelle de la transformation,
on dfinit quelques jalons par an (par exemple trimestriellement)
la fin desquels une rtrospective globale permet de faire le
point sur les progrs raliss et les points de blocage lever.
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!
Daprs Balogun et Hope Hailey 1998
65
Qui?
Revues frquentes
Utilisateur
Lapproche systmique est intimidante et parat hors de porte. Lexprience

montre cependant que lon arrive trs vite aux frontires de lquipe projet.
Nous avons constat de nombreuses reprises que la volont de participer au
changement de la part des personnes relevant des organisations priphriques
tait plus forte que prvu.
Prproduction
et
Exploitation
patrick le go
// Expert et coach Agile
// Valtech
Qui?
quipe
projet
Les changements
majeurs
Bnfices
Risques, freins et
contraintes
Dveloppement
itratif et livraisons
incrmentales
Motivation porte par

les retours des clients
et des utilisateurs
Les anciens chefs de projet

ont du mal sadapter au
partage du pouvoir de dcision.
Il est initialement compliqu
pour les quipes de sadapter
au rythme itratif, surtout si
les itrations sont courtes
Dveloppement
orient par les tests
Organisation perue
comme moins
procdurire, offrant
plus dimagination et
de libert daction
Les dveloppeurs voient

comme une suspicion
dincomptence le fait de
devoir crire dabord les tests,
tout en assurant, en plus, une
couverture trs importante
Auto-organisation
La qualit est sous

contrle permanent
Soustraitants
Mthodes
et outils
Client
(Product
Owner)
Contractualisation
Agile
Lvolutivit des besoins

est prise en compte
Ncessite plus de disponibilit
Rle de Product
Owner: participation
au planning ditration,
dmonstration et
rtrospective ditration
Meilleure visibilit
sur lavancement
Remise en cause du forfait

classique cot, dlai
et primtre figs
Exigences formalises
tout au long du
projet (au lieu dun
cahier des charges
initialement complet)
Possibilit offerte
dintervention sur la
planification (priorits,
mise en production)
Difficult trouver le
bon Product Owner
Qualit et adquation
aux besoins
Tentation de la perfection:
il faut savoir finir le projet:
le client doit apprendre
raisonner en termes de
valeur livre, plutt quen
liste de fonctions fournies
Rduction de la phase
davant-projet
Dploiement
incrmental (optionnel)
Validation incrmentale
intervalles rguliers
Mises en production
plus frquentes.
Bnfices
Mise disposition
de fonctionnalits
plus tt que dans un
projet classique
Meilleure visibilit sur

les dveloppements,
anticipation plus aise
des adaptations des
environnements
Obligation de plus
de transparence sur
lavancement, sur les
difficults rencontres.
La visibilit est
donne au moins
chaque itration.
Limitation des erreurs

et dfauts constats
tardivement, ce qui
rduit les risques pour
le sous-traitant.
Signature de
contrats Agiles
Moins de ngociations
contractuelles en cours
de projet, ce qui rduit les
tensions entre les parties.
Passage dun
processus linaire
bas sur des livraisons
de documents, un
processus itratif et
incrmental, bas
sur des livraisons de
code oprationnel.
Modernisation des
approches et outils.
Acquisition et
dploiement de
nouveaux outils pour
lenvironnement de
dveloppement et
le suivi de projet
Collaboration et
esprit dquipe fort
66
Les changements
majeurs
Risques, freins et
contraintes
Ncessite plus de disponibilit.
Pour tre efficiente, une transformation vers lAgilit doit dpasser

le cadre de lquipe de dveloppement et stendre la cration
dun cosystme Agile.
Ncessite la disponibilit
rcurrente (potentiellement
chaque itration) des quipes
et des environnements.
La planification des
activits est trs
dpendante des projets.
Lobligation de transparence
est souvent antagoniste
des pratiques des
projets au forfait
Un des risques est de

construire un nouveau
standard dtaill et rigide, et
doublier les aspects essentiels
que sont lamlioration et
ladaptation continue.
67
Achats
Modification de la
forme et de lesprit
des contrats.
La ngociation sur
un volume de
fonctionnalits (mesur
en points) est plus simple
que la ngociation sur
une liste de fonctions.
Ressources
humaines
Redfinition des
missions, nouvelles
descriptions de postes,
prise en compte
des changements
organisationnels,
modification
des principes de
rmunration
variable, etc.
Alignement clair des

dfinitions de rle
sur les missions des
intervenants Agiles.
Le rle oprationnel
du management
intermdiaire est amplifi.
Les contrats Agiles gagnantgagnant apparaissent

moins protecteurs que
les contrats au forfait.
Il est inhabituel de sengager
sur un contrat pour lequel
le primtre fonctionnel
est reconnu variable.
La priode de transition peut

tre complexe grer, les
quipes Agiles et non encore
Agiles tant soumises des
rgimes diffrents.
PMO
Les changements
majeurs
Abandon du contrle
davancement sur les
phases classiques
(spcification,
conception,
dveloppement,
tests) au profit dun
suivi par fonctions
livres, adaptation
des tableaux de bord
de suivi de projet.
Bnfices
Risques, freins et
contraintes
Participe la ractivit
de lorganisation (gestion
de portefeuille).
Le changement de
mthodes de travail et des
repres classiques est
dstabilisant. Le temps
dadaptation aux nouveaux
indicateurs et aux outils,
peut tre consquent.
Gestion Agile
du portefeuille de
projet avec utilisation
de KANBAN 3
Meilleure implication
dans les projets,
et rapprochement
avec les besoins des
clients/utilisateurs.
Assurance
Qualit
La qualit est
ladquation aux
attentes du client
plutt que la
conformit au cahier
des charges: les
comptes-rendus
de dmonstration
deviennent un
lment cl.
aa
aa
aa
aa
aa
aa
Meilleure implication
dans les projets, le rle
du QA est revaloris.
Prise en compte de
nouveaux indicateurs,
issus de lusine de
dveloppement logiciel
tableau 7
Ces experts, gnralement externes, ont pour vocation intervenir:
Ncessite la remise en
cause des savoir-faire
Lassurance qualit devient

plus technique que la seule
vrification de documents.
Les cls de la transformation Agile (Source Valtech)
aa
aa
Identifier les moyens 3
aa
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.
aa
Visuellement, un KANBAN se prsente comme un tableau qui porte en colonnes les tapes dun processus (par
exemple tude dopportunit, pr-tude, dveloppement, qualification, dploiement), et pour chaque tape le nombre
maximum de tches que lon peut raliser en parallle (en fonction de la capacit des quipes). Chaque item (ici un
projet) est matrialis par une carte que lon dplace dune colonne lautre ds quune tape est franchie.
auprs de la direction informatique, et autres directions fonctionnelles

(directions mtier, marketing, achats, etc.), pour la quantification des
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 (meneur-facilitateur 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:
68
3.
auprs du sponsor, pour la mise au point de la vision et la qualification des

objectifs gnraux,
Qui?
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.
69
4.4
Critre
Le projet se prte une ralisation
en itrations courtes (les fonctions
peuvent tre dcoupes de faon
tenir dans une itration, les
dmonstrations sont significatives)
La capacit obtenir un retour

rapide et frquent est une des
cls du dveloppement Agile.
Obligatoire
La synchronisation du projet et de
la transformation Agile vite un
grand nombre de rsistances, et
vite de perturber un projet qui
aurait t lanc pralablement.
Obligatoire
Les conditions de lancement

sont runies:
EXPERIMENTER : Le pilote
le projet dmarre en mme temps

que les activits de coaching
une quipe pluridisciplinaire
est constitue
lenvironnement matriel est en place
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.
leffort de monte en comptence

est inclus dans le budget du projet
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.
Les contraintes lies lorganisation

et lenvironnement sont limites.
La priode pilote est loccasion de mettre en place les structures de relais internes
(communauts, sponsors locaux) et les moyens ddis (wiki, forum, sminaires
priodiques) pour le partage des expriences et la propagation des nouveaux
savoir-faire.
Commencer les premiers pilotes en

environnement simple (pas de soustraitance, quipe localise, pas de
dpendance avec dautres projets),
et complexifier progressivement
durant lapprentissage
Le projet pilote apporte une

relle valeur mtier.
Le niveau dimplication du Product

Owner est li la valeur mtier
apporte par le projet.
Important
Les risques4 du projet sont assez

limits (dlais, qualit, budget, etc.)
La pression de lapprentissage en
sus de la pression sur le projet peut
conduire lquipe abandonner
lexprience en cours de route
Important
Le type de projet est reprsentatif

(nouveau dveloppement, intgration,
maintenance, dveloppement de
services ou de composants)
Favoriser les projets de

dveloppement, plus adapts une
adoption Agile by the book
Important
Les primtres fonctionnel et

technique sont reprsentatifs.
Loutillage de la plateforme de
dveloppement est en partie dpendant
du langage (Java, C#, C++, etc.)
Important
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.
70
Commentaires
Slection des projets pilotes et conditions de lancement
Le dimensionnement du projet
est adapt (dure, effort)
Dure idale comprise entre

3 et 9 mois (pour obtenir des
conclusions assez rapidement)
Variable
Important
quipe idale entre 5 et 10 personnes
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:
Critre
Acqurir les savoir-faire par les apports de formateurs, coachs

et mentors externes, et partager les succs et les checs par des
communauts internes pour amplifier la transformation.
tableau 8
Critres de slection dun projet pilote (Source Valtech)
La transformation dune quipe de projet en quipe Agile
Commentaires
Le sponsor est rellement impliqu

et disponible, il facilite la mise
disposition des moyens
Le sponsor de lAgilit est une pice

matresse de la transformation
Obligatoire
Le Product Owner est rellement

impliqu et disponible, il a la capacit
de dfinir le produit dvelopper
Le Product Owner est un rle

difficile tenir, mais il est une pice
matresse pour la russite du projet
Obligatoire
Le Scrum Master et les membres de

lquipe sont motivs pour devenir
Agiles, leur niveau de sniorit est
suffisant pour valoriser lexprience
Durant la transformation, lquipe

peut passer par des phases de
doute et dchecs. La motivation est
essentielle (cycle de Kubler-Ross)
Obligatoire
54
patrick le go
Une des cls de la russite de la transformation Agile, lchelle dune

quipe de projet, est de laisser lopportunit et le temps aux personnes qui
la composent dexprimenter et dapprivoiser ltat desprit Agile. La
recherche damliorations rapides ds la premire itration est absolument
nfaste moyen et long terme.
// Expert et coach Agile

// Valtech
4.
noter quun fort niveau de risque est souvent prsent comme un discriminant absolu et rdhibitoire. Il faut
cependant remarquer quune partie des risques classiques sont traits directement par les pratiques Agiles. A
mditer ?
71
FORMATION
INITIALE
TRANSFORMATION
CONCLUSIONS
LES VALEURS
LES PRATIQUES
ANALYSE
Scrum et
pilotage Agile
Introduction progressive de pratiques dingnierie

Evaluation rgulire de la maturit (GIPS)
Pilotage du coaching par la maintenance dun backlog de transformation
Coaching dquipe et transformation de lenvironnement selon les besoins
INTENSIT DE LACCOMPAGNEMENT
MATURIT DE LQUIPE
dbutante
ITRATIONS
FIGURE 13
autonome
oprationnelle
Retrospective
Partage
des rsultats
...
...
...
Laccompagnement dans la transformation Agile (Source Valtech)
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 par
tous5; 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.
lchelle dun projet pilote, la dmarche de transformation est pilote de faon

Agile: au dmarrage de la transformation, puis la suite de chaque 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.
Pour mesurer la progression
et la maturit de lquipe,
Valtech a dvelopp son
propre GPS quipe Agile
qui reprsente le niveau
dacquisition des pratiques
et techniques Agiles, au
moyen de plus de 200 points
de mesure, regroups en
40 pratiques essentielles et
projets sur 7 dimensions.
Collaborating
100
72
Public vis
Dure et rythme
Formation
initiale Agile
Tous participants
la transformation
2 jours par session de

formation, en dbut
de transformation
Valeurs et principes de
lAgilit, concepts et
pratiques du pilotage
Agile de projet
40
20
0
Testing
Lordre dans lequel les

pratiques sont introduites
est variable car dpendant
des besoins de lquipe et du
projet. Le scnario suivant
non exhaustif est une base
de travail.
Pratiques
dingnierie Agile
Programmeurs,
concepteurs,
testeurs
Quelques journes
dintervention par
quipe au cours de
la transformation
Intgration continue,
dveloppement pilot par
les tests (TDD), exigences
excutables (TDR)6
Scrum Master
Coaching dquipe
de dveloppement
Coaching de
Product Owner
tableau 9
Dveloppeurs,
testeurs, analystes,
concepteurs, etc.
Product Owner
2 4 mois (au minimum

4 itrations) avec un
niveau dintervention
qui diminue au fil du
temps (80% -> 10%)
1 2 mois, raison
de quelques jours
par itration
Mise en place de
lAgilit au sein dun
projet: ltat desprit
Agile, itrations,
planification, estimation,
indicateurs et tableaux
de bord, qualit, etc.
Organisation
quipe
pluridisciplinaire
Membres de
lquipe assigns
100% au projet
Idalement, lquipe
est co-localise
Participation du
responsable de
produit (Product
Owner)
visuelle (tableau
blanc)
Gestion de la
configuration
logicielle
Serveur dintgration
continue
Outils collaboratifs
(par exemple wiki)
25-45 %
60-75 %
80-95 %
Gestion de projet
Ingnierie
Gestion du backlog de
Histoires utilisateur et
produit
Estimations relatives
Plan de release
Dfinition de done
et done done
critres dacceptation
(user story cards)
Tests unitaires
automatiss
Remaniement du code
(refactoring)
Runions
Programmation en
Planning ditration
Standards de code
quotidiennes
Dmonstration
Rtrospective
binme
Tests fonctionnels
automatiss
Dploiement
burndown ditration,
vlocit, release
burnup, prdictibilit,
suivi de la dette
technique
Dispositif daccompagnement pour un projet (Source Valtech)
Voir le Manifesto Agile

La connaissance des pratiques dingnierie est prfrentiellement transmise par lexemple pendant le dveloppement
du projet (coding dojos, mentoring)
Gestion de projet
Fundamental maturity
Functionnal maturity
Fluid maturity
Mesure de maturit Agile (Source Valtech)
Indicateurs:
Dveloppement
de spcifications
Agiles (user stories),
gestion du backlog,
crmonies Scrum
Tracking
ADOPTION EVALUATION - 24/09

reporting et de suivi
davancement
tableau 10
5.
6.
Defining
Developing
Environnement
Outillage de
Planning
60
FIGURE 14
Sujets traits
80
Releasing
Le dispositif daccompagnement pour un projet 66

Intervention
Schmatiquement, la transformation se droule selon les tapes suivantes:
Ordre dintroduction des pratiques Agiles (Source Valtech)
automatis
73
TRANSFORMER : Dploiement
et optimisation en continu
Le dploiement grande chelle des pratiques Agiles est source potentielle
de nombreuses transformations dans lentreprise. Nous abordons ici celles
considres communment comme ncessaires.
Stratgie et organisation
aa
aa
aa
aa
aa
une gestion Agile des responsabilits des personnes limitation de

laffectation dune personne de multiples projets en parallle, constitution
dquipes durables,
une gestion Agile du portefeuille de projets,
ECOSYSTME AGILE / LEAN
ENTREPRISE
Contrats Agile, optimisation de la relation

Cross-fertilisation possible avec les partenaires
OPTIMISATION GLOBALE
Facilitation par les nouveaux processus et l'organisation
Vritable vision client
LIGNE DE PRODUIT
OU DEPARTEMENT
Le tableau ci-dessous rassemble les principales interventions identifies par

Valtech dans des contextes varis ; les interventions, dans leur dtail (contenu,
rythme, dure) sont trs dpendantes du niveau de service attendu, de la taille et
de la complexit des organisations, et de lexprience pralable des personnes en
place 7.
Intervention
Pilotage de la
transformation
Public vis
" Conflits " visibles avec les organisations transverses
tablissement de la vision
Responsables de domaines
fonctionnels ou techniques,
Plan de dploiement
DSI ou dpartement R&D,
Suivi du dploiement
Dpartements support
Formation de coach
interne (Coach
the coach)
Techniques de coaching
Futurs coachs internes
Coaching de
responsable dquipe
Potentiellement, des contraintes dues l'environnement
figure 15
Le plan de dploiement (Source Valtech)
Le plan de dploiement est labor pour rpondre aux enjeux identifis lors du
cadrage, et sappuie sur le contenu du portefeuille de projets pour slectionner les
projets candidats prioritaires.
Approfondissement des pratiques Agiles

Gestion du dploiement Agile
Organisation dquipe (rduction des
silos, quipes pluridisciplinaires,
quipes durables)
Management intermdiaire
OPTIMISATION LOCALE
Qualit, dlai l'chelle du projet
Les succs permettent l'extension
Sujets traits
Sponsor,
OPTIMISATION PARTIELLE
Partage de pratiques
Meilleure gestion des ressources et du portfolio
Mise en commun d'environnements techniques
PROJET
le temps ncessaire ladaptation des processus et de lorganisation.
Risques de rsistance de l'environnement externe
Risque de re-normalisation trop forte des pratiques
74
le temps ncessaire lapprentissage par les quipes de projet (3 6 mois

pour les pratiques de dveloppement Agiles et de gestion de projet),
Le dispositif daccompagnement pour la gnralisation
un retour dinvestissement rapide sur le cot de la transformation

application directe de pratiques exprimentes dans le mme contexte.
ENVIRONNEMENT
la disponibilit des personnes mobilisables (quipe de support en formation,

coaching, mentoring, mise en place des environnements techniques
adquats),
Enfin, le plan de dploiement doit tre revisit et mis jour priodiquement, par
exemple sur une base trimestrielle.
La stratgie de dploiement vise construire progressivement des ensembles

cohrents de plus en plus grands. La construction dcosystmes Agiles locaux
(par dpartement, par ligne de produit, par zone gographique, par type de produit
ou de technologie, etc.) favorise entre autres:
aa
Le plan de dploiement tient galement compte de facteurs dterminants :
4.5
Pilotage de lactivit (indicateurs

de performance)
Rle du manager entraneur-facilitateur
Coaching pour la
gestion de portefeuille
de projets
Coaching et mise en
place de pratiques
tableau 11
7.
PMO,
Gestion dun backlog de projets
Responsables dquipes
Mise en place de KANBAN

Suivi et indicateurs davancement,
tableaux de bord
Responsables et
oprationnels
Le reste de lcosystme
Dispositif daccompagnement (Source Valtech)
Il est souvent bnfique de complter ce dispositif par des interventions de type coaching personnel pour faciliter
la transition de manager gestionnaire en leader facilitateur
75
Parmi les actions qui contribuent le plus significativement la russite dun

programme dadoption de lAgilit, on peut citer:
aa
La rduction des silos organisationnels au sein des quipes techniques

(DSI, R&D). Une organisation en silos calqus sur le cycle en V est
frquemment rencontre : des quipes de dveloppement sont
soutenues par des architectes provenant dun autre dpartement, les
rsultats tant tests par des ingnieurs en provenance dun troisime
dpartement. Dans ce cas, chaque dpartement gre ses personnels et
les alloue temporairement aux projets en fonction des besoins et surtout
des disponibilits! Ladoption des principes Agiles conduit considrer les
silos comme autant de freins la communication directe, la poursuite
dobjectifs partags, la mise en place dun planning favorisant la livraison
au plus tt des fonctions.
>> Crer des quipes pluridisciplinaires intgres, co-localises et stables

tout au long du projet
aa
La gestion Agile ou lean du portefeuille de projets. Augmenter la valeur

cre par les quipes de dveloppement tient entre autres deux facteurs:
la priorisation des projets en fonction de leur valeur mtier. Les clients

doivent participer intensivement la priorisation du portefeuille de
projets.
La rduction du nombre de projets mens en paralllepour viter que les

ressources passent en permanence dun contexte de projet un autre.
>> Prioriser les projets par la valeur mtier, rduire le cot li aux
changements de contexte
76
aa
La transformation du rle de manager gestionnaire en leader facilitateur.

Un des objectifs frquemment assign aux responsables dquipes est den
optimiser le taux dutilisation. Dans le rle du facilitateur, le manager a pour
objectif doptimiser la valeur cre. Dans ce cadre, le manager devient un
point descalade lorsque lquipe rencontre des difficults, et son rle est
dliminer ces difficults pour favoriser la production de lquipe.
>> Les managers deviennent des acteurs de la production de valeur, au lieu

den tre des gestionnaires
aa
La mise en place de communauts Agiles. Les communauts sont un

vecteur organis pour assurer la mise en commun des pratiques, des
questions et interrogations, des checs et russites des projets. Selon la
taille de lorganisation, des communauts locales seront installes (par
dpartement, localisation, ligne de produit, etc.) avec une communaut
globale dont le but est de faire la synthse des ides.
aa
Ladaptation des processus et de lorganisation de lcosystme au rythme

et lesprit des principes Agiles
La validation, la production: adapter lorganisation et la disponibilit
des environnements aux livraisons frquentes. Cela peut constituer un

vritable changement, quand on constate que les environnements de
validation sont trs souvent partags entre plusieurs projets concurrents
(ils doivent tre rservs pour des crneaux fixes et dtermins
longtemps lavance), et quil est courant que les quipes de production
soient loignes du dveloppement.
Agir sur lorganisation et sur les processus
La sous-traitance, contractualisation: les principes Agiles prennent
tout leur sens dans le contexte de projets o lincertitude et la variabilit

rgnent. Dans ce contexte, les relations contractuelles et oprationnelles
doivent tre adaptes pour permettre de la souplesse (contractualisation
Agile), et pour assurer le bon niveau de transparence sur lavancement et
les points de blocage: les contrats au forfait pur ne sont plus adapts
ces exigences.
Mthodes et outils: le corpus mthodologique existant bas sur une
dmarche en cascade doit tre abandonn au profit de la culture Agile.

Un objectif majeur est de concevoir un rfrentiel mthodologique
simple, lger et flexible, de ne normaliser que ce qui est ncessaire, et de
rvaluer les pratiques en permanence.
La cellule qualit, lvaluation de la qualit: dans le mme temps le
rfrentiel mthodologique volue, lvaluation de la qualit passe du

contrle de ladquation au processus (le projet suit-il les phases du cycle
en V, la documentation est elle conforme au standard?) et du contrle de
ladquation aux exigences (le projet a-t-il fourni les fonctions telles que
spcifies?), une valuation de la qualit du service rendu(les fonctions
fournies sont elles acceptes par le responsable du produit, sont-elles
toutes utiles, nen manque-t-il pas dessentielles?).
Ressources humaines, valuation de la performance: alors que les
pratiques Agiles encouragent et ncessitent une approche collaborative,

collective, les systmes de gestion de la performance des membres des
projets sont souvent individualistes8. Ce domaine trs sensible il conduit
au final dterminer le niveau de rmunration ou lavancement des
personnes doit tre revu pour introduire des indicateurs de performance
collective bass sur des critres tels que le nombre de fonctionnalits
livres, la valeur mtier livre, ou des critres Agiles tels que la vlocit,
ou la prdictibilit de lquipe
>> Crer un cosystme adapt est le passage oblig pour un retour sur
investissement significatif
>> Une communaut est un lieu dchange et de gnration dides. Elle

acclre la transformation.
8. Nous avons rencontrs des cas o la performance est mesure en nombre de lignes de codes produites, en nombre de
dfauts dtects ou autres mesures, certes relativement simples acqurir, mais dont la valeur relle est trs faible !
77
valuer les progrs et les rsultats
La plate-forme technique de dveloppement est un sujet essentiel, mais ce point

ne sera pas dtaill ici car la littrature abonde de descriptions de ce quest un
environnement de dveloppement Agile.
La transformation est value sur deux plans. Le premier plan est une mesure
des progrs du dploiement ; le second plan est une mesure des effets de la
transformation.
Par contre, la ncessit damplifier la collaboration entre les membres dun projet
apporte des changements notoires du cot des outils non techniques.
valuer lavancement du projet de transformation
Dans le cas dun projet dune demi-douzaine de participants, travaillant sur le

mme site, avec un Product Owner proche et disponible, la conversation face
face, lutilisation de Post-it et de schmas sur des tableaux muraux seront
suffisants pour assurer la communication.
En environnement distribu, avec une quipe plus importante il devient
absolument ncessaire de disposer des outils qui vont fluidifier et scuriser les
flux dinformation, et tenter de produire une certaine illusion de localit. Audel des systmes de mails ou de messagerie instantane (linformation nest pas
toujours partage, les fils dinformation ne sont pas structurs ni archivs), une
plate-forme collaborative doit tre installe.
A minima, une telle plate-forme comprend des outils de partage/stockage de
documents et informations digitales:
Adapter linfrastructure et les environnements de travail
Lapprciation de lavancement du projet de transformation est, par exemple,

simplement ralise par comptage en nombre de projets ou dquipes, et par une
cartographie des dpartements ou lignes de produits qui ont adopt lAgilit.
Ensuite, des donnes plus subjectives sont recueillies par enqute auprs des
diffrents intervenants des projets pour avoir leur perception des effets de la
transformation : moral des quipes, perception du niveau de reconnaissance,
apprciation sur les nouvelles conditions de travail.
Enfin, si des communauts ont t mises en place, leur activit doit tre apprcie
pour sassurer de leur utilit et du bon fonctionnement du dispositif: frquence des
runions, assiduit, rsultats produits, qualit de la communication, etc.
Mesurer les effets de ladoption de la dmarche et des pratiques Agiles

Les rsultats escompts de la transformation seront mesurs en fonction des
enjeux et des objectifs de dpart; mme sil est complexe dtablir un ROI pour un
tel projet, il nen reste pas moins quil aura une traduction conomique.
Rpertoires partags,
outils de gestion et de
partage de contenu
Sharepoint, documents
Google.
Outils de stockage
et de structuration
dinformations et de
documents tels que les
Wiki, forums, FAQ.
78
Outillage ncessaire
la gestion Agile
du projet (backlog,
estimations et reste
faire, iteration
burndown, release
burnup, vlocit, etc.).
Loffre est aujourdhui
trs toffe.
Pour remplacer les discussions en face--face, les outils de tlcommunication

sont amens voluer:
La mesure de la rentabilit est trs hasardeuse lorsquelle est fonde sur des
hypothses du type si nous avions fait le projet comme avant, il aurait cot X,
mais il a en fait cot Y, donc le Retour sur Investissement est de X Y.
Les bnfices apports par lAgilit sont mesurs par lapprciation des variations
de la qualit de service.
Du point de vue des clients, cela se traduit par:
aa
aa
aa
aa
une amlioration des dlais de mise disposition des fonctions (time to

market),
lutilit des fonctions dveloppes (plutt que le respect du cahier des
charges initial),
la visibilit sur lavancement tout au long du projet,
une diminution des dfauts constats durant la validation et aprs la mise
en production.
Pour lentreprise, en fonction des objectifs initiaux, la mesure de la russite est

tablie par exemple par:
Tlphonie sur IP,
Skype (pour contenir les cots!)
Visioconfrence, ventuellement
base de webcams, outils de
confrence sur le Web (tel que
Microsoft Office Live Meeting)
aa
aa
aa
la variation des parts de march,

la diminution des cots de maintenance,
la rduction des appels au support utilisateur (help desk).
79
Ces rsultats sont obtenus sur le moyen ou long terme, par la mise en place de
tableaux de bords spcifiques et denqutes de satisfaction auprs dutilisateurs
ou de clients.
Enfin, une synthse est labore pour suivre la progression du nombre de projets
russis, mitigs ou en chec et les comparer aux tudes publies (par exemple
ltude du Standish group) ou la situation qui prvalait avant la transformation...
Lessentiel retenir
5
Les difficults
surmonter
Nous rappelons les points essentiels de la transformation vers

lAgilit :
>> Identifier les enjeux et les objectifs de la transformation (objectifs de
lentreprise, facteurs de succs),
>> Dfinir la vision du changement (primtre, roadmap, critres de
succs),
>> Sassurer un support fort et constant au plus haut niveau de
lorganisation (sponsor),
>> Acqurir les moyens de la transformation (formation, mentoring,
coaching, outillage),
>> Ancrer la transformation dans la dure (communauts, coachs
internes, volution du management intermdiaire, transformation de
lcosystme),
80
81
>> Suivre le projet avec un tableau de bord complet (couverture, effets

conomiques, adhsion des personnes).
Ou comment prvenir les risques et lever les rticences
LES Difficults couramment

rencontres
On peut donc affirmer aujourdhui que lAgilit constitue un outil rellement efficace
pour favoriser lutilisation dquipes distantes en nearshore ou en offshore,
capable de rduire la distance entre les hommes au niveau organisationnel,
dmarche projet et outil, et de crer lesprit dquipe si bnfique la ralisation
des projets informatiques.
Ladoption de lAgilit est une dmarche dentreprise qui peut se limiter un projet.
Cependant de la mme manire que le CMMI sadresse une organisation et non
un projet unique, ladoption de lAgilit peut galement avoir comme primtre,
lensemble des projets dune organisation.
Hubert gillon
// Delivery Manager
// Valtech
Une des premires difficults est le passage lacte qui suppose que le
management soit convaincu des bienfaits dune telle approche pour les clients
et pour les projets dlivrant les applications ou les produits.
Autre difficult souvent rencontre, celle dadopter ltat desprit Agile, qui
suppose de ne pas se contenter de faire son march dans les pratiques Agiles.
En effet, ladoption de lAgilit est laffaire de tous et non de certains acteurs qui
mettraient en uvre telle ou telle pratique Agile, pensant que cela limiterait les
risques dchec.
En supposant que tout le monde soit convaincu de lintrt dadopter lAgilit, la
mise en uvre concrte des pratiques telles que planning games, rtrospectives
et backlogs produits suppose une bonne matrise des concepts sous-jacents ainsi
quune exprience concrte des projets.
aa
82
aa
Si lon prend lexemple des tches des backlogs ditration, il arrive trs
souvent que les chefs de projet se retrouvent littralement noys par le
nombre de tches grer. La raison : la granularit des tches gres est
souvent bien trop fine, ce qui induit videmment un nombre draisonnable
de tches : une quipe de 20 personnes dfinissant chaque itration de 4
semaines des tches de 2 heures en charge en moyenne, se traduit par 1600
tches !
Le fait de fonctionner en time boxing (dure ditration fixe quoiquil arrive et
quelque soit le rsultat de litration), de livrer des documents partiellement
raliss (contraire notre culture), ou didentifier 3 voire 4 amliorations
raliser sur la prochaine itration lissue dune rtrospective, constituent
autant de difficults et de piges quil faut tout prix viter, au risque de
discrditer lAgilit jamais.
Aussi est-t-il trs important de faire intervenir un Scrum Master et des experts des
pratiques Agiles pour se faire aider dans la mise en uvre de lAgilit.
La granularit des tches aurait oscill entre 4 heures et 2 jours par tche ce qui
aurait conduit 5 fois moins de tches grer, le projet aurait t livr lheure, et
le nombre damliorations aurait t de 1 par itration au maximum.
5. les difficults surmonter
5.1
Lessentiel retenir
Pour tre Agile :
>> il ne faut pas dtailler toutes les exigences fonctionnelles avant de
dmarrer les dveloppements,
>> on ne prvoit pas entirement lavance les dtails, pour viter le
gaspillage,
>> une machine est ddie lintgration continue,
>> il faut astreindre les dveloppeurs poster plusieurs fois par jour
leur travail sur le dpt central,
>> il faut adopter collgialement ltat desprit Agile,
>> la mise en uvre concrte des pratiques telles que les planning
games, rtrospectives et backlogs produit suppose une bonne
matrise des concepts sous-jacents ainsi quune exprience projet
concrte,
>> il est important de faire intervenir un Scrum Master et des experts
des pratiques Agiles pour se faire aider dans la mise en uvre de
lAgilit.
83
La Gestion du stress
dans les quipes Agiles
Si lintrt des mthodes Agiles nest plus dmontrer, comme lindique le
nombre croissant de projets de ce type, lexprience montre galement les risques
de pression et de stress qui peuvent dcouler de ces pratiques. En tant quexpert,
Valtech est confront ces problmatiques et souhaite avertir les quipes Agiles
et les responsables des drives potentielles, mais surtout leur apporter des
propositions et solutions concrtes.
La problmatique
Une des forces de lAgilit est de mesurer prcisment, court, moyen et long
termes, lavancement et le reste--faire dun projet:
aa
aa
aa
tous les jours, lors de runions quotidiennes,

toutes les 2 ou 3 semaines, lors de dmonstrations, rtrospectives et
runions de planification ditrations,
tous les 3 ou 4 mois, lors de livraisons de releases.
Cela implique pour chaque membre de lquipe un engagement de tous les

instants. Si cette mthode permet damliorer la ractivit aux changements,
grce aux mtriques utilises et la collaboration sans cesse favorise, elle peut
dans certains cas devenir une source de pression et de stress pour lquipe ou pour
lindividu.
84
Un engagement individuel qui nuit lengagement de lquipe

Certains individus supportent mal de ne pas tenir leurs engagements personnels
quotidiens. Dautres encore ont tendance comparer leurs performances
individuelles celles des autres quipiers au lieu de se proccuper des objectifs
communs et favoriser le travail en quipe. Cela se traduit par une baisse de
motivation et de performance.
Une livraison impose primtre constant

Le Product Owner, le client ou le management pousse parfois lquipe Agile faire
des livraisons des dates imposes (time boxing) et sans marge de manuvre sur
le primtre fonctionnel livr. Lquipe perd alors de son autonomie de dcision, et
est contrainte de dtriorer la qualit de lapplication en ralisant moins de tests
par exemple. La pression en rsultant dsolidarise lquipe, et peut impacter la
sant morale et physique de certains.
Quelques solutions
Afin dviter ces drives, Valtech a pu mettre en uvre des solutions permettant
damliorer la collaboration entre les individus et donc de contribuer la russite
des projets.
Un rythme rgulier soutenu et soutenable

Toutes les parties prenantes dun projet se doivent dinstaurer un rythme rgulier
soutenu et soutenable et veiller son maintien, quitte se fixer des objectifs moins
ambitieux court terme et privilgier la performance moyen et long termes,
plutt que la performance trs court terme.
Des rtrospectives ouvertes et sincres
Au travers de ses expriences, Valtech a constat des drives lies au manque de

matrise du rythme sur les projets Agiles, en particulier celles exposes ci-aprs:
A la fin dune itration, chaque quipier doit voquer sincrement les problmes
quil a rencontrs ; attention aux fausses rtrospectives qui ne mettent
en exergue que des problmes superficiels. Afin dviter les non-dits et les
rtrospectives difficiles quand la pression est trop forte, il est conseill de faire
intervenir une personne externe au projet qui aura une vision plus objective et
pourra mieux exprimer les problmatiques sous-jacentes.
La recherche constante de la sur-performance
Pas de sur-engagement
Les drives et leurs consquences
Lamlioration continue, vertu indiscutable dun processus Agile, est parfois

confondue avec la sur-performance. En dautres termes, faire mieux ne signifie
pas forcment faire plus. Ainsi, la mesure et le suivi de la vlocit dune quipe
chaque fin ditration, peut entraner lquipe se fixer des objectifs toujours
plus ambitieux dune itration une autre, sans tenir compte de sa capacit relle.
Cela entraine terme un puisement de lquipe, une baisse de qualit et peut
parfois se traduire par un accident de livraison ditration avec une vlocit
proche de 0.
5.2
Une estimation de charge trop optimiste ou approximative peut provoquer de

mauvaises surprises lors de la ralisation du projet. Les estimations doivent
systmatiquement tre collectives, partages avec le client et se baser sur les
rsultats constats lors des itrations prcdentes.
Pas dengagement contractuel aveugle

Un engagement contractuel rigide visant fixer lavance les dlais de livraison,
les cots et le primtre fonctionnel dun projet, est souvent en dcalage avec
les engagements oprationnels pouvant tre pris par une quipe Agile. Cela
peut mener lchec du projet. Il faut au contraire veiller tablir des contrats
85
Les attentes de chaque partie prenante
Ces solutions peuvent aider les responsables projets viter les drives, un projet
Agile, cest avant tout une histoire humaine, un travail dquipe bas sur lchange
et la collaboration. Fort de ces expriences dans la mise en uvre des mthodes
Agiles, Valtech propose ses clients un accompagnement par le coaching Agile
permettant de mener terme leurs projets dans les meilleures conditions pour les
quipes et donc pour le client.
Prcurseur dans les mthodes Agiles, Valtech a t le premier mettre en place

la contractualisation Agile dans ses projets. Si jusqu prsent la confiance des
clients envers la socit a permis lacceptation de ces contrats, il sagit aujourdhui
de proposer des standards de contrats Agiles, adapts diffrents contextes.
Valtech a travaill avec des directeurs informatiques, des juristes, des intgrateurs,
des experts Agiles indpendants afin didentifier les exigences des projets et les
attentes des diffrents intervenants et de dterminer les volutions apporter aux
contrats actuels.
Lessentiel retenir
Pour tre sr de prenniser la mise en place de lAgilit dans une
quipe, il faut prendre garde :
>> maintenir un rythme soutenu mais soutenable,
>> ne pas dissimuler les vrais problmes lors des rtrospectives,
>> viter le sur-engagement,
>> donner de la flexibilit au contrat.
flexibles, permettant dune part la satisfaction des objectifs mtiers et dautre part
ladaptation aux capacits de ralisation oprationnelles.
Comment concilier les exigences fonctionnelles et budgtaires du client avec

les contraintes oprationnelles et financires du prestataire ? Comment faire
collaborer les quipes du client et du prestataire autour dun projet qui volue au
cours de son dveloppement? Comment transcrire juridiquement ces diffrents
lments permettant de rassurer et protger client et prestataire dans un mme
objectif de russite du projet ? Comment faire adhrer les diffrents services
concerns ce nouveau type de collaboration?
Malgr certaines divergences inhrentes la position de chacun, client/prestataire,
ou sa fonction, technique/juridique, il merge un certain nombre de points
daccord intgrer dans les contrats Agiles et ce, selon deux grands axes : les
concepts et les dogmes.
Les nouveaux concepts intgrer dans un contrat Agile
5.3
La contractualisation Agile
Une volution inluctable pour toutes les parties prenantes de
lentreprise.
86
Les mthodes Agiles tant principalement axes sur la collaboration et sur les
hommes, les lments qui dterminent un projet Agile sont bass sur de nouveaux
concepts redfinir afin que les diffrentes parties aient la mme vision du
droulement du projet:
aa
nathalie lopez-saussier
// Valtech Technology
Clients, juristes, intgrateurs et experts des mthodes Agiles jugent

inluctable ladaptation des contrats aux nouvelles pratiques de ralisation
Agiles. Ils commencent poser ensemble les fondements de nouveaux
contrats flexibles rpondant au mieux aux exigences et contraintes de chaque
partie prenante et de lentreprise.
aa
Avec lintrt croissant des entreprises pour lutilisation des mthodes Agiles dans
les projets IT, il est devenu ncessaire de faire voluer les contrats classiques en
contrats Agiles adapts ces nouveaux principes et mthodes de collaboration.
Outil indispensable et obligatoire, le contrat ne doit plus tre peru comme un
frein mais comme un outil administratif et juridique destin accompagner les
diffrentes parties et rpondant aux contraintes des mthodes Agiles.
aa
aa
Unit de valeur: indispensable pour dterminer les priorits de

dveloppement, la valeur des fonctionnalits du projet est dfinie en fonction
des critres de priorit, dutilisation et de besoin dfinis par le client. Cette
unit de valeur est spcifique chaque client et chaque projet. Les clauses
contractuelles doivent permettre au client de dcider de larrt ou de la
poursuite dun projet ds lors quun minimum dunits de valeur a t
produit.
Point de complexit: en parallle, le point de complexit tablit le rapport
entre les exigences du client et leffort de ralisation, afin de mesurer
le bnfice de chaque fonctionnalit par rapport la tche que cela
reprsente. Dans un contrat Agile, le prestataire sengage raliser un
nombre de points de complexit dans un budget donn.
Backlog de produit: volutif, ce rfrentiel contient la liste des besoins
fonctionnels (et parfois techniques), ainsi que leur valeur et leur complexit.
Transparenceet collaboration : principe de base de la russite dun projet
Agile, la relation entre les quipes du client et celles du prestataire ncessite
un partage et un change quotidiens pour une collaboration sereine
87
aa
Exploitabilit continue: chaque fin de priode (itration), les

fonctionnalits livres sont oprationnelles et peuvent tre mises en
production. Ainsi, leur utilisation immdiate permet de les modifier ou
dadapter le dveloppement au fur et mesure de lavancement du projet.
Evolution des dogmes et fondamentaux

contractuels bass sur la collaboration
Dans le contrat Agile, les engagements du prestataire et du client portent sur les
mthodes de collaboration, les moyens, les outils, la qualit et la vlocit plutt
quexclusivement sur le primtre du produit final, le dlai et le budget. Les projets
sont caractriss par des notions dunit de temps, de lieu et de valeur plutt que
par un objectif fixe et contraignant.
thomas beaugrand
// Avocat spcialiste des contrats
et des mthodes Agiles
// Cabinet Staub & associs
Pour rpondre ces nouveaux aspects contractuels, ce sont les dogmes du contrat
qui doivent tre adapts:
aa
88
La ralisation continue et le dmarrage au plus tt : la diffrence

des projets classiques o les actions sont menes par phases successives
(spcification, conception, dveloppement, tests, recette) avec les risques
deffet tunnel et de litiges la livraison que cela peut entrainer, les
projets Agiles sont construits et raliss par itrations courtes (2 3
semaines) fournissant des incrments fonctionnels dmontrables et
favorisant la collaboration entre le client et le prestataire. Le client nest
plus amen valider des documents intermdiaires techniques mais
accepter directement une partie du produit final. Les actions se mnent de
front et de faon continue, les modifications sont intgres et les priorits
sont values au fur et mesure de la ralisation en fonction des notions
de valeurs dfinies par le client. Ainsi, lengagement du prestataire est de
fournir itrativement des fonctionnalits dmontrables; celui du client est
dassurer un flux continu de demandes et de valider le produit chaque
livraison ditration.
aa
aa
Le copilotage et le coworking : le projet est men sur la base dun vritable

co-working qui inclut une relle collaboration entre les parties au niveau
dcisionnel et oprationnel. Il ny a pas deffet navette entre les quipes du
client et du prestataire puisquelles travaillent ensemble sur le projet et font
le point tous les jours sur lavance du dveloppement et les dcisions de
pilotage.
et efficace. La transparence se traduit contractuellement par un accs

permanent aux indicateurs de pilotage court, moyen, long termes du projet
(itration, release, Product Backlog, indicateurs de vlocit et de qualit).
La devoir de collaboration doit tre explicite dans le contrat, principalement
pour fiabiliser les estimations de complexit.
Lengagement du prestataire sur son quipe: au-del des comptences

de lquipe, le prestataire sengage sur la prennit et la flexibilit de son
quipe (diminution de personnel ou monte en charge) afin de sadapter aux
besoins du projet. Lentente entre les hommes et leurs comptences tant
indispensable la russite du projet, le client a un droit de regard sur le
choix des intervenants du prestataire.
Pour que les projets bnficient des innovations apportes par les mthodes
Agiles, il est indispensable dintgrer ces notions dans le contrat, de mettre en
avant mthodologies et outils de collaboration.
La contractualisation Agile: une volution culturelle

Si la contractualisation Agile est une notion compltement assimile pour Valtech
et ses clients, cest effectivement une vritable volution culturelle qui doit tre
mene dans les entreprises, que ce soit chez les clients ou chez les prestataires.
Il sagit prsent de faire accepter un contrat flexible, o lengagement ne porte
plus sur le triptyque primtre, dlai, budget souvent au dtriment de la qualit
mais sur une combinaison subtile de la vlocit, du cot du point de complexit,
de la qualit, et de la mise en uvre de pratiques itratives et collaboratives au
service de la satisfaction client.
De ce constat, il ressort la ncessit de mettre en place une communication accrue
entre les services concerns, quils soient techniques, achats et/ou juridiques,
avec une impulsion qui doit venir de la direction. La direction a effectivement
la vision et lautorit ncessaires pour dterminer les objectifs communs aux
diffrents intervenants et engager la socit.
Fort de ces constatations et de limplication de ces partenaires, Valtech poursuit
son action dans llaboration de contrats standards favorisant le dveloppement
des mthodes Agiles.
89
Lessentiel retenir
Pour tre certain de prenniser la mise en place de lAgilit dans
une quipe, il faut prendre garde :
aa
aa
>> maintenir un rythme soutenu mais soutenable,

>> ne pas dissimuler les vrais problmes lors des rtrospectives,
>> viter le sur-engagement,
>> donner de la flexibilit au contrat.
aa
aa
des modles contractuels fonds sur la valeur livre,

une plus grande collaboration entre les quipes par la mise en place des
runions quotidiennes inter-quipes (Scrum of scrums), de protocoles
dquipes, de salles de runion virtuelles, de voyages (vers lInde et depuis
lInde) et lutilisation partage de wikis et doutils de gestion du cycle de vie
des applications,
On citera par exemple:
des dmonstrations et des livraisons frquentes, des rtrospectives

auxquelles le client est associ,
le dveloppement de matriel de formation ad-hoc pour optimiser la courbe
dapprentissage des nouveaux membres au sein des quipes projets.
Les sections ci-dessous prsentent brivement certaines de ces pratiques.
5.4
LExternalisation Agile
Les modles de livraison

Le contrat Agile
Fort du retour dexprience rsultant de ladoption des mthodes Agiles ds leur

mergence et de la formation sur la transformation Agile reue de Craig Larman
en 2003, Valtech a tendu les pratiques Agiles de Scrum et XP son centre de
dveloppement offshore Bangalore, en Inde et a adopt des pratiques de
collaboration distance qui ont grandement amlior le modle de dveloppement
duo-shore.
Ce chapitre prsente un aperu des pratiques Agiles dans le modle duo-shore de
Valtech.
90
LApproche Valtech de la dlocalisation

Chez Valtech, nous sommes convaincus que la confiance est au cur de la russite
de la dlocalisation Agile. Une fois la confiance tablie, les processus en place sont
mieux accepts par toutes les parties prenantes.
Les quipes Valtech ont introduit de nouvelles pratiques dans leurs activits
quotidiennes, pour tablir un bon niveau de confiance dans lquipe de projet et
avec les clients, sans compromettre les valeurs et les principes Agiles.
La contractualisation Agile a t adopte dans le modle duo-shore. Outre les

concepts intgrs dans les contrats Agiles prsents dans un chapitre prcdent,
le dveloppement en mode duo-shore ncessite les adaptations suivantes:
aa
aa
aa
aa
aa
un budget de voyage est dtermin lors du lancement du projet,

la facturation est base sur les units de valeur livres (estimes en points
de complexit), plutt que sur des jalons classiques,
la dsignation par le client dun Product Owner ddi au projet est
imprative,
la flexibilit des horaires de travail doit tre mutuellement accepte, en
raison du dcalage horaire potentiel,
le contrat tient compte des exigences de communication entre les quipes
localises onshore et offshore, et tient compte des frais gnraux associs.
Cycles de nouvelles versions et itrations

Pour assurer une bonne prdictibilit de la vlocit de lquipe9, et assurer
galement que la qualit des fonctions ralises sera acceptable, il est ncessaire
de tenir compte de leffort ncessaire au transfert de connaissances et de
comptences. Malgr les pratiques mises en place, le transfert de connaissance
sur un sujet complexe prend plus de temps lorsque lquipe est distance, tout
simplement parce que la communication directe est moins fluide (pas de
conversations possibles la machine caf!)
9.
La vlocit mesure la quantit fonctionnelle construite et livre en tat oprationnel au cours dune itration par
lquipe de projet.
91
Protocoles dquipes
Un protocole dquipe dcrit des rgles, gnralement simples, pour guider la
ralisation dune activit de lquipe. Certains protocoles peuvent tre mis en place
au dmarrage dun projet, et dautres sont issus de ladaptation de lquipe de
nouvelles situations.
Exemple 1: une quipe a mis en place un protocole pour enregistrer les sessions
de chat entre les membres de lquipe. Chaque session dbute par une ligne
Objet et se termine par un Rsum. Une fois complte, la totalit de la
conversation est publie dans le wiki de rfrence.
Exemple 2 : une autre quipe a cr un protocole de gestion des anomalies.
Lorsquun dfaut est dcouvert, il est ajout comme une tche sur le tableau blanc.
Si aprs 4 heures dattente le dfaut nest pas corrig, il est considr comme une
anomalie et gr en tant que tel.
Exemple 3 : pour pallier une indisponibilit temporaire du client, une quipe
offshore a cr un protocole qui lui permet de poursuivre la dfinition fonctionnelle
de lapplication: des membres de lquipe offshore crivent des user stories, et
les soumettent au client via le wiki du projet. Le client a alors 48 heures pour
commenter ou valider la proposition.
Exemple 4: pour amliorer la lisibilit du tableau des tches, une quipe a dcid
de regrouper les user stories en catgories, et chaque catgorie est caractrise
par des cartes de couleurs diffrentes.
Les protocoles dquipe sont gnralement applicables localement (ils ne sont

pas contractuels), car ils sont la traduction oprationnelle des rsultats des
rtrospectives de fin ditration.
Outils lgers
Les outils collaboratifs comme un wiki et les outils de gestion de projet comme
JIRA et Rally qui sont disponibles au travers daccs web, se sont avrs des
moyens de communication plus efficaces que les outils de communication point-point, tels que les e-mails.
Les outils de messagerie instantane comme Skype ou Google Talk offrent la
possibilit, cot ngligeable, dtablir des communications directes avec des
outils de partage de documents ou de vido confrence.
Nous avons plusieurs outils pour amliorer la collaboration, la productivit et le
contrle de qualit. Certains de ces outils ont t dvelopps par nous-mmes,
dautres ont t dvelopps par nos prestataires.
JIRA est utilis pour la gestion de projet, la collecte dindicateurs de performance,
le suivi des exigences et des anomalies.
Le wiki Confluence est utilis comme plate-forme de partage dinformations pour
tous les projets. Les informations concernant un projet (avancement, indicateurs),
le produit (spcifications, architecture, etc.) ou lquipe (contacts, rles, etc.)
sont publies dans le wiki et rendues accessibles tous les membres du projet
ainsi quau client. Avec les fonctionnalits de gestion des versions des pages et
des documents, et lenvoi de mails lorsque des modifications de contenu sont
introduites, lutilisation dun wiki est extrmement efficace. Pour chaque projet,
une Usine de Dveloppement Logiciel (Software Factory) est mise en place pour
prendre en charge lintgration continue (utilisation de CruiseControl ou de
Hudson), lautomatisation de lexcution des tests, et lanalyse statique de code.
Valtech Quality Suite intgre de multiples outils danalyse de code statique (PMD,
Checkstyle, Dependometer, Juca etc.), et fournit un mcanisme de gnration de
rapport efficace concernant la qualit du code et la couverture de tests.
92
Salle de runion virtuelle : les quipes utilisent couramment des outils de vido
confrence simples (webcam + casque et micro, ou tlphone + flux vido projet
sur un cran) lors des runions avec les membres de lquipe. La qualit de la
communication est trs grandement amliore.
LoFAT est un wrapper pour Selenium et QTP visant rduire leffort requis par les
testeurs pour crer et maintenir des scripts de test automatiss.
Structure dquipe
Pour une quipe de taille consquente (par exemple effectif > 20), il est prfrable de
diviser lquipe en groupes pluridisciplinaires centrs sur des units fonctionnelles
du produit. Dans cette organisation (feature team), chaque groupe est responsable
du dveloppement et de lintgration dune unit fonctionnelle (feature).
figure 16
Tableau de Scrum avec les diffrents types dhistoires utilisateur (Source Valtech)
Techniques de collaboration
Chaque feature team est compose danalystes, de concepteurs-dveloppeurs, de

testeurs, guids par un Scrum Master.
93
figure 18 Accueil dun membre de lquipe onshore par ses

homologues offshore Bangalore.
La mise en place de principes Agiles de collaboration a galement

amlior le transfert des connaissances dans le modle de
dveloppement duoshore. Notamment:
figure 17
Product Owner en train

dexpliquer les nuances des
fonctionnalits lquipe
Les sessions de travail en binme (2 dveloppeurs, 2 testeurs

ou 1 dveloppeur/ 1 testeur, travaillant ensemble sur une mme
tche) permettent le transfert des connaissances par la pratique,
une meilleure gestion des risques associs au dpart de membres
de lquipe.
Au cours des visites, la communication directe permet de

rpondre rapidement des questions de dtail qui nauraient
pas t abordes en communication distance, et permet
de recentrer lensemble des participants sur la vision et les
enjeux du projet.
Il a t possible de maintenir la collaboration distance en

utilisant des outils de communication optimiss pour le Web
comme WebEx, Interwise ou bien en utilisant des outils de
prise de commande de PC distance, tels que VNCou RDC, en
combinaison avec les mthodes de tlphonie sur le Web tels
que Skype. La vidoconfrence sest galement avre tre un
outil trs efficace pour assurer la collaboration rapide entre les
quipes distribues.
Les changes directs construisent lquipe, renforcent

la collaboration, chacun tant conscient et au fait des
proccupations et des attentes des uns et des autres.
Une visite du site onshore par le Product Owner et par les

architectes de lquipe onshore au dmarrage dun nouveau
projet est le moyen le plus efficace pour partager la connaissance
du domaine, des besoins fonctionnels et pour dvelopper
larchitecture du produit. Une bon modle du domaine peut
tre construit dans ces conditions, pour assurer la bonne
comprhension des besoins techniques du projet.
Le transfert des connaissances
Infrastructure
En bonne pratique, toutes les activits lies la mise en place de linfrastructure
sont compltes au dmarrage dun nouveau projet avec toutes les activits dites
de calibrage du projet, ce qui comprend le transfert des connaissances du produit.
Dans la mthodologie Scrum adopte par Valtech, cette priode de calibrage porte
le nom de litration de calibrage ou itration-0. Aucune livraison de nouvelle
fonctionnalit du produit ne survient durant cette priode.
Les activits de mise en place de linfrastructure suivante sont compltes lors de

litration 0:
Dimension culturelle
94
Traditionnellement le voyage se produisait une fois, au dbut du projet et plus

tard, au cours du dploiement. Plusieurs fois, seulement un ou deux membres
de lquipe offshore rendaient visite au client. Il ny a eu aucune tentative de
comprendre les dimensions culturelles de lautre quipe. Nous avons fait une
tentative pour rpondre cette proccupation en planifiant plus de voyages.
PARIJAT SINHA
Les voyages frquents nous ont aids approfondir la liaison entre les quipes. Les
personnes qui voyagent participent aux activits culturelles et sportives, visitent
les lieux historiques avec les membres dquipe pour mieux comprendre la culture
du pays. Ces initiatives dinteractions informelles sur diffrents sujets nous aident
comprendre la culture des autres.
// Practice Head
// Valtech India
La frquence des voyages du client sur le site de dveloppement (Product

Owners ou autres parties prenantes) a une influence directe sur la qualit des
applications produites. Le cot de ces dplacements est amorti par la rduction
des gaspillages et des pertes defficacit.
aa
aa
aa
aa
aa
aa
mise en place dun dpt de code source commun pour onshore et offshore,
mise en place dun serveur dintgration continue du code source qui soit
compltement fonctionnel, cest--dire qui soit capable de dclencher une
nouvelle construction chaque modification du code source, dexcuter les
test unitaires, les tests fonctionnels et les outils danalyse de code statique,
et de signaler les anomalies dtectes aux membres de lquipe,
mise en place doutils de gestion de projet et dun wiki accessible tous les
membres de lquipe et que chacun sache utiliser,
chaque membre de lquipe possde deux moniteurs,
mise en place dun espace de travail ouvert pour la circulation libre
dinformations entre les membres de lquipe,
vrification que toute information partage soit accessible par lquipe
onshore, les clients, etc.
95
aa
la multiplication de systmes de contrle de version (par exemple, un pour

les dveloppeurs onshore, un autre pour les dveloppeurs offshore ou pour
le client),
lutilisation de-mails et de rapports comme source primaire dchange
dinformation.
aa
Lessentiel retenir
>> Au fur et mesure que les quipes commenaient gagner en
maturit dans lAgile, nous avons commenc trouver nos propres
modles de travail. Notre engagement onshore-offshore est
maintenant pilot par les valeurs et les principes Agiles.
figure 19
Espace de travail ouvert entour de tableaux blancs chez Valtech India
Le gaspillage selon la dfinition Agile

Les mthodologies Agiles, y compris Scrum, considrent comme du gaspillage
toute tche qui napporte pas de valeur au client. Par exprience, nous identifions
les tches suivantes comme du gaspillage:
aa
aa
96
aa
aa
aa
aa
aa
aa
la cration de documents labors pour le suivi de conformit, concernant

par exemple les revues de code. Ils sont avantageusement remplacs par
des notes rapides ou des discussions entre dveloppeurs,
la sur-qualit dans la documentation de conception, utilisation pousse
dUML. Bien souvent, des schmas dessins au tableau, visibles de tous
en permanence, sont appropris. La documentation ncessaire la
maintenance peut tre labore aprs coup,
la rdaction de comptes-rendus de runion (runion quotidienne,
rtrospective). Le rsultat de la runion quotidienne est traduit en
modifications du task board, les conclusions des rtrospectives peuvent tre
incluses comme nouvelles tches, ou formalises en protocole dquipe,
les runions mal prpares et qui naboutissent aucune conclusion en
raison de labsence dagenda et dobjectif,
la duplication dinformation,
la production de multiples rapports davancement, chacun destin un
lecteur diffrent (client, chef de projet, etc.) mais tous bass sur les
mmes donnes,
la mise en place dintermdiaires dans la communication entre lquipe et le
client (fonction de coordinateur),
la non adhrence au bon protocole pour toute forme de communication.
Mcomprhension due aux assomptions et intentions qui ne sont pas
transparentes,
5.5
LAgilit face aux autres standards

Qualit du produit ou des processus : Agilit ou ISO?
Les mthodes Agiles se dcrivent souvent par une approche peu formelle o le
focus est mis sur la collaboration entre les personnes et sur le produit raliser.
A contrario, les mthodes ISO sont souvent qualifies de procdurires voire
de contraignantes vis vis des rgles applicables, et plus orientes processus que
produit. Ceci semble les opposer, pourtant ...
Le management par la qualit vise dfinir des objectifs qualit au niveau de
lentreprise qui se dclinent ensuite par nature dactivit. Il sagit de planifier et de
dfinir les mthodes ncessaires la matrise des prestations et des produits, et
de mesurer le niveau defficacit atteint. On traduit souvent cette approche par le
concept de PDCA (Plan, Do, Check, Act).
Ce mode de management est assez proche de la logique ditration en Agile avec
notamment sa planification des itrations, ses bilans ditration pour en mesurer
les rsultats et ses rtrospectives, pour dcider des amliorations raliser dans
les itrations futures. Agilit et ISO se rejoignent donc sur des valeurs
communes de planification oprationnelle et damlioration continue.
Ensuite, la dimension majeure de lISO 9001 est son approche processus qui vise
matriser lensemble des activits dun organisme en cohrence avec la politique
qualit de sa direction et les exigences mtier et rglementaires pour satisfaire
au mieux les clients. Les mthodes Agiles apportent cette mme dimension
de matrise projet et produits avec galement une forte implication des clients.
Agilit et ISO se retrouvent donc nouveau sur ces valeurs.
97
FAIRE LE TRAVAIL
TEL QUE PRVU ET
ENREGISTRER LES
RSULTATS
(PREUVES)
PRVOIR LES
ACTIONS DEVANT
TRE RALISES
VRIFIER LE
TRAVAIL RALIS
(REVUE, AUDIT)
AGIR EN
EXPLOITANT LES
COMPTES-RENDUS DE
REVUE, LES RAPPORTS
DAUDIT > PLAN
DAMLIORATIONS
figure 20
Cycle de Deming PDCA (Plan, Do, Check, Act) (Source : Valtech)
Cest oublier un peu vite que le fondement du modle CMMI est dinciter une
organisation samliorer de faon continue en structurant cet effort autour dun
ensemble de processus et avec une approche progressive par niveau de maturit.
Le cycle damlioration continue IDEAL (et plus gnralement toute dmarche de
type PDCA) sous-jacent au modle CMMI se conforme donc bien au paradigme
ditration prn par les mthodes Agiles.
Par ailleurs, CMMI dfinit des objectifs (Specific Goals et Generic Goals) visant
garantir que la qualit des produits raliss ne dpende pas de lhrosme des
quipes mais de lefficacit de ses processus. Pour atteindre ces objectifs, CMMI
propose un certain nombre dexigences structures par processus (Process Area),
dcrivant le quoi faire, et non le comment faire. Il y a donc toute libert
mettre en uvre des pratiques Agiles pour atteindre ces exigences.
Des pratiques CMMI Agiles ?

Si les agilistes taient dj confiants dans la conformit de leurs pratiques avec
un grand nombre dexigences du modle CMMI, on constate aujourdhui que le
SEI (Software Engineering Institute) tudie galement cette compatibilit, travers
divers articles (CMMI or Agile: why not embrace both?) ou ouvrages (Integrating
CMMI and Agile Development). Certains Lead Appraisers ont acquis lexprience
de la mise en uvre des pratiques Agiles et savent donc valuer une organisation
de ce type.
La couverture des pratiques Agiles vis--vis des exigences spcifiques du modle
(Specific Goals) est analyse ci-dessous.
hubert gillon
// Delivery Manager
// Valtech
Agilit et ISO concourent rendre les pratiques de projet plus efficaces au

bnfice des produits livrs et de la satisfaction client.
Le niveau 2, focalis principalement sur les activits projet, est globalement

satisfait par les pratiques Agiles Scrum et XP:
aa
REQM: ce domaine de processus est globalement couvert par:
le rle central du Product Owner, qui permet dassurer la bonne
comprhension des exigences par lquipe de dveloppement lors des

ateliers fonctionnels,
98
le Product Backlog, partag entre lquipe et le Product Owner, il permet
5.6
Mettre de lAgilit
dans une dmarche CMMI
de dfinir le besoin et de tracer les changements,
la traabilit entre les exigences et les tests, grce aux techniques et
aa
des outils de Test Driven Requirement.
PP:
le Plan de Release, le Product Backlog et lIteration Backlog dtaillent la

dcomposition du travail, lestimation des charges et le planning,
les runions de planification (Iteration Planning) permettent de sassurer
Qui a dit inconciliable ?

On a souvent tendance opposer Agilit et CMMI en prtendant qutre Agile
signifie faire limpasse sur tout processus prdfini qui constituerait un carcan
nuisible la crativit et la productivit. Les dtracteurs des modles qualit tel
que CMMI ont coutume daffirmer que mettre en place des pratiques Agiles cest
assurer la qualit du produit, alors que se conformer un modle tel que le
CMMI na pour effet que de rassurer ceux qui lappliquent.
de lengagement des membres de lquipe,
par contre, le plan de data management nest pas couvert explicitement
aa
par les pratiques Agiles, mais lutilisation dun wiki favorise la bonne
maitrise des informations.
PMC: les runions de planification ditration, les scrum meetings, les

runions de fin ditration et rtrospectives assurent le suivi et le contrle
des activits projets.
99
aa
aa
aa
M&A: les informations davancement collectes lors des Scrum meetings,

consignes dans literation backlog et consolides dans les indicateurs
graphiques satisfont un certain nombre de pratiques de ce domaine.
SAM: la slection et la gestion des sous-traitants ne sont pas du tout
couvertes par les pratiques Agiles. Il convient pour cela dtablir des
contrats flexibles innovants (Cf. supra)
PPQA: ce domaine nest pas couvert par des pratiques Agiles de Scrum ou
XP.
CM: la mise en place dune usine logicielle et de lintgration continue
implique de mettre en place un outil de gestion de configuration. Loutillage
de la gestion des changements est galement souvent mis en place.
Par ailleurs, alors que le niveau 2 du CMMI tablit des pratiques projet, le niveau
3 vise linstitutionnalisation de ces pratiques dans lorganisation. Or les pratiques
Agiles restent focalises au niveau projet et ne couvrent donc pas les domaines de
processus organisationnels (OPF, OPD, OT).
Quest-ce quun Rfrentiel Qualit Agile ?

Tout dabord, rappelons que lAssurance Qualit au sens du CMMI couvre
la fois les processus et le produit. Concentrons-nous ici sur le volet processus.
LAssurance Qualit consiste sassurer que lorganisation se conforme
systmatiquement aux dispositions du Rfrentiel Qualit , autrement dit
au cadre mthodologique et aux procdures affrentes. Les mthodes Agiles
introduisent un certain nombre de pratiques dont le succs passe par une
application rigoureuse, comme par exemple les diffrentes crmonies Scrum:
iteration planning, Scrum meeting, revue ditration, rtrospective. Le contrle
qualit du processus incombe au Scrum Master, qui reste nanmoins avant tout
un facilitateur dans la mise en place et ladoption des diffrentes pratiques Agiles.
Le rfrentiel qualit:
aa
Citons les pratiques relatives lingnierie:
aa
aa
aa
aa
RD: la plupart des pratiques du domaine sont couvertes avec la planification

de litration, les ateliers fonctionnels avec une implication du Product
Owner pour dtailler les fonctionnalits slectionnes pour litration et
identifis les critres de validation.
100
aa
aa
TS: les pratiques Agiles ne couvrent pas vraiment le processus de choix

de la meilleure solution technique au travers de ltude de solutions
alternatives.
PI: lintgration continue couvre parfaitement cet objectif.
VER, VAL: sont couverts par les pratiques de dveloppement (eXtreme
Programming) et par les spcifications pilotes par les tests.
Cot gestion de projet, regardons:

RSKM: il ny a pas de description explicite de gestion des risques dans
Scrum ou XP. Cependant il est reconnu que les pratiques Agiles encouragent
les quipes se concentrer sur les risques les plus critiques le plus tt
possible, quil sagisse de risques techniques ou non. Il convient donc
dajouter aux pratiques Agiles classiques une gestion des risques qui pourra
tre mise en uvre lors des iteration planning ou de runions ddies
Les pratiques Agiles ne rpondent pas explicitement aux niveaux 4 et 5. On doit

cependant mentionner que leur mise en place participe lamlioration continue
des processus: lors des rtrospectives de fin ditration, des outils comme les 5
pourquoi ou le diagramme dIshikawa (Fishbone) sont utiliss dans la recherche
de causes racine.
Scrum apparait comme une force pour permettre la couverture de certaines
pratiques gnriques (Generic Goals), par exemple pour assurer lengagement
des parties prenantes (cas du Product Owner et de lquipe), pour assurer la
planification et le suivi de certains domaines de processus grce aux backlogs.
aa
identifie les diverses mthodes et pratiques appliques sans pour autant

les re-dtailler. Il suffit pour cela de se rfrer labondante bibliographie
qui existe sur le sujet. Chaque projet Scrum pourra simplement indiquer
la dure de ses itrations puis utiliser les outils communs de gestion de
backlog et de suivi des risques,
contient divers modles de documents Organisation Agile ne signifie
pas zro documentation mais en nombre rduit. Le principe est de
ne produire que la documentation utile - qui apporte de la valeur - et
au bon moment. Rdiger un volumineux dossier de conception noffre
aucun intrt si lon se conforme dj des standards darchitecture et de
codage. Lutilisation de frameworks peut aider imposer larchitecture et
la rendre transparente. Il est par ailleurs relativement facile dautomatiser
la vrification de telles rgles avec des outils danalyse statique. Par contre,
il est important de garder trace des rflexions qui ont amen ces choix
darchitecture et de frameworks, afin de transfrer la connaissance du
projet et viter ainsi de se reposer plus tard les mmes questions.
Un vrai rfrentiel qualit Agile :
aa
aa
aa
dcrit un ensemble de pratiques et de procdures,

contient uniquement les procdures qui ncessitent dtre dtailles afin
dtre rellement exploitables,
voit sa bonne application contrle en permanence par les Scrum Masters.
Qui occupe la tour divoire de lEPG ?

Un autre des principes Agiles, prn en particulier par Scrum, consiste
responsabiliser totalement lquipe en lui confrant le pouvoir dauto-organisation
et dauto-dtermination. Par exemple, ce nest plus un chef de projet qui affecte
les tches aux membres de lquipe, mais ces derniers qui se les approprient, en
fonction de leurs comptences techniques ou fonctionnelles.
101
Ces principes ont t, eux-mmes, dclins dans Lean Software Development

([Rf.2]) par les principes suivants :
aa
aa
aa
aa
aa
aa
aa
Certains considrent considre quen appliquant le CMMI, on se repose sur

quelques minents qualiticiens pour promulguer les bonnes pratiques respecter.
Or ce cnacle, lEngineering Process Group (EPG), est en fait le rassemblement
temporaire de certains membres des quipes projets, lgitims par leur exprience
et porteurs de lensemble des retours dexprience de leur quipe. Toute lquipe
projet participe ainsi lamlioration des pratiques dune organisation Agile.
LAgilit faon Lean
liminer les gaspillages,

favoriser la connaissance,
De mme, on attend de chacun, lors des rtrospectives, quil identifie les points
damlioration possibles sur les processus en vigueur et fournisse, si possible, les
solutions associes.
construire la qualit intrinsque,

reporter la dcision,
livrer rapidement,
respecter les personnes,
optimiser le systme dans son ensemble.
Agile is Lean
On constate que les pratiques Agiles hrites des mthodes Scrum et eXtreme
Programming servent directement les principes du Lean Software Development
car tous se focalisent sur le produit en visant la satisfaction client.
Sengager dans une dmarche damlioration continue Lean permet aux matrises
douvrage (MOA) et aux directions informatiques de concrtiser les bnfices des
mthodes Agiles, en conciliant de faon optimale leurs impratifs de qualit et de
ractivit.
Lean Software Development considre toutes les mthodes Agiles comme valides
pour appliquer le Lean Thinking au monde du logiciel, et en particulier le
dploiement de la mthode Scrum.
Elisabeth ducarre
// Expert Lean et CMMI
// Valtech
Les principes Lean

Lean est connu dans le monde automobile par lexprience Toyota, devenu le
premier constructeur automobile, reconnu la fois pour la qualit et linnovation
de ses produits. Tout le monde saccorde reconnatre que ce succs est d son
systme de production Lean. Et les dboires de Toyota en 2009 ne tendent qu
prouver limportance de ne pas droger aux principes noncs ci-dessous.
jeff sutherland
// Extrait traduit de langlais
// Agile Software Development
with Srcum
aa
Cette approche vise la fois
102
aa
aa
aa
amliorer la qualit et les dlais,

rduire les cots en tirant le meilleur parti des ressources tant humaines
que matrielles,
aa
viter toute forme de gaspillage.
Le Lean est bas sur les principes fondamentaux suivants :
aa
aa
aa
aa
aa
dterminer ce qui cre de la valeur pour le client,

sassurer que chaque activit du processus apporte de la valeur ajoute ou
est indispensable,
raliser chaque activit juste temps et la demande, pour que ses
rsultats soient utiliss sans dlai,
rechercher la perfection,
sappuyer sur ceux qui ralisent les activits pour rechercher des
amliorations.
aa
Favoriser la connaissance, Reporter la dcision et Livrer rapidement

peuvent se traduire par la segmentation en itrations courtes des projets
Agiles, ce qui apporte aux entreprises clientes la prdictibilit dont elles ont
besoin sur la disponibilit des fonctionnalits en cours de dveloppement.
Elles peuvent ainsi planifier lintgration continue des nouvelles fonctions
leur rythme et en fonction des ressources disponibles, sans surcot ni
surcharge de travail qui induisent de nombreuses sources derreur (Concept
Lean Just in time).
Un exemple concret de la mise en uvre du principe Construire la qualit
intrinsque (dcoulant du principe Rechercher la perfection) peut se
traduire par la technique TDD associe lautomatisation des tests, qui
constituent une approche efficace damlioration de la qualit au plus tt
dans le cycle de dveloppement. Cela permet de savoir immdiatement si ce
qui est produit possde le bon niveau de qualit et de corriger les dfauts au
plus tt.
Nous rpondons galement au concept Lean Stop the line, en corrigeant
les anomalies ds quelles sont dtectes, ce qui vite de gaspiller des
ressources en poursuivant le dveloppement de lapplication sur des bases
non fiables 100%. En effet, la priorit de correction des anomalies doit tre
suprieure la priorit dajouter de nouvelles fonctions au logiciel. Lquipe
dispose pour cela dune usine logicielle qui gnre quotidiennement une
version excutable de lapplication en cours de dveloppement et excute les
tests automatiss afin de dtecter au plus tt les anomalies potentielles.
103
aa
aa
Enfin, le Visual Management est un important concept Lean, largement

soutenu dans les mthodes Agiles par une organisation de lespace de
travail. Il permet toutes les parties impliques (dveloppeurs, testeurs,
chefs de projets, reprsentants du mtier) de visualiser instantanment
ltat davancement du projet, et ceci en termes simples: avertissement
sonore ou lumineux pour alerter dun build cass, consolidation des
divers indicateurs davancement (couverture de tests, anomalies en cours)
sous forme de diagrammes et symboles de couleur sur un cran ou un
tableau la vue de tous.
Lensemble des pratiques cites ci-dessus rpondent galement au premier
principe Eliminer les gaspillages : rduire les retards (itrations courtes),
se concentrer sur les dfauts (TDD), mieux comprendre les exigences (TDR),
etc.
6
glossaire
des pratiques Agiles
Lessentiel retenir
>> Agilit et ISO se rejoignent sur des valeurs communes de
planification oprationnelle et damlioration continue.
>> Toute organisation souhaite rendre ses processus efficaces et
efficients. Certaines dploient des pratiques Agiles pour amliorer
leur ractivit et leur satisfaction du besoin client. Dautres se
focalisent sur lhomognisation et le respect de leurs processus en
mettant en uvre une dmarche damlioration continue telle que
CMMI, ISO ou Lean. La performance globale de lorganisation passe
certainement par la combinaison des deux.
104
>> CMMI impose des objectifs visant garantir que la qualit des
produits raliss ne dpend pas de lhrosme des quipes mais
de lefficacit de ses processus. Pour atteindre ces objectifs,
CMMI propose un certain nombre de pratiques qui sont des
recommandations sur le quoi faire, et non sur le comment
faire. Les pratiques Agiles apportent une rponse ces exigences.
105
Dfinitions
Agilit nest pas synonyme de dsordre, au contraire, le monde de lAgilit
comprend un certain nombre de mthodes trs formalises tel que Scrum ou
eXtreme Programming (XP) pour ne citer que les plus connues.
Equipe Unique (whole team) : il sagit ici de casser le modle cloisonn SpcificateurDveloppeur-Testeur. Les participants dun projet de dveloppement forment une
seule quipe ou tout le monde participe la hauteur de ses comptences, et dans
le cadre dun rle identifi, vers un but commun. Il est important de souligner que
cette pratique consiste aussi rassembler lquipe sur le plan gographique (dans
la mesure du possible).
Livraisons frquentes (Small Releases) : les livraisons sont effectues souvent,
toutes les 2 4 semaines. Cette pratique permet de rduire notamment les
difficults parfois rencontres au moment de la mise en production.
Voici un schma qui est inspir de la reprsentation en 3 niveaux de Ron Jeffries

(un des fondateurs de leXtreme Programming), agrment dautres pratiques
Agiles que nous utilisons rgulirement chez Valtech :
Rtrospective : chaque fin ditration, un temps est prvu pour rflchir au

droulement de litration passe et pour chercher les moyens damliorer
lefficacit pour les itrations futures.
- le cercle extrieur contient les pratiques lies au client,
Sance de planification (Planning game) : la structure des sances de planification

est trs codifie, avec un certain nombre dtapes identifies raliser avec tous
les membres de lquipe. Ces sances de planification reviennent cycliquement
en dbut de chaque itration, dfinissant ainsi les spcifications de lapplication
produire petit petit, plutt quen un seul grand coup de canon en dbut de
projet. Cest lors de ces sances que lon dfinit ce que lon appelle dans Scrum le
Sprint Backlog ou Iteration Backlog, partir de la liste des fonctions / scnarios
rassembls dans le Product Backlog et qui suit lapplication ditration en itration.
- le cercle intermdiaire contient les pratiques de management,

- le cercle intrieur contient les pratiques de dveloppement.
EQUIPE
UNIQUE
DEVELOPPEMENTS
ITRATIFS
PROPRIT
COLLECTIVE
DU CODE
SPCIFICATIONS
EXCUTABLES
(TDR)
106
PROGRAMMATION
EN BINME
INTGRATION
CONTINUE
LIVRAISONS
FRQUENTES
Figure 21
DVELOPPEMENT
PILOT PAR
LES TESTS
RGLES DE
CODAGE
CONCEPTION
SIMPLE
REFACTORING
PERMANENT
6. glossaire des pratiques Agiles
6.1
Tests client automatiss (TDR ou Customer Tests) : on parle aussi de spcifications

excutables ou Test Driven Requirement. Le client dfinit les critres dacceptation
des scnarios fonctionnels sous forme de cas de test.
Cercle Management
SANCE DE
PLANIFICATION
RYTHME
DURABLE
MTAPHORE
RTROSPECTIVE
Les pratiques Agiles issues de XP et Scrum (Source Valtech)
Cercle client
Dveloppement Itratif : lactivit de dveloppement est organise en cycles dont
la dure est fixe une fois pour toute pour le projet. On appelle ces cycles des
itrations ou sprints. Ils dfinissent le rythme du projet (heart beat).
Intgration Continue (Continuous Integration) : le systme dvelopp est

intgralement assembl et test plusieurs fois par jour. Aujourdhui, cette pratique
est grandement facilite par des outils ddis (Hudson, CruiseControl).
Mtaphore (Metaphore) : lquipe doit rechercher et utiliser une analogie comme
modlisation du systme dvelopper. Cette technique trs rpandue dans
le monde informatique permet aussi lquipe de se construire un vocabulaire
commun, notamment pour la communication entre les profils fonctionnels et ceux
techniques.
Proprit collective du code (Collective Code Ownership) : tout le code de
lapplication est accessible en modification par tous les membres de lquipe. Il ny
a pas de domaine rserv. Cette pratique qui a lavantage de rsoudre le syndrome
de lautobus (quest-ce quon fait si une personne de lquipe se fait renverser
par un autobus?), permet aussi de fluidifier le travail quotidien de lquipe. Elle
suppose davoir une communication trs dveloppe sur les dtails techniques
de ralisation. Les tests unitaires intensifs et la programmation en binme
soutiennent cette pratique de manire significative.
Rgles de codage (Coding Standard) : lquipe se fixe des rgles de codage de
manire ce que le code soit homogne et facilement lisible par tous.
107
Rythme durable (Sustainable Pace) : cette pratique initialement intitule par les
Amricains 40 heures par semaine et qui na jamais signifi grand chose dans
la culture franaise, recommande de ne pas faire dheures supplmentaires plus
de deux semaines de suite. Les membres de lquipe doivent tre en forme pour
donner le meilleur deux-mmes. La gnralisation des heures supplmentaires
est le flau des quipes mal organises. Loptimisation des processus apporte
par ce type de mthode permet damliorer notablement la productivit sans
augmenter la charge de travail.
Cercle Dveloppement
Conception Simple (Simple Design) : tout moment, le design de lapplication est
le plus simple possible afin quil puisse rpondre aux exigences rencontres jusque
l. La simplicit ne sous-entend pas de prendre des raccourcis sur la qualit. Le
code doit tre concis, modulaire, cohrent, lisible et doit passer tous les tests.
7
rfrences
bibliographiques
Dveloppement Pilot par les Test (TDD : Test Driven Development) : lactivit
de programmation suit le processus suivant : crire un test > crire le code le
plus simple qui puisse compiler > amliorer le code (refactoring) pour introduire
labstraction ncessaire et liminer dventuelles duplications.
Programmation en binme (Pair Programming) : elle se caractrise par le fait
que le code est crit par deux personnes, un pilote et un copilote. Les rles au sein
du binme et les binmes eux-mmes changent rgulirement, ce qui permet
lquipe davoir une meilleure connaissance du code de lapplication.
Refactoring permanent (Mercyless Refactoring) : pratique de dveloppement qui
consiste amliorer le code sans en changer le comportement.
108
6.2
Abrviations
CMMI :
DSI :
LSD :
MOA :
MOE :
PDCA :
PMD :

ROI :
RSA :
TDD :
TDR :
Capability Maturity Model Integration

Direction des Systmes dInformation
Lean Software Development
Matrise dOuvrage
Matre duvre
Plan Do Check Act
Outil danalyse des flux de donnes et de recherche des copier/coller,
du code mort et des constructions complexes en Java
Return On Investment (retour sur investissement)
IBM-Rational Software Architect
Test Driven Development
Test Driven Requirement
109
Document
[Ref.1]
Agile Software Development

with Scrum
[Ref.2]
diteur
dition
Ken Schwaber
Pearson
Education
2008
Implementing Lean Software

Development, From Concept to Cash
Mary and Tom

Poppendieck
Addison Wesley
2007
[Ref.3]
Gestion de projet : vers

les mthodes Agiles
Vronique
Messager
Eyrolles
2007
[Ref.4]
Agile estimating and planning
Mike Cohn
Prentice Hall
2004
[Ref.5]
Gestion de projet Extreme

Programming
Jean-Louis
Bnard
Eyrolles
2004
[Ref.6]
User stories applied
Mike Cohn
Addison-Wesley
Professional
2004
[Ref.7]
Test-Driven Development
Kent Beck
Pearson
Education
2003
[Ref.8]
Agile and Iterative development
Craig Larman
Addison-Wesley
Professional
2003
[Ref.9]
Coaching Agile Teams: A Companion

for Scrum Masters, Agile Coaches,
and Project Managers in Transition
Lyssa Adkins
Addison Wesley
2010
[Ref.10]
Practices for Scaling Lean & Agile

Development: Large, Multisite, and
Offshore Product Development
with Large-Scale Scrum
Addison-Wesley
2010
Addison-Wesley
2008
Peter Senge
Currency
Doubleday
1990
Gestion de Projet Agile,

[Ref.13] avec Scrum, Lean, eXtreme
Programming, 3eme dition
Vronique
Messager
Eyrolles
2010
The Toyota Way: 14 Management

[Ref.14] Principles from the Worlds
Greatest Manufacturer
Jeffrey K. Liker
McGraw Hill
2004
Agile Product Management

[Ref.15] with Scrum Creating Product
that Customer Love
Roman Pichler
Addison-Wesley
2010
[Ref.16] The Enterprise and Scrum
Ken Schwaber
Microsoft Press
2007
Addison-Wesley
2009
Scaling Lean & Agile Development:

[Ref.11] Thinking and Organizational
Tools for Large-Scale Scrum
[Ref.12]
110
Auteur
The Fifth Discipline - The Art &

Practice of the Learning Organization
Craig Larman,
Bas Vodde
Craig Larman,
Bas Vodde
7. rfrences bibliographiques
7. rfrences bibliographiques
Rf.
111
Alan Shalloway,
[Ref.17]
Lean-Agile Software Development:

Achieving Enterprise Agility
Guy Beaver,
James R. Trott
[Ref.18]
10 contract forms for your

next Agile project
Peter Stevens
[Ref.19] Five dysfunctions of a team
Patrick Lencioni
[Ref.20] Agile software development
Alastair Cockburn
Extreme Programming,
[Ref.21]
embrace change, 2nd edition
Kent Beck
tableau 12
Munich,
21-Oct-09
2009
Toute reprsentation ou reproduction intgrale ou partielle, faite sans le consentement de Valtech,

de ses ayants droit, ou ayants cause, est illicite (Loi du 11 Mars 1957, article 40, alina 1).

Livre Blanc Methodes Agiles PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Livre Blanc Methodes Agiles PDF

Загружено:

Авторское право:

Доступные форматы

transition vers lagilit

lchelle dune organisation

deuxime edition - 2012

// Responsable de loffre Agile

Les mthodes Agiles pour les nuls

La transformation vers lAgilit

1.1. Pourquoi adopter les mthodes Agiles ?

4.1. Enjeux et motivations

1.2. Qui est concern ?

4.2. Le projet de transformation

1.3. Quelles sont les pratiques Agiles les plus rpandues ?

4.3. Dfinir le projet: le cadrage

4.4. Experimenter : Le pilote

4.5. Transformer : Dploiement et optimisation en continu

Les difficults surmonter

LAgilit par la pratique

2.1. Tmoignage dun coach Agile Valtech

2.2. tude dopportunit 

2.3. Recueil des besoins dans le Product Backlog

5.1. Les difficults couramment rencontres

2.4. Test Driven Requirement: la spcification par lexemple

5.2. La gestion du stress dans les quipes Agiles

2.5. TDD, le dveloppement sous contrle

5.3. La contractualisation Agile

2.6. Suivi et pilotage avec lIteration Backlog

5.4. Lexternalisation Agile

2.7. Retour dexprience sur la gestion de projet

5.5. LAgilit face aux autres standards

2.8. Retour dexprience sur lautomatisation des tests

5.6. Mettre de lAgilit dans une dmarche CMMI

2.9. Rsultats obtenus sur des projets raliss par Valtech

Le marketing digital Agile

3.1. La vision du produit

3.2. Personas, vous avez dit Personas?

3.3. La dmarche crative

3.4. Agilit et Exprience Utilisateur

Glossaire des pratiques Agiles

Table des tableaux

Exemple de Burndown Chart

TDR - Donnes initiales

Prsentation schmatique du processus de dveloppement

TDR - Affaire versus Convention

Exemple de pratiques dingnierie et de pilotage de projet

TDR - Affaire versus Convention

Exemple de Product Backlog

TDR - Validation de convention

Gestion des priorits et de la complexit dans le Product

Exemple de Burndown Chart

Les cls de la transformation Agile

Planning dtaill dune itration

Critres de slection dun projet pilote

Planning dtaill dune semaine

Dispositif daccompagnement pour un projet

Planning dtaill dune journe

Ordre dintroduction des pratiques Agiles

Les tapes dune transformation Agile

Une quipe de projet en relation avec son cosystme

Laccompagnement dans la transformation Agile

Mesure de maturit Agile

Tableau de Scrum avec les diffrents types dhistoires

Product Owner en train dexpliquer les nuances des

Accueil dun membre de lquipe onshore par ses

Espace de travail ouvert entour de tableaux blancs

1.1. Pourquoi adopter les mthodes Agiles ?

4.1. Enjeux et motivations

1.2. Qui est concern ?

4.2. Le projet de transformation

1.3. Quelles sont les pratiques Agiles les plus rpandues ?

4.3. Dfinir le projet: le cadrage

4.4. Experimenter : Le pilote

4.5. Transformer : Dploiement et optimisation en continu

2.1. Tmoignage dun coach Agile Valtech

2.2. tude dopportunit

2.3. Recueil des besoins dans le Product Backlog

5.1. Les difficults couramment rencontres

2.4. Test Driven Requirement: la spcification par lexemple

5.2. La gestion du stress dans les quipes Agiles

2.5. TDD, le dveloppement sous contrle

5.3. La contractualisation Agile

2.6. Suivi et pilotage avec lIteration Backlog

5.4. Lexternalisation Agile

2.7. Retour dexprience sur la gestion de projet

5.5. LAgilit face aux autres standards

2.8. Retour dexprience sur lautomatisation des tests

2.9. Rsultats obtenus sur des projets raliss par Valtech

3.1. La vision du produit

3.2. Personas, vous avez dit Personas?

3.3. La dmarche crative

3.4. Agilit et Exprience Utilisateur

TDR - Donnes initiales

Dispositif daccompagnement pour un projet

Ordre dintroduction des pratiques Agiles

Ou en quoi consistent les mthodes Agiles