EDITION EBOOK
Chapitre 1
Prface
AGILE ?
En ce dbut d'anne 2011, nous sommes un tournant important du
monde de l'informatique d'entreprise. Les mthodes classiques de
dveloppement logiciel - le fameux cycle en V o phase aprs phase un
logiciel merge de spcifications rputes "justes" - ont chou
adresser la complexit toujours grandissante de nos Systmes
d'Information. La productivit, s'y est dgrade, c'est dire que le cot
marginal et le dlai de mise disposition d'une nouvelle fonctionnalit
dans le SI ne fait qu'augmenter. "Trop long, trop cher" sont les
principaux griefs adresss aux DSI, dont la dure moyenne du mandat a
considrablement diminu, passant en dessous des deux ans en France
(source Cigref)...
En marge de ce phnomne gnralis, des diteurs professionnels ou
Open Source obtiennent des rsultats l'extrme oppos : leur
productivit est stable malgr la masse croissante de code qu'ils doivent
grer : Google, Eclipse, Firefox, iPhone OS ... Mais ces diteurs ne
fonctionnent plus selon des mthodes classiques, mais au sein d'quipes
intgres produisant en cycles courts des logiciels qualifis d'utile par
leurs utilisateurs.
Mais au fond qui pourrait ne pas le souhaiter ? Qui peut prfrer
livrer dans des dlais longs des logiciels laissant les utilisateurs insatisfaits
? Alors en matire d'informatique, les modes se succdent, reflets de
cette perptuelle insatisfaction : UML, SOA, RAD, ERP, EAI, MDA, XML,
Cloud (was ASP)... et rcemment l'Agile et (bientt) le Lean.
4
Chapitre 1: Prface
Le march l'a bien compris. tout le monde doit tre agile ! Pourtant
ces nouvelles mthodes ne rclament pas qu'un simple coup de peinture,
mais l'abandon de rgles et d'habitudes profondment ancres. Le
dirigeant qui souhaitera obtenir les rsultats des pionniers ne pourra pas
se payer uniquement de mots avec "la suite de modlisation XYZ, votre
meilleur outil pour agiliser vos quipes", "notre chef de projet MOA agile
800 jour", "10 leons pour devenir agile en 15 jours !". Ce serait
reproduire la tragdie de la diffusion du Lean au-del des frontires de
son inventeur Japonais Toyota : en ne reprenant que les pratiques
superficielles, sans changer les habitudes managriales qui laissent peu
d'autonomie aux quipes, nos industriels occidentaux n'ont tir que de
maigres bnfices de cette mthode. Pendant ce temps, Toyota est
devenu leader mondial, car pour lui le Lean n'est pas un corpus fig
d'outils, mais une dynamique quotidienne damlioration continue
emmene par la base avec le soutien des cadres.
Si votre objectif est de rechercher la satisfaction de vos clients, en
livrant rgulirement des fonctionnalits, sans perturber celles qui
fonctionnent dj, ce recueil de pratiques est fait pour vous. Il ne se lit
pas comme un vulgaire manuel d'agilit en 15 leons, mais comme un jeu
de cartes vous permettant de toucher du doigt des principes qui se sont
avrs utiles dans de nombreuses quipes, et que vous pourrez
progressivement apprendre, puis utiliser - ou pas - dans les vtres.
J'espre que vous prendrez autant de plaisir que moi le parcourir.
Prface.........................................................................................iv
Table des matires....................................................................vi
Remerciements........................................................................ xii
Guide de Lecture ..................................................................... xv
Chapitre 2
La rupture Agile ...................................................................... 24
Chapitre 3
Quel avenir pour les approches Agiles?............................... 32
Chapitre 4
Un capital: les pratiques Agiles............................................. 37
Chapitre 5
Comment utiliser le rfrentiel............................................ 47
vi
Table des matires
Chapitre 7
Backlog ...................................................................................... 56
Chapitre 8
Bote de temps......................................................................... 58
Chapitre 9
Build automatis ..................................................................... 60
Chapitre 10
Cartes CRC (Classe, Responsabilit, Collaborateurs) ...... 63
Chapitre 11
Carton, Conversation, Confirmation ................................... 65
Chapitre 12
Charte projet............................................................................ 66
Chapitre 13
Conception au tableau blanc ................................................. 68
Chapitre 14
Conception simple................................................................... 70
Chapitre 15
Critres de simplicit ............................................................. 75
Chapitre 16
Dcoupage d'une user story .................................................. 77
Chapitre 17
Dfinition de "prt" ................................................................ 78
Chapitre 18
Dfinition de 'fini' .................................................................... 79
vii
Chapitre 19
Dploiement continu .............................................................. 82
Chapitre 20
Dveloppement incrmental................................................. 84
Chapitre 21
Dveloppement itratif.......................................................... 85
Chapitre 22
Dveloppement par les tests ................................................ 86
Chapitre 23
Dveloppement par les tests client ..................................... 92
Chapitre 24
Entretien du backlog............................................................... 94
Chapitre 25
Equipe ........................................................................................ 96
Chapitre 26
Estimation................................................................................. 98
Chapitre 27
Estimation relative................................................................ 100
Chapitre 28
Facilitation .............................................................................. 102
Chapitre 29
Gestion de versions............................................................... 103
Chapitre 30
Given - When - Then ............................................................ 104
Chapitre 31
Graphe burn-down................................................................ 105
Chapitre 32
Grille INVEST......................................................................... 107
viii
Table des matires
Chapitre 33
Intgration continue ............................................................. 110
Chapitre 34
Itration .................................................................................. 115
Chapitre 35
Langage omniprsent (ubiquitous language).................... 117
Chapitre 36
Livraisons frquentes ........................................................... 119
Chapitre 37
Niko-niko................................................................................ 121
Chapitre 38
Objets fantaisie (Mock Objects).......................................... 123
Chapitre 39
Personas .................................................................................. 125
Chapitre 40
Planning poker ....................................................................... 127
Chapitre 41
Points (estimation en) .......................................................... 129
Chapitre 42
Programmation en binmes................................................ 131
Chapitre 43
Radiateurs d'information..................................................... 136
Chapitre 44
Refactoring ............................................................................. 138
Chapitre 45
Responsabilit collective du code ...................................... 142
Chapitre 46
Rythme soutenable ............................................................... 145
ix
Chapitre 47
Rtrospective jalon ............................................................... 146
Chapitre 48
Rtrospectives d'itration ................................................... 148
Chapitre 49
Runion quotidienne............................................................. 151
Chapitre 50
Rle - fonctionnalit - bnfice .......................................... 154
Chapitre 51
Salle ddie............................................................................. 155
Chapitre 52
Scrum de Scrums ................................................................... 157
Chapitre 53
Story mapping........................................................................ 159
Chapitre 54
Tableau des tches ................................................................ 161
Chapitre 55
Tableau kanban...................................................................... 164
Chapitre 56
Temps de cycle ...................................................................... 167
Chapitre 57
Test d'utilisabilit ................................................................. 168
Chapitre 58
Test exploratoire .................................................................. 170
Chapitre 59
Tests fonctionnels automatiss .......................................... 172
Chapitre 60
Tests unitaires automatiss ................................................ 176
x
Table des matires
Chapitre 61
Trois questions ...................................................................... 178
Chapitre 62
Tches choisies ...................................................................... 179
Chapitre 63
User stories ............................................................................ 180
Chapitre 64
Vlocit ................................................................................... 186
ANNEXES
Chapitre 65
Bibliographie .......................................................................... 188
xi
Rfrentiel des pratiques Agiles
Chapitre 2
Remerciements
12
Chapitre 2: Remerciements
13
Rfrentiel des pratiques Agiles
Xavier Warzee pour y avoir cru le premier. Merci galement pour leurs
ides et encouragements Karim, Vincent, Romain, Benoit, Alex, Manu
et Manu, Gilles, Jrme, Arthur, Colin et Alain. Merci pour leur amiti
Bernard Notarianni et Jonathan Perret. Pour leur patience, Sophie,
Axel, Erwan et Mika.
Image de couverture: reprsentation en volume dite "Alexander",
extraite de Wikimedia Commons, par l'utilisateur Bastianow d'aprs J.
Scholten.
14
Chapitre 3: Guide de lecture
Chapitre 3
Guide de lecture
15
Rfrentiel des pratiques Agiles
16
Chapitre 4: Au commencement tait... le Gnie Logiciel
Chapitre 4
Au commencement
tait... le Gnie Logiciel
17
Rfrentiel des pratiques Agiles
DE GARMISCH ROME
On fait en gnral remonter l'histoire de la discipline l'anne 1968, et
en particulier une confrence organise sous l'gide de l'OTAN dans le
cadre enchanteur de Garmisch-Partenkirchen, une station de sports
d'hiver, aux pieds des montagnes de Bavire.
Il y eut non pas une mais deux confrences de l'OTAN sur le Gnie
Logiciel, un an d'intervalle; mme les rares auteurs qui font rfrence
la confrence de 1968 semblent ignorer celle qui se tient en 1969
Rome.
Les actes des deux confrences sont disponibles sur le Web, dans
une version PDF d'une qualit remarquable alors que la plupart des
documents de cette poque sont en gnral simplement scanns, donc
non indexs ni "cherchables". Ils mritent d'tre lus avec attention. (On y
18
Chapitre 4: Au commencement tait... le Gnie Logiciel
19
Rfrentiel des pratiques Agiles
20
Chapitre 4: Au commencement tait... le Gnie Logiciel
SUR-PLACE
Plus de quarante ans aprs, les "symptmes" de la "crise" semblent
persister, inchangs. D'importantes drives continuent frapper des
projets informatiques de grande ampleur: ainsi Chorus), le nouveau
systme d'information destin toutes les administrations franaises,
dfraie la chronique en 2010 par ses drapages considrables.
Le projet prvu sur quatre ans dmarre en Mars 2006, son cot
annonc aux parlementaires l'origine est dj important: 600M. Ds le
dbut 2008 apparaissent les premires drives et l'on apprend que des
retards sont envisager, que le budget serait dpass. Fin 2008, une
"mise au point" du ministre permet d'apprendre qu'en fait le budget
communiqu ne tenait pas compte des cots de fonctionnement, chiffrs
100M annuels sur cinq ans: la facture serait donc de 1,1Md. Un petit
oubli, en somme. (Un rapport parlementaire de juillet 2010, un peu
inquitant, recommande "d'actualiser l'valuation du cot complet de
Chorus" - ce qui laisse supposer que ce cot rel est encore inconnu
l'heure actuelle...) Les dlais s'accumulent, et ds 2009 Chorus qui devait
21
Rfrentiel des pratiques Agiles
MONOPOLE
Malgr ce peu de succs apporter des solutions la "crise", la discipline
devient une institution et continue bien se porter pendant les annes
70, 80, 90. Il faut dire (et, regret car ils sont passionnants, sans rentrer
dans le dtail) que bien des bouleversements caractrisent ces dcennies,
22
Chapitre 4: Au commencement tait... le Gnie Logiciel
23
Rfrentiel des pratiques Agiles
Chapitre 5
La rupture Agile
THORIE DE LA RUPTURE
La thorie de la rupture est due Clayton Christensen qui la prsente
en 1997 dans The Innovator's Dilemma. Le sous-titre, loquent, avertit
24
Chapitre 5: La rupture Agile
25
Rfrentiel des pratiques Agiles
26
Chapitre 5: La rupture Agile
27
Rfrentiel des pratiques Agiles
28
Chapitre 5: La rupture Agile
29
Rfrentiel des pratiques Agiles
30
Chapitre 5: La rupture Agile
31
Rfrentiel des pratiques Agiles
Chapitre 6
32
Chapitre 6: Quel avenir pour les approches Agiles?
33
Rfrentiel des pratiques Agiles
34
Chapitre 6: Quel avenir pour les approches Agiles?
35
Rfrentiel des pratiques Agiles
36
Chapitre 7: Un capital: les pratiques Agiles
Chapitre 7
37
Rfrentiel des pratiques Agiles
38
Chapitre 7: Un capital: les pratiques Agiles
39
Rfrentiel des pratiques Agiles
difficile dcrire finement, ont jusqu' prsent surtout fait l'objet d'une
"tradition orale", d'un apprentissage par la transmission individuelle.
Mme si cette dernire garde son importance dans la culture Agile, elle
ne peut que bnficier d'un corpus crit, si celui-ci est soigneusement
ralis et entretenu.
40
Chapitre 7: Un capital: les pratiques Agiles
41
Rfrentiel des pratiques Agiles
42
Chapitre 7: Un capital: les pratiques Agiles
Figure 2: Diagramme
"corrig" Dans ces diagrammes on s'intresse aux caractristiques quantitatives
des situations: une bulle est une quantit susceptible, si on le voulait,
d'tre mesure. Une flche est un lien de cause effet. Lorsqu'elle est
orne d'un "+", l'effet et la cause vont dans le mme sens (si l'un
augmente, l'autre augmente, et vice-versa); orne d'un "-", cause et effet
vont dans le sens oppos. On doit ce type de diagramme Peter Senge
et Jerry Weinberg.
Je dis "susceptibles d'tre mesure" parce que ces diagrammes
donnent surtout des rsultats qualitatifs. Il existe des outils permettant
de transformer des diagrammes de ce type en simulations numriques.
Mais ds que l'on fait intervenir tous les facteurs qui rendent l'analyse
plus raliste, la complexit des modles rend cette analyse laborieuse,
alors qu'on peut obtenir de trs bons rsultats sur la base d'une analyse
quantitative. Ainsi on voit sur le second diagramme que le cot du test
est fonction de plusieurs variables, notamment la taille du projet et le
dlai entre ralisation et test: on rend compte du fait que plus il s'coule
de temps entre l'introduction d'un dfaut et sa mise en vidence par le
43
Rfrentiel des pratiques Agiles
test, plus il est difficile corriger. Comme les effets de ces deux variables
se renforcent, on peut s'attendre ce que le cot du test augmente plus
que linairement avec la taille des projets.
Les paramtres qui nous proccupent sont souvent les mmes d'un
projet un autre: taille du projet, taille de l'quipe, dlai, productivit,
qualit, etc. Par contre les influences qui s'exercent sur ces paramtres
peuvent tre trs diffrentes, selon le type d'entreprises (SSII, diteur,
industriel), le secteur d'activit (finance, scientifique, commerce) et
autres caractristiques du contexte. Et, toujours en fonction du
contexte, la priorit accorde ces diffrents paramtres peut tre trs
diffrente. Chez un diteur on pourra privilgier le respect des dlais par
rapport la qualit, dans un contexte industriel l'inverse peut se
produire; dans la finance de marchs les performance peuvent tre le
critre dominant, etc.
Par consquent, il faut s'attendre ce que chaque projet soit rgi par
un modle diffrent. L'idal est de runir plusieurs personnes
concernes par la situation et chercher explorer, dans une session de
type "brainstorm", les liens de causalit entre les diffrentes variables.
Ensuite, on cherche trouver des interventions: des modifications dans
la faon habituelle d'aborder le projet qui, en modifiant le sens d'une
relation existante, en supprimant ou crant de nouvelles relations, aient
une influence favorable sur les paramtres qui nous proccupent sans
pour autant avoir d'influence nfastes. (C'est souvent l qu'est l'os...)
Souvent, on ne trouve une rponse efficace qu'aprs avoir obtenu un
"dclic" qui permet de rduire le modle un nombre moins importants
de variables. Les pratiques agiles sont autant d'interventions permettant
de modifier la structure des influences mutuelles entre les paramtres du
projet. Ainsi la pratique du dveloppement par les tests modifie
profondment l'interaction modlise ci-dessus: pour une bonne partie
l'activit de test a lieu avant le dveloppement, la valeur moyenne du
paramtre "dlai entre l'introduction d'un dfaut et le test permettant de
le dtecter" est rduit de plusieurs ordres de grandeur.
Ces diagrammes d'effets font partie des outils utiliss par les meilleurs
consultants tiquets "Agiles" pour s'assurer de l'efficacit de leurs
interventions. Pour tre efficace avec une approche Agile il faut non
seulement trs bien connatre les mcanismes "typiques" qui rgissent les
projets de dveloppement, mais encore tre capable d'analyser finement
les variations de ces mcanismes propres un contexte donn. La simple
connaissance des pratiques ne suffit pas: il faut savoir pourquoi et
44
Chapitre 7: Un capital: les pratiques Agiles
45
Rfrentiel des pratiques Agiles
46
Chapitre 8: Comment utiliser le rfrentiel
Chapitre 8
Comment utiliser le
rfrentiel
47
Rfrentiel des pratiques Agiles
48
Chapitre 8: Comment utiliser le rfrentiel
pour les adopter, le plus grand nombre de bnfices possibles sur les
aspects du projet qui nous intressent. Peu importe d'o viennent ces
pratiques - de Scrum, d'XP, de Lean...
Il est cependant important, pour plusieurs raisons approfondies plus
loin, de positionner les pratiques dans un contexte historique, de
retracer leurs origines et leur volution. La "dfinition de 'fini'" ne fait
partie de Scrum que depuis quelques annes, et son intgration dfinitive
dans les pratiques considres comme indispensables ne remonte qu'
2006-2007 environ d'aprs les diffrentes sources disponibles: listes de
diffusion, blogs, livres sur le sujet. Ou bien il est possible de pratiquer
Scrum sans utiliser une dfinition explicite de "fini" - auquel cas on doit
se demander s'il est ncessaire dans un contexte particulier d'utiliser
cette pratique - ou bien cet volution s'explique par le fait que seules les
quipes qui l'utilisaient russissaient dans leur application de Scrum, et
qu'on a finalement mis le discours en conformit avec la pratique. La
diffrence entre ces deux scnarios n'est pas anodine.
BIBLIOGRAPHIE SCIENTIFIQUE
Un dernier lment, mais qui a son importance, consiste relever les
travaux scientifiques pertinents. Ceux-ci sont de deux types: thoriques
ou conceptuels, qui vont donner un clairage plus prcis et plus
rigoureux sur les mcanismes par lesquels une pratique produit ses
effets; et, les plus importants, empiriques, qui vont constater dans des
conditions contrles la ralit et l'importance quantitative de ces
prtendus effets.
Cette validation scientifique n'est pas un prrequis l'utilisation de
pratiques qui ont montr leur efficacit. J'aurai l'occasion de revenir sur
ce sujet, mais il faut bien constater que le dialogue entre les chercheurs
qui s'intressent la dynamique des projets agiles d'une part, et les
praticiens d'autre part, n'est pas encore d'une grande qualit. On ne
s'tonnera pas, par consquent, que la recherche tarde s'intresser
ce que les praticiens trouvent vident depuis longtemps, ou que ces
derniers ignorent des rsultats que les chercheurs considrent comme
acquis. Mais la convergence au fil du temps entre ces deux communauts
me semble indispensable.
Si les pratiques sont rellement utiles et produisent leurs effets de
faon fiable, alors on doit tre en mesure de le prouver; sinon c'est
qu'elles ne sont qu'un placebo, et leur utilisation est nuisible puisqu'elles
49
Rfrentiel des pratiques Agiles
50
Chapitre 8: Comment utiliser le rfrentiel
51
Rfrentiel des pratiques Agiles
Chapitre 9
BDD (Behaviour-Driven
Development)
Pratique
DE QUOI S'AGIT-IL?
BDD est une laboration des pratiques TDD (dveloppement par les
tests) et ATDD (dveloppement par les tests client).
Au lieu de parler de "tests", une personne utilisant BDD prfrera le
terme "spcifications". Il s'agit en fait de runir dans un mme document
des exigences (User Stories) exprims selon le formalisme rle-fonction-
bnfice et des scnarios ou exemples exprims selon le canevas given-
when-then, ces deux notations tant les plus lisibles.
En mettant l'accent sur le mot "spcifications", BDD cherche fournir
une rponse unique ce que nombre d'quipe Agiles considrent
comme deux activits spares: l'laboration de tests unitaires et de
code "technique" d'une part, l'laboration de tests fonctionnels (servant
formaliser les exigences) et de "fonctionnalits" d'autre part.
Plutt que parler de "test unitaire d'une classe", une personne ou une
quipe utilisant BDD prfre dire qu'elle fournit les "spcifications du
comportement (behaviour) de la classe". Cela se traduit par une plus
grande attention porte au rle documentaire de ces spcifications: leur
nom doit tre parlant et, complt par leur description structure par le
canevas given-when-then, doit pouvoir servir de documentation
technique.
52
Chapitre 9: BDD (Behaviour-Driven Development)
ON L'APPELLE GALEMENT...
On parle galement de "behaviour driven design" pour des raisons
similaires celles invoques dans le cas de TDD.
Le terme n'a pas t francis.
ERREURS COURANTES
bien que son crateur, Dan North, explique avoir conu BDD
pour rpondre des difficults rcurrentes lors de
l'enseignement de TDD, il faut bien constater que BDD
mobilise un plus grand nombre de concepts que TDD, et il
semble difficile d'envisager qu'un programmeur novice soit
form d'abord BDD sans s'tre pralablement familiaris avec
TDD
il est parfaitement possible d'appliquer BDD sans outils
particuliers, et indiffremment du langage: l'erreur serait d'y
53
Rfrentiel des pratiques Agiles
ORIGINES
l'anctre de BDD est un outil, agiledox, qui permet de gnrer
automatiquement une documentation technique partir de
tests unitaires JUnit, ralis par Chris Stevenson en 2003
visant liminer le mot "test" et le remplacer par
"comportement", Dan North ralise l'outil JBehave et le diffuse
partir de mi-2004
en collaboration avec Chris Matts, North formule le canevas
given-when-then pour intgrer l'activit d'analyse l'approche
BDD, qu'il dcrit dans un article "Introducing BDD" qui parat
en 2006
sont apparus depuis de nombreux outils confirmant
l'engouement pour l'approche BDD, tels RSpec ou, plus
rcemment, Cucumber ou GivWenZen
54
Chapitre 9: BDD (Behaviour-Driven Development)
55
Rfrentiel des pratiques Agiles
Chapitre 10
Backlog
Concept
DE QUOI S'AGIT-IL?
Un "backlog" est une liste de fonctionnalits ou de tches, juges
ncessaires et suffisantes pour la ralisation satisfaisante du projet:
si une tche contenue dans le backlog ne contribue pas aux
objectifs du projet, il faut l'en retirer;
a contrario, ds qu'on a connaissance d'une tche qu'on pense
ncessaire pour le projet, on doit l'inclure dans le backlog
Ces proprits s'apprcient relativement l'tat des connaissances de
l'quipe un instant donn: l'laboration du backlog peut se poursuivre
tout au long du projet.
Il est le principal rfrentiel de l'quipe en matire d'exigences
ERREURS COURANTES
Le backlog n'est pas un cahier des charges.
Dans l'absolu, sa forme n'est pas impose: on peut le reprsenter par
un document Excel, un fichier texte, une base de donnes ou encore par
un ensemble de Post-It ou fiches cartonnes, ces dernires formes tant
les plus courantes parmi les quipes Agiles.
L'important est l'aspect "atomique" des lments d'un backlog, par
opposition un document narratif dans lequel, par exemple, une seule
56
Chapitre 10: Backlog
57
Rfrentiel des pratiques Agiles
Chapitre 11
Bote de temps
Concept
DE QUOI S'AGIT-IL?
Une bote de temps ou "timebox" est une priode fixe pendant laquelle
on cherche excuter le plus efficacement possible une ou plusieurs
tches.
On peut utiliser les "timebox" diffrentes chelles de temps. La
"technique du pomodoro" s'appuie sur des botes de 25 minutes. Dans
un autre domaine que le logiciel, le "speed dating" est connu pour ses
botes de 7 minutes. D'autres domaines peuvent utiliser des dures allant
de la journe plusieurs semaines.
Le plus important est qu'on s'astreint, la fin de la priode, s'arrter
de travailler pour effectuer un bilan: l'objectif est-il atteint, ou
partiellement atteint si on s'est fix plusieurs tches? Dans le cas o une
seule tche tait prvue on ne tient compte que de deux tats possibles
de compltion: 0% ou 100%.
ORIGINES
Le "timeboxing" est une variante de la pratique ancienne de la "deadline",
mais son utilisation explicite comme stratgie de gestion de projets
logiciels remonte sans doute James Martin, Rapid Application
Development, en 1991. Il s'inspire des travaux de Scott Shultz chez
58
Chapitre 11: Bote de temps
59
Rfrentiel des pratiques Agiles
Chapitre 12
Build automatis
Pratique
DE QUOI S'AGIT-IL?
Le terme "build" dsigne la production, partir de l'ensemble des fichiers
qui sont sous la responsabilit d'une quipe de dveloppement, du
produit sous sa forme dfinitive.
Cela inclut non seulement la compilation des fichiers sources,
ventuellement leur regroupement sous la forme de fichiers compresss
(Jar, zip, etc.) mais galement la production de fichiers d'installation, de
mise jour ou cration de bases de donnes, et ainsi de suite.
On parle de "build automatis" ds lors que toutes ces tapes
peuvent tre ralises de manire totalement rptable et sans
intervention humaine, uniquement partir des fichiers sources prsents
dans l'outil de gestion des versions.
ERREURS COURANTES
ne pas confondre build automatis et intgration continue:
l'intgration continue consiste dclencher le plus frquemment
possible le processus de construction (idalement,
automatiquement chaque publication de code dans l'outil de
gestion des versions) et vrifier l'intgrit du rsultat produit,
notamment par l'excution de tests automatiss
60
Chapitre 12: Build automatis
ORIGINES
le principe d'automatiser une mcanique complexe
d'assemblage de composants logiciels ne date pas d'hier: l'outil
"make" remonte ... 1977
bien que la pratique ne soit pas nouvelle, ni limite aux
approches Agiles, ce sont ces dernires qui relancent l'intrt
pour une automatisation complte; la vogue des
environnements intgrs pendant les annes 90 a putt eu
pour effet de marginaliser les outils du type "make", on assiste
ensuite un revirement dans les annes 2000
61
Rfrentiel des pratiques Agiles
62
Chapitre 13: Cartes CRC (Classe, Responsabilit, Collaborateurs)
Chapitre 13
Pratique
DE QUOI S'AGIT-IL?
Les cartes CRC sont un exercice mlant "jeux de rles" et conception
objet.
Afin de dcrire rapidement plusieurs manires d'aborder la
conception d'une mme partie du systme, on crit sur des fiches
cartonnes les noms des principales classes concernes, et, afin de
cerner la faon dont elles interagissent, les responsabilits de chacune et
celles avec lesquelles elles doivent collaborer.
On cherche ensuite valider le modle de conception en simulant un
scnario d'excution, chaque dveloppeur participant la runion jouant
le rle d'une des classes concernes.
Ainsi un dialogue typique pourrait tre: "Bonjour Contrleur
d'Authentification, je suis une Requte Web" - "Trs bien, je vais noter
vos informations d'identit et l'opration que vous souhaitez effectuer et
les transmettre au Gestionnaire d'Accs, s'il vous accepte je vous
redirigerai vers l'Afficheur de Page", etc.
63
Rfrentiel des pratiques Agiles
ORIGINES
La technique des cartes CRC est invente par Ward
Cunningham en reprenant, sur des fiches cartonnes, la
maquette d'une application Hypercard destine documenter
la conception d'un systme; elle fait l'objet d'un article cocrit
avec Kent Beck (1989)
(Pour l'anecdote, c'est partir de l'ide originale de cette
mme application que Ward Cunningham invente en 1995 le
concept du Wiki, qui devient quelques annes plus tard
l'anctre de Wikipedia et l'une des innovations les plus
marquantes de ce qu'il convient d'appeler le Web 2.0)
64
Chapitre 14: Carton, Conversation, Confirmation
Chapitre 14
Carton, Conversation,
Confirmation
Concept
DE QUOI S'AGIT-IL?
Formule propose par Ron Jeffries selon laquelle une User Story est la
conjonction de trois lments:
le carton ou Post-It, qui permet de donner une forme tangible
et durable ce qui n'est sans cela qu'une abstraction, savoir:
une conversation qui peut avoir lieu en plusieurs temps au fil
d'un projet, entre toutes les personnes concernes par un
aspect fonctionnel d'un logiciel: clients, utilisateurs,
dveloppeurs, testeurs; cette conversation est en grande partie
orale mais trs souvent complte par des documents;
la confirmation, enfin, la plus formalise possible, que l'objectif
dont il a t question au cours de cette conversation est
atteint.
65
Rfrentiel des pratiques Agiles
Chapitre 15
Charte projet
Pratique
DE QUOI S'AGIT-IL?
L'quipe rsume, dans un document trs court, idalement susceptible
d'tre affich aux murs de l'espace de travail au format d'une feuille de
"paperboard", les enjeux principaux du projet, son primtre et les
accords rciproques passs avec les commanditaires du projet.
La communaut Agile s'est approprie divers techniques ou
formalismes intressants pour leur capacit condenser ces
informations: par exemple le "dessin riche" issu de l'approche SSM, le
"diagramme de contexte" hrit de l'approche Yourdon pour l'analyse
structure, ou le A3 du Lean (qui tire prcisment son nom du format
de papier).
ON L'APPELLE GALEMENT...
Le terme anglais est "project charter".
ERREURS COURANTES
vitez d'utiliser un "modle de document" pour une charte de
projet; l'intrt de l'exercice consiste cerner l'information
66
Chapitre 15: Charte projet
ORIGINES
le contenu idal d'une charte projet est dfini dans un article
longtemps rest confidentiel, voire obscur: "Charters and
Charterings, Immunizing your Project Against Foreseeable
Failure" (2001)
l'adoption de cette pratique par la communaut Agile a t
lente et graduelle, et sa popularit plus rcente s'explique
probablement par la volont de rpondre la critique souvent
formule qu'une approche Agile porte trop peu d'intrt la
"vue d'ensemble" du projet
67
Rfrentiel des pratiques Agiles
Chapitre 16
Conception au tableau
blanc
Pratique
DE QUOI S'AGIT-IL?
Afin de prendre les dcisions de conception "juste temps", les
dveloppeurs au sein de l'quipe guettent certains moments critiques o
un choix se pose parmi plusieurs alternatives qui peut avoir une influence
durable sur la suite du projet.
Lorsqu'un choix de ce type est identif, une runion impromptue
autour d'un tableau blanc ou d'une session de cartes CRC s'organise,
mobilisant une partie de l'quipe (gnralement deux ou trois
dveloppeurs). Deux facteurs d'efficacit de ce type de session sont
noter:
on envisage plusieurs alternatives, idalement un minimum de
trois; le choix dfinitif se fait parmi des alternatives acceptables
sur la base de critres telles que simplicit ou cohrence avec
l'existant;
on prouves chacune des alternatives proposes en
considrant un scnario concret; par exemple en imaginant
comment le test de recette associ une user story serait
trait dans une conception donne
68
Chapitre 16: Conception au tableau blanc
ON L'APPELLE GALEMENT...
En anglais le terme consacr, provenant de Ron Jeffries dans sa
description d'Extreme Programming, est "quick design session".
69
Rfrentiel des pratiques Agiles
Chapitre 17
Conception simple
Comptence
DE QUOI S'AGIT-IL?
L'adhsion cette pratique implique trois rgles de conduite, sur
lesquelles l'quipe appuie sa stratgie de conception logicielle:
la conception est value selon les 4 critres de simplicit
noncs par Kent Beck, ce qui suppose notamment la pratique
du refactoring mais galement l'adoption de l'heuristique
YAGNI (voir dfinition ci-dessous), fort controverse;
les lments de conception tels que patrons de conception ou
"design patterns", architecture base de "plugins", etc. sont
conus comme ayant un cot et pas uniquement une valeur;
l'quipe cherche diffrer aussi longtemps qu'il est possible de
le faire de faon responsable les dcisions importantes de
conception, afin d'obtenir le plus d'information possible sur la
pertinence de ces dcisions avant d'en payer le cot
Elle s'appuie souvent sur ces pratiques annexes:
sessions improvises de conception
sessions CRC, moins rpandues
remanier vers un pattern
rtrospectives ou revues de conception
70
Chapitre 17: Conception simple
ON L'APPELLE GALEMENT...
la littrature anglophone dsigne souvent cette pratique par
l'expression YAGNI, un acronyme qui signifie "You Aren't
Gonna Need It", c'est--dire "Tu n'en auras pas besoin";
allusion l'argumentation utilise par certains programmeurs
pour justifier une dcision de conception ("Plus tard nous
aurons besoin de telle ou telle capacit technique, alors
pourquoi pas la raliser maintenant")
on emploie galement le terme de "Conception Emergente",
pour insister sur le fait que la conception n'est pas considre
comme une activit qui a lieu antrieurement la
programmation et impose un cadre cette dernire; mais
qu'au contraire une bonne conception ou une bonne
architecture rsultent d'une attention porte tout au long du
projet aux qualits structurelles du code, et "mergent" donc
des interactions entre les dtails de bas niveau et les
proccupations d'ensemble
ERREURS COURANTES
la premire erreur, fatale, serait de ngliger, par exemple lors
du recrutement, l'importance des comptences en conception
au sein de l'quipe, au motif que la conception est "mergente"
ou "au fil de l'eau": ces termes ne signifient pas qu'elle se fera
toute seule!
il s'agit exclusivement de conception logicielle et ce serait un
abus d'invoquer ces rgles pour argumenter par exemple une
dcision relevant des exigences du client ou d'un arbitrage
d'ergonomie
la pratique doit tre modre, voire est contre-indique,
lorsque:
le cot du dploiement de nouvelles versions du
logiciel est important
le projet exige ou doit s'accomoder d'une quipe
plthorique et disperse
71
Rfrentiel des pratiques Agiles
ORIGINES
l'expression YAGNI est associe Extreme Programming ds
les premiers jours (1998)
la formulation des critres de simplicit est peine plus tardive
(avant 2000)
l'application dlibre du remaniement en vue d'obtenir
certains patrons de conception fait l'objet d'une premire
publication par Joshua Kerievsky, "Refactoring to Patterns"
(2004)
les pratiques agiles ayant trait la conception sont relativement
stables dans la priode 2000-2010, avec peu d'innovations par
rapport d'autres domaines comme les tests automatiss
COMMENT S'AMLIORER?
Sur le plan individuel:
Dbutant
je suis capable d'identifier des lments de
conception redondants et de proposer des
simplifications du code existant
Intermdiaire
je suis capable de diffrer une dcision de conception
lie une exigence future, et de dterminer les
critres qui permettront d'arbitrer cette dcision
Avanc
je suis capable d'identifier le moment pertinent pour
introduire une dcision de conception trs
structurante, par exemple une architecture base de
"plugins"
A titre collectif, une tape majeure est franchir par toute quipe
abordant la Conception Simple: partager les dcisions de conception.
Celles-ci ne sont pas uniquement le fait des architectes ou dveloppeurs
senior, elles sont comprises et mise en oeuvre par l'ensemble de l'quipe
qui sait se les approprier.
72
Chapitre 17: Conception simple
73
Rfrentiel des pratiques Agiles
74
Chapitre 18: Critres de simplicit
Chapitre 18
Critres de simplicit
Concept
DE QUOI S'AGIT-IL?
Grille d'valuation propose par Kent Beck pour juger qu'un code
source est "simple":
le code est dot de tests unitaires et fonctionnels et tous ces
tests passent
le code ne fait apparatre aucune duplication
le code fait apparatre sparment chaque responsabilit
distincte
le code contient le nombre minimum d'lment (classes,
mthodes, lignes) compatible avec les trois premiers critres
Le premier critre est ais juger, bien qu'il sous-entende quelque chose
de moins trivial, savoir que le logiciel en question est correct, ne
prsente pas de dfauts. Les tests unitaires ne sont au mieux qu'une
indication favorable de cet tat; le discours Agile tient cependant pour
acquis qu'ils sont la solution la plus pragmatique connue ce jour.
Les second et troisime critres prsentent une plus grande part de
subjectivit. Ainsi le second peut tre interprt littralement:
malheureusement, la "programmation par copier-coller" est une pratique
encore rpandue dans l'industrie et plombe de nombreux projets, le
refactoring est un antidote efficace. Mais les programmeurs plus
chevronns sont capables d'identifier comme "duplication" des
75
Rfrentiel des pratiques Agiles
76
Chapitre 19: Dcoupage d'une user story
Chapitre 19
Concept
DE QUOI S'AGIT-IL?
On considre en gnral que l'estimation associe une user story doit
tre suffisamment petite pour qu'il soit envisageable de raliser cette
story en une seule itration.
Lorsque ce n'est pas le cas, il est ncessaire de dcouper une story en
plusieurs, plus petites mais de telle sorte que chacune garde un rel
intrt pour le responsable produit ou l'utilisateur final.
77
Rfrentiel des pratiques Agiles
Chapitre 20
Dfinition de "prt"
Pratique
DE QUOI S'AGIT-IL?
Par analogie la "dfinition de 'fini'", l'quipe explicite et rend visible les
critres (gnralement une dclinaison de la grille INVEST) faute
desquels une fonctionnalit ne saurait faire l'objet d'un travail au cours
de l'itration qui commence.
ON L'APPELLE GALEMENT...
Traduction directe de "definition of ready".
ORIGINES
appellation trs rcente, formule par Jeff Sutherland en 2008
78
Chapitre 21: Dfinition de 'fini'
Chapitre 21
Dfinition de 'fini'
Pratique
DE QUOI S'AGIT-IL?
L'quipe affiche de faon visible une liste de critres gnriques qui
conditionnent le fait de pouvoir considrer un incrment comme "fini".
Faute de remplir ces critres en fin de Sprint ou d'itration le travail
ralis n'est pas comptabilis dans la vlocit.
ON L'APPELLE GALEMENT...
En anglais "done" signifie "termin, fini". L'anecdote veut que quand on
demande un dveloppeur si quelque chose est "fini" cela n'a qu'un sens
technique: il a fini de coder. Si le sens de la question est de savoir s'il a
fini de coder, de tester, de mettre jour les tests et la documentation, il
faut le regarder droit dans les yeux en insistant: "est-ce que c'est fini-
fini?"
On parle de "Definition of Done" ou "Done List", en franais on
pourra entendre "Dfinition de fini" ou "Dfinition de termin".
Le terme "Sashimi" plus imag gagne du terrain pour dsigner une
"tranche" fonctionnelle laquelle rien ne saurait manquer.
79
Rfrentiel des pratiques Agiles
ERREURS COURANTES
Accorder trop d'importance la liste peut tre contre-
productif: elle doit dfinir le minimum faire pour qu'on puisse
considrer un incrment comme termin
Si la liste n'est qu'implicite, au lieu d'tre affiche au mur, elle
perd beaucoup de son intrt, ce qui fait sa valeur tant
prcisment que chacun est au courant de tous les critres
Constater qu'un incrment n'est pas rellement fini mais se
dire "on reviendra dessus plus tard" rduit considrablement
l'intrt de cette pratique.
ORIGINES
Propose par Dan Rawsthorne en 2002-2004
Rpandue sous ce terme partir de 2007 environ
Considre comme un lment majeur de Scrum
80
Chapitre 21: Dfinition de 'fini'
81
Rfrentiel des pratiques Agiles
Chapitre 22
Dploiement continu
Pratique
DE QUOI S'AGIT-IL?
Le dploiement continu, prolongement de l'intgration continue, est une
pratique visant rduire le plus possible le temps de cycle, le temps
coul entre l'criture d'une nouvelle ligne de code et l'utilisation relle
de ce mme code par des utilisateurs finaux.
L'quipe s'appuie sur une infrastructure qui automatise l'ensemble des
tapes de dploiement (ou "mise en production"), de sorte qu'aprs
chaque intgration qui se solde par des tests passant avec succs,
l'application en production est mise jour.
82
Chapitre 22: Dploiement continu
ORIGINES
cette pratique relativement rcente (2008) est reprsentative
de deux tendances dans la communaut Agile:
adaptation des pratiques Agiles pour les besoins des
nouvelles gnrations de startups, ou Lean Startup
extension de l'approche Agile des mtiers
connexes au dveloppement, en l'occurrence les
mtiers de l'exploitation; c'est le mouvement Devops
83
Rfrentiel des pratiques Agiles
Chapitre 23
Dveloppement
incrmental
Concept
DE QUOI S'AGIT-IL?
Le dveloppement incrmental consiste raliser successivement des
lments fonctionnels utilisables, plutt que des composants techniques.
Un dcoupage en incrments est dit "vertical", en rfrence
l'imagerie habituelle qui prsente les composants techniques d'une
architecture logicielle comme les couches empiles d'un gteau. (Cet
article en est une illustration typique.) Un incrment est une
fonctionnalit complte, mtaphoriquement une tranche verticale du
gteau.
Une approche incrmentale implique ncessairement d'adopter
galement, au moins dans une certaine mesure, une approche itrative,
mais les deux concepts ne sont pas identiques.
84
Chapitre 24: Dveloppement itratif
Chapitre 24
Dveloppement itratif
Concept
DE QUOI S'AGIT-IL?
Le dveloppement itratif implique de dcouper un projet en un certain
nombre de cycles, ou itrations, au cours desquelles on prvoit de
rpter les mmes activits.
Ainsi, on considre comme itratif un cycle dans lequel on prvoirait,
l'issue d'une phase de spcifications et d'analyse, de rpter 3 fois une
itration au cours de laquelle on raliserait successivement la
conception, le dveloppement et le test.
Un tel cycle serait itratif mais ne serait pas "Agile" au sens strict:
l'approche Agile privilgie des itrations nombreuses et trs courtes, et
considre que chaque itration doit regrouper l'ensemble des activits
du dveloppement, de la spcification jusqu'au test.
A distinguer du dveloppement incrmental qui consiste planifier
par lments fonctionnels ayant de l'intrt sparment.
85
Rfrentiel des pratiques Agiles
Chapitre 25
Comptence
DE QUOI S'AGIT-IL?
Ce terme dsigne une technique de dveloppement qui entremle la
programmation, l'criture de tests unitaires et l'activit de remaniement.
Elle propose les rgles suivantes:
crer un seul test unitaire dcrivant un aspect du programme
s'assurer, en l'excutant, que ce test choue pour les bonnes
raisons
crire juste assez de code, le plus simple possible, pour que
ce test passe
remanier le code autant que ncessaire pour se conformer
aux critres de simplicit
recommencer, en accumulant les tests au fur et mesure
La pratique est indissociable de la famille d'outils de tests xUnit, qui elle
doit son vocabulaire: "barre verte" signifie que l'ensemble des tests
unitaires accumuls passent avec succs, "barre rouge" signifie qu'au
moins un test est en chec. (L'chec d'un unique test suffit dclencher
l'affichage rouge, avec sa connotation d'alerte: cette tolrance zro
reflte la philosophie de l'outil et de la pratique.) L'expression "drouler
les tests" dsigne le fait de lancer ou d'excuter tous les tests accumuls
("suite" ou "batterie" de tests).
86
Chapitre 25: Dveloppement par les tests
L'une des notions les plus importantes pour un dbutant est celle de
granularit d'un test. Supposons par exemple qu'on crive un
correcteur orthographique. Un test "gros grain" consisterait vrifier
que lorsqu'il est appel avec un mot mal orthographi, par exemple
"importent", le correcteur renvoie la suggestion "important". Un test
"grain fin" l'inverse vise vrifier la bonne implmentation d'un aspect
plus prcis de l'algorithme de correction: par exemple qu'une fonction
calculant la "distance" entre ces deux mots renvoie bien 1 (une seule
lettre a chang).
ON L'APPELLE GALEMENT...
Le nom anglais est "Test Driven Development", l'acronyme TDD tant
trs souvent utilis.
On parle galement, moins souvent, de dveloppement pilot par les
tests.
A l'origine on parle de "Test First Coding", programmation en
commenant par les tests, souvent abrg en "Test First". A mesure
qu'une communaut de programmeurs s'empare de cette pratique on
cherche lui donner un nom plus valorisant. La variante "Test Driven"
insiste sur le rle dterminant des tests. Une construction inverse
partir de l'acronyme TDD le rinterprte en "Test Driven Design", ou
conception par les tests.
ERREURS COURANTES
Quelques erreurs courantes des programmeurs novices en
dveloppement par les tests:
oublier de drouler les tests frquemment
crire de nombreux tests la fois
crire des tests d'une granularit inadapte
crire des tests non probants, par exemple dpourvus
d'assertions
crire des tests pour du code trivial, par exemple des
accesseurs
Quant l'organisation de l'quipe autour de cette pratique, les cueils
suivants sont courants:
87
Rfrentiel des pratiques Agiles
ORIGINES
L'ide d'une squence chronologique dans laquelle l'laboration de tests
prcde celle des programmes eux-mmes n'est pas nouvelle; c'est en
fait dans la mesure o cette tche incombe aux programmeurs
eux-mmes qu'il existe une rupture. Depuis 1976 date la publication
du livre de Glenford Myers Software Reliability, et jusqu' l'apparition
d'Extreme Programming, il sera communment admis "qu'un
programmeur ne doit jamais tester son propre code".
Cette affirmation prsente comme un axiome fournit une
justification l'tablissement du test comme une discipline spare de la
programmation, le "test indpendant". Jusqu'aux annes 1990, la
tendance se confirme avec la vogue de l'approche "black box testing" et
la domination du march par des outils qui enregistrent et rejouent des
squences de clics (ce qui suppose videmment que le code soit dj
crit!).
On peut donc faire remonter l'historique de cette pratique aux
premiers outils encourageant les programmeurs tester leur propre
code:
l'article "A Brief History of Test Frameworks" prsente
l'histoire apparemment parallle de deux outils remontant
1992 environ
l'vnement le plus dterminant est sans conteste la cration
par Kent Beck de l'outil SUnit pour Smalltalk, dont toute la
famille xUnit va s'inspirer (The Smalltalk Report, octobre 1994)
l'ide d'crire les tests en premier est dcrite comme un des
piliers de l'approche Extreme Programming ds 1996
l'laboration du "Test First" en "Test Driven" fait partie d'une
priode d'intense laboration sur le Wiki C2.com entre 1996
et 2002
88
Chapitre 25: Dveloppement par les tests
COMMENT S'AMLIORER?
Niveaux de performance individuels:
Dbutant
je suis capable d'crire un test unitaire avant le code
correspondant
je suis capable d'crire le code permettant de faire
passer un test
Intermdiaire
je pratique la "correction de dfauts pilote par les
tests", lorsqu'un dfaut est dtect j'cris le test le
mettant en vidence avant de le corriger
je suis capable de dcomposer une fonctionnalit
coder en un certain nombre de tests crire
je connais plusieurs "recettes" pour guider l'criture
de mes tests (par exemple: "pour un algorithme
rcursif, crire d'abord le test pour le cas terminal")
je suis capable d'extraire des lments rutilisables
de mes tests unitaires afin d'obtenir un outil de test
adapt mon projet
Avanc
je suis capable d'laborer une "feuille de route" pour
une fonctionnalit complexe sous forme de tests
envisags, et de la remettre en question si ncessaire
je suis capable de piloter par les tests diffrents
"paradigmes" de conception: objet, fonctionnel, par
vnements...
89
Rfrentiel des pratiques Agiles
90
Chapitre 25: Dveloppement par les tests
91
Rfrentiel des pratiques Agiles
Chapitre 26
Pratique
DE QUOI S'AGIT-IL?
Sur le modle du dveloppement par les tests, cette pratique ajoute au
dveloppement de tests de recette automatiss une contrainte
supplmentaire: ceux-ci doivent tre raliss en amont des
dveloppements correspondants.
L'idal recherch (mais atteint relativement rarement) consiste ce
que le responsable du produit, client ou expert fonctionnel soit en
mesure de dfinir de nouvelles fonctionnalits sous la forme de tests de
recette, sans que l'intervention des dveloppeurs soit ncessaire.
ON L'APPELLE GALEMENT...
Couramment dsigne par l'acronyme ATDD ("acceptance test driven
development"), plus rarement STDD ("storytest driven development").
ERREURS COURANTES
Plus encore que la simple utilisation de tests de recette automatiss,
cette pratique est lie des outils tels que Fit/FitNesse, Cucumber, etc.
92
Chapitre 26: Dveloppement par les tests client
ORIGINES
Kent Beck aborde brivement cette pratique dans son livre
"Test Driven Development: By Example" mais la juge peu
praticable (2003)
c'est partir de 2003-2004 et sous l'impulsion de Fit/FitNesse
que cette pratique fait son chemin malgr les objections
souleves par Beck
93
Rfrentiel des pratiques Agiles
Chapitre 27
Entretien du backlog
Pratique
DE QUOI S'AGIT-IL?
Le responsable client et tout ou partie de l'quipe se runissent
rgulirement pour un "toilettage" du backlog, l'occasion duquel on
peut:
identifier des user stories qui n'auraient plus de sens
crer de nouvelles stories si des besoins nouveaux ont t
signals
rvaluer la priorit des stories entre elles
attribuer des estimations des stories qui n'en ont pas encore
corriger des estimations en fonction de nouvelles informations
dcouper des user stories prioritaires mais encore trop
lourdes pour tre planifies dans une prochaine itration.
ON L'APPELLE GALEMENT...
En anglais "backlog grooming", littrallement "toilettage" ou "pouillage"
du backlog.
94
Chapitre 27: Entretien du backlog
ORIGINES
On doit apparemment l'expression "backlog grooming" Mike Cohn et
elle remonte au moins 2005.
95
Rfrentiel des pratiques Agiles
Chapitre 28
Equipe
Concept
DE QUOI S'AGIT-IL?
Une "quipe" au sens Agile est un petit groupe de personnes affectes
un seul projet, pour la plupart temps plein (un membre d'une quipe
peut avoir par ailleurs des responsabilits oprationnelles, c'est--dire
qui ne constituent pas un "projet" proprement parler).
La notion d'quipe implique le partage des responsabilits: bon ou
mauvais, le rsultat obtenu est le fait de l'quipe plutt que de tel ou tel
individu.
L'quipe runit l'ensemble des comptences ncessaires:
fonctionnelles et techniques. L'accent est mis sur les rsultats obtenir
plus que sur les rles et responsabilits de chacun: un dveloppeur peut
tester, analyser ou dcouvrir des exigences, mme si celles-ci restent
soumises la validation du client; un testeur peut dvelopper si
ncessaire, etc.
ON L'APPELLE GALEMENT...
En anglais "Whole Team" ou "One Team".
96
Chapitre 28: Equipe
ERREURS COURANTES
l'erreur la plus lmentaire est de penser qu'il suffit de runir
un groupe de personnes pour constituer une quipe
une quipe est constitue d'au minimum 3 personnes ( deux,
on forme un binme), et dpasse rarement une dizaine
une mme personne peut intervenir sur plusieurs projets
pendant une mme priode, mais ne fait gnralement pas
partie de plus d'une quipe la fois
ORIGINES
Kent Beck propose l'expression "Whole Team" fin 2004 pendant la
rdaction de la deuxime dition de son livre "Extreme Programming
Explained", en remplacement de sa prcdente ide du "Client sur site",
juge trop restrictive.
97
Rfrentiel des pratiques Agiles
Chapitre 29
Estimation
Concept
DE QUOI S'AGIT-IL?
Une "estimation" au sens usuel en dveloppement logiciel consiste
valuer l'effort ncessaire la ralisation d'une tche de dveloppement.
On cherche ensuite a "agrger" ces estimations individuelles de faon
tablir une planification prvisionnelle d'un projet.
ERREURS COURANTES
Il existe de nombreuses coles de pense au sein de la communaut
Agile concernant les estimations et leur utilisation. Cependant un
consensus se dgage sur un certain nombre d'erreurs lmentaires ne
pas commettre:
une "estimation" n'est pas la mme chose qu'un "engagement";
il n'est pas judicieux de reprocher un programmeur de
mettre 3 jours terminer ce qu'il avait prvu de raliser en 2 -
la notion d'estimation implique une incertitude; confondre
"estimation" et "engagement" conduit les personnes
concernes gonfler artificiellement leurs estimations, ce qui
est contre-productif
une "estimation" n'est pas dfinitive; elle est le reflet
l'information dont on disposait au moment de l'mettre: il est
par consquent toujours admissible de rviser une estimation,
98
Chapitre 29: Estimation
99
Rfrentiel des pratiques Agiles
Chapitre 30
Estimation relative
Pratique
DE QUOI S'AGIT-IL?
Une des nombreuses pratiques d'estimation utilises par des quipes
Agiles. Celle-ci prconise d'attribuer des estimations aux tches ou user
stories, non pas considres isolment, mais en regroupant ensemble
des lments considrs comme de difficult quivalente.
Une mise en oeuvre possible consiste tracer sur un tableau blanc
plusieurs colonnes, autant qu'on souhaite avoir de valeurs distinctes
l'issue de l'activit. Plus le nombre de colonnes est important, plus le
rsultat sera prcis; mais plus il prendra de temps. Certaines quipes
utilisent pour cet exercice les "tailles tee-shirt", de XS XXL.
Cette technique peut galement tre utilise pour ajouter des user
stories un backlog dj estim: plutt que de les estimer isolment, on
cherchera les rapprocher d'une user story dj connue dont la
difficult serait comparable.
ON L'APPELLE GALEMENT...
On parle galement d'estimation par affinit ("affinity estimation") ou
d'estimation par similitude d'effort.
100
Chapitre 30: Estimation relative
ORIGINES
le nom "Affinity Estimating" semble d Lowell Lindstrom qui
met au point cette technique lors d'un Scrum Gathering en
2008
l'ide d'estimation en "tailles tee-shirt" remonte au moins
2005
101
Rfrentiel des pratiques Agiles
Chapitre 31
Facilitation
Concept
DE QUOI S'AGIT-IL?
Un facilitateur est une personne dsigne pour animer une runion. Il ou
elle s'interdit gnralement de participer au contenu de la runion, mais
se cantonne crer les conditions dans lesquelles un groupe en runion
pourra parvenir l'objectif qu'il s'est pralablement fix.
La facilitation est une comptence part entire, dont les tenants et
les aboutissants dpassent largement le cadre des approches Agiles;
plutt que d'en faire ici une description complte, on se rfrera avec
profit aux publications de l'IAF, International Association of Facilitators.
102
Chapitre 32: Gestion de versions
Chapitre 32
Gestion de versions
Concept
DE QUOI S'AGIT-IL?
La gestion de versions n'est pas proprement parler une "pratique"
Agile, puisqu'elle caractrise (heureusement) de trs nombreux projets
de dveloppement mens selon d'autres principes.
Il est cependant pertinent de la citer ici pour deux raisons:
bien qu'elles soient devenues rares, certaines quipes restent
encore rfractaire l'utilisation d'outils de gestion de versions,
or il s'agit l non seulement d'une "bonne pratique" mais d'un
prrequis nombre de pratiques Agiles (intgration continue
par exemple)
il est judicieux pour une quipe Agile d'expliciter sa politique
de gestion de versions, et de s'assurer que celle-ci est adapte
aux pratiques qu'elle utilise
103
Rfrentiel des pratiques Agiles
Chapitre 33
Concept
DE QUOI S'AGIT-IL?
La matrice Given-When-Then est un format recommand pour le test
fonctionnel d'une User Story:
(Given) (Etant donn) un contexte,
(When) (Lorsque) l'utilisateur effectue certaines actions,
(Then) (Alors) on doit pouvoir constater telles consquences
Par exemple:
Etant donn un solde positif de mon compte, et aucun retrait
cette semaine,
Lorsque je retire un montant infrieur la limite de retrait,
Alors mon retrait doit se drouler sans erreur ou
avertissement
Des outils tels que JBehave, RSpec ou Cucumber encouragent l'utilisation
de cette formule.
104
Chapitre 34: Graphe burn-down
Chapitre 34
Graphe burn-down
Pratique
DE QUOI S'AGIT-IL?
L'quipe affiche en grand format, sur un des murs de son local, un graphe
reprsentant la quantit de travail restant effectuer (sur l'axe vertical)
rapporte au temps (sur l'axe horizontal). C'est un "radiateur
d'information".
Ce graphe peut concerner l'itration en cours ("iteration burndown")
ou plus couramment l'ensemble du projet ("product burndown").
ON L'APPELLE GALEMENT...
Claude Aubry, expert Scrum, a propos la francisation "beurdone"; elle
est reste quelque peu marginale.
105
Rfrentiel des pratiques Agiles
ORIGINES
Cette pratique est dcrite pour la premire fois par Ken
Schwaber sur son site "Control Chaos" (2000)
Elle devient populaire dans la communaut Scrum partir de
2002
Diverses alternatives sont ensuite proposes, sans toutefois
dtrner le "burn down" comme choix le plus simple, telles
que le "burnup" (on inverse l'axe des Y) ou le plus sophistiqu
"Cumulative Flow Diagram", partir de 2003
106
Chapitre 35: Grille INVEST
Chapitre 35
Grille INVEST
Concept
DE QUOI S'AGIT-IL?
La grille des critres INVEST permet de juger de la qualit d'une User
Story; elle conduira ventuellement reformuler son nonc, voire
modifier en profondeur la Story (ce qui se traduit souvent physiquement:
on dchire la fiche ou le Post-It correspondant et on en crit une autre).
Une bonne User Story est:
Indpendante des autres
Ngociable initialement, plutt qu'un engagement ferme
Verticale, ou ayant de la valeur en soit
Evalue en termes de complexit relative
Suffisamment petite (en anglais Small)
Testable en principe, ce qu'on vrifie en crivant un test
Plus en dtail, une bonne User Story:
Pour rpondre au critre I, doit pouvoir tre implmente
avant ou aprs n'importe quelle autre; une erreur classique
tant par exemple d'argumenter que "la Story sur la prise de
commande implique d'avoir ouvert un compte, donc il faut
raliser en premier celle concernant l'identification (login) de
l'acheteur". C'est un peu comme supposer qu'on ne peut crire
le chapitre 2 d'un roman qu'aprs avoir achev le chapitre 1:
plus facile, mais avec un peu d'imagination on arrive trs bien
inverser cette squence. Dans notre exemple l'quipe de
107
Rfrentiel des pratiques Agiles
108
Chapitre 35: Grille INVEST
109
Rfrentiel des pratiques Agiles
Chapitre 36
Intgration continue
Pratique
DE QUOI S'AGIT-IL?
On appelle "intgration" tout ce qu'il reste faire une quipe projet,
quand le travail de dveloppement proprement parler est termin,
pour obtenir un produit exploitable, "prt l'emploi".
Par exemple, si deux dveloppeurs ont travaill en parallle sur deux
composants A et B, et considrent leur travail comme termin, vrifier
que A et B sont cohrents et corriger d'ventuelles incohrences relve
de l'intgration. Ou encore, si le produit final est fourni sous la forme
d'un fichier compress, regroupant un excutable, des donnes, une
documentation, les tapes consistant produire ces fichiers et les
rassembler relvent aussi de l'intgration.
Une quipe qui pratique l'intgration continue vise deux objectifs:
rduire presque zro la dure et l'effort ncessaire chaque
pisode d'intgration
pouvoir tout moment fournir un produit exploitable
Dans la pratique, cet objectif exige de faire de l'intgration une
procdure reproductible et dans la plus large mesure
automatise.
Pour la plupart des quipes utilisant actuellement une approche Agile,
cela se traduit ainsi:
l'quipe utilise un rfrentiel de gestion de versions du code
source (CVS, SVN, Git, etc.)
110
Chapitre 36: Intgration continue
ERREURS COURANTES
Attention ne pas confondre les outils (serveurs d'intgration
continue du type Cruise Control, Hudson, etc.) avec la
pratique. L'intgration continue n'est pas en premier lieu une
question d'outil mais d'attitude, et s'appuie sur un outillage
diversifi: outils d'automatisation de la compilation et
gnration, outils de test, et bien sr outils de gestion des
versions.
L'oppos d'une intgration continue serait une quipe
prvoyant un unique pisode d'intgration, la toute fin du
projet. Gnralement, cette intgration s'avre alors longue et
pnible, ce qui conduit la plupart des dveloppeurs
expriments prfrer plusieurs pisodes d'intgration au fil
du projet, afin d'anticiper les difficults et d'amliorer la
procdure d'intgration. L'intgration continue consiste
pousser ce raisonnement sa limite. Par consquent, toute
activit qui n'apparat qu'au moment d'une livraison
intermdiaire et que l'quipe vit comme longue et pnible est
candidate pour tre prise en compte au titre de l'intgration
continue... mme si l'quipe estime dj utiliser cette pratique.
ORIGINES
l'expression "intgration continue" est relativement ancienne,
on la trouve par exemple dans cet article de 1993, qui ne
l'emploie que pour recommander au contraire une intgration
assez frquente mais "programme" dans le cadre d'un
processus incrmental
la technique du "Daily Build and Smoke Test" est un
prcurseur, applique dans les annes 90 par Microsoft pour
111
Rfrentiel des pratiques Agiles
112
Chapitre 36: Intgration continue
113
Rfrentiel des pratiques Agiles
114
Chapitre 37: Itration
Chapitre 37
Itration
Concept
DE QUOI S'AGIT-IL?
Une itration au sens Agile est une "boite de temps" ou "timebox" dont
la dure:
varie d'un projet l'autre, de 1 semaine 4 semaines, rarement
plus
est en principe fixe sur la dure du projet
Dans la plupart des cas les itrations sont alignes avec les semaines
civiles, dbutant un lundi et se terminant un vendredi.
La dure fixe des itrations permet d'appliquer une simple formule de
proportionnalit pour dduire, compte tenu de la vlocit observe et
de l'effort estim restant fournir, la dure prvisionnelle du projet.
ON L'APPELLE GALEMENT...
Le terme "Sprint" est galement utilis et vient de Scrum. Les deux
termes "Sprint" et "itration" sont utiliss indiffremment sans
connotation particulire.
115
Rfrentiel des pratiques Agiles
ORIGINES
L'usage courant du terme "itration" suggre bien l'ide de base de
rpter plus d'une fois une mme dmarche, mais son association avec la
stratgie consistant dlibrment "trononner" la dure d'un projet en
sous-priodes semble remonter Objectory, prcurseur d'Unified
Process, vers 1993.
116
Chapitre 38: Langage omniprsent (ubiquitous language)
Chapitre 38
Langage omniprsent
(ubiquitous language)
Pratique
DE QUOI S'AGIT-IL?
Pratique de conception issue du livre de David Evans "Domain Driven
Design" (2003), elle consiste notamment s'attacher utiliser le
vocabulaire et les notions des clients et experts mtiers, non seulement
dans les discussions autour des exigences, mais galement dans le code
source.
(D'autres techniques complmentaires sont dtailles dans le livre
d'Evans, mais le nom de "langage omniprsent" reflte l'intention
principale.)
117
Rfrentiel des pratiques Agiles
ORIGINES
dans les premires annes, Kent Beck tente de populariser une
pratique d'Extreme Programming appele "Mtaphore"; celle-ci
est rarement utilise car mal comprise (2000 environ)
le terme "langage omniprsent" apparat avec le livre de David
Evans (2003)
un consensus s'tablit ensuite pour ne plus parler de
"Mtaphore", et remplacer cette pratique par les
recommandations, juges plus prcises, de David Evans
concernant ce "langage omniprsent" (2004)
118
Chapitre 39: Livraisons frquentes
Chapitre 39
Livraisons frquentes
Pratique
DE QUOI S'AGIT-IL?
Une quipe Agile met frquemment son produit entre les mains
d'utilisateurs finaux, aptes l'valuer et formuler des critiques ou des
apprciations.
Ce qu'on entend par "frquemment" varie selon le contexte
technique, mais on estime en gnral qu'une telle livraison doit avoir lieu
toutes les quatre six itrations au grand maximum.
(Dans certains contextes, tels que le dveloppement Web, on peut
souvent envisager des frquences plus leves, par exemple une livraison
par itration; la limite tant le dploiement continu.)
ON L'APPELLE GALEMENT...
Le terme anglais est "small release" ou "frequent releases", on entend
parfois le proverbe "release early, release often".
ERREURS COURANTES
livrer le produit un responsable marketing ou un chef de
projet pour qu'il "teste" la dernire version n'est pas suffisant,
pas plus qu' une quipe d'assurance qualit; au minimum une
119
Rfrentiel des pratiques Agiles
120
Chapitre 40: Niko-niko
Chapitre 40
Niko-niko
Pratique
DE QUOI S'AGIT-IL?
L'quipe affiche, sur un mur visible de tous, un calendrier de type
journalier. A la fin de chaque journe de travail les membres de l'quipe
indiquent par un dessin ou en collant des gommettes de couleur leur
valuation subjective de cette journe.
ON L'APPELLE GALEMENT...
Le terme "feeling board" est galement utilis. C'est un radiateur
d'information.
Le terme est d'origine japonaise, le redoublement indiquant un effet
d'onomatope, "niko" signifie "sourire".
ORIGINES
propos par Akinori Sakata dans cet article dbut 2006
121
Rfrentiel des pratiques Agiles
122
Chapitre 41: Objets fantaisie (Mock Objects)
Chapitre 41
Concept
DE QUOI S'AGIT-IL?
Technique couramment utilise dans la mise au point de tests unitaires
automatiss.
Il s'agit de crer pour les besoins d'un test une version spcifique d'un
composant logiciel (typiquement une classe, qui sera par consquent
instancie par un objet), qui au lieu de reproduire le fonctionnement rel
de ce composant en fournit une version "pr-enregistre": par exemple,
le "mock" d'une base de donnes est un objet qui simule la base de
donnes, en renvoyant des donnes prdtermines quelle que soit la
requtre qu'on lui transmet.
ON L'APPELLE GALEMENT...
On parle galement de "simulacres".
Le terme "stub" (bouchon) n'est pas proprement parler un
synonyme, mais fait partie du mme vocabulaire cr pour parler avec
plus de prcision de certaines techniques lies aux tests unitaires.
Le terme gnrique pour l'ensemble des objets de ce type est
"doublure" (en anglais "test double" par analogie "stunt double").
123
Rfrentiel des pratiques Agiles
ORIGINES
le terme est d Steve Freeman, Tim McKinnon et Philip
Craig, c'est une allusion un passage d'Alice au Pays des
Merveilles de Lewis Carroll sur la Tortue Fantaisie (Mock
Turtle), leur article "Endo-Testing: Unit Testing with Mock
Objects" est publi en 2000
ERREURS COURANTES
Cette technique un peu controverse a de nombreux adeptes mais
galement des dtracteurs, qui estiment que l'utilisation de ces objets
fantaisie ou "mocks" complique, souvent inutilement, le code des tests
unitaires, au dtriment de leur rle de documentation technique.
124
Chapitre 42: Personas
Chapitre 42
Personas
Pratique
DE QUOI S'AGIT-IL?
Lorsque le projet l'exige (par exemple si l'ergonomie joue un rle
dterminant dans le succs du projet), l'quipe rdige la fiche
biographique dtaille d'un utilisateur fictif de son produit: c'est ce qu'on
appelle une "persona".
Le plus souvent cela prend la forme d'une page A4 avec la photo de
ce personnage (dcoupe par exemple dans un magazine), son nom et
des dtails de sa situation sociale, personnelle et professionnelle:
"Amanda Jones, 34 ans, attache de presse d'un grand groupe
alimentaire, etc."
Un produit logiciel tant le plus souvant destin plusieurs catgories
de personnes, avec potentiellement des prfrences diffrentes qui
peuvent les amener avoir des attentes diffrentes quant au produit, on
ralise autant de "personas" qu'on a identifi de catgories importantes.
Ces fiches biographiques sont affiches dans le local de l'quipe.
125
Rfrentiel des pratiques Agiles
ERREURS COURANTES
Ne pas confondre les Personas avec diffrents autres outils utiliss pour
la gestion des exigences ou dans le marketing:
ce ne sont pas des "rles d'utilisateurs" (par exemple
administrateur, agent de saisie, etc.) caractriss
principalement par leur fonction professionnelle
ce ne sont pas non plus des "segments de march" (l'exemple
canonique tant la mnagre de moins de cinquante ans)
dfinis par des critres principalement dmographiques
126
Chapitre 43: Planning poker
Chapitre 43
Planning poker
Pratique
DE QUOI S'AGIT-IL?
Une mthode ludique d'estimation, utilises par de nombreuses quipes
Agiles.
L'quipe se runit avec son client ou Product Owner. Autour de la
table, chacun dispose d'un jeu de cartes reprsentant des valeurs
typiques pour l'estimation en points d'une user story.
Le client prsente rapidement l'objectif d'une story. Chacun choisit
ensuite une estimation, en silence, et prpare la carte correspondante
face cache. Lorsque tout le monde est prt, on retourne les cartes
simultanment et on donne lecture des estimations.
Les membres de l'quipe ayant donn les estimations la plus basse et
la plus haute sont invits expliquer leur raisonnement; aprs une brve
discussion, on cherche mettre une estimation faisant consensus,
ventuellement en rptant le jeu.
ERREURS COURANTES
Un danger potentiel du Planning Poker rside dans l'obligation de
"converger" vers une estimation produisant un consensus. En procdant
de la sorte, on risque d'ignorer une information importante, savoir le
degr d'incertitude que reprsentait une divergence importante entre les
estimations initiales.
127
Rfrentiel des pratiques Agiles
ORIGINES
le Planning Poker est une adaptation du "Wideband Delphi"
propos par Barry Boehm dans les annes 1970
sa forme actuelle est propose par James Grenning dans un
article paru en 2002
rendue populaire notamment dans la communaut Scrum, et
comme nombre d'autres techniques lies la planification, par
le livre de Mike Cohn *Agile Estimating and Planning paru en
2005
128
Chapitre 44: Points (estimation en)
Chapitre 44
Pratique
DE QUOI S'AGIT-IL?
La plupart des quipes Agiles prfrent mettre des estimations dans
une unit autre que les classiques hommes-jours.
L'une des principales raisons en est que l'usage de la vlocit pour la
planification permet de s'affranchir de toute unit: quelle que soit l'unit
utilise, on peut calculer la dure prvisible du projet en termes du
nombre d'itrations, chaque itration produisant une certaine quantit
de fonctionnalits.
Une raison plus socio-psychologique tient au fait que l'estimation dans
une unit arbitraire tels que les "points" fait peser sur les dveloppeurs
une moindre pression.
ERREURS COURANTES
La principale erreur consiste investir trop de temps ou d'nergie dans
le dbat sur l'unit d'estimation, dans la mesure o la planification base
sur la vlocit rend ce choix largement sans consquence.
ON L'APPELLE GALEMENT...
L'expression anglophone consacre est "story points".
129
Rfrentiel des pratiques Agiles
130
Chapitre 45: Programmation en binmes
Chapitre 45
Programmation en
binmes
Comptence
DE QUOI S'AGIT-IL?
Deux programmeurs partagent un seul poste de travail (cran, clavier,
souris), se rpartissant les rles entre un "conducteur" (aux commandes)
et un "copilote" (surveillant l'cran et intervenant en cas de besoin),
intervertissant les rles frquemment.
ON L'APPELLE GALEMENT...
De l'anglais "pair programming", ou programmation (ou dveloppement)
par paires, on parle aussi de binmage.
Donne les verbes: binmer, "pairer" (frquent au Qubec).
ERREURS COURANTES
les deux programmeurs doivent tre actifs et impliqus tout au
long de la session, sinon, aucun bnfice ne peut en tre
attendu
un calcul simpliste assimile le binmage un doublement des
cots; les tudes mettent en vidence qu'il n'en est rien,
131
Rfrentiel des pratiques Agiles
ORIGINES
longue tradition en milieux universitaires, militaires...
suggre par Larry Constantine (Constantine on Peopleware)
sous le nom "Dynamic Duo" (1995)
simultanment dcrite dans les "Organizational Patterns" de
Jim Coplien (1995)
pratique Extreme Programming ds ses dbuts (1996)
la variante "ping pong" (cf. ci-dessous) est dcrite en 2003
COMMENT S'AMLIORER?
L'un des principaux cueils la pratique du binmage est la passivit.
Lorsqu'on l'utilise conjointement avec le dveloppement par les tests,
une variante appele "ping pong programming" favorise l'change de
rles: l'un des deux programmeurs crit un test unitaire qui choue, puis
passe le clavier son collgue qui cherche alors faire passer ce test, et
peut alors son tour crire un test. Cette variante peut tre utilise soit
pour des raisons pdagogiques, soit dans un esprit plus ludique par des
programmeurs dj confirms.
Dbutant
je suis capable de participer en tant que copilote et
intervenir bon escient
je suis capable de participer en tant que conducteur,
en particulier d'expliquer tout moment le code que
j'cris
Intermdiaire
132
Chapitre 45: Programmation en binmes
133
Rfrentiel des pratiques Agiles
134
Chapitre 45: Programmation en binmes
135
Rfrentiel des pratiques Agiles
Chapitre 46
Radiateurs
d'information
Pratique
DE QUOI S'AGIT-IL?
"Radiateur d'information" est le terme gnrique dsignant un affichage
mural (passif, par exemple une feuille de papier, ou actif, par exemple un
cran affichant des rsultats d'intgration continue) ralis par une
quipe pour diffuser publiquement une information juge pertinente:
nombre total de tests, vlocit, nombre d'incidents en exploitation, etc.
ON L'APPELLE GALEMENT...
un terme apparent est "Big Visible Chart" (un grand graphe
bien visible).
pour gnraliser on utilise galement le terme "informative
workspace"
on peut enfin rapprocher ces termes de la notion de "Visual
management" de la pense dite Lean
136
Chapitre 46: Radiateurs d'information
ORIGINES
le terme "information radiator" est d Alistair Cockburn,
entre 2000 et 2002
le terme "big visible chart" remonte la mme poque, il est
en tout cas antrieur 2001
137
Rfrentiel des pratiques Agiles
Chapitre 47
Refactoring
Comptence
DE QUOI S'AGIT-IL?
Refactorer consiste modifier un code source de faon en amliorer la
structure, sans que cela modifie son comportement fonctionnel.
ON L'APPELLE GALEMENT...
L'anglicisme est le plus souvent employ: l'activit est le refactoring, on
utiliser galement le verbe refactorer. Par le substantif, un refactoring,
on dsigne une modification gnrique qu'il est possible d'appliquer un
code pour le transformer.
On peut galement traduire par remanier, remaniement. Le terme de
refactorisation est galement rencontr, mais nettement moins courant.
ERREURS COURANTES
Attention, refactorer n'est pas:
rcrire du code
corriger des bugs
amliorer un aspect extrieurement visible du logiciel, comme
l'IHM
138
Chapitre 47: Refactoring
ORIGINES
Connue sous le nom de "factoring" chez les programmeurs
Forth depuis 1984
Formellement dcrite par Bill Opdyke en 1992
Intgre par Kent Beck dans Extreme Programming en 1997
Popularise par Martin Fowler en 1999
COMMENT S'AMLIORER?
Niveaux de performance individuels:
Dbutant
je connais la dfinition
j'utilise quelques refactorings de mon environnement
de dveloppement
j'utilise quelques refactorings que je sais appliquer
manuellement
je connais les risques de rgression associs au
refactorings manuels et automatiques
je reconnais la duplication et sais l'liminer par
refactoring
Intermdiaire
je reconnais et j'limine une gamme plus tendue de
"mauvaises odeurs" dans le code
je peux enchaner plusieurs refactorings pour mener
bien une intention de conception, en matrisant
leurs dpendances (mthode dite "Mikado")
j'applique le refactoring en continu, en ayant
rarement besoin d'une longue session de refactoring
Avanc
j'ai un sens aigu de la duplication et des diffrentes
formes de couplage
je matrise des refactorings concernant d'autres
lments que le code: schmas de bases de donnes,
de documents...
je suis en mesure de faire voluer mon code vers des
structures de mon choix issues de diffrentes
origines: paradigme objet, paradigme fonctionnel,
"patterns" connus
139
Rfrentiel des pratiques Agiles
140
Chapitre 47: Refactoring
141
Rfrentiel des pratiques Agiles
Chapitre 48
Responsabilit
collective du code
Pratique
DE QUOI S'AGIT-IL?
Une quipe tablit gnralement des conventions, tacites, orales ou
implciites, prcisant quel dveloppeur peut intervenir sur quelle partie du
code source dont l'quipe a la charge. Diffrents modes existent: ainsi un
module ou un fichier peut tre la responsabilit exclusive d'un
dveloppeur, un autre membre de l'quipe ne pouvant le modifier
qu'avec sa permission.
Lorsque cette responsabilit est collective, tous les dveloppeurs sont
autoriss et encourags modifier toute partie du code lorsque c'est
ncessaire, soit pour raliser une tche en cours, soit pour corriger un
dfaut ou amliorer la structure de l'ensemble.
ON L'APPELLE GALEMENT...
Le terme anglais est "collective code ownership".
142
Chapitre 48: Responsabilit collective du code
ERREURS COURANTES
Il est frquent que des rgles tacites existent qui sont en contradiction
avec les rgles explicite de l'quipe: par exemple, une quipe peut avoir
ostensiblement adopt un modle de responsabilit collective, mais un
des dveloppeurs manifeste des mouvements d'humeur lorsqu'on
modifie certains fichiers, conduisant l'quipe les considrer comme de
facto sous sa responsabilit exclusive. Il est important de vrifier qu'une
responsabilit collective revendique se traduit effectivement dans les
faits.
143
Rfrentiel des pratiques Agiles
ORIGINES
Ds ses dbuts, Extreme Programming fait une pratique part entire de
ce qui n'est l'origine qu'un priori favorable, issu des pratiques des
dveloppeurs Smalltalk - pour qui la notion de "fichier" est nettement
moins structurante, compte tenu des outils de dveloppement utiliss.
144
Chapitre 49: Rythme soutenable
Chapitre 49
Rythme soutenable
Pratique
DE QUOI S'AGIT-IL?
L'quipe vise un rythme de travail tel qu'il pourrait tre soutenu
indfiniment.
Ceci implique en gnral de refuser ce qui est parfois considr
comme un "mal ncessaire": heures supplmentaires, travail le week-end.
ON L'APPELLE GALEMENT...
Le terme anglais originel tait "40 hour week" soit "semaine de 40
heures". On lui a prfr "sustainable pace", terme plus gnral.
145
Rfrentiel des pratiques Agiles
Chapitre 50
Rtrospective jalon
Pratique
DE QUOI S'AGIT-IL?
A mi-chemin de la dure prvue du projet, ou bien en fin de projet (et
surtout lorsque l'quipe prvoit d'tre ensuite nouveau runie pour un
nouveau projet), l'ensemble des membres permanents de l'quipe (au
sens large, et pas seulement les dveloppeurs) consacre une voire deux
journes entires un bilan approfondi.
Plus encore que lors d'une rtrospective d'itration, cette runion
doit tre facilite, suivre un format qui peut varier selon les objectifs
mais qui sera dcid l'avance.
ON L'APPELLE GALEMENT...
On parle en anglais de "project retrospective" ou "interim retrospective"
pour la distinguer de la rtrospective d'itration.
ERREURS COURANTES
Il est souvent conseill de faire appel un facilitateur extrieur
plutt que de confier ce rle un membre de l'quipe: on
considre que le facilitateur ne peut pas jouer ce rle s'il prend
galement part aux discussions.
146
Chapitre 50: Rtrospective jalon
ORIGINES
le terme "Rtrospectives" est d au livre de Norm Kerth (cf.
ci-dessous) en 2001
la pratique de la rtrospective jalon reste marginale au sein des
quipes agiles, qui privilgient le plus souvent les rtrospectives
d'itration, populaires partir de 2006
147
Rfrentiel des pratiques Agiles
Chapitre 51
Rtrospectives
d'itration
Pratique
DE QUOI S'AGIT-IL?
L'quipe se runit priodiquement, le plus souvent un rythme cal sur
celui des itrations, pour rflchir explicitement sur les vnements
saillants depuis la prcdente runion de ce type, et dcider
collectivement des actions d'amlioration ou de remdiation suggres
par la discussion.
Le plus souvent il s'agit d'une runion facilite et utilisant un format
prdtermin, l'intention tant de s'assurer que tous les membres de
l'quipe ont l'occasion de s'exprimer.
ON L'APPELLE GALEMENT...
Le terme "retrospective" est emprunt directement l'anglais, on le
prfre "debriefing" ou "post-mortem" pour ses connotations plus
neutres. On parle galement de "heartbeat retrospectives" pour insister
sur le fait que leur rgularit contribue donner au projet une cadence
(le sens littral est "battement de coeur").
Le terme "reflection workshop" (atelier de rflexion) utilis par
Alistair Cockburn est moins utilis mais connu de quelques experts.
148
Chapitre 51: Rtrospectives d'itration
ERREURS COURANTES
Une rtrospective a pour objet de mettre jour des lments
soit factuels, soit d'ordre relationnel, qui ont des effets
tangibles sur le travail de l'quipe, et d'en tirer des pistes
d'amlioration; elle ne doit pas se transformer en discussion
"de comptoir" ou en dfouloir.
A contrario, une rtrospective ne peut fonctionner que si
chacun se sent libre de s'exprimer, la responsabilit de
l'animateur est d'tablir les conditions de la confiance entre
participants; cela peut exiger la prise en compte des relations
hirarchiques; la prsence d'un responsable peut entraner des
tensions.
Comme toute runion impliquant l'ensemble de l'quipe, elle
reprsente un investissement en temps consquent; si la
runion est inefficace, que ce soit pour des raisons usuelles
(manque de prparation, participants en retard ou dissips) ou
spcifiques ce format (rticences des participants, non-dits),
cette pratique pourtant trs utile risque d'tre discrdite au
sein de l'quipe.
Une rtrospective d'itration doit aboutir des dcisions; ni
trop peu (il y a toujours quelque chose amliorer), ni en trop
grand nombre (il ne sera pas possible de rgler toutes les
difficults en une seule itration). Une ou deux pistes
d'amlioration par rtrospective suffisent.
Si les mmes constats reviennent systmatiquement d'une
rtrospective sur l'autre, sans que les dcisions prises soient
suivies d'effets, c'est le signe d'une ritualisation des
rtrospectives.
149
Rfrentiel des pratiques Agiles
ORIGINES
Alistair Cockburn revendique l'usage du terme "reflection
workshop" ds 1995, bien que la premire description par
crit apparaisse dans son livre de 2001
la notion de "reflection" et d'ajustement est inscrite au
Manifeste Agile ds 2001, trs probablement inspire par
Cockburn
le terme "Rtrospectives" est d au livre de Norm Kerth (cf.
ci-dessous) en 2001
la pratique se diffuse notamment par le biais des confrences
XP Day en Europe partir de 2003
le livre de Diana Larsen et Esther Derby ciblant spcifiquement
les quipes Agiles finit de codifier la pratique de la
rtrospective d'itration en 2006
150
Chapitre 52: Runion quotidienne
Chapitre 52
Runion quotidienne
Pratique
DE QUOI S'AGIT-IL?
L'quipe se runit une fois par jour, heure fixe, pour mettre en
commun les apports de chacun au produit ou l'infrastructure de
dveloppement, et signaler les obstacles rencontrs. On utilise souvent
les trois questions suggres par Scrum pour structurer la runion.
Cette runion est gnralement timeboxe pour une dure de 15
minutes. Tout sujet risquant de dborder est not et abord en dehors
de la runion en plus petit comit.
ON L'APPELLE GALEMENT...
Plusieurs synonymes existent:
"Stand-up" ou "runion debout" : appellation Extreme
Programming, qui recommande que les participants restent
debout pour encourager raccourcir la dure de la runion
"Daily Scrum" ou "mle quotidienne": bien que ce soit
historiquement incorrect (cf. ci-dessous) cette "mle" (en
anglais rugbystique, "scrum") quotidienne est la pratique
ponyme de l'approche Scrum
151
Rfrentiel des pratiques Agiles
ERREURS COURANTES
la runion quotidienne doit tre une "place de march" o les
changes se font d'un membre de l'quipe un autre; l'erreur
la plus courante consiste en faire un "compte-rendu", chaque
quipier s'adressant une seule personne (son responsable, ou
bien le "Scrum Master" dsign de l'quipe)
la deuxime difficult la plus couramment rencontre: une
runion qui s'ternise; des comptences en facilitation en
viendront rapidement bout
troisime difficult courante: l'quipe trouve peu de valeur
dans la runion, au point qu'elle "oublie" de la tenir si le Scrum
Master ou chef de projet n'en prend pas l'initiative; c'est
souvent le symptme d'une adhsion tide aux principes de
l'approche Agile
dernier syndrome couramment rencontr: le "tout va bien",
aucun membre de l'quipe ne profite de la runion quotidienne
pour faire tat d'obstacles ou de difficults rencontre, alors
mme que le fonctionnement de l'quipe est objectivement
amliorable - une telle rticence admettre des difficults doit
amener rflchir sur le style d'encadrement de l'entreprise.
152
Chapitre 52: Runion quotidienne
ORIGINES
Jim Coplien observe chez l'quipe Quattro Pro Windows de
Borland, "hyperproductive", l'habitude de tenir une runion
presque tous les jours, mais sans lui donner un nom distinct,
dans un article de 1994
bien que la pratique "Daily Scrum" soit dcrite dans les articles
concernant Scrum partir de 2000 elle n'apparat pas dans les
tous premiers crits (1996)
(le nom "SCRUM" lui-mme n'est pas initialement associ la
"mle" strictement, mais fait allusion l'expression "moving
the scrum downfield" utilise dans l'article de Takeuchi et
Nonaka "The New New Product Development Game" et
exprime l'ide d'auto-organisation)
on retrouve le "Daily Stand Up" dans les premiers articles sur
Extreme Programming (1998)
les "trois questions" de Scrum sont adoptes par les quipes
Extreme Programming ds le dbut des annes 2000
La pratique trouve sa forme dfinitive avec la gnralisation du
tableau des tches, il devient alors important de tenir la
runion devant le tableau (2004-2006)
153
Rfrentiel des pratiques Agiles
Chapitre 53
Rle - fonctionnalit -
bnfice
Concept
DE QUOI S'AGIT-IL?
La matrice Rle-Fonctionnalit-Bnfice est un format recommand
pour verbaliser ou crire une User Story:
En tant que <rle>
Je veux que <fonctionnalit>
Afin de <bnfice>
Par exemple:
En tant que client de la banque
Je veux retirer de l'argent un guichet automatique
Afin de ne me soucier ni des horaires d'ouverture ni de
l'affluence en agence
Cette formulation permet d'quilibrer les proccupations: non pas
seulement ce que le logiciel doit faire, mais galement pour qui et afin de
satisfaire quel objectif de la personne en question.
Il en existe de nombreuses variantes.
154
Chapitre 54: Salle ddie
Chapitre 54
Salle ddie
Pratique
DE QUOI S'AGIT-IL?
L'quipe (idalement au complet, c'est dire incluant le "client" ou
Product Owner) dispose d'un local ddi plein temps pour le projet,
cloisonn des autres activits de l'entreprise.
Ce local est quip de faon rpondre aux besoins logistiques du
projet: stations de travail (si ncessaires adaptes au binmage), tableaux
effaables et chevalets, espaces aux murs pour l'affichage de Post-Its, etc.
ERREURS COURANTES
le critre de cloisonnement est important: un "open space" ou
bureau paysager n'est pas une mise en oeuvre adquate de
cette pratique; le bruit occasion par des personnes trangres
au projet constitue une distraction nfaste la concentration
requise pour un projet de dveloppement
155
Rfrentiel des pratiques Agiles
156
Chapitre 55: Scrum de Scrums
Chapitre 55
Scrum de Scrums
Pratique
DE QUOI S'AGIT-IL?
Approche utilise lorsqu'un projet mobilise plus d'une dizaine de
personnes, pour "monter en chelle".
On divise le groupe en petites quipes (de 4 9), chacune utilisant
Scrum de faon habituelle. A l'issue de chaque runion quotidienne, un
membre de chaque quipe est dsign comme "ambassadeur" pour
participer une meta-runion, formant ainsi une quipe "virtuelle" dont
la mission est de rsoudre les difficults poses par la coordination inter-
quipes: cration d'interfaces, d'accords de fonctionnement..
Ce "Scrum de Scrums" dispose de son propre backlog qui regroupe
toutes les tches identifies qui contribuent une meilleure coordination
entre les quipes oprationnelles.
ON L'APPELLE GALEMENT...
Traduction directe de l'anglais "Scrum of Scrums", on parle aussi de
"meta Scrum".
157
Rfrentiel des pratiques Agiles
ORIGINES
Dcrite pour la premire fois dans l'article Cross-continent
development using scrum and XP de Bent Jensen (2003)
158
Chapitre 56: Story mapping
Chapitre 56
Story mapping
Pratique
DE QUOI S'AGIT-IL?
Pratique mergente visant structurer la planification des livraisons, le
"story mapping" consiste en une organisation en deux dimensions des
user stories: l'axe horizontal matrialise la succession (chronologique)
des usages de l'utilisateur, l'axe vertical matrialise la priorit des
fonctionnalits: en haut celles qui sont indispensables l'usage, en bas
celles qui sont annexes ou ne concernent qu'une fraction des flux
d'informations que traite le produit.
ORIGINES
formule, sans la nommer, par Jeff Patton dans un article
intitul "It's All in How You Slice" en 2005
159
Rfrentiel des pratiques Agiles
160
Chapitre 57: Tableau des tches
Chapitre 57
Pratique
DE QUOI S'AGIT-IL?
On rpartit sur un tableau mural divis en trois colonnes, " faire", "en
cours", "termin" des Post-It ou fiches bristol reprsentant les tches
raliser au cours de l'itration.
De nombreuses variantes existent; soit dans la disposition qui peut
galement tre horizontale, ou plus sophistique; soit dans le nombre et
l'intitul des colonnes, qui matrialisent en gnral des activits - par
exemple une colonne "en test".
En gnral au cours de la runion quotidienne, l'quipe met jour le
tableau au fil de l'itration pour visualiser sa progression. Le tableau est
"remis zro" en dbut d'itration avec de nouvelles tches.
ON L'APPELLE GALEMENT...
En anglais, "task board"; on parle aussi de "project wall".
On entend plus rarement "tableau de Sprint" ou "tableau d'itration".
ERREURS COURANTES
une erreur classique consiste prfrer d'emble un support
informatis ("tableau des tches virtuel"); c'est se priver des
161
Rfrentiel des pratiques Agiles
ORIGINES
ds les origines de Scrum et d'Extreme Programming on
manipule des fiches bristol ou des Post-It mais le format prcis
du tableau des tches ne se gnralise qu'assez tardivement
La galerie de photos collecte par Bill Wake montre que
mme si de nombreuses quipes Agiles utilisent un affichage
mural, le tableau des tches "standardis" le plus largement
adopt sera celui de Mike Cohn, comportant cinq colonnes (fin
2004)
En partie en raction aux tableaux plus sophistiqus produits
par les quipes qui commencent s'intresser la
transposition Agile des tableaux Kanban, on viendra un peu
plus tard considrer comme "canonique" la version trois
colonnes (fin 2007)
162
Chapitre 57: Tableau des tches
163
Rfrentiel des pratiques Agiles
Chapitre 58
Tableau kanban
Pratique
DE QUOI S'AGIT-IL?
Pratique mergente, porte par une minorit trs active, l'approche dite
"kanban" regroupe un ensemble de modifications au dispositif Agile le
plus couramment utilis pour le pilotage du projet:
les itrations, les estimations et la mesure de la vlocit sont
abolies;
la mesure du temps de cycle se substitue celle de la vlocit
enfin, la modification la plus visible remplace le tableau des
tches par un tableau dit "tableau kanban":
on y retrouve les colonnes correspondant aux
diffrents tats par lesquels peut transiter une "unit
de valeur" (qui est souvent une user story, mais pas
ncessairement)
par contre il comporte, outre ces colonnes, des
limites de stock: si une activit, par exemple le
test, se voit attribuer une limite de stock gale 2,
cela signifie qu'il est "interdit" de dmarrer l'activit
de test concernant une troisime user story, si deux
d'entre elles sont dj en test;
si cette situation se prsente, il faut au contraire
demander d'autres membres de l'quipe qui sont
ventuellement disponibles ce moment de venir
164
Chapitre 58: Tableau kanban
ON L'APPELLE GALEMENT...
Le terme est japonais, et signifie simplement "tiquette" ou "carte".
Il dsigne un systme utilis dans les usines Toyota; sans entrer dans
les dtails, il est analogue ce qu'on peut observer dans certains
supermarchs, o derrire un stock, par exemple de botes de crales,
on place une carte portant la mention "veuillez rapprovisionner ce
produit".
Ce systme permet de tenir une comptabilit prcise des "stocks" ou
"en-cours" (en anglais "Work In Process" qui donne l'acronyme WIP). Le
systme de production Toyota cherche rduire la quantit de ces en-
cours.
ERREURS COURANTES
Les tableaux kanban sont souvent plus sophistiqus qu'un simple tableau
des tches. Ce n'est pas en soi une erreur, mais il convient d'viter la
rintroduction, par le biais d'un tableau kanban structur en fonction
d'une squence d'activits, d'un modle "en cascade" avec tout ce que
cela peut impliquer: cration de "silos" ou de spcialistes au sein de
l'quipe.
On se mfiera en particulier de l'utilisation d'un tableau kanban sans
l'assortir de "limites de stock" qui soient vritablement opposables aux
clients et commanditaires de l'quipe. Ce sont ces limites de stock qui
sont l'lment le plus structurant de l'approche dite "kanban".
165
Rfrentiel des pratiques Agiles
ORIGINES
le rapprochement entre la philosophie d'organisation du travail
en vigueur chez Toyota (sous l'tiquette "Lean") remonte la
publication du livre de Mary et Tom Poppendieck, Lean
Software Development (2003)
cependant ce rapprochement reste relativement abstrait dans
le dbut des annes 2000; l'un des premiers adeptes de cette
approche, David Anderson, exprimente certaines ides
(suppression des estimations et des itrations notamment)
chez Microsoft, ds 2004
d'aprs David Anderson, la premire mise en oeuvre complte,
y compris l'utilisation d'un tableau kanban avec des limites de
stock, a lieu alors qu'il travaille pour Corbis partir de
septembre 2006
suite une prsentation lors de la confrence Agile aux Etats-
Unis, un groupe de discussion se forme pour changer sur
cette approche (mi-2007)
une communaut plus visible, organisant des confrences
ddies, sous le titre "The Limited WIP Society" finit par se
former en 2009
166
Chapitre 59: Temps de cycle
Chapitre 59
Temps de cycle
Concept
DE QUOI S'AGIT-IL?
Le "temps de cycle" est un terme emprunt l'approche manufacturire
connue sous le nom de Lean ou Toyota Production System, o il dsigne
le dlai entre la rception de la commande d'un client, et la livraison au
client du produit fini.
Transpos au domaine du logiciel, le temps de cycle est le dlai
coul entre le moment o apparat un besoin, et la satisfaction de ce
besoin. Cette dfinition plus abstraite permet d'analyser plusieurs types
de situation: par exemple on peut mesurer le "temps de cycle" entre la
formalisation d'une exigence sous la forme d'une user story et le dbut
de l'utilisation ("en production", en conditions relles) de la
fonctionnalit correspondante.
Les quipes ayant adopt une approche base de kanban privilgient
cette mesure, de prfrence celle de la vlocit. Au lieu d'avoir pour
effet d'augmenter la vlocit, les amliorations du fonctionnement de
l'quipe ont (en principe) pour effet de diminuer le temps de cycle.
ON L'APPELLE GALEMENT...
Le terme anglais est "lead time".
167
Rfrentiel des pratiques Agiles
Chapitre 60
Test d'utilisabilit
Pratique
DE QUOI S'AGIT-IL?
Le test d'utilisabilit est une technique empirique et exploratoire
permettant de rpondre la question "comment un utilisateur
apprhendra notre produit dans les conditions relles d'utilisation ?".
On place un utilisateur final devant le produit, en lui fixant une tche
typique de celles que le produit permet de raliser (par exemple "utilisez
notre site de banque en ligne pour rgler par virement votre facture de
tlphone").
Les dveloppeurs et/ou ergonomes observent l'utilisateur sans
intervenir et enregistrent (soit informellement en prenant des notes, soit
de faon plus complte par des moyens tels que la vido, la capture
d'cran ou l'eye-tracking) les difficults ventuelles rencontres par
l'utilisateur, afin d'amliorer la prise en main du produit dans des
versions ultrieures.
ORIGINES
l'invention de cette technique est attribu aux ingnieurs du
clbre Xerox PARC Palo Alto en 1981
l'assimilation progressive (et encore balbutiante) de cette
pratique est reprsentative de l'ouverture rcente de la
communaut Agile aux techniques issues des disciplines
168
Chapitre 60: Test d'utilisabilit
169
Rfrentiel des pratiques Agiles
Chapitre 61
Test exploratoire
Pratique
DE QUOI S'AGIT-IL?
Au sein d'une quipe Agile, la rpartition usuelle des rles entre les
spcialistes du dveloppement et les spcialistes du test se trouve
fortement modifie suite l'utilisation de tests unitaires et fonctionnels
automatiss. Une grande partie des activits de vrification consistant
drouler des scripts, scnarios ou plans de test est dsormais sous la
responsabilit des dveloppeurs.
Cependant, il s'avre que ces tests automatiss ne suffisent pas
valuer les risques de dfauts de qualit dont peut souffrir le produit: les
spcialistes du test continuent jouer un rle important dans les projets
Agiles.
L'approche exploratoire de l'activit de test s'avre trs
complmentaire de l'approche Agile pour plusieurs raisons:
elle insiste sur l'autonomie, la comptence et la crativit du
testeur, tout comme l'approche Agile met en avant ces qualits
du dveloppeur;
elle prconise de mener de front toutes les activits lies au
test: dcouverte d'informations sur le produit, conception de
tests susceptibles de rvler des dfauts et excution de ces
tests;
elle insiste sur l'importance d'une pluralit de techniques, qui
ne peut en aucun cas se rduire un "plan de test" formel, et
170
Chapitre 61: Test exploratoire
ON L'APPELLE GALEMENT...
Le terme anglais est "exploratory testing". Il est utilis par une
communaut de testeurs qui revendiquent leur appartenance
intellectuelle une "cole de pense" qu'ils appellent "the Context-
Driven School" et qu'ils distinguent des autres "coles" ayant des
approches diffrentes de l'activit de test: Analytique, Standardise,
Oriente Qualit, et Agile.
ORIGINES
La pratique du test exploratoire, bien que reste relativement marginale
dans la communaut Agile, est vanglise ds 2001 par Brian Marick,
l'un des participants au sminaire de Snowbird qui donne naissance au
Manifeste Agile, et qui se dcrit lui-mme comme "le testeur de service"
au sein de ce groupe.
Il est indniable que l'essor du mouvement Agile a contribu
renforcer l'intrt de nombreux dveloppeurs pour les activits de test,
jusqu'alors peu valorises dans la profession. Cependant, il a galement
eu l'effet paradoxal de marginaliser un peu plus le testeur, puisque c'est
le dveloppeur qui s'appropriait certaines activits de test.
171
Rfrentiel des pratiques Agiles
Chapitre 62
Tests fonctionnels
automatiss
Pratique
DE QUOI S'AGIT-IL?
Un test fonctionnel, au sens Agile, est une description formelle du
comportement d'un produit, gnralement exprime sous la forme d'un
exemple ou d'un scnario.
Des formalismes trs divers existent pour l'expression de ces
exemples ou scnarios, mais on cherche le plus souvent ce qu'il soit
possible d'en automatiser le droulement l'aide d'un outil (interne
l'quipe de dveloppement, ou disponible "sur tagre").
Comme pour un test unitaire son rsultat est binaire, un "chec"
(comportement diffrend de celui attendu) laissant prsumer la prsence
d'un bug.
De tels tests tiennent lieu, pour une quipe Agile, de cahier des
charges principal: il arrive qu'ils compltent et prcisent un cahier des
charges rdig selon une technique non spcifiquement Agile ("use
cases", ou encore document narratif); et dans certains cas qu'ils
constituent l'unique expression formelle des exigences.
172
Chapitre 62: Tests fonctionnels automatiss
ON L'APPELLE GALEMENT...
On parle galement de "tests de recette", plus rarement de "tests client"
(par opposition "tests dveloppeur"). La traduction littrale "tests
d'acceptation" est aussi utilise (de l'anglais "acceptance test").
Le terme anglais "Storytest" (le plus souvent en un seul mot) est
parfois utilis, dans l'expression "storytest driven development" par
exemple.
ERREURS COURANTES
un travers courant consiste exprimer les tests fonctionnels
dans un formalisme trop proche de l'implmentation, ce qui les
rend inintelligibles par les clients, utilisateurs ou experts
mtiers qui en sont l'audience privilgie; on rencontre
souvent ce dfaut lorsque ce sont les dveloppeurs qui
prennent l'initiative de mettre en place cette pratique, il est
donc impratif de faire participer client, utilisateur
ou expert mtier cette activit
une autre consquence de ce type de drive est de rendre les
tests fonctionnels "fragiles", c'est dire qu'ils chouent suite
des modifications de comportement qui sont sans rapport avec
la fonctionnalit teste (par exemple la modification de
l'tiquette d'un champ de texte)
ORIGINES
la pratique est intgre dans Extreme Programming ds ses
dbuts, mais sans tre lie un outil ou un formalisme
particulier; sa description recouvre sous une mme tiquette
tests unitaires et de recette (1996)
Ward Cunningham, l'un des crateurs d'Extreme Programming,
publie l'outil Fit pour formaliser les tests de recette (2002)
l'adoption de Fit reste marginale pendant quelque temps, mais
explose lorsque Bob Martin fusionne Fit avec une autre
cration de Cunningham, le Wiki, donnant naissance FitNesse
(2003)
173
Rfrentiel des pratiques Agiles
174
Chapitre 62: Tests fonctionnels automatiss
175
Rfrentiel des pratiques Agiles
Chapitre 63
Tests unitaires
automatiss
Pratique
DE QUOI S'AGIT-IL?
Un test unitaire, au sens Agile, est un court programme, crit et
maintenu par les dveloppeurs, servant vrifier de manire trs troite
le bon fonctionnement d'une partie restreinte du programme principal.
Son rsultat est binaire: il "passe" si le comportement du programme
est celui attendu et "choue" dans le cas contraire. Une convention
hrite de l'outil JUnit et de ses nombreux drivs veut qu'on reprsente
par une "barre rouge" l'chec d'un ou plusieurs tests; une "barre verte"
symbolise l'excution avec succs de la totalit des tests unitaires
associs un produit.
ON L'APPELLE GALEMENT...
On parle galement de "tests dveloppeur" (par opposition "tests
client") pour insister sur la fonction qui en est responsable, plutt que
sur le niveau d'abstraction technique.
176
Chapitre 63: Tests unitaires automatiss
ERREURS COURANTES
La terminologie entourant les diffrents types de test prte confusion.
En effet, la mouvance Agile a repris son compte des termes tels que
"tests unitaires" dj utiliss auparavant en leur donnant un sens diffrent
(dans un environnement Agile ce terme ne saurait dsigner que des tests
automatiss, par exemple).
Il est galement important de diffrencier la simple utilisation de tests
unitaires automatiss, raliss par des programmeurs, de la pratique plus
contraignante qu'est le dveloppement par les tests.
ORIGINES
plusieurs articles du mme auteur, David J. Panzl, attestent de
l'invention d'outils trs proches de JUnit ds 1976
l'mergence des outils du type "enregistrer et rejouer" a sans
doute contribu marginaliser les tests unitaires plus proches
du code, de la fin des annes 80 jusqu'au milieu des annes 90
la tendance s'inversera grce la popularit du dveloppement
par les tests et de l'outil JUnit dans la fin des annes 90
la pratique est intgre dans Extreme Programming ds ses
dbuts sous la forme du dveloppement par les tests (1996)
177
Rfrentiel des pratiques Agiles
Chapitre 64
Trois questions
Pratique
DE QUOI S'AGIT-IL?
Les runions quotidiennes sont structures autour des trois questions
suivantes:
Qu'as-tu termin depuis la prcdente runion?
Que penses-tu pouvoir terminer d'ici la prochaine runion?
Quels obstacles rencontres-tu en ce moment?
ERREURS COURANTES
il est important d'insister sur le mot "termin" dans ces
questions; une erreur courante consiste rpondre: "hier j'ai
travaill sur le schma de la base de donnes... et je continue
l-dessus aujourd'hui... sinon tout va bien"; dans ce cas-l il vaut
mieux dire "je n'ai rien termin de nouveau"; cf. la dfinition de
'termin'
ORIGINES
Ces trois questions sont l'origine une spcificit des runions Scrum,
dsormais adopte par presque toutes les quipes Agiles
178
Chapitre 65: Tches choisies
Chapitre 65
Tches choisies
Pratique
DE QUOI S'AGIT-IL?
Au sein d'une quipe Agile, il est rare qu'un responsable attribue des
tches de dveloppement aux diffrents membres de l'quipe. Le plus
souvent l'affectation des tches est base sur le volontariat et la
discussion.
En rgle gnrale ce choix des tches s'effectue devant le tableau des
tches au cours de la runion quotidienne. Il est souvent matrialis par
une annotation sur le Post-It reprsentant la tche concerne. Certaines
quipes utilisent des photos (format identits) ou de plus petits Post-It
qui sont colles de faon amovible celui reprsentant la tche qu'ils ont
choisi de raliser.
ERREURS COURANTES
Bien que rarement identifie comme une pratique part entire,
l'attribution des tches sur la base du volontariat semble tre un lment
important, sinon essentiel, constitutif d'une approche Agile.
Certaines quipes "en transition" vers l'Agilit peuvent conserver
quelque temps un rle de "chef de projet" dont l'une des prrogatives
est traditionnellement la distribution des tches au membres de l'quipe.
Ce modle est cependant largement considr comme incompatible sur
le long terme avec les autres pratiques Agiles.
179
Rfrentiel des pratiques Agiles
Chapitre 66
User stories
Comptence
DE QUOI S'AGIT-IL?
L'intgralit du travail raliser est dcoupe en incrments fonctionnels
et les activits de dveloppement s'organisent autour de ces incrments
appels "User Stories".
Adopter la pratique des User Stories implique de tenir pour
gnralement vraies un certain nombre d'hypothses sur ces incrments:
on peut les raliser dans un ordre arbitraire, et chacun indpendamment
des autres peut avoir une valeur pour l'utilisateur.
Pour rendre ces hypothses trs concrtes, on privilgie une
reprsentation (on peut mme parler de rification) de ces User Stories
sous une forme bien prcise: la fiche cartonne ou le Post-It, qui en
renforcent le caractre atomique et manipulable par tous les
intervenants du projet.
ON L'APPELLE GALEMENT...
Littralement "histoire utilisateur", le terme "scnario client" est
galement utilis. Dans les deux cas il s'agit de mettre en avant l'aspect
narratif ("voici ce qui se passe") et d'autre part le point de vue adopt,
celui, non technique, de l'utilisateur ou du donneur d'ordres ("client").
Au singulier: "une user story".
180
Chapitre 66: User stories
ERREURS COURANTES
une "erreur" classique consiste partir d'un cahier des charges
rdig en amont et le dcouper en User Stories en s'appuyant
sur sa structure textuelle; cela peut tre une bonne approche
pour une quipe dbutante mais ne constitue pas une pratique
recommande
une User Story n'est pas un document; le terme dsigne
l'intgralit des activits qui sont ncessaires pour transformer
une version V du produit en une version V' qui a plus de
valeur; en ce sens une User Story est un objectif
le niveau de dtail correspondant une User Story n'est pas
constant, mais volue au fil du temps, en fonction de l'horizon
de planification: une User Story dont la ralisation est prvue
dans plusieurs semaines ne sera dcrite que d'une brve
phrase, alors qu'une User Story dont la ralisation est
imminente doit tre cadre par des tests de recette, des
exemples, etc.
une User Story n'est pas un Use Case; bien que la comparaison
entre les deux notions soit souvent utile, il n'est pas possible
d'tablir un lien simple et direct
une User Story ne correspond en rgle gnrale pas un
quelconque dcoupage technique: un cran, une bote de
dialogue, un bouton ne sont pas des User Stories
ORIGINES
Les User Stories sont issues d'Extreme Programming. Elles ne sont
initialement pas dcrites comme une pratique part entire; elles
n'apparaissent dans la premire dition du livre de Kent Beck, Extreme
Programming Explained, que comme une des "pices" utilises dans le
"jeu du planning".
Au fil des annes, une pression croissante pousse la communaut
Agile et sa composante Extreme Programming en particulier rpondre
de faon plus prcise la question "comment sont traites les
exigences", il mergera de cette pression une dfinition
considrablement plus sophistique de ces User Story:
la matrice rle-fonctionnalit est propose par Rachel Davies
et Tim McKinnon en 2001
181
Rfrentiel des pratiques Agiles
COMMENT S'AMLIORER?
A titre individuel, les personnes concernes par l'acquisition de
comptences en matire de User Stories sont en premier lieu celles
occupant le rle et les responsabilits d'analystes. Il est trs souhaitable,
comme pour la plupart des comptences Agiles, que celles-ci soit
largement partages dans l'quipe.
A titre individuel:
Dbutant
je suis capable de partir d'une autre formalisation
(cahier des charges, use cases, etc.) et la transposer
en User Stories
je connais au moins une matrice d'expression des
User Stories
je suis capable d'illustrer une User Story par un
exemple (raconter ce que fait l'utilisateur et le
rsultat)
Intermdiaire
je suis capable de "morceler" l'ensemble des objectifs
fonctionnels d'un projet en User Stories, en
m'assurant qu'il n'y a pas d'oubli
je connais diffrentes matrices d'expression des User
Stories et suis capable d'utiliser la plus approprie
je suis capable de formaliser les critres de
satisfaction d'une User Story sous une forme
susceptible d'tre transforme en test de recette
je connais ou puis identifier les diffrentes
populations d'utilisateurs et m'y rfrer dans les User
Stories
je suis capable d'valuer une User Story selon la
grilles INVEST ou un quivalent, et reformuler ou
182
Chapitre 66: User stories
183
Rfrentiel des pratiques Agiles
184
Chapitre 66: User stories
185
Rfrentiel des pratiques Agiles
Chapitre 67
Vlocit
Concept
DE QUOI S'AGIT-IL?
A la fin d'une itration, l'quipe additionne les estimations associes aux
user stories qui ont t termines au cours de cette itration. Ce total
est appel vlocit.
Une fois connue, la vlocit peut tre utilise pour valider ou rviser
la planification de l'ensemble du projet, en partant du principe que la
vlocit lors de futures itrations sera approximativement gale la
dernire vlocit constate.
Exemple: une quipe entame une itration, prvoyant de terminer
les stories suivantes: A, estime 2 points; B, estime 2 points; C,
estime 3 points. A la fin de l'itration, les stories A et B sont
termines 100% mais C n'est termine qu' 80%.
Une quipe Agile ne reconnait que deux niveaux de compltion: 0%
ou 100%. Par consquent C n'est pas comptabilise, et la vlocit de
l'itration est de 4 points. Supposons que la totalit des stories du projet
reprsente 40 points; on prvoit donc une dure totale du projet
quivalente 10 itrations.
L'itration suivante, l'quipe devrait ne prvoir qu'un lot de stories
quivalent 4 points, afin d'viter de retomber dans le travers que
constitue une story termine 80%. La vlocit fonctionne ainsi comme
une soupape permettant de faire retomber la pression lorsque l'quipe
rencontre des difficults tenir ses engagements. (Si la story C est
186
Chapitre 67: Vlocit
ERREURS COURANTES
Cette dfinition a plusieurs consquences importantes:
la vlocit est une constatation, une mesure postriori, et
non un budget ou une prvision; parler de "fixer une vlocit"
est un contresens
on parle de la vlocit d'une quipe uniquement, en aucun cas
de vlocit individuelle; cela n'aurait pas de sens, une quipe
tant conue prcisment comme un ensemble plus
performant que la somme de ses individus
on ne peut pas directement comparer la vlocit de deux
quipes diffrentes, puisque ces quipes peuvent avoir mis
leurs estimations sur des bases diffrentes
pour que la vlocit permette la prvision d'une date de fin du
projet, il est impratif que l'ensemble des user stories que
comprend le projet soient estimes de faon cohrente; il
existe deux manires d'y parvenir:
estimer la totalit des user stories trs tt dans le
projet (avant ou pendant les premires itrations)
utiliser une technique d'estimations relatives pour
s'assurer que les estimations tardives sont mises sur
la mme base que celles mises en dbut de projet
ORIGINES
le terme de "vlocit" provient d'Extreme Programming, o il
apparat assez tardivement, remplaant le terme "load factor"
dont la dfinition est juge trop complexe (milieu de l'anne
2000)
la dfinition canonique apparat dans Planning Extreme
Programming de Beck et Fowler (2001)
le terme est ensuite adopt par la communaut Scrum partir
de 2002
187
Rfrentiel des pratiques Agiles
Chapitre 68
Bibliographie
acadmique
Charte projet
Charters and Chartering: Immunizing Against Foreseeable Project
Failure (III, 2001)
188
Chapitre 68: Bibliographie acadmique
189
Rfrentiel des pratiques Agiles
190
Chapitre 68: Bibliographie acadmique
191
Rfrentiel des pratiques Agiles
Personas
Personas - a Literature Review
Personas is not applicable: local remedies interpreted in a wider
context (Ronkko, Kari and Hellman, Mats and Kilander, Britta
and Dittrich, Yvonne, 2004)
Resolving Incommensurable Debates: A Preliminary Identification of
Persona Kinds, Attributes, and Characteristics (Ingbert R. Floyd and
M. Cameron Jones and Michael B. Twidale, 2008)
Real or Imaginary: The effectiveness of using personas in product
design (Long, Frank, 2009)
An Empirical Study Demonstrating How Different Design
Constraints, Project Organization and Contexts Limited the Utility of
Personas (Ronkko, K., 2005)
Planning poker
Using planning poker for combining expert estimates in software
projects (Molokken-Ostvold, Kjetil and Haugen, Nils Christian
and Benestad, Hans Christian, 2008)
192
Chapitre 68: Bibliographie acadmique
Programmation en binmes
Controlled experimentation on adaptations of pair programming
(Domino, Madeline Ann and Collins, Rosann Webb and
Hevner, Alan R., 2007)
Preliminary Analysis of the Effects of Pair Programming and Test-
Driven Development on the External Code Quality (Madeyski, Lech,
2005)
Pair programming productivity: Novice-novice vs. expert-expert (Lui,
Kim Man and Chan, Keith C. C., 2006)
Personality and the nature of collaboration in pair programming
(Walle, Thorbjorn and Hannay, Jo E., 2009)
An empirical comparison between pair development and software
inspection in Thailand (Phongpaibul, Monvorath and Boehm,
Barry, 2006)
The case for collaborative programming (Nosek, John T., 1998)
A multiple case study on the impact of pair programming on
product quality (Hulkko, Hanna and Abrahamsson, Pekka, 2005)
Video analysis of pair programming (Hofer, Andreas, 2008)
Effects of Personality on Pair Programming (Jo E. Hannay and Erik
Arisholm and Harald Engvik and Dag I.K. Sjoberg, 2010)
The benefits of pairing by ability (Braught, Grant and
MacCormick, John and Wahls, Tim, 2010)
An interpretation of the results of the analysis of pair programming
during novices integration in a team (Fronza, Ilenia and Sillitti,
Alberto and Succi, Giancarlo, 2009)
The Economics of Software Development by Pair Programmers
(Erdogmus, H. and Williams, L., 2003)
The Costs and Benefits of Pair Programming (Cockburn, Alistair
and Williams, Laurie, 2000)
The effectiveness of pair programming: A meta-analysis (Hannay, Jo
E. and Dybaa, Tore and Arisholm, Erik and Sjoberg, Dag I. K.,
2009)
193
Rfrentiel des pratiques Agiles
194
Chapitre 68: Bibliographie acadmique
Refactoring
Refactoring--Does It Improve Software Quality? (Stroggylos,
Konstantinos and Spinellis, Diomidis, 2007)
Refactoring trends across n versions of n java open source systems:
an empirical study (Deepak Advani and Youssef Hassoun and
Steve Counsell, 2005)
Why don't people use refactoring tools (Emerson Murphy-Hill and
Andrew P. Black, 2007)
A comparison of software refactoring tools (J Simmonds and T
Mens, 2002)
Digging the Development Dust for Refactorings (C Schofield and B
Tansey and Z Xing and E Stroulia, 2006)
Are refactorings less errorprone than other changes (P
Weissgerber and S Diehl, 2006)
Roots of refactoring (J Philipps and B Rumpe, 2001)
Program Refactoring, Program Synthesis, and Model-Driven
Development (D Batory, 2007)
Work experience versus refactoring to design patterns: a controlled
experiment (T H Ng and S C Cheung and W K Chan and Y T
Yu, 2006)
A discussion of refactoring in research and practice (B Du Bois and
P Van Gorp and A Amsel and N Van Eetvelde and H Stenten
and S Demeyer and T Mens, 2004)
Refactoring Practice: How it is and How it Should be Supported - An
Eclipse Case Study (Zhenchang Xing and Stroulia, E., 2006)
A survey of software refactoring (Tom Mens and Tom Tourwe,
2004)
Refactoring: emerging trends and open problems (T Mens and A V
Deursen, 2003)
Rtrospective jalon
Project retrospectives, and why they never happen (Glass, R.L.,
2002)
Runion quotidienne
Daily scrums in a distributed environment (Ganis, Matt and
Surdek, Steffan and Woodward, Elizabeth, 2009)
195
Rfrentiel des pratiques Agiles
Tableau kanban
Exploring the Sources of Waste in Kanban Software Development
Projects (Ikonen, Marko and Kettunen, Petri and Oza, Nilay and
Abrahamsson, Pekka, 2010)
Test exploratoire
Defect Detection Efficiency: Test Case Based vs. Exploratory Testing
(Itkonen, Juha and Mantyla, Mika V. and Lassenius, Casper,
2007)
196
Chapitre 68: Bibliographie acadmique
User stories
Supporting Program Comprehension in Agile with Links to User
Stories (Sukanya Ratanotayanon and Susan Elliott Sim and
Rosalva Gallardo-Valencia, 2009)
Sizing user stories using paired comparisons (Miranda, Eduardo
and Bourque, Pierre and Abran, Alain, 2009)
Generating user stories in groups (Nguyen, Cuong D. and
Gallagher, Erin and Read, Aaron and De Vreede, Gert-Jan,
2009)
INVEST in Good Stories, and SMART Tasks (William Wake, 2003)
197
(c) 2011 Institut Agile