Agile de A À Z

Agile: de A Z
Rfrentiel des Pratiques Agiles: dition eBook

Une production de l'Institut Agile
Prface de Pierre Pezziardi, Directeur Informatique, Bred Banques Populaires
1
Agile: de A Z
(...ou presque...)
RFRENTIEL DES PRATIQUES AGILES
EDITION EBOOK
(c) 2011 Institut Agile
(c) 2011 Laurent Bossavit
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.
Rfrentiel des pratiques Agiles
4
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.
Pierre Pezziardi, 13 avril 2011
Pierre Pezziardi est Directeur Informatique de la Bred Banques
Populaires, et auteur de "Lean Management, Mieux, plus vite, avec les
mmes personnes" publi aux ditions Eyrolles.
Chapitre 1: Prface
5

Table des matires
Prface.........................................................................................iv
Table des matires....................................................................vi
Remerciements........................................................................ xii
Guide de Lecture ..................................................................... xv
PREMIRE PARTIE: AGILE
Chapitre 1
Au commencement tait... le Gnie Logiciel...................... 17
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
DEUXIME PARTIE: LES PRATIQUES
Chapitre 6
BDD (Behaviour-Driven Development) .............................. 52
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
Table des matires
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
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
Table des matires
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
Chapitre 61
Trois questions ...................................................................... 178
Chapitre 62
Tches choisies ...................................................................... 179
Chapitre 63
User stories ............................................................................ 180
Chapitre 64
Vlocit ................................................................................... 186
ANNEXES
Chapitre 65
Bibliographie .......................................................................... 188
Table des matires
xi
Chapitre 2
Remerciements
Fdrant un rseau de comptences individuelles reconnues, mandat
par des entreprises dveloppant un savoir-faire et une culture distincte
bases sur ces comptences, mais agissant en toute indpendance et
neutralit, lInstitut Agile a pour missions de dvelopper en France le
march du produit Agile, de prsenter une dfinition claire et
cohrente de ce que recouvre le terme Agile, de recenser les attentes
du march, de mettre au point des programmes de collecte
dinformations et de mesures sur les effets constats des pratiques dites
Agiles.
Pour plus d'informations: http://institut-agile.fr/
Merci tous ceux qui ont soutenu le projet de l'Institut Agile,
commencer par les partenaires et soutiens financiers:
12
Remerciements personnels de la part de Laurent Bossavit tous
ceux, qui ont un moment ou un autre donn un coup de pouce crucial:
bien qu'il soit impossible faute de place de rendre chacun l'hommage
qui convient, je tiens saluer Godefroy Beauvallet pour ses conseils et
Chapitre 2: Remerciements
13
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
La premire partie de cet ouvrage en prsente les motivations:
pourquoi vouloir publier, en 2011, soit dix ans aprs la parution du
Manifeste Agile, et alors que ne nombreux livres dj parus sur le sujet,
un parcours encyclopdique travers les nombreuses pratiques dites
"agiles"?
Si vous souhaitez aller rapidement l'essentiel, vous pouvez
commencer directement par le chapitre 5, prsentant le canevas des
fiches consacres aux pratiques Agiles. Si vous prfrez prendre le temps
de connatre les questions de fond qui sous-tendent le travail ralis,
suivez l'ordre chronologique.
Le premier chapitre aborde donc le positionnement de ces approches
Agiles sous l'angle historique, en remontant aux origines de la discipline
dont la plupart des personnes concernes se rclament encore
aujourd'hui, le Gnie Logiciel.
Le chapitre suivant est consacr notamment dcrire le mouvement
Agile comme tablissant une rupture avec cet hritage; il s'attache
mettre en lumire les diffrences les plus structurantes entre les deux
courants de pense.
Afin d'clairer la fois les enjeux du prsent livre et plus largement
les perspectives d'avenir qui s'ouvrent, dans l'analyse de l'Institut Agile,
ces nouvelles pratiques, le chapitre 3 tablit un bilan des annes
2001-2011 et cite quelques dfis restant relever.
Au chapitre 4, nous verrons plus en dtail pourquoi les "pratiques
Agiles" constituent la matire la plus intressante produite par ce
mouvement au cours de cette dcennie.
Le chapitre 5 aborde pour finir le canevas de description dtaille de
ces diffrentes pratiques.
Chapitre 3: Guide de lecture
15
La deuxime partie est consacre aux pratiques Agiles proprement
parler. Abordes par ordre alphabtique, chacune y est dcrite selon le
canevas prcdemment dcrit, de la faon la plus concise mais galement
la plus claire possible.
16
Chapitre 4
Au commencement
tait... le Gnie Logiciel
De mme qu'il existe une Histoire de France ou une Histoire des
sciences, il existe une Histoire, ft-elle brve, de l'activit qui consiste
crer des logiciels. Mais contrairement au deux premires, on a parfois
l'impression que ceux qu'elle concernent - nous, les programmeurs,
analystes, dveloppeurs, ingnieurs; les testeurs, les chefs de projets, etc.
- ne s'y intressent quasiment pas. Notre profession semble tourner le
dos son pass.
Ainsi des ides techniques nous sont-elles prsentes comme
"neuves" et "rvolutionnaires" alors que, pour qui s'est pench sur
l'historique de la discipline, il ne s'agit que de rchauff: des ides
prsentes dans tel ou tel dialecte de Lisp ou de Smalltalk depuis trente
ou quarante ans. (Si vous ne me croyez pas, penchez-vous sur les
comparaisons entre XML et les "s-expressions" ou entre la
Programmation Oriente Aspects et les MOP ou Meta-Object
Protocols.) On pourrait aussi se demander combien, parmi ceux qui se
rclament aujourd'hui du mouvement Agile, ont conscience de ses
prdcesseurs, tels le RAD ou le Processus en Spirale d Barry Boehm.
De faon gnrale, notre profession tend considrer toute ide ge
de plus de cinq ans comme obsolte et digne de peu d'intrt, et c'est
sans doute en partie pour cela qu'on a parfois l'impression que l'industrie
du logiciel est le jouet de cycles qui relvent plus de la mode que du
progrs.
Chapitre 4: Au commencement tait... le Gnie Logiciel
17
RETOUR AUX SOURCES
Pourtant, il semble impossible de comprendre les enjeux que recouvrent
le terme "Agile", et les raisons qui ont pouss un nombre considrable
de professionnels se mobiliser pour le faire connatre, sans en
comprendre les racines lointaine, et son positionnement par rapport
ces origines.
Parmi les ides qui ont faonn les mtiers du logiciel, une l'a fait de
faon particulirement forte et durable, l'ide du Gnie Logiciel. Le
logiciel relve-t-il vraiment d'une activit d'ingnieur? La question,
lancinante, revient comme un serpent de mer dans les confrences
consacres au sujet, mais elle est rarement traite sous un angle
historique.
Rares sont ceux qui semblent conscients que le "logiciel" ayant lui-
mme une histoire d' peine plus d'un demi-sicle, il a bien fallu inventer
l'expression Gnie Logiciel; que celle-ci ne va pas de soi, et que
l'application des techniques de l'ingnieur au domaine du logiciel relve,
non pas des lois de la nature, mais d'une dcision laquelle il a fallu
rallier divers groupes: des militaires, des scientifiques, des groupes
industriels.
Nous allons donc brivement rappeler la discrte histoire du Gnie
Logiciel. C'est une excursion qui a de quoi satisfaire les esprits curieux,
mme s'il devaient en ressortir plus convaincus que jamais de la
pertinence de ce mariage. Mais nous verrons que cette histoire a de quoi
alimenter bien des doutes...
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
trouve par exemple ce conseil de Peter Naur qui recommande de
s'intresser aux ides d'un jeune architecte, Christopher Alexander. Le
mme Alexander qui sera redcouvert vingt anx plus tard par un certain
Kent Beck, donnant naissance au mouvement des Design Patterns.)
Structurs d'une faon trs systmatique, ils couvrent la quasi-totalit
des proccupations encore d'actualit aujourd'hui quant la faon de
mener des projets dans le domaine du logiciel. Environ cinquante experts
venus de onze pays sont prsents. Parmi les participants on compte des
sommits comme Edsger Dijkstra (connu pour sa campagne contre le
"goto" et en faveur de la programmation structure), Alan Perlis
(crateur d'Algol et auteur de proverbes qui sont au logiciel ce qu'une
certaine tradition japonaise est au jeu de Go) ou Peter Naur (co-crdit
de l'invention de la notation BNF pour dcrire les langages de
programmation).
Ces documents sont loquents quant au degr de controverse que
suscite la question du gnie logiciel. Voici une citation d'un participant:
"La chose la plus dangereuse dans le domaine du logiciel est l'ide,
apparemment presque universelle, que vous allez spcifier ce qu'il y a
raliser, puis le raliser. Voil d'o viennent la plupart de nos ennuis. On
appelle russis les projets qui sont conformes leurs spcifications. Mais
ces spcifications s'appuient sur l'ignorance dans laquelle taient les
concepteurs avant de dmarrer le boulot!"
Les titres de la confrence de 1968 refltent un certain degr
d'incertitude: "Rflexions sur le squencement de l'criture d'un logiciel",
"Vers une mthodologie de la conception", "Quelques rflexions sur la
production de systmes de grande taille". Certes la plupart des
participants utilisent l'expression "Gnie Logiciel" comme si elle allait de
soi, et des lacunes sont dj apparentes (on parle notamment assez peu
du facteur humain), mais on peut deviner une vritable controverse sur
les grandes lignes de ce qui proccupera cette discipline.
En 1969 les titres des articles publis ont gagn en assurance.
"Critres pour un langage de description de systmes", "La conception
de systmes trs fiables en exploitation continue", etc. Mais c'est surtout
en lisant entre les lignes qu'on dcle un changement, et notamment en
lisant "The Writing of the NATO reports" de Brian Randell, une sorte de
"making of" datant de 1996. Une drle d'ambiance rgne apparemment
la confrence de 1969, mais on ne peut que la deviner dans la
description demi-mot qu'en fait Randell:
19
Contrairement la premire confrence, ou il tait tout fait
clair que le terme de Gnie Logiciel refltait l'expression d'un
besoin plutt qu'une ralit, Rome on avait dj tendance
en parler comme si le sujet existait dj. Et, pendant la
confrence, l'intention cache des organisateurs se prcisa,
savoir: persuader l'OTAN de financer la mise en place d'un
Institut International du Gnie Logiciel. Cependant les choses
ne se passrent pas comme ils l'avaient prvu. Les sessions
qui taient censes fournir les preuves d'un large et ferme
soutien cette initiative furent en fait domines par le plus
grand scepticisme, au point qu'un des participants, Tom
Simpson de chez IBM, crivit une superbe et courte satire
intitule "Masterpiece Engineering" (Ingnierie du Chef-
d'Oeuvre).
Un article qui parlait, par exemple, de mesurer la productivit des
peintres en nombre de coups de pinceau par journe. Et Randell
d'ajouter que les organisateurs russirent le "persuader" d'omettre cet
article satirique de Tom Simpson des actes officiels!
L'acte de naissance dfinitif du Gnie Logiciel ayant ainsi t associ
un acte de censure, Randell ajoute qu'il s'interdit pendant la dcennie qui
suivit d'utiliser le terme, le jugeant injustifi. Il n'acceptera de revenir sur
cette dcision que pour une confrence marquant en 1979 le dixime
anniversaire de Rome, o il profita de l'occasion pour adresser Barry
Boehm, alors la "nouvelle star" de la discipline, une srie de piques, que
Boehm "ignora soigneusement, je suis navr de le rapporter, moins
qu'il n'ait pas t en mesure de les reconnaitre comme telles".
QUARANTE ANS DE CRISE
Comment expliquer, malgr ces dbuts au mieux hsitants, le succs
qu'allait connatre par la suite l'ide mme de Gnie Logiciel?
Il est parfois difficile de faire le tri, s'agissant de ce sujet, entre ralit
et mythologie. L'poque des pionniers tant relativement rcente,
l'essentiel de ce qu'il en reste est constitu de ce que les historiens
professionnels appellent la littrature primaire - des crits que nous
devons ceux-l mme qui sont t les acteurs de ces vnements, qui
ont particip aux projets ou assist aux confrences de cette poque. Le
regard que portent des auteurs tel que Frederick Brooks ou Edsger
Dijkstra sur le sujet est ncessairement partial: c'est sur leur
20
recommandation que la discipline se met en place. Plus rcemment, des
historiens ont commenc proposer un regard plus distanci sur ces
jeunes annes du Gnie Logiciel.
L'un des facteurs qui contribuera pendant cette premire dcennie
convaincre une large population de sy'intresser sera, selon ces
historiens, l'utilisation permanente d'une "rhtorique de crise": on se
rfre chaque occasion la "Crise du Logiciel".
Cette soi-disant Crise se manifestait par divers aspects. Les projets
de dveloppement dpassaient les dlais et budgets impartis, les logiciels
produits taient de mauvaise qualit et leurs performances insuffisantes,
ils ne rpondaient pas aux exigences exprimes, ils taient difficiles
faire voluer. La situation tait catastrophique et il y avait urgence y
mettre bon ordre!
La ralit, telle que la rapportent les historiens, est plus nuance.
D'une part, les seuls agiter le chiffon rouge de la Crise l'poque
furent sans doutes les mmes personnes qui militrent pour la cration
d'un Institut du Gnie Logiciel. Les actes des deux confrences, relvent
les historiens, ne font quasiment pas rfrence une "crise" et certains
des intervenants cherchent mme explicitement relativiser certains
constats parmi les plus alarmistes.
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
tre dploy entirement partir de 2010 se voit repouss janvier
2011, et ce malgr une rvision la baisse de ses objectifs fonctionnels.
Il y a pire: Chorus... ne fonctionne pas. Plus exactement son
installation perturbe le paiement des factures aux fournisseurs des
administrations. Alors que l'Etat gronde le secteur priv sur les dlais de
paiement, son propre systme d'information met en difficult de trs
nombreuses PME qui se retrouvent dans l'incapacit d'encaisser leur d:
un comble! Est-ce une difficult transitoire? C'est en tout cas un
transitoire qui dure... et la Cour des Comptes met fin 2010 des
rserves sur l'ventualit que Chorus puisse un jour assumer pleinement
la comptabilit de l'Etat franais.
Ce n'est l que l'exemple le plus rcent et le plus visible, mais chacun
au sein de la profession peut rapporter des "histoires de guerre" du
mme type, concernant des projets parmi les plus petits et les plus
simples aussi bien que les plus importants.
Combien de livres, d'articles ou de prsentations dans la profession
ne commencent-il pas par l'vocation du fameux (et controvers)
rapport CHAOS, dit par le Standish Group, et qui est la source quasi
systmatique des "statistiques" sur le taux d'chec des projets
informatiques: vers la fin des annes 2000, moins d'un tiers des projets
mens par les entreprises interroges pouvaient selon le rapport tre
considr comme russis; un taux cependant en amlioration par
rapport aux annes 1990 o un projet sur six seulement entrait dans
cette catgorie.
Cependant les chiffres et la mthodologie du Standish Group ont t
vivement critiques. En effet, s'agissant de projets de dveloppement
logiciel, ou mme plus gnralement dans les technologies de
l'information en gnral, la mesure prcise de diffrentes quantits
pertinentes qui servent d'indicateurs objectifs (productivit, dlais, ROI)
est rendue difficile par la complexit mme du sujet.
On peut donc difficilement se prononcer sur la ralit de la crise elle-
mme, mais il est vident que le discours de crise a jou, et continue de
jouer, un rle important de justification.
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
qui rendent difficile l'valuation des progrs rellement accomplis.
L'informatique des annes 1960 concerne encore surtout des systmes
militaires ou scientifiques; elle va dans un premier temps se diffuser vers
les milieux d'affaires, subir de profondes mutations lorsque s'imposent
successivement l'ordinateur personnel, les interfaces graphiques, les
rseaux d'entreprise et enfin l'Internet. De faon moins visible
extrieurement, des innovations telles que la programmation objet ou
UML seront tour tour accueillies comme "LA solution" tous les maux
qui constituent la "crise".
A chacune de ces rvolutions, chaque mode, succde une
dsillusion, et la prise de conscience qu'une seule innovation ne saurait
suffire: selon l'expression consacre "il n'y a pas de balle d'argent". (Ceux
qui se dclarent sceptiques quant la ralit de la crise sont enclins
dire: "tant pis, de toutes faons il n'y a jamais eu de loup-garou non
plus!".)
Voil le contexte dans lequel, discrtement d'abord avant d'clater au
grand jour au dbut 2001, se dveloppe un nouveau courant (une
nouvelle mode?) qui prendra le nom de "mthodes Agiles" l'issue d'une
rencontre entre quelques auteurs, "gourous" ou consultants qui
cherchent, bien que chacun d'une "chapelle" diffrente, une synthse
entre leurs diffrentes approches. Cela se passe aux Etats-Unis,
Snowbird, une... station de ski. L'histoire ne se rpte pas, dit-on, elle
bgaie.
23
Chapitre 5
La rupture Agile
Citons l'histoire officielle (dans la traduction qu'en propose Fabrice
Aimetti):
Du 11 au 13 Fvrier 2001, dans l'htel The Lodge de la
station de ski Snowbird situe dans les montagnes Wasatch
de l'Utah, dix-sept personnes se sont runies pour parler,
skier, se dtendre, essayer de trouver un terrain d'entente et
bien sr, manger. Ce qui en est sorti s'appelle le Manifeste du
Dveloppement Agile de Logiciels. Y participrent des
reprsentants de l'Extreme Programming, de SCRUM, de
DSDM, de l'Adaptive Software Development, de Crystal, du
Feature-Driven Development, du Pragmatic Programming, et
d'autres personnes sensibles la ncessit de trouver une
alternative aux pesants processus de dveloppement logiciel
pilots par la documentation.
Le ton est donn: le mouvement Agile se positionne d'emble en
raction une situation juge insatisfaisante, et qui trouve pourtant son
inspiration aux racines de la discipline du Gnie Logiciel: les "processus
de dveloppement" sont excessivement "pilots par la documentation".
Mais pourquoi cette approche "Agile" devient-elle une alternative,
pourquoi ce moment? Et surtout, comment la caractriser?
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
du risque que prsentent certaines innovations ou "ruptures
technologiques": "lorsque de nouvelles technologies entranent la chute
de grandes entreprises".
Christensen distingue deux types d'innovation, l'innovation de
continuit et l'innovation de rupture. La premire est caractrise par
des produits qui renforcent, dans le contexte concurrentiel, la position
dominante des acteurs dj bien placs sur ce march: ces produits sont
jugs sur des critres de performance dj reconnus. Imaginez par
exemple la dernire gnration des appareils photos numriques, qui
passent de 8 12 megapixels. (Une innovation "rvolutionnaire" n'est pas
ncessairement une rupture en ce sens, ainsi l'article Wikipedia consacr
la thorie prcise que l'automobile fut une rvolution mais pas, dans
ses effets sur les acteurs de l'conomie industrielle, une vritable
rupture.)
L'innovation de rupture se caractrise par l'ouverture de nouveaux
marchs, et la mise en danger des acteurs dominants dans un march
donn; elle propose quelque chose d'inattendu en dcalage avec les
critres de valorisation dominants.
L'histoire de la photo numrique ses dbuts est ce titre clairante,
sa victime emblmatique tant Polaroid, l'un de ces noms de marque
passs dans l'usage courant, tant son emprise sur un important segment
du march tait complte. Pourtant, en 2001 Polaroid se mettait en
faillite, pour ne renatre de ses cendres qu' la suite du rachat de la
marque et presque uniquement de cela par des investisseurs cherchant
profiter d'une image encore favorable.
Pourtant, seulement dix ans plus tt, bien malin qui aurait pu prdire
la photographie le bel avenir qui est devenu notre prsent: disparition
inluctable non seulement des modles argentiques mais galement de
tout un secteur d'conomie qui en dpendait, comme les petites
boutiques qui assuraient le dveloppement de nos "ploches".
Ainsi en 1991 le modle Fotoman, est selon une critique pourtant
lucide "incapable de produire des images de qualit professionnelle". En
noir et blanc et d'une rsolution maximum de 320x240, il cote la
bagatelle de 1000$. Ce n'est en fait qu'un gadget, conseill aux personnes
qui souhaitent s'amuser sur leur PC triturer et retoucher leurs photos.
Comment un tel produit arrive-t-il, petit petit, s'imposer jusqu'
vingt ans plus tard avoir totalement dtrn la gnration prcdente?
Pour avoir un dbut de rponse, il faut comprendre que les acteurs
dominants du march le sont en vertu de l'excellence de leurs produits
selon des critres de performance apprcis par la clientle: en
Chapitre 5: La rupture Agile
25
l'occurrence, la finesse de l'image, le bon rendu des couleurs, etc. De ce
point de vue la photo numrique prsente des avantages (facilit de
stockage, moins d'usure mcanique, manipulation numrique) mais ceux-
ci ne sont pas suffisant pour l'emporter face aux concurrents dominants.
Oui, mais certains marchs n'ont que faire de ces critres de
performance majeurs. Parmi les premiers clients auxquels s'adresse le
numrique on trouve des fabricants d'avions, qui doivent prendre leurs
appareils sous toutes les coutures pendant leur construction pour des
raisons rglementaires, et vont donc faire des conomies considrables
sur le dveloppement chimique, mais ne se soucient gure d'une
rsolution trs fine. Ou bien encore des journalistes qui vont privilgier
la transmission rapide d'une information brlante mais ne sont que peu
handicaps, compte tenu des qualits d'impression, par une rsolution
limite ou par le noir et blanc.
L'innovation de rupture est donc porte par des produits initialement
totalement inadquats quand on les juge l'aune des critres de
performance tablis, mais qui vont conqurir un march de niche puis se
dvelopper. L'innovation plus classique, "de continuit", permet
progressivement ces produits de rattraper tout ou partie de leur
retard sur ces critres dominants, et c'est ainsi qu'ils peuvent finir par
mettre en danger les leaders du march.
Alors, en quoi le dbat entre "Gnie Logiciel" et "Agile" peut-il tre
considr comme une instantiation de ce modle? Certes, il faut faire
preuve d'un peu de prudence: considrer l'un et l'autre comme des
"produits" en concurrence sur un "march" relve, sinon de la
mtaphore, d'une moins d'une interprtation assez libre de ces termes.
Je trouve pourtant que le modle s'applique plutt bien, et permet
d'expliquer non seulement le succs initial de l'approche Agile mais
galement ses volutions au cours des dernires annes. (Evolutions qui
sont souvent mal connues des personnes qui pratiquent ces approches et
mme de certains experts: toujours ce blocage sur l'histoire...)
L'ide est donc d'analyser le Gnie Logiciel comme le produit
dominant, et d'expliquer cette domination par le fait qu'il rpond aux
critres exigs par le march. L'histoire du projet Chorus nous suggre
que "le succs du projet" ne fait pas ncessairement partie de ces
critres... alors quels sont-ils? Selon quel critre de performance le
discours classique du Gnie Logiciel, issu des confrences de 1968 et
1969, est-il, malgr ces checs, jug satisfaisant, tel point qu'on
enseigne encore le cycle en V dans les universits?
26
Pour obtenir une rponse, il faut se repencher sur les origines du
Gnie Logiciel dans la "crise du logiciel". Celle-ci se manifeste
initialement par des difficults fournir des prvisions fiables quant aux
projets, souvent lies des allers-retours autour des exigences. Le
critre de performance exig de tout ce qui se prsente comme une
solution ladite crise est, en un mot, la possibilit de contrler tout ala.
On va privilgier la traabilit, la documentation, et le respect des
contraintes que ces outils permettent de suivre le mieux: dlais (et donc
cots) matriss, spcifications respectes.
"A NE PEUT PAS MARCHER"
Cette phrase qui constitue le leitmotiv d'un des chapitres du livre de
Kent Beck illustre bien en quoi l'approche Agile joue le rle du produit
"gadget", totalement insuffisant, dans l'analogie avec la photo numrique
autour des annes 1990.
Planifier en permanence, itrativement, a ne peut pas marcher, on
ferait peur au client (pas assez de contrle). Mettre une nouvelle version
en exploitation tous les mois ou deux, a ne peut pas marcher, on ferait
peur aux utilisateurs (pas assez de contrle). Dmarrer le
dveloppement avec une vision architecturale rsume en une
mtaphore, a ne peut pas marcher, et si on s'tait tromps? (Pas assez
de contrle.) Ne pas anticiper sur les besoins futurs lors de la
conception, a ne peut pas marcher, on se retrouvera coincs (pas assez
de contrle). Faire crire les tests par les programmeurs, a ne peut pas
marcher, tout le monde sait que les programmeurs ne peuvent pas
tester leur propre travail et que le test est une profession part entire
(pas assez de spcialisation, donc de contrle). Travailler en binmes, a
ne peut pas marcher, a va prendre deux fois plus longtemps, et ils
risquent de ne pas s'entendre (pas assez de contrle, mais aussi une
vision du dveloppement comme activit mcanique, rduite la saisie
de code au clavier).
Pour la plupart ces arguments sont lgitimes, de mme qu'il est
lgitime de condamner en 1990 la nouvelle technologie numrique
comme tout fait inadquate.
27
VALEURS CLASSIQUES CONTRE VALEURS
AGILES
L'approche Agile quand elle est initialement destine des projets qui
ne se soucient que trs peu de contrler et de tracer. On privilgie la
communication directe et orale avec le client, lui permettant d'ajuster sa
demande en temps rel; la qualit du produit et sa pertinence pour
rpondre aux besoins rels (plus qu' ceux exprims), la matrise des
priorits fonctionnelles sous contrainte de dlais.
Ne pas chercher faire concurrence aux "mthodologies"
dominantes et aux approches de management orientes sur les
production documentaires de ces dernires permet aux "agilistes"
comme on ne les appellera que plus tard de s'affranchir de nombreuses
contraintes, et d'inventer un mode de dveloppement trs souple, bas
sur des itrations courtes rgies par la rgle du "timebox" (on cherche
en faire le maximum en temps imparti plutt qu' terminer un objectif
fixe quitte jouer les prolongations), dcompos par incrments
fonctionnels. Les phases amont et le travail documentaire sont rduits
l'essentiel, c'est--dire ce qui permet l'quipe de partager une mme
comprhension de l'objectif. Le chef de projet perd ses prrogatives: il
n'attribue plus les tches et ne joue plus les intermdiaires, le client tant
prsent sur place. Des dispositifs techniques (automatisation des tests,
intgration continue) limitent au minimum les cots d'intgration et de
refonte.
Une mtaphore souvent employe compare l'quipe Agile des
musiciens de jazz qui improvisent, par rapport leurs collgues dans une
formation classique: l'absence de contrle n'implique pas moins de
technicit, et de satisfaction procure par le rsultat final.
Une recherche textuelle dans les actes des confrences de l'OTAN
(NATO1968), compare la mme recherche (grce Google Books)
dans les actes de la confrence europenne sur XP et les processus
agiles (XP2008) permet d'objectiver quelque peu ces diffrences de
valeurs:
le mot-cl "control" apparat plus de 100 fois dans NATO1968,
27 fois dans XP2008 (et souvent dans le contexte "groupe
contrle vs groupe exprimental", pour les papiers
scientifiques
le mot-cl "team" apparat plus de 100 fois dans XP2008,
seulement 17 fois dans NATO1968
28
le mot-cl "skill" apparat seulement 5 fois dans NATO1968, 15
fois dans XP2008
le mot-cl "motivation" apparat seulement une fois dans
NATO1968 ("la motivation de cette confrence..."), 12 fois
dans XP2008 et pour la plupart au sens "motivation de
l'quipe"
Le critre de performance privilgi par l'approche Agile, ce n'est plus le
contrle, mais bien l'exploitation du talent individuel et collectif. Lorsque
les approches Agiles se font connatre sous ce nom, en 2001, ces valeurs
sont codifies sous la forme du fameux Manifeste Agile.
AGILE, DIX ANS APRS
Mais depuis 2001, les pratiques ont volu: le challenger Agile a
progress sur plusieurs critres de performance y compris ceux
reconnus par le modle dominant. C'est exactement ce que prdit la
thorie de la rupture, pourtant cette volution est en grande partie
invisible, trs peu reconnue par les professionnels qui ont rejoint la
communaut rcemment et ignore mme d'un certain nombre de
vtrans. (Ou bien, elle se traduit pour certains par un inconfort, un
sentiment que "Agile c'est devenu n'importe quoi".)
Plusieurs pratiques considres dsormais comme au coeur de Scrum
sont ainsi apparues depuis 2001, postrieurement au terme Agile lui-
mme: par exemple les Rtrospectives et le Task Board, deux pratiques
trs proche du "noyau" mais pourtant d'importation relativement
rcente. Quant Extreme Programming son statut de "work in
progress" est acquis depuis la deuxime dition du livre de Kent Beck.
Des pratiques sont apparues pour combler par exemple des lacunes
dans la prise en compte de l'ergonomie par les approches Agiles, ou
encore pour donner des directives plus prcises sur la faon d'organiser
les "phases amont", le recueil des exigences: on parle de Personas, de
Charte Projet, de Story Mapping.
Initialement vcue comme une obligation draisonnable, la pratique
Extreme Programming dsigne l'origine par le conseil "faites crire
vos tests de recette par le client" a beaucoup volu et donn naissance
des coles et appellations diverses: ATDD ou pilotage par les tests
client, BDD ou Spcifications Excutables. Bien que ce sujet soit
actuellement en pleine fermentation, une tendance se dgage clairement:
ces volutions commencent rpondre de faon satisfaisante aux
29
exigences de formalisation et de traabilit qui sont l'apanage des
organisations les plus exigeantes en termes de contrle.
Des pans entiers de pratiques ont enfin servi occuper de nouveaux
terrains. En 2001, Scrum et XP se focalisent sur de petites quipes
colocalises dont la proccupation presque exclusive est le
dveloppement dans un contexte projet: la "date de fin" est une des
proccupations majeures, on conoit le projet comme un effort unique
au-del duquel l'quipe passe autre chose.
Ce n'est qu'au fil du temps que la recherche d'adaptation des
approches agiles d'autres contextes conduit explorer des pratiques
alternatives. Ainsi l'approche Lean et Kanban peut-elle trouver un terrain
d'application fertile parmi les quipes charges de maintenance ou de
TMA. La communaut Agile voit aussi se dvelopper des mouvements
visant repenser d'autres mtiers, l'image de DevOps qui runit des
admin systmes sensibles aux volutions du dveloppement.
AGILE DANS DIX ANS?
En 2010, la photo numrique a entirement remplac la technologie
prcdente (et une nouvelle mutation s'amorce, celle du cinma, mais
c'est une autre histoire). Peut-on imaginer un avenir comparable pour les
approches Agiles? Il convient de rester prudent. D'une part, on apprend
vite quand on s'intresse l'histoire et la sociologie des sciences et des
techniques que le progrs n'est jamais gagn d'avance. Rejet par toute la
communaut mdicale de son temps, Semmelweiss ne fut reconnu
comme un pionnier de l'hygine mdicale qu'aprs avoir t pouss
une dpression nerveuse qui lui fut fatale. Il faut du temps, beaucoup de
travail et sans doute un peu de chance pour qu'une ide s'impose de
manire irrversible; le plus simple est sans doute encore de considrer
que tout est rversible.
Il existe une autre raison d'tre prudent: le statut de "challenger" ne
confre pas automatiquement l'infallibilit de ceux qui se rangent sous sa
bannire. Comme le disait Carl Sagan: "They laughed at Columbus, they
laughed at Fulton, they laughed at the Wright brothers. But they also
laughed at Bozo the Clown." On s'est moqus de Christophe Colomb,
de Robert Fulton - l'inventeur du bateau vapeur - des frres Wright, et
de Semmelweiss.
Mais on s'est aussi moqus de tout un tas de gugusses que l'histoire a
eu bien raison d'ignorer.
30
Notamment, certaines lacunes persistantes continuent plomber la
communaut Agile, et risquent de mettre en pril l'avenir du sujet.
31
Chapitre 6
Quel avenir pour les
approches Agiles?
En dix ans, de 2001 2011, les approches dites agiles pour le
dveloppement de logiciels (Extreme Programming, Scrum) ont chang
de statut: initialement considres comme marginales, elles sont
dsormais perues comme lune des alternatives majeures
l'interprtation traditionnelle d'une discipline, le gnie logiciel, qui savre
incapable de remplir les promesses sans doutes excessives avances lors
de la confrence fondatrice de 1968.
En France notamment, de nombreux cabinets de conseil remportent
un succs croissant en rpondant lapptence dentreprises de tous
profils pour une expertise sur ces stratgies, vues comme mieux
capables de rpondre au contexte de crise et dinstablit actuel. Une
rupture, plus qu'une simple volution, semble se dessiner.
Pour autant, ces approches, explores essentiellement sur le terrain
par des intervenants de projets de toutes sortes, sont encore mal
comprises par le public quelles visent, souvent mal expliques, leurs
bnfices attendus spcifis de faon trop vague, de sorte que beaucoup
dquipes qui sy essayent font fausse route dans leur application; avec
pour consquences que le march quelles reprsentent tarde se
dvelopper, et la promesse dune amlioration globale dans lindustrie du
logiciel semble toujours aussi lointaine.
32
AGILE: DES VALEURS OU DES PRATIQUES?
Un dbat agite rgulirement les listes et forums de diffusions destines
aux spcialistes du sujet: "Qu'appelle-t-on Agile, finalement; s'agit-il d'une
philosophie, de valeurs, ou de pratiques concrtes?"
Les agilistes forment ce qu'il convient d'appeler une "communaut", le
terme consacr ds lors qu'un nombre important de personnes,
communiquant via Internet, s'intressent un mme sujet. Le terme peut
sembler intrinsquement flatteur: il voque respect mutuel, solidarit.
Pourtant, il n'est pas anodin, car il sous-tend parfois des connotations
moins agrables: fermeture sur soi-mme, rejet des "autres". En dehors
de cette communaut justement, des voix s'lvent parfois pour poser la
question plus brutalement: "Est-ce que a veut dire quelque chose, Agile-
avec-un-grand-A?"
A cette question, et justement pour viter de trancher d'une faon
trop dogmatique, il convient de rpondre par une autre question:
"Dans une bonne bouteille, vous buvez l'tiquette?"
Ce qui est important dans l'ensemble certes un peu htroclite de
notions associes au terme "Agile", ce n'est videmment pas le mot
"Agile", de la mme faon que ce qui nous procure du plaisir dans une
bonne bouteille de vin, c'est (en principe) son contenu.
En principe? Oui, une des vertus de cette analogie, c'est de nous
rappeler que trop souvent c'est bien de l'tiquette qu'on se dlecte. On
appelle "effet de halo" le biais cognitif qui nous fait trouver plus plaisant
un produit lorsqu'on sait qu'il provient d'une "bonne" marque, alors
mme que si nous faisions l'essai l'aveugle nous ne saurions pas
distinguer une piquette d'un cru la mode.
Sans jeter la pierre personne, le fait est que nous courons un risque
trop parler des tiquettes: Agile, Lean, Scrum, XP... On entend trop
souvent des choses parfaitement absurdes, par exemple "Lean est le
successeur d'Agile".
C'est un contre-sens pour qui connat le contenu qu'on dsigne par le
terme Agile: un ensemble de pratiques, certes pas toutes de la mme
origine, certes pas toutes aussi largement connues et pratiques, mais
dont statistiquement, en interrogeant un assez grand nombre de
personnes faisant partie de la communaut depuis longtemps (cette
appartenance pourrait se dterminer par un critre concret tel que la
participation des confrences), le recouvrement nous donnerait une
ide assez prcise.
Citons en vrac, et pour l'exercice: le dveloppement par les tests
(TDD), le refactoring, l'automatisation du build, l'intgration continue, la
Chapitre 6: Quel avenir pour les approches Agiles?
33
conception incrmentale, les User Stories, les tests de recette, les
critres "Done", les Personas, le Story Mapping, le Planning Poker, les
itrations timeboxes, les rtrospectives, le tableau des tches, le libre
choix des tches, la runion quotidienne ou "mle", la programmation
en binmes, les demandes d'aide explicites...
Parmi les approches dites Agiles on peut effectivement recenser
certaines dont les prconisations sont des sous-ensembles de cette
longue liste: Scrum et XP notamment.
Si on se pose la question de savoir de quel mode de pense sont
issues les pratiques Agiles, alors oui, on retombe sur quelque chose qui a
de nombreuses affinits avec le discours Lean. Pour autant, le
recouvrement en termes de pratiques est relativement faible.
Or, soyons clair l-dessus, ce qui fait le succs ou non d'un projet, ce
n'est pas le nom du discours dont on se revendique, l'attachement
identitaire des membres de l'quipe: "nous sommes Agiles" ou "nous
sommes Lean". Ce qui fait le succs d'un projet, c'est ce que
font les gens!
De ce point de vue, force est de constater que beaucoup d'quipes se
proclament "Agiles" alors mme qu'elles peinent appliquer de faon
comptente des pratiques aussi lmentaires que le refactoring, ou
qu'elles rvlent lorsqu'on interroge les ingnieurs des contresens sur
des notions de base comme la vlocit.
Une partie de ce dficit est mettre sur le compte de la communaut
Agile elle-mme. Pendant de longues annes, elle ne s'est que peu
proccupe de donner une description systmatique, dtaille,
cohrente et mise jour des pratiques dsignes par le terme "Agile".
C'est justement ce constat qui a motiv l'ouvrage que vous avez en
mains.
LE PROJET DE L'INSTITUT AGILE: UN AVENIR
POSSIBLE
A quoi pourrait ressembler un march des prestations informatiques
dans lequel les approches Agiles auraient pleinement trouv leur place ?
les entreprises consommatrices qui sy intressent trouveraient
une information claire, cohrente, neutre et indpendante de
tout discours commercial sur ce que recouvre rellement le
terme Agile - ce Rfrentiel tant un dbut de rponse, sans
doute complter
34
les entreprises prestataires comptentes dans le domaine Agile
bnficieraient dune reconnaissance de ces comptences et
dun accs facilit aux contrat les exigeant
cette reconnaissance proviendrait notamment, au travers de
partenariats entre les grandes SSII et les acteurs aux
comptences les plus pointues, du succs reconnu de projets
de rfrence notables par leur chelle ou leur importance
les bnfices rels de ces pratiques feraient lobjet dtudes
empiriques, galement ralises de faon neutre et
indpendante, agrgeant des chantillons statistiquement
reprsentatifs
ces lments empiriques permettraient dune part de justifier
lutilisation des approches Agiles, mais aussi dinflchir leur
volution au fil du temps, vers plus defficacit
les parcours de formation permettant dobtenir les
comptences ncessaires la mise en oeuvre de projets Agiles
seraient identifis, afin de pouvoir recruter les comptences
appropries pour ces projets
le milieu de la recherche et de lenseignement, en lien avec
lindustrie, contribuerait pleinement la consolidation et
lvolution des connaissances et comptences dans ce domaine
pour autant, lensemble de cet cosystme resterait fidle ce
qui est la fois la particularit et la valeur de la dynamique
Agile, savoir dtre avant tout un mouvement de terrain
initi par des intervenants oprationnels (dveloppeurs, chefs
de projet) et qui sappuie sur leur exprience au quotidien.
LES OBSTACLES SURMONTER
L'analyse faite plus haut du discours Agile, replac dans le contexte
historique plus global qui est celui du Gnie Logiciel, et vu sous l'angle de
la thorie de la rupture, claire un certain nombre d'obstacles qui
peuvent encore empcher cette situation de se raliser.
L'obession persistante de la communaut pour le sujet de la
certification continue de mener bataille sur un terrain, le contrle des
qualifications, o elle reprsente prcisment ce qu'il ne faut pas faire,
une concurrence frontale au modle dominant. Le mouvement Agile doit
trouver des solutions cette question lancinante, mais des solutions qui
soient compatibles avec sa propre philosophie. Des modles ont t
proposs, inspirs notamment par le succs des "rseaux sociaux": ils
Chapitre 6: Quel avenir pour les approches Agiles?
35
ont pour nom WeVouchFor (dfunt), Entaggle (naissant). La version
Web du prsent Rfrentiel des pratiques servira de base l'Institut
Agile pour proposer, sans prtentions, des outils permettant
Il faut rpondre enfin une autre question lancinante, celle du
modle contractuel. Nous continuons dire que le contrat
forfaitaire est un frein l'adoption des pratiques Agiles en France, mais
quelle solution proposons-nous?
La prolifration de jargon rend difficile la conversation au-del du
cercle des initis; la communication sur les pratiques Agile est
brouillonne et trop centre sur les tiquettes: Scrum vs Kanban vs Lean
vs XP. Le prsent travail est un dbut de rponse, mais l'Institut Agile
veut encourager ceux qui prsentent la ralit du terrain, les lments
concrets et visibles qui au sein d'une quipe permettent d'identifier
les pratiques Agiles et les bnfices qu'elles apportent.
A ce sujet, il est regrettable que l'une des critiques les plus courantes
du mouvement Agile soit dsormais la suivante: "Depuis 10 ans, il n'y a
toujours pas de chiffres probants". La communaut Agile a dsormais
suffisamment d'ampleur pour tre en principe capable de fournir ces
chiffres.
Certes, il y a dix ans, la demande "montrez-nous vos statistiques"
pouvait raison tre rejete comme un discours de dlgitimation, une
faon de remettre leur place ces "hippies du logiciel". Mais nous ne
sommes plus en 2001, nous sommes en 2010; les lments empiriques
sont ncessaires, non seulement pour tayer ce que nous avanons, mais
aussi pour faire le tri entre celles des pratiques qu'il faut conserver et
celles qu'il faut modifier ou liminer de notre discours. Non seulement
ncessaires, mais disponibles, pour peu que nous nous donnions la peine
d'aller les chercher.
Dans cette logique, il est critique que la communaut Agile se
rapproche de la communaut de la recherche et de
l'enseignement. Pour l'instant, rares sont les chercheurs qui
s'intressent l'Agilit, tout simplement parce que les travaux dans ce
domaine ne trouveraient pas tre publis. Ceci pourrait tre rpar en
entamant une dmarche explicite pour faire de ce sujet une discipline
soeur, voire concurrente, du Gnie Logiciel. Aprs tout, cette dernire a
pu persister pendant 40 ans sans solutionner les difficults qui ont
motiv sa cration... il est temps qu'elle subisse la concurrence.
Cette liste n'est sans doute pas exhaustive mais suffirait probablement
tracer une feuille de route pour les approches Agiles au cours des 10
ans venir.
36
Chapitre 7
Un capital: les pratiques
Agiles
La question "sommes-nous Agiles" n'a que peu d'intrt. Bien plus
importante est la question "qu'avons-nous appris, qui nous permet dans
la pratique de mieux russir nos projets?"
C'est la rponse cette question qui semble le mieux cerner la
contribution du mouvement Agile, un capital progressivement enrichi au
cours des dix annes coules. On peut tenter de le structurer un peu
en ajoutant: ce capital se compose de principes, concepts,
pratiques et comptences.
Principes, concepts, pratiques et comptences : voici rsums, par
ordre croissant d'importance, les lments qui font le contenu de
l'approche Agile. Les principes, c'est ce qui nous proccupe quand on
s'arrte pour rflchir; les concepts, ce sont les dfinitions auxquelles on
revient pour viter de se tromper; les pratiques, c'est ce qui nous
distingue visiblement d'autres quipes; mais le plus important reste les
comptences, c'est--dire que nous nous attachons amliorer.
Lors de la runion o fut crit le fameux Manifeste, c'est cette
question qui animait les participants. Leur objectif tait de dcrire leurs
points de convergence les plus forts possibles: c'est une dmarche qui les
conduisait ncessairement une formulation un peu abstraite, un peu
loigne de la ralit quotidienne des projets qu'ils vivaient alors. Ce
sont donc les "douze principes" rputs sous-tendre la pratique Agile.
Les principes fournissent un garde-fou utile. Si je m'aperois que la
mise en place de pratiques censment Agiles a eu pour rsultat de
dmoraliser toute l'quipe, le cinquime principe, "btissez le projet
autour de personnes motives", m'avertit qu'il y a probablement une
Chapitre 7: Un capital: les pratiques Agiles
37
contradiction quelque part. A tout le moins, je dois le prendre comme
un srieux avertissement, envisager que j'ai pu faire fausse route.
Mais on ne peut pas construire un projet sur la seule base de
quelques principes. Admettons, nous somme tous d'accord pour
"satisfaire le client en livrant tt et rgulirement des logiciels utiles".
Cela ne constitue pas un conseil oprant, ou comme on le dit en anglais
avec beaucoup de pertinence, "actionable". C'est comme si on vous
conseillait, pour gagner en bourse: "achetez des actions lorsque les prix
sont bas et revendez-les lorsque les prix sont hauts". Parfaitement juste
et sens, mais aussi parfaitement inutile: on demande immdiatement
comment?
Les concepts doivent tre matriss sous peine de contresens
fatals. Scne vcue: un "Scrum Master" nouvellement certifi dbarque
sur une liste de diffusion et demande, "est-il raisonnable de fixer pour le
prochain Sprint une vlocit de 80% parce qu'un membre de l'quipe est
absent?". Des questions de ce type mettent mal l'aise quant l'efficacit
et la qualit des formations!
La mise en place d'une approche Agile exige de connaitre un peu de
thorie. Pour acqurir un concept thorique il suffit le plus souvent d'en
recevoir la dfinition, par exemple "la vlocit est obtenue en faisant le
total des points (estimations) associs aux User Stories qui ont t
termines dans l'itration qui vient de s'achever". Cette dfinition suffit
identifier les erreurs de notre jeune Scrum Master; la vlocit est
quelque chose qui se mesure, non quelque chose qui se dcrete
l'avance; c'est une mesure qui s'exprime dans la mme unit que les
estimations, donc des points ou des hommes-jours mais en aucun cas un
pourcentage. Le rflexe qui joue est le mme que celui du physicien qui
on annoncerait une vitesse exprime en mtres carrs: ce n'est pas la
peine de vrifier le calcul, il faut d'abord rectifier une incomprhension
thorique.
Nuanons quand mme le propos: certains des termes utiliss pour
dcrire Scrum ou XP exigent plus qu'une dfinition brute, il faut
comprendre comment les mettre en relation. La communaut Agile
affectione les simulations de projet comme outil pdagogique pour
garantir que des termes comme vlocit ou itration sont bien compris.
Les pratiques, c'est ce dont on peut constater la mise en place sur
le terrain, de faon visible. Par exemple, une heuristique souvent utile
pour juger si une quipe prend au srieux l'approche Agile: les murs de
la salle de travail sont-ils recouverts de tableaux blancs remplis, de
grandes feuilles de papier chargs de Post-It, de documents divers relatifs
38
au projet et mis jours rcemment? La prsence de ces indices n'est
videmment pas une garantie de succs, mais elle met en vidence
certaines pratiques communes parmi les quipes Agiles: utilisation d'un
tableau de tches par exemple.
Ou bien encore, passer un peu de temps avec un dveloppeur, et
constater quelques diffrences visibles entre son travail et ce qu'on a vu
faire ailleurs. Lorsqu'il programme, on le voit systmatiquement se
proccuper de tests unitaires automatiss, qui se matrialisent par une
"barre verte" ou "barre rouge" dans l'outil qui gre ces tests. Ou bien, on
remarque qu'il ne travaille que rarement seul, mais le plus souvent avec
un autre dveloppeur assis au mme bureau; il ne travaille pas en silence
mais explique (sans trop lever la voix pour ne pas perturber d'autres
binmes) le raisonnement derrire le code qu'il propose son collgue.
Les comptences, c'est ce qu'on peut voir quand on examine de
plus prs certaines pratiques (mais pas toutes), ce sont celles parmi les
pratiques qui amnent distinguer des niveaux de performance. Telle
quipe est meilleure que l'quipe voisine dans le domaine de la
conception volutive. Tel dveloppeur est plus dou qu'un autre pour le
refactoring, il l'applique de faon plus fluide, une plus grande chelle,
avec plus de rapidit.
Certaines pratiques ne sont pas ncessairement des comptences:
d'un certain point de vue une runion de type "stand-up" ou "daily
Scrum", c'est simplement une runion. On constate, ou non, que l'quipe
se runit une fois par jour heure fixe pour changer sur les progrs
accomplis. Par contre on peut considrer que l'animation de cette
runion est une comptence. Si cette comptence est prsente cela se
traduit par une runion courte et le sentiment (subjectif, certes) qu'elle a
t utile. Si cette comptence fait dfaut, la runion peut s'terniser et
sembler contre-productive.
Attention, "animer un stand-up court" ne dcrit pas une comptence!
On prfrera quelque chose comme: "telle personne est capable
d'quilibrer les temps de parole lors d'une runion, en encourageant les
plus timides contribuer et les plus extravertis se limiter". Cette
comptence s'appuie sur de l'observation (il faut avoir not qui a parl
ou pas parl) et sur de l'autorit (adopter le ton juste lorsqu'on demande
quelqu'un de rendre la parole: ni minauderie ni clat de voix).
Conclusion: pour pouvoir obtenir les bnfices d'une approche Agile,
il est important d'avoir accs une description approfondie et dtaille
du contenu de cette approche, avec une attention particulire aux
pratiques et aux comptences qui, sans doute parce qu'elles sont plus
39
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.
PRATIQUES AGILES: PRCAUTIONS
D'UTILISATION
Attention, terrain min. Nous venons d'exposer que pour tirer parti des
approches Agiles, il tait plus efficace de s'intresser en priorit aux
pratiques: ce que font les quipes et les individus; les principes servant
plutt de rgles gnrales pour vrifier la cohrence de ces actions.
Pour autant, il y a un risque majeur trop se focaliser sur ces
pratiques: celui de tomber dans l'imitation, ce que l'on connait sous le
nom de Culte du Cargo, en rfrence ces tribus mlansiennes qui,
durant la seconde guerre mondiale, voyaient les militaires japonais et
amricains construire des pistes d'atterrissage et des tours de contrle.
Activits systmatiquement suivies de l'arrive d'avions charges de
cargaisons de vivres et autres objets sophistiqus. Lorsque la guerre
cessa, et faisant le lien logique entre l'activit et son rsultat, certains
chefs tribaux promirent leurs ouailles la reprise des livraisons: il
suffisait pour cela... de construire des rpliques en bambou des tours et
des pistes!
On aurait tort de se moquer, tant on retrouve souvent la mme
attitude au sein d'quipes et d'entreprises dans le domaine du logiciel.
"Chez Goopple les quipes utilisent des pratiques Agiles: du TDD, des
rtrospectives, des itrations. Et regardez leur valorisation en bourse!
Chez nous aussi, faisons du TDD, des rtrospectives et des itrations.
On devrait avoir les mmes rsultats." (De mme pour l'approche
"classique" des projets de dveloppement: les botes qui marchent bien
font un contrat, puis un cahier des charges, puis une conception
technique dtaille, puis implmentent et testent, alors on va faire la
mme chose. Ainsi se perptue une "mthode" qui, en ralit, ne
fonctionne pas.)
L'utilisation judicieuse des pratiques et des comptences proposes
par la communaut Agile exige d'abord de bien connatre les mcanismes
par lesquels on produit du logiciel, puis de comprendre en quoi les
pratiques qu'on souhaite utiliser modifient ces mcanismes.
40
Si l'on ne se proccupe pas du tout de la question sous-jacente,
"qu'est-ce que c'est, finalement, que cette activit qui consiste produire
du logiciel", on se retrouve dans une situation analogue celle des tribus
Mlansiennes, qui voient arriver "magiquement" du cargo mais ignorent
tout de la formidable complexit du systme industriel qui, des milliers
de kilomtres, est responsable de la production de ces richesses.
Voici donc, en version courte, la notice d'utilisation des pratiques
Agiles:
On dploie une pratique dans le but d'en obtenir des bnfices bien
identifis; l'hypothse selon laquelle nous obtiendrons ces bnfices doit
tre justifie par un mcanisme suppos (on pourrait aussi dire une
modlisation de l'activit de dveloppement) qui nous permet de penser
que cette pratique aura les bnfices attendus. L'utilisation sur la dure
de cette pratique ou comptence doit tre soumise une vrification
empirique. Si nous n'obtenons pas, dans un dlai pralablement tabli, les
bnfices attendus d'une faon que nous pouvons un tant soit peu
objectiver, alors il nous faudra, d'une part abandonner ou modifier cette
pratique, d'autre part remettre en question notre comprhension des
mcanismes.
La question "qu'est-ce que c'est que la production de logiciel" est
videmment trs vaste, mais on ne peut pas en faire l'conomie. Pour
tre utile, la description des pratiques Agiles doit faire le lien entre la
nature de cette activit d'une part, les "lois" et les contraintes qui la
rgissent, et d'autre part les bnfices attendus et le raisonnement qui
nous laisse penser que ces pratiques apporteront ces bnfices.
Agilit en kit: les outils de montage
Une autre raison pousse vouloir donner un coup de projecteur sur les
pratiques Agiles, plutt que sur les tiquettes Scrum, XP, etc. Chacune
de ces diffrentes approches est prsente comme un tout: un ensemble
de pratiques qui vont donner un bnfice maximal si on les met en place
ensemble.
Oui, mais vouloir passer d'un seul coup de "pas Agile du tout" "tout
Scrum" ou "tout XP" est, du point de vue humain et managrial, une
situation trs rare. Elle peut se produire lorsque les quipes sont en
crise et sont prtes tout pour en sortir; ou encore lorsque des gens se
retrouvent pour un nouveau projet qui ont dj utilis Scrum ou XP
prcdemment. Mais la situation encore la plus courante est celle
41
d'quipes et d'entreprises qui veulent bien mettre un pied dans l'eau,
mais pas plonger la tte la premire.
Une premire ide est d'appliquer la logique Agile la transition elle-
mme: "Adoptez la pratique qui vous semble la plus importante, puis
itrez". Ce type de conseil a un intrt limit, d'une part parce qu'il n'est
justement pas vident de dterminer quel outil "agile" est pertinent dans
telle ou telle situation, d'autre part parce qu'une seule pratique utilise
en isolation peut avoir des bnfices marginaux. Enfin, il existe un risque
que le discours consistant dire "cette pratique ne s'applique pas dans
mon contexte" serve de prtexte ne pas se remettre en question.
Pour viter les cueils du type "Culte du Cargo", nous voudrions une
dmarche qui permette de dployer, dans un contexte donn, et
diverses tapes d'un projet, les pratiques agiles les plus pertinentes. Avec
au dpart un "kit" de pratiques, et des outils permettant un assemblage
cohrent, on va fabriquer une mthodologie sur mesure.
Le premier de ces outils est la modlisation du processus de
dveloppement.
Un exemple. Un des principes Agiles consiste tester tout au long du
projet: on a remis en cause l'approche classique consistant laisser le
test pour la fin. La base de cette critique est une rflexion sur les
modles qui conduisent prendre cette dcision. Dans un modle trop
simplifi, on part du principe que la production de code aboutit une
certaine production de dfauts, et qu'il suffit une fois le code produit de
procder l'limination de ces dfauts:
Figure 1: Diagramme "naf"
Si on croit cela, on va lgitimement remettre les tests la fin du projet.
Le diagramme ci-dessus, dans une notation appele "diagramme d'effets",
42
permet de rendre explicite cette supposition, et on peut le comparer
avec le diagramme suivant:
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
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
comment elles fonctionnent, mais aussi quand elles sont susceptibles de
ne pas fonctionner.
LE MONDE EST UNE SCNE
Les chapitres qui viennent n'aborderont pas de faon dtaille les "rles",
qu'ils soient traditionnels et connus - testeur, dveloppeur, analyste - ou
nouveaux et propres tel ou tel approche Agile: Scrum Master, Product
Owner, Coach... Pourquoi? Il convient de rappeler le principe suivant:
Ce qui compte surtout pour le succs d'un projet, c'est
ce que les gens font.
Il existe bien sr des contraintes: les journes de travail ne faisant (en
principe) que 8 heures, une mme personne ne peut pas tout faire. On
doit bien se spcialiser afin de mener certaines activits de faon
comptente; le temps que j'investis devenir un meilleur dveloppeur
est autant de temps que je ne passerai pas acqurir des rudiments de
graphisme.
Le principe de Ricardo ou principe de l'avantage comparatif me
pousse m'associer une personne comptente dans le domaine
graphique, et montre que je peux y trouver un avantage mme dans le
cas o je suis un peu dou en graphisme. (Ce qui est contre-intuitif dans
le principe de Ricardo, c'est l'ide que mme si je suis strictement
meilleur en dveloppement ET en graphisme qu'une autre personne,
m'associer avec elle en nous spcialisant chacun dans un domaine peut
quand mme tre intressant pour chacun des deux.)
Mais ce qui vaut en analyse conomique ne vaut pas ncessairement
dans un projet. Par exemple les acteurs d'un projet ne travaillent pas
chacun dans leur coin: ils ont besoin, chacun, de comprendre ce que font
les autres acteurs. Trop de spcialisation peut engendrer le "syndrome
du bb", d'aprs une conversation entre parents, par exemple au
supermarch: "Dis donc, le bb n'est pas avec toi?" - "Ah non, je croyais
qu'il tait avec toi..." - "Alors o est-il?" Transpos au monde du projet,
cela donne des tches importantes qui ne sont pas ralises parce que
chacun pense qu'elles relvent de la responsabilit de quelqu'un d'autre.
Prenons donc l'exemple d'un des nouveaux "rles" Agiles les plus
emblmatiques, celui du Scrum Master. Le Scrum Master est charg:
de lever les obstacles signals par l'quipe lors des runions
quotidiennes ("mles")
d'tre un facilitateur lors de ces runions
de rappeler l'quipe les fondamentaux thoriques de Scrum
45
de protger l'quipe des interruptions
Sur le papier, ce rle est cohrent. Mais imaginez la situation suivante:
dans votre quipe, une personne est trs doue pour agir et
communiquer vers l'extrieur; une autre est trs l'aise pour animer des
runions. A votre avis, vaut-il mieux:
donner l'une de ces personnes les quatre responsabilits ci-
dessus, au risque que deux d'entre elles soient moins bien
assures, ou
jeter aux orties la dfinition stricte du rle du Scrum Master,
et rpartir ces quatre responsabilits entre les deux quipiers
en fonction de leurs talents?
La seconde solution a plus de chances d'tre efficace.
Un rle formellement dfini n'est qu'une "checklist", le rappel utile
d'un certain "lot" d'activits ou responsabilits dont il est important de
garantir que chacune est assure par au moins un membre de l'quipe,
afin d'viter le "syndrome du bb". La spcialisation a du sens au niveau
des responsabilits isoles, pas au niveau de rles agrgeant plusieurs
responsabilits.
Il existe, bien sr, des corrlations. Un dveloppeur comptent est
probablement une personne plus apte se charger d'un travail de
rdaction technique qu'un graphiste comptent. Mais c'est seulement une
tendance (peut-tre mme pas une tendance trs marque). Lorsqu'il
s'agit de se rpartir des tches prcises, identifies, au sein d'un projet
particulier, entre des personnes relles, dans toute leur singularit, la
notion de rles doit passer au second plan.
46
Chapitre 8
Comment utiliser le
rfrentiel
Nous voici donc prts aborder le contenu de la dmarche Agile, les
pratiques elles-mmes. Comme indiqu plus haut, les chapitres sont
destins tre lus en "accs direct" plutt que squentiellement: vous
lirez ainsi la description d'une pratique vous intressant en particulier.
Suivant votre situation, vous pourrez vous intresser des aspects
diffrents d'une mme pratique; ci-dessous, nous abordons le schma
auxquel se conforme chacun des chapitres restants.
CANEVAS DE DESCRIPTION D'UNE
COMPTENCE
Voici les lments qui semblent pertinents pour dcrire une pratique
agile. Nous allons prendre pour exemple une pratique Scrum
relativement rcente, la Dfinition de 'fini'.
Parlons d'abord, mme si ce n'est pas la premire chose qu'on lira (ce
sera le nom, abord plus bas), du descriptif succint d'une pratique. Le
rfrentiel n'a pas vocation se substituer aux livres, articles et contenus
de formation qui donnent une dfinition plus prcise et plus dtaille de
chaque pratique, comptence et outil abords. Il s'agit donc ici de se
borner un paragraphe court qui reprend l'essentiel.
Un autre exercice dlicat consiste choisir un nom canonique pour
cette pratique. La plupart de nos collgues francophones utilisent un
demi-anglicisme, et parlent de "Definition du Done", quand ce n'est pas
le terme anglais qu'ils utilisent directement. Quand c'est possible, il est
Chapitre 8: Comment utiliser le rfrentiel
47
prfrable de vraiment traduire, c'est pourquoi nous prfrons "fini"
"done".
Le but n'est pas de faire voluer le lexique, mme s'il est tentant de
chercher jouer de son influence... Notre prfrence irait peut-tre au
terme "Liste Sashimi", le terme "sashimi" bnficie actuellement d'un
petit effet de mode, et comme l'illustre le site Web d'un collgue coach,
J.B. Rainsberger il est parlant et plaisant. Mais cette appellation pour
dsigner une pratique spcifique reste tout fait marginale.
En tout cas, pour toutes ces raisons, il semble important de recenser
les synonymes connus qui dsignent la mme pratique ou des
pratiques tellement voisines que nous les considrerons comme une
seule (par exemple le Sprint de Scrum ne diffre pas assez de l'Itration
d'XP pour y voir deux pratiques distinctes).
Une pratique s'accompagne gnralement d'un certain nombre
d'erreurs classiques, de contre-sens et d'abus. En rencensant les plus
courantes, on donne de la profondeur la description brve (mais
toujours sans chercher se substituer un contenu plus pdagogique),
et on encourage se mfier des imitations et contrefaons.
Conformment la division "principes, concepts, pratiques,
comptences" on fera ressortir de cette pratique le ct visible: on sait
qu'une quipe utilise une pratique quand on peut le constater par des
signes observables dans l'espace de travail, par exemple une feuille de
paperboard sur laquelle on peut lire la (ou les) dfinition(s) de "fini".
(C'est l un arbitrage, certaines personnes diront qu'il suffit qu'une
quipe connaisse sa dfinition de "fini" et que tout le monde soit
d'accord. Pourquoi pas: dans ce cas, le signe observable consiste
s'asseoir avec plusieurs personnes dans l'quipe et leur demander de
rciter cette dfinition. Il est presque certain que dans ces conditions
chacun donnera une dfinition de "fini" lgrement diffrente; ce qui
nous renvoie donc la rubrique "erreurs classiques".)
Comme indiqu prcdemment, une pratique ne vaut que par les
bnfices qu'elle confre au projet. Dcider, en conscience, d'adopter
une pratique, c'est s'engager vrifier quelques temps aprs si ces
bnfices ont bien t obtenus, et remettre en question sa vision du
fonctionnement du projet si ce n'est pas le cas. L'objectif n'est pas
d'utiliser telle et telle pratique pour le plaisir de s'identifier comme
"Agile" mais bel et bien d'obtenir ces bnfices. Notamment, chaque
pratique se caractrisera aussi par un cot d'utilisation plus ou moins
grand et une efficacit plus ou moins nette: notre objectif, idalement,
est d'obtenir avec le minimum de pratiques, exigeant le minimum d'effort
48
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
mobilisent une partie de l'nergie des intervenants d'un projet, qu'ils
pourraient consacrer d'autres pratiques qui elles sont rellement utiles.
Les travaux les plus importants sont mentionns dans le chapitre
correspondant aux quelques pratiques qui on fait l'objet de telles
recherches; une bibliographie reprend l'ensemble de ces rfrences, en
annexe.
CANEVAS DE DESCRIPTION D'UNE
COMPTENCE
Que dire de plus pour clairer prcisment une comptence, par
rapport ce qu'on peut dire concernant une pratique? Notre exemple
sera le Refactoring, comptence centrale dans Extreme Programming.
Tout d'abord, une comptence est aussi une pratique: elle se constate
certains signes visibles, elle apporte un bnfice prsum, qui peut tre
dmontr par des tudes empiriques. Le canevas de description d'une
comptence est donc en rgle gnrale un sur-ensemble de celui qui
vaut pour les pratiques.
La principale diffrence est qu'une comptence nous amnes
distinguer des niveaux de performance. Cela n'a pas tellement de
sens de dire qu'une personne ou mme une quipe est "doue" pour
tablir sa "definition of Done". Soit elle a une dfinition, et la trouve
satisfaisante; soit elle n'en a pas. Il n'y a pas grand chose dire une
quipe qui lui permettra d'amliorer sa pratique de la dfinition. (Certes,
une quipe peut avoir une mauvaise dfinition de "fini", si elle est
incomplte ou au contraire trop rigoureuse. Pour autant on ne parlera
pas d'amliorer une comptence, mais simplement d'amliorer... le
document!)
Au contraire, une personne peut matriser plus ou moins bien les
diffrentes techniques du refactoring, et s'amliorer dans ce domaine,
soit par la recherche et la pratique personnelle, soit par des mcanismes
d'apprentissage en travaillant auprs d'un mentor qui lui enseignera des
lments plus avancs que ceux dj connus, soit en suivant une
formation qui fixera des objectifs pdagogiques adapts.
N'tant pas lui-mme un support pdagogique, le rfrentiel n'a pas
vocation recenser l'intgralit des savoirs-faires qui composent une
comptence donne, mais simplement de fournir des pointeurs vers les
ressources documentaires, lorsqu'elles existent, qui font autorit. Par
exemple, le livre de Martin Fowler qui dfinit plusieurs dizaines de
50
refactorings lmentaires. La connaissance encyclopdique de tous ces
refactorings n'est certes pas une exigence pour pouvoir prtendre
matriser le sujet, mais d'vidence l'une des choses qui distinguera un
expert d'un dbutant sera le nombre de ces refactorings qu'il est capable
d'utiliser bon escient.
PLACE AUX PRATIQUES!
Vous voil maintenant quips pour tirer le meilleur parti de cet outil.
Bonne lecture! N'oubliez pas son pendant sur le Web, constamment
actualis:
http://referentiel.institut-agile.fr/
51
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
Plutt que parler de "test fonctionnel" on prfrera "spcifications du
comportement du produit"; par ailleurs le volet technique de BDD est
complt par un ensemble de techniques favorisant la conversation avec
les interlocuteurs responsables de la dfinition du produit.
En supplment des techniques de refactoring utilises dans TDD,
l'approche BDD prte, en matire de conception, une attention
particulire la rpartition des responsabilits ce qui conduit favoriser la
technique dite de "mocking".
En synthse, BDD consiste augmenter TDD et ATDD d'un certain
nombre de principes supplmentaires:
appliquer le principe des "cinq pourquoi" chaque User Story
propose pour en comprendre l'objectif
raisonner "de l'extrieur vers l'intrieur", c'est--dire toujours
implmenter le comportement qui contribue le plus
directement cet objectif
dcrire ces comportements dans des notations accessibles
tous: experts fonctionnels, dveloppeurs, testeurs
appliquer ces techniques jusqu'aux plus bas niveaux de
description du logiciel, en tant attentif la rpartition des
comportements entre classes
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
Chapitre 9: BDD (Behaviour-Driven Development)
53
voir un sujet purement technique ou de rduire la pratique
l'utilisation d'un outil
COMMENT RECONNAITRE SON
UTILISATION?
au sein d'une quipe utilisant BDD, une partie significative de la
"documentation fonctionnelle" du produit devrait tre
disponible sous la forme de User Stories agrmentes de
scnarios excutables
QUELS BNFICES EN ATTENDRE?
Une quipe utilisant dj TDD ou ATDD peut souhaiter voluer vers
BDD pour les raisons suivantes:
BDD propose un cadre plus prcis pour le dialogue avec les
experts fonctionnels
les notations issues de l'approche BDD (notamment le canevas
given-when-then) sont plus proches du langage courant et
moins contraignantes compares des outils du type Fitnesse
l'approche BDD permet de gnrer automatiquement une
documentation technique partir des "spcifications"
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
O SE RENSEIGNER POUR EN SAVOIR PLUS?
(LIVRES, ARTICLES)
"Introducing BDD", de Dan North (2006)
"Translating TDD to BDD", de Liz Keogh (2009)
PUBLICATIONS ACADMIQUES ET TRAVAUX
DE RECHERCHE
Le peu de publications ce sujet se concentre sur des questions
d'implmentation, par exemple cet article.
Chapitre 9: BDD (Behaviour-Driven Development)
55
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
phrase peut contenir plusieurs exigences distinctes, ou au contraire
dcrire sur plusieurs paragraphes une exigence unique.
Tous les lments du backlog ne sont pas dcrits au mme niveau de
dtail chaque moment du projet: les lments dont la ralisation est
prvue une date lointaine peuvent tre des pans entiers de
fonctionnalits dcrits en une seule phrase, alors que ceux dont la
ralisation est imminente peuvent tre trs dtaills et accompagns de
nombreux lments de dtails tels que tests, dessins d'interface, etc.
Chapitre 10: Backlog
57
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
l'industriel DuPont, qui met au point une stratgie de prototypage de
nouveaux produits en moins de 90 jours.
Chapitre 11: Bote de temps
59
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
en particulier, les outils d'intgration continue (CruiseControl,
Hudson, etc.) sont distincts des outils d'automatisation du build
(make, Ant, Maven, rake, etc.)
la prise en charge par un environnement de dveloppement
(IDE) de certaines oprations d'assemblage n'est pas suffisante:
il doit tre possible de raliser le "build" en dehors de l'IDE
on conseille en gnral s'assurer que le "build" dure moins de
10 minutes, tests automatiss compris; au-del, on compromet
la capacit de l'quipe pratiquer l'intgration continue
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
UTILISATION?
Pour s'assurer de la mise en place d'un build automatis, le plus simple
est d'effectuer un test l'improviste: demander par exemple une
quipe de fournir une version installable de son produit.
Utilisez un chronomtre pour mesurer le temps ncessaire
l'obtention d'une version, puis tentez l'installation sur une machine qui
n'a pas t prpare par l'quipe de dveloppement. Toute "surprise"
pendant ce processus peut tre considre comme une piste
d'amlioration du build automatis.
L'automatisation du build est un prrequis l'utilisation efficace de
l'intgration continue. Elle apporte cependant des bnfices propres:
Chapitre 12: Build automatis
61
elle limine une source de variation et par consquent de
dfauts; une procdure manuelle qui contient de nombreuses
tapes, toutes ncessaires, offre autant d'opportunits de se
tromper
elle impose de documenter l'ensemble des hypothses et
suppositions qui caractrisent l'environnement cible, ainsi que
les dpendances envers des produits externes
(LIVRES, ARTICLES)
Pragmatic Project Automation, de Mike Clark (2004)
62
Chapitre 13
Cartes CRC (Classe,
Responsabilit,
Collaborateurs)
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.
Chapitre 13: Cartes CRC (Classe, Responsabilit, Collaborateurs)
63
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
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.
Chapitre 14: Carton, Conversation, Confirmation
65
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).
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
qui, dans le contexte unique de votre projet, permettra
l'quipe de prendre des dcisions avises
une charte de projet ne doit pas dpasser une page en
longueur, faute de quoi elle deviendra un nouveau document
rbarbatif et rarement lu
On constate souvent, quand on interroge les membres d'une mme
quipe, des divergences surprenantes entre leurs rponses des
questions du type: "Quel est l'objectif de ce projet? Quels en sont les
aspects les plus importants? Qui cherchez-vous satisfaire? De quels
moyens disposez-vous?"
L'tablissement d'une charte mais surtout le fait de s'assurer que son
contenu soit connu et approuv par l'ensemble de l'quipe donne au projet
une unit d'intention qui est un facteur de succs souvent critique.
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
Chapitre 15: Charte projet
67
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
En anglais le terme consacr, provenant de Ron Jeffries dans sa
description d'Extreme Programming, est "quick design session".
Dans une approche Agile l'activit de conception est rpute tre
"lisse" tout au long du projet, plutt que concentre dans une phase
explicite de conception en amont de l'implmentation.
Cependant, il n'est pas suffisant de supprimer cette phase explicite de
conception pour s'assurer que les activits de conception, qui restent
ncessaires, sont menes de faon satisfaisante.
Les sessions de conception au tableau blanc sont l'une des deux
pratiques Agiles qui jouent ce rle, l'autre tant le refactoring.
Chapitre 16: Conception au tableau blanc
69
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
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
Chapitre 17: Conception simple
71
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
UTILISATION?
l'quipe dispose d'un "backlog" de tches spcifiquement lies
la conception:
dfauts identifis ncessitant un refactoring explicite
opportunitis de simplification
dcisions potentielles, diffres en attendant plus
d'informations
ce "backlog" ne stagne pas, et ne sert pas de cahier de
dolances jamais confrontes; une partie du temps productif de
l'quipe est effectivement consacre ces volutions de
conception
l'quipe utilise une ou plusieurs pratiques annexes (sessions
improvises, CRC, revues de conception) offrant une
opportunit d'aborder le sujet
on doit considrer comme un signal d'alarme, indiquant
que la pratique n'est pas correctement mise en oeuvre, toute
impression que des volutions relativement simples prennent
de plus en plus de temps mesure que le projet progresse
une rduction du cot total de dveloppement
une rduction des risques lis la surconception ("gold
plating")
(LIVRES, ARTICLES)
Is Design Dead?, article de Martin Fowler publi en 2000 et mis
jour en 2004, synthse du point de vue Agile sur la
conception logicielle
DE RECHERCHE
Empiriques
Chapitre 17: Conception simple
73
Les tudes empiriques font tat de faon constante
d'un taux important d'volution des exigences au
cours d'un projet
Capers Jones estime qu'en moyenne 35% des
exigences (volume calcul en points de fonction) d'un
projet sont modifies au cours de sa dure
("Assessment and Control of Software Risks", 1994)
Les recherches se sont jusqu' prsent focalises sur
la prvention de ces volutions, il n'existe pour
l'instant pas de travaux notables axs sur l'approche
Agile consistant tenir la volatilit des exigences
comme un constat auquel s'adapter, non une
difficult surmonter...
74
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
Chapitre 18: Critres de simplicit
75
ressemblances plus subtiles entre lments de code. De mme le
troisime s'appuie sur les notions non triviales de couplage et cohsion.
Le quatrime critre, sous rserve d'avoir pu se mettre d'accord sur
les trois premiers, peut tre plus facilement objectiv.
76
Chapitre 19
Dcoupage d'une user
story
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.
Chapitre 19: Dcoupage d'une user story
77
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.
Traduction directe de "definition of ready".
vite de commencer travailler alors que les critres de
satisfaction ne sont pas clairs, ce qui risquerait d'entraner de
coteux allers-retours avant de se mettre d'accord
ORIGINES
appellation trs rcente, formule par Jeff Sutherland en 2008
78
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.
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.
Chapitre 21: Dfinition de 'fini'
79
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.
UTILISATION?
l'quipe est capable de montrer, sur demande, sa dfinition de
"fini"
ces critres sont voqus en fin de Sprint ou d'itration et
justifient la dcision de comptabiliser un incrment dans la
vlocit, ou non
en amont, fonctionne comme une "checklist" guidant la
rflexion des dveloppeurs pendant l'estimation et la
ralisation
en aval, moins de temps perdu en travaux de "rfection" une
fois qu'une fonctionnalit a t accepte
rduit les risques de brouille entre l'quipe et ses
commanditaires en instaurant un contrat clair
ORIGINES
Propose par Dan Rawsthorne en 2002-2004
Rpandue sous ce terme partir de 2007 environ
Considre comme un lment majeur de Scrum
80
DE RECHERCHE
Aucun travail de recherche thorique ou empirique connu ne concerne
cette pratique. On peut cependant considrer comme pertinents les
travaux de Flores et Winograd, Macomber:
Understanding Computers and Cognition, Flores F., Winograd
T., 1987, prsentant le modle "Conversation for Action"
Securing Reliable Promises on Projects, Macomber H., 2001
Chapitre 21: Dfinition de 'fini'
81
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.
Dans le contexte des entreprises qui l'ont mise en place initialement
(startups du Web 2.0), le principal bnfice du dploiement continu est
la rduction du temps de cycle, avec deux effets principaux:
le retour sur investissement pour chaque nouveau
dveloppement commence bien plus tt, ce qui limite les
besoins en capitaux
il est possible d'obtenir trs rapidement des retours des
utilisateurs sur une nouvelle fonctionnalit, ce qui permet par
exemple de tester plusieurs hypothses et de retenir celle qui
reprsente une amlioration du produit
82
QUELS COTS OU INVESTISSEMENTS FAUT-
IL CONSENTIR?
L'infrastructure permettant le dploiement continu tient compte non
seulement du test automatis, mais galement (entre autres) de la
surveillance du comportement de l'application en production pour
dtecter rapidement des anomalies qui n'auraient pas t rvle par ces
tests, et de la possibilit de retour en arrire trs rapide dans le cas
d'une telle anomalie. L'investissement ncessaire est donc sensiblement
plus important.
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
Chapitre 22: Dploiement continu
83
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
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.
Chapitre 24: Dveloppement itratif
85
Chapitre 25
Dveloppement par les
tests
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
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).
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:
Chapitre 25: Dveloppement par les tests
87
adoption partielle: seuls certains dveloppeurs plus motivs ou
mieux forms utilisent TDD; on ne peut pas attendre de
bnfices collectifs dans ce cas
mauvais entretien de la batterie de tests: en particulier, une
batterie de tests qui prend trop longtemps drouler
dlaissement de la batterie de tests: dcoulant parfois du
mauvais entretien, parfois d'autres facteurs tel un trop brusque
renouvellement de l'quipe
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
des techniques spcifiques avec leurs propres outils
apparaissent pendant cette priode, l'une des plus connues est
sans doute l'approche "Mock Objects" de Freeman et
McKinnon en 2000
le livre de Kent Beck Test Driven Development: By Example
achve de codifier la pratique en 2003
on assiste ensuite la naissance de plusieurs pratiques
inspires par TDD mais qui s'en cartent suffisamment pour
tre considres comme des innovations part entire:
"ATDD" ou "dveloppement pilot par les tests fonctionnels"
et "BDD)" sont les plus notables (2006-2010)
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
je suis capable de piloter par les tests diffrents types
de domaines techniques: calcul, interface graphique,
accs aux donnes...
UTILISATION?
la couverture de code est un des moyens courants de
constater l'utilisation du dveloppement par les tests; une
couverture leve ne signifie pas ncessairement une bonne
utilisation, mais une couverture infrieure environ 80% est
contrario un signe d'utilisation probablement dficiente
les historiques de la gestion de versions (logs CVS ou git par
exemple) font apparatre des modifications quilibres: chaque
publication de code principal s'accompagne d'une publication
de nouveaux tests (hors refactoring)
de faon informelle, de nombreux retours d'exprience
d'quipes utilisant TDD font tat d'une rduction trs
significative du nombre de dfauts, en contrepartie d'un
surcot modr du dveloppement initial
ces mmes retours suggrent que ce surcot est compens
par l'limination d'une partie importante de l'effort de mise au
point en fin de projet
en imposant l'criture du test avant celle du code, cette
pratique annule le "biais de confirmation" qui est la justification
avance par Myers pour affirmer qu'un dveloppeur "ne doit
jamais tester son propre code"
bien que les travaux scientifiques ce sujet restent
circonspects, de nombreux vtrans de cette pratique y voient
un facteur d'amlioration de la conception objet de leur code,
et plus gnralement de la qualit technique: on entend ainsi
que la pratique du TDD a pour rsultat du code possdant une
meilleure cohsion et un plus faible couplage
90
(LIVRES, ARTICLES)
Test Driven Development: By Example, de Kent Beck
DE RECHERCHE
Cette pratique considre par des auteurs tels que Steve McConnell
(Code Complete, 2nd Edition) comme l'une des contributions les plus
importantes du mouvement Agile a fait l'objet de plusieurs tudes.
De mme que pour le binmage, les valuations empiriques sont
souvent sont menes sur des populations d'tudiants plutt que sur des
professionnels dans des conditions relles d'exercice, ce qui limite la
porte de leurs conclusions.
Empiriques
"Test Driven Development: Empirical Body of
Evidence" recense les principales tudes connues en
2006, portant majoritairement sur les effets
constats informellement de rduction des dfauts
(globalement favorable) et d'augmentation de l'effort
(globalement neutre)
"Realizing quality improvement through test driven
development" est une tude plus rcente dans un
contexte industriel, confirmant ces rsultats (2008)
"Does Test-Driven Development Improve the
Program Code? Alarming Results from a
Comparative Case Study " est l'une des premires
s'intresser l'effet de TDD sur les mtriques
usuelles considres comme corrles la qualit du
code, et "s'alarme" d'un effet dfavorable du TDD
sur ces dernires (2008)
91
Chapitre 26
Dveloppement par les
tests client
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.
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
Il convient par consquent d'tre d'autant plus vigilant ce que le
choix des outils ne se fasse pas au dtriment de la facilit, pour les
responsables produit, dialoguer avec les dveloppeurs propos de la
dfinition des exigences.
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
de mme que le dveloppement par les tests oblige
concevoir les applications pour tre facilement testable au
niveau unitaire, le dveloppement par les tests client oblige
crer des interfaces spcifiques pour le test fonctionnel; il est
gnralement conseill de ne pas tester directement travers
l'IHM mais de fournir une couche ddie au test applicatif par
exemple
Chapitre 26: Dveloppement par les tests client
93
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.
En anglais "backlog grooming", littrallement "toilettage" ou "pouillage"
du backlog.
94
L'intrt de cette runion est de s'assurer de la pertinence du backlog.
Contrairement un cahier des charges celui-ci est un "document" par
nature volutif: il n'est pas ncessaire par exemple que toutes les user
stories aient t finement dcoupes et estimes en dbut de projet, par
contre il est important qu' tout moment une quantit suffisante de
stories soient finement dcoupes et estimes.
Il arrive frquemment qu'un backlog "enfle" excessivement au cours
d'un projet, se chargeant de fonctionnalits qui ne sont pas vraiment
prioritaires mais qu'on a considr comme potentiellement de bonnes
ides ne pas oublier: en l'absence d'une effort dans le sens inverse,
cette inflation peut s'avrer nfaste au respect du calendrier de livraison
souhait.
ORIGINES
On doit apparemment l'expression "backlog grooming" Mike Cohn et
elle remonte au moins 2005.
Chapitre 27: Entretien du backlog
95
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.
En anglais "Whole Team" ou "One Team".
96
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.
Chapitre 28: Equipe
97
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
la hausse ou la baisse, lorsqu'on a acquis de nouvelles
informations plus pertinentes
Chapitre 29: Estimation
99
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 parle galement d'estimation par affinit ("affinity estimation") ou
d'estimation par similitude d'effort.
100
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
exprimer les estimations de faon relative, surtout lorsqu'on
utilise une unit telle que les points, est une faon d'viter les
erreurs courantes lies l'activit d'estimation: exiger trop de
prcision, ou confondre estimation et engagement
Chapitre 30: Estimation relative
101
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
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
Chapitre 32: Gestion de versions
103
Chapitre 33
Given - When - Then
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
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").
Claude Aubry, expert Scrum, a propos la francisation "beurdone"; elle
est reste quelque peu marginale.
En rendant non seulement visible mais indniable la situation relle de
l'itration ou du projet par rapport au planning initialement prvu, cette
pratique oblige l'quipe confronter les difficults plus rapidement.
(Corollairement, pour tre efficace ce graphe doit tre affich dans
un format assez grand et dans un endroit o il suscite des discussions; on
vitera de le placer l'cart dans un couloir, au format A4...)
Chapitre 34: Graphe burn-down
105
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
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
Chapitre 35: Grille INVEST
107
dveloppement mettra en place les "bouchons" ncessaires
pour simuler un utilisateur identifi.
Pour rpondre au critre N, ne formuler dans un premier
temps que l'essentiel, savoir l'objectif fonctionnel recherch;
on vitera par exemple de spcifier dans une User Story des
lments techniques, par exemple "En tant qu'acheteur,
lorsque j'cris dans le champ texte puis que je clique sur le
bouton Recherche, la liste gauche du champ de recherche est
renseigne avec les articles correspondants". Ces dtails
d'implmentation feront l'objet d'une discussion permettant
d'identifier la meilleure solution; initialement, une formulation
du type "L'acheteur peut chercher des articles par mot-cl" est
suffisante pour l'estimation et la planification.
Pour rpondre au critre V, reprsenter un incrment
rellement utile pour l'utilisateur final ou du point de vue du
client. Par exemple, "raliser le schma de la base de donnes
pour la facturation" n'est pas un incrment ayant de la valeur
en soi, mais une tche technique. A contrario, "mettre une
facture pour les achats d'articles en France" en laissant pour
plus tard une seconde Story dont l'nonc serait "mettre une
facture pour des achats livrs depuis l'tranger" reprsente un
meilleur dcoupage: chaque incrment permet de raliser une
partie distincte du chiffre d'affaires.
Pour rpondre au critre E, tre suffisamment comprise, mais
galement suffisamment prcise. Il arrive parfois qu'on formule
des User Stories qui reprsentent presque un projet part
entire, par exemple "Optimiser le calendrier de livraison des
achats". Les conditions de satisfaction doivent tre
suffisamment prcises et restreintes pour que l'quipe de
dveloppement puisse quantifier l'effort d'implmentation,
sinon dans l'absolu du moins en termes de complexit relative.
(L'quipe estime par exemple que "Livrer en deux fois lorsque
des carts suprieurs une semaine sparent les dates de
livraison de deux articles du panier" reprsente deux fois
l'effort requis pour "Emettre la facture", cette dernire servant
en quelque sorte d'talon.)
Pour rpondre au critre S, ne pas dpasser quelques jours-
hommes. La granularit exacte est fonction du nombre de
personnes dans l'quipe de dveloppement et de la dure de
l'itration, le critre dterminant tant la possibilit de
108
terminer au minimum une, et idalement cinq ou six au
minimum, User Stories dans une seule itration.
Pour rpondre au critre T, tre suffisamment bien comprise
pour qu'il soit possible de fournir un exemple dtaill:
"Lorsque j'achte l'article X au prix Y, sachant que la TVA sur
la catgorie Livres est de Z, la facture doit indiquer le montant
total suivant:..." La fonctionnalit envisage doit entraner de la
part du produit des consquences ou des comportements
observables. Ainsi "Amliorer la performance" n'est pas une
bonne User Story, il est prfrable de prciser: "La page
contenant les rsultats de recherche doit s'afficher en moins de
2 secondes".
Chapitre 35: Grille INVEST
109
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
l'quipe a automatis entirement le processus de compilation
et gnration du produit
ce processus inclut l'excution d'une batterie de tests unitaires
et fonctionnels automatiss chaque publication dans le
rfrentiel des sources
en cas d'chec ne serait-ce que de l'un de ces tests, l'quipe
cherche prioritairement rtablir la stabilit du produit
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
Chapitre 36: Intgration continue
111
Windows NT 3.0 et dcrite entre autres par Steve McConnell
en 1996
on ne parle alors pas d'automatisation, ni des tests, ni
du"build", c'est--dire les tapes de compilation,
dition de liens et production de l'excutable et des
fichiers annexes; l'accent est mis sur la frquence, le
cycle quotidien tant considr comme "extrme"
l'expression "Smoke Test" est hrite de
l'lectronique: le test le plus basique pour un circuit
complexe consiste le mettre sous tension; si on
voit de la fume s'chapper d'un des composants,
c'est qu'il y avait une erreur... il s'agit d'un test
rudimentaire pour s'assurer du bon fonctionnement
gnral du logiciel, sans prjuger de l'existence de
dfauts moins vidents
l'ide d'intgration continue comme un objectif de
l'organisation du projet, caractrisant un processus de
dveloppement "moderne" et par contraste aux intgrations
infrquentes qui ont t la rgle jusqu'alors, apparat dans
"Software project management: a unified framework" de
Walker Royce, en 1998
l'ide d'intgration continue, avec les ingrdients suivants, est
propose par Extreme Programming en 1997 et dcrite par
Martin Fowler en 2000:
utilisation d'un rfrentiel de gestion de versions du
code source
automatisation du processus de "build"
prsence de tests unitaires et fonctionnels
automatiss (en lieu et place d'un "smoke test"
manuel)
excution au minimum quotidienne de l'ensemble
(build+test)
gestion manuelle du processus d'intgration
le premier "serveur d'intgration continue", Cruise Control,
est publi sous une license Open Source en 2001
par rapport la pratique prcdente, il automatise la
surveillance du rfrentiel des versions, le lancement
de l'ensemble (build+test), la notification des
rsultats et la publication de rapports
112
la priode 2001-2007 est surtout marque par l'apparition de
nombreux outils de ce type, la concurrence entre outils
attirant l'attention de faon sans doute disproportionne sur
ces aspects un peu annexes
un progrs important, cependant, est l'ide de rendre visible
l'tat de l'intgration la plus rcente par un signal visuel, l'ide
remonte environ 2004
dans les premiers temps elle a plutt l'aspect d'un
gadget, utilisant une lampe d'ambiance
on voit ensuite apparatre de vritable tableaux de
bord de l'intgration continue, semblable des
tableaux de bord industriels
partir de 2007 on commence parler de "dploiement
continu", tout d'abord comme un idal thorique; c'est un
article d'un ingnieur chez l'diteur IMVU qui fera sensation et
marque l'avnement concret de cette pratique, au dbut 2009
UTILISATION?
Le signe le plus courant de la pratique au sein d'une quipe est la
prsence d'un moniteur ddi ou d'un indicateur visuel (lampe, cran
LED ou LCD, etc.) ddi l'affichage du rsultat de l'intgration la plus
rcente.
Plus subtilement, il convient d'observer comment l'quipe ragit une
intgration "casse" signalant un dfaut dans le produit. Ds lors que
l'quipe est consciente d'un dfaut, mais tolre et laisse persister une
situation o elle n'est pas en mesure de livrer un produit exploitable, il
n'est plus possible de parler d'intgration continue!
Il est, de ce fait, presque tentant de parler de l'intgration continue
comme d'une comptence (d'quipe) plutt que comme d'une pratique.
le principal intrt de l'intgration continue est de rduire la
dure, l'effort et la douleur provoque par chaque intgration,
l'exprience suggrant qu'il existe un "cercle vicieux" dans le
sens inverse: plus les intgrations sont espaces, plus elles sont
Chapitre 36: Intgration continue
113
difficiles, et plus (en raction la douleur provoque) on a
tendance les espacer
l'intgration continue dmultiplie le bnfice d'une batterie
tendue de tests unitaires: elle permet de dtecter au plus tt
les dfauts n'apparaissant qu' l'intgration et par consquent
de minimiser leurs consquences et les risques associs aux
dfauts d'intgration
l'intgration continue permet de tirer le meilleur parti du
dveloppement incrmental: des questions comme l'installation
et le dploiment du produit ne sont pas laisses de ct jusqu'
la fin du projet mais rsolues ds le dpart dans le cadre de la
pratique
(LIVRES, ARTICLES)
Continuous Integration, Martin Fowler (2006)
Continuous Integration: Improving Software Quality And
Reducing Risk, de Paul Duvall (2007)
DE RECHERCHE
Sur le plan de l'valuation empirique, l'une des questions les plus
importantes semblerait tre la suivante: si l'on compare le cot total,
c'est--dire le cot unitaire d'une intgration multipli par le nombre
d'intgrations au cours d'un projet, existe-t-il une frquence optimale
d'intgration?
Cette question semble pour l'instant sans rponse, et aucune tude
ne semble avoir t directement consacre l'valuation de l'intgration
continue.
114
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.
Le terme "Sprint" est galement utilis et vient de Scrum. Les deux
termes "Sprint" et "itration" sont utiliss indiffremment sans
connotation particulire.
Chapitre 37: Itration
115
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)
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.)
L'un des obstacles couramment rencontr par les projets de
dveloppement concerne la difficult de la traduction entre deux langages
techniques, celui des dveloppeurs d'une part, celui des experts mtier
d'autre part.
Pour une part cette traduction est invitable: les dveloppeurs
doivent s'exprimer en termes d'algorithmes, par exemple, qui n'ont pas
Chapitre 38: Langage omniprsent (ubiquitous language)
117
ncessairement un quivalent dans le vocabulaire de l'entreprise pour
laquelle ils travaillent.
Cependant on constate souvent que ce vocabulaire du logiciel
"dborde" du cadre dans lequel il est justifi, au point que les
interlocuteurs des dveloppeurs se sentent dmunis, voire alins, lors
des conversations avec ces derniers.
L'adoption explicite et dlibre d'un "langage omniprsent" permet
de mitiger ces difficults et reprsente donc un facteur de succs d'une
approche Agile.
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
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.)
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
Chapitre 39: Livraisons frquentes
119
livraison doit tre une "version beta" value par des
utilisateurs reprsentatifs
dans certains contextes (logiciels embarqus, par exemple) il
n'est pas possible de prvoir une livraison frquente tous les
utilisateurs; cela ne doit pas servir de prtexte ne pas
organiser une livraison frquente des utilisateurs (sites
pilotes, clients volontaires, etc.)
Savoir organiser une mise en production frquente ds les dbuts du
projet est l'une des pierres angulaires de la rduction du risque par
l'approche Agile:
on diminue l'effet tunnel pour la planification du projet
on s'assure plus rapidement de l'adquation du produit aux
besoins rels
on obtient un retour plus rapide sur la qualit et la stabilit du
produit
120
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.
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
Chapitre 40: Niko-niko
121
L'intrt de la pratique est d'objectiver un lment, la motivation ou le
bien-tre de l'quipe, habituellement subjectif et difficile mesurer.
C'est une excellente illustration du "Principe de Gilb": "Si vous avez
besoin de quantifier quelque chose, il existe toujours une manire de le
faire qui soit prfrable ne pas le quantifier du tout." En d'autres
termes, il n'est pas ncessaire qu'une mesure soit parfaite ou trs
prcise, ds lors que votre objectif est de rendre quantifiable quelque
chose qui ne l'est pas encore: l'essentiel est de commencer.
(LIVRES, ARTICLES)
Niko-niko, d'Emmanuel Chenu (2009)
122
Chapitre 41
Objets fantaisie (Mock
Objects)
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 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").
Chapitre 41: Objets fantaisie (Mock Objects)
123
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
Le principal intrt de cette technique est qu'elle permet de dcoupler
des parties du code de faon les tester de faon rellement "unitaire",
c'est--dire sans que le rsultat du test soit dpendant d'un composant
qui n'a rien voir avec celui que l'on teste, mais dont ce dernier dpend
pour son fonctionnement.
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
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.
Le principe des Personas se rsume l'observation suivante: un
concepteur qui cherche faire plaisir tous les utilisateurs concevable
est contraint tellement de compromis que sa cration ne convient
finalement personne.
Chapitre 42: Personas
125
Par consquent, il est prfrable de dcrire de faon prcise et
personnalise un utilisateur nammoins reprsentatif, et justifier ses
choix (de fonctionnalit, de conception graphique, d'ergonomie) en
fonction de cet utilisateur.
Partager ces informations au sein de l'quipe permet galement de
responsabiliser chacun sur les consquences de ses choix. Un
dveloppeur soucieux d'optimiser son produit pour "Jeanine, retraite"
vitera de lui-mme de proposer un dialogue de prfrences contenant
50 rglages; ce ne serait pas ncessairement le cas s'il avait en tte la
notion plus abstraite de "l'utilisateur".
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
DE RECHERCHE
Deux tudes empiriques notables concernent cette pratique:
"An Empirical Study Demonstrating How Different Design
Constraints, Project Organization and Contexts Limited the
Utility of Personas" de Ronkko et al. (2005) est une tude de
cas qui s'appuie sur trois projets pour montrer que les enjeux
politiques prsents au sein de toute entreprise peuvent limiter
voire annuler l'efficacit de cette pratique
"Real or Imaginary: The effectiveness of using personas in
product design" de Long (2009) prsente une tude
exprimentale, utilisant des tudiants, qui tend confirmer
l'intrt de la pratique
126
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.
Chapitre 43: Planning poker
127
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
le format de la runion permet d'exploiter la connaissance de
tous les membres de l'quipe, alors que dans une runion "
btons rompus" il arrive souvent que certaines personnes ne
s'expriment jamais
la discussion qui a lieu suite la rvlation des estimations
initiales permet de mettre en commun des connaissances sur la
user story en question et les difficults potentielles de son
estimation
DE RECHERCHE
Plusieurs tudes initiales menes par Nils Christian Haugen semblent
confirmer l'intrt de la pratique, qui produirait des estimations
lgrement plus fiables que l'estimation par un seul "expert".
128
Chapitre 44
Points (estimation en)
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.
L'expression anglophone consacre est "story points".
Chapitre 44: Points (estimation en)
129
Plusieurs synonymes existent exprimant avec plus ou moins de
fantaisie l'intention de se dmarquer des estimations "ralistes" en
hommes-jours: l'un des plus courants est "NUTS", acronyme anglophone
pour "Nebulous Units Of Time".
On peut galement croiser des "cahouettes" (francisation de "nuts"),
des "nounours" (francisation de "gummi bears", c'est dire des bonbons
en forme d'ourson), etc.
130
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.
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,
Chapitre 45: Programmation en binmes
131
lorsqu'il est pratiqu correctement, mais dans le cas limite o
un seul programmeur travaille rellement, c'est bien le risque
encouru
on doit entendre parler le conducteur; binmer c'est aussi
"programmer haute voix", s'il est silencieux le copilote doit
intervenir
imposer le binmage ne peut en aucun cas s'avrer fructueux
dans une situation o les aspects relationnels, y compris les
plus concrets (hygine personnelle, etc.) prsentent un
obstacle
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
je reconnais le bon moment pour abandonner le
clavier et changer de rle
je reconnais le bon moment pour "voler" le clavier et
changer de rle
Avanc
je suis capable de m'insrer dans le rle de copilote
en cours de dveloppement d'une tche commence
par un autre
UTILISATION?
l'agencement du mobilier dans la pice et des postes de travail
sont adapts au binmage (on peut reconnatre une quipe
novice tout amnagement qui rend le binmage
inconfortable, par exemple trop peu de place pour deux
siges)
l'ambiance sonore est matrise: les conversations de N
binmes simultanes crent un murmure perceptible mais qui
ne perturbe pas le travail
si vous pouvez voir des programmeurs portant un casque
audio en entrant dans la pice, c'est un signe ngatif suggrant
non seulement l'absence de binmage mais galement de
conditions dfavorables son adoption
une plus grande qualit des dveloppements; "programmer
haute voix" conduit mieux apprhender les complexits et
les dtails pernicieux, limitant ainsi le risque d'erreurs ou de se
fourvoyer
une meilleure diffusion des connaissances dans l'quipe,
notamment lorsqu'un dveloppeur peu familier d'un module
travaille avec un autre qui le connait mieux
une amlioration plus rapide des comptences des
dveloppeurs juniors, au contact de leurs ans
une rdution de l'effort de coordination, puisqu'au lieu de N
dveloppeurs on est amen coordonner N/2 binmes
133
une meilleure capacit rester concentrer et rsister aux
interruptions: lorsqu'un des deux membres du binme doit
s'interrompre, l'autre peut rester focalis sur la tche et aider
son collgue se reconcentrer ensuite
IL CONSENTIR?
Sans que ce soit confirm de faon probante par des tudes empiriques,
on estime que dans le cas idal, la programmation en binmes se traduit
par un surcot de 15% par rapport la situation o chaque dveloppeur
travaille sparment, surcot qui serait facilement compens par
l'amlioration de la qualit, puisqu'une mauvaise qualit se traduit par
une pnalit de maintenance tout au long du projet.
(LIVRES, ARTICLES)
Pair Programming Illuminated, de Laurie Williams
DE RECHERCHE
Thoriques
Les travaux thoriques les plus intressants sont
ceux qui poursuivent l'approche ethnographique
initie entre autres par Sallyann Freudenberg (ne
Bryant), en examinant " la loupe" des interactions
entre programmeurs dans leur milieu habituel
How Pair Programming Really Works cite certains
de ces travaux assez reprsentatifs de la tendance
rcente remettre en question le modle
"conducteur/copilote"
Empiriques
The Collaborative Software Process, thse doctorale
de Laurie Williams, la plus connue des tudes ce
sujet, rapportant les conclusions initiales suivantes:
134
amlioration de la qualit, pas de surcot constat de
faon statistiquement significative
The effectiveness of pair programming: A meta-
analysis, une mta-analyse recensant et regroupant
les 18 principales tudes empiriques connues ce
jour, conclusions: le binmage amliore la qualit et
permet de rduire les dlais de dveloppement, mais
conduit une augmentation du cot (i.e. en termes
de charge); la rduction du dlai concerne surtout les
tches les plus simples confies des juniors et peut
s'accompagner d'une rduction de la qualit.
La plupart des tudes empiriques (14 sur les 18
analyses dans la rfrence ci-dessus) souffrent d'un
dfaut qui entche leurs conclusions; elles sont
menes sur des populations d'tudiants plutt que
sur des professionnels dans des conditions relles
d'exercice.
135
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.
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
L'usage significatif de radiateurs d'information vhicule deux messages
importants:
l'quipe n'a rien cacher (notamment ses clients)
l'quipe n'a rien se cacher: elle admet et confronte ses
difficults
Le principal intrt de cette pratique est donc de responsabiliser les
diffrents intervenants. Un avantage annexe consiste susciter des
conversations lorsque des personnes extrieures l'quipe visitent les
locaux.
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
Chapitre 46: Radiateurs d'information
137
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.
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
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
Chapitre 47: Refactoring
139
UTILISATION?
les historiques de la gestion de versions (logs CVS ou git par
exemple) contiennent des entres libelles "Refactoring"
les modifications correspondantes sont rellement
isofonctionnelles (pas d'effet sur les tests unitaires, pas de code
ajout)
les aspects objectifs de la qualit du code (longueur,
duplication, couplage, cohsion, complexit cyclomatique)
s'amliorent au fil du temps
en lien avec la [proprit collective], la connaissance des
dcisions de conception est mieux partage dans l'quipe
des schmas de conception, ou des modules gnriques,
mergent et peuvent tre rutiliss par la suite
(LIVRES, ARTICLES)
Refactoring, de Martin Fowler
Refactoring (SourceMaking)
Le Refactoring, Rgis Medina
La mthode Mikado
DE RECHERCHE
Les travaux empiriques concernant la pratique du remaniement sont
quivoques, et peinent mettre en vidence les bnfices prtendus par
les quipes de dveloppement, qui y voient pourtant une pratique
indispensable. C'est un sujet de recherche prioritaire compte tenu de
l'importance accorde cette pratique au sein des mouvements Agile,
Extreme Programming et Software Craftsmanship.
Thoriques
140
Refactoring Object-Oriented Frameworks, thse de
doctorat de Bill Opdyke
Empiriques
An Empirical Evaluation of Refactoring, tude
prliminaire, bilan: pas d'effets constats
Refactoring--Does It Improve Software Quality?,
tude prliminaire, bilan: effets nfastes selon
certaines mtriques sur des projets open source
Chapitre 47: Refactoring
141
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.
Le terme anglais est "collective code ownership".
142
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.
Un modle de responsabilit collective
diminue les risques de blocage en cas d'absence d'un des
dveloppeurs
favorise la transmission des connaissances techniques
rend chacun des dveloppeurs responsable de la qualit de
l'ensemble
favorise une conception du code dicte par des dcisions
techniques et non par la structure sociale de l'quipe
IL CONSENTIR?
Si la notion de responsabilit collective est bien accepte dans le
discours Agile car conforme la philosophie gnrale de responsabilit
partage, elle a ses dtracteurs qui y voient plusieurs risques, auxquels il
convient d'tre attentif:
rendre chacun responsable de la qualit peut amener ce que
personne ne s'en proccupe ou ce que chacun se renvoie la
balle
la possiblit d'intervenir sur toutes les parties du code peut
tre dfavorable la dfinition d'interfaces claires et explicites
entre ces diffrentes parties, alors que ces interfaces sont
garantes d'une bonne conception
Chapitre 48: Responsabilit collective du code
143
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
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.
Le terme anglais originel tait "40 hour week" soit "semaine de 40
heures". On lui a prfr "sustainable pace", terme plus gnral.
L'approche Agile considre que le recours autre qu'exceptionnel des
mesures telles que les heures supplmentaires est rarement productif, et
contribue en fait masquer des dfauts de planification, de management
ou de qualit interne. Il est prfrable de mettre au jour ces dfauts et
d'en traiter la cause profonde plutt que de leur appliquer un traitement
symptmatique.
Chapitre 49: Rythme soutenable
145
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 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
Les enjeux d'une rtrospective jalon sont diffrents et par
certains aspects plus importants que ceux d'une rtrospective
d'itration; l'accent est mis sur des questions stratgiques, sur
le long terme, sur la sant relationnelle de l'quipe, alors
qu'une rtrospective d'itration s'intresse souvent des
questions concrtes et tactiques.
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
(LIVRES, ARTICLES)
Project Retrospectives, de Norm Kerth (2001)
Chapitre 50: Rtrospective jalon
147
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.
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
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.
UTILISATION?
assister en observateur une runion de ce type est la
meilleure faon de constater la mise en place de cette pratique
dfaut, on sera attentif aux pistes et dcisions d'amlioration
prises lors de la rtrospective: elles peuvent prendre la forme
d'un document crit, ou simplement de Post-It matrialisant les
dcisions prises et affichs sur un tableau mural spcifique
Chapitre 51: Rtrospectives d'itration
149
en premier lieu, les rtrospectives permettent de tirer le
meilleur parti des cycles itratifs: elles sont l'occasion d'adapter
et d'amliorer graduellement le fonctionnement de l'quipe
en mettant entre les mains des acteurs du projet les dcisions
sur le fonctionnement du projet, les rtrospectives
responsabilisent les participants et favorisent l'appropriation
des dcisions
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
(LIVRES, ARTICLES)
Project Retrospectives, de Norm Kerth (2001)
Agile Software Development, de Alistair Cockburn (2001,
rdit 2006)
Agile Retrospectives, de Esther Derby et Diana Larsen (2006)
150
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.
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
Chapitre 52: Runion quotidienne
151
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.
UTILISATION?
assister en observateur une runion de ce type est la
meilleure faon de constater la mise en place de cette pratique
la runion quotidienne favorise la circulation d'informations
importantes; elle apporte une occasion explicite permettant
l'ensemble de l'quipe de se synchroniser
le partage d'informations l'occasion d'une runion courte et
nergique contribue galement la cohsion de l'quipe
152
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)
(LIVRES, ARTICLES)
It's not Just Standing Up, de Jason Yip (2004)
DE RECHERCHE
Peu de travaux de recherche concernent directement cette pratique.
Chapitre 52: Runion quotidienne
153
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
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
une salle ddie favorise ce que Alistair Cockburn nomme la
"communication osmotique": la diffusion d'information (jusqu'
l'quilibre) entre ceux qui en disposent et ceux qui en ont
Chapitre 54: Salle ddie
155
besoin; au lieu de dpendre de mcanismes explicites de
communication (tlphone, email, runion) cette diffusion se
fait de faon "ambiante", par exemple en entendant (sans les
couter activement) les conversations des autres membres de
l'quipe, ou en lisant des Post-It affichs au mur
DE RECHERCHE
Les conditions "environnementales" favorisant la performance des
dveloppeurs ont fait l'objet d'un certain nombre d'tudes. Bien qu'il soit
gnralement difficile d'tablir de faon fiable quoi que ce soit qui ait trait
la productivit, en raison du caractre flou et ambigu de la notion
mme de "productivit" pour un programmeur, il semble en ressortir
que les deux "extrmes" que sont le bureau individuel ou le local ddi
soient les plus favorables.
Le bureau paysager, malgr son intrt conomique vident, et
l'attrait (plus subtil) qu'il peut exercer sur des managers soucieux de
"surveiller" leurs troupes, s'avre tre la pire des solutions, retenant le
plus mauvais des deux mondes.
How office space affects programming productivity examine
quelques tudes empiriques assez anciennes et voque l'intrt
de bureaux privatifs (1995)
Rapid software development through team collocation, une
tude plus rcente, semble confirmer qu'un local ddi favorise
de meilleures performances (du moins mesures par des
indices subjectifs de satisfaction, du client comme des
dveloppeurs) (2002)
156
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.
Traduction directe de l'anglais "Scrum of Scrums", on parle aussi de
"meta Scrum".
Chapitre 55: Scrum de Scrums
157
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
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.
L'intention de cette pratique est de modrer le risque de livrer un
produit qui comporterait des fonctionnalits avec une forte "valeur
mtier", mais que l'utilisateur ne pourrait pas exploiter parce qu'elles
s'avrent dpendantes de fonctionnalits plus faible "valeur mtier",
donc de plus basse priorit et qui n'ont pas encore t ralises.
ORIGINES
formule, sans la nommer, par Jeff Patton dans un article
intitul "It's All in How You Slice" en 2005
Chapitre 56: Story mapping
159
nomme "Story Mapping" dans un article, trs illustr, du
mme Jeff Patton: "The new user story backlog is a map", en
2008
160
Chapitre 57
Tableau des tches
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.
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
Chapitre 57: Tableau des tches
161
nombreux bnfices de la ralisation plus "artisanale", et seules
de fortes contraintes (par exemple une quipe disperse
gographiquement) doivent justifier cette solution de dernier
recours
ne pas confondre le tableau des tches "canonique" avec le
tableau Kanban dont le principe est assez diffrent
(notamment, il n'est pas "remis zro")
le tableau des tches est un "radiateur d'information" - il
favorise le partage instantan d'informations importantes pour
toute l'quipe
le tableau des tches sert de point focal pour la runion
quotidienne
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)
(LIVRES, ARTICLES)
Task Boards, de Mike Cohn (2004-2010)
Task Boards, de Tom Perry
162
Elements of Task Board Design, et plus gnralement le blog
"Visual Management", de Xavier Quesada
DE RECHERCHE
Peu de travaux de recherche concernent directement cette pratique.
Des investissements considrables sont consacrs par de nombreux
diteurs ou quipes Open Source la ralisation d'quivalents virtuels du
tableau de tches, alors mme que la communaut des praticiens
aguerris reste majoritairement persuade de l'intrt, voire de la
ncessit, du tableau de tches physique; mettre en vidence le bnfice
rel de cette deuxime solution serait donc une piste de recherche
prioritaire.
Chapitre 57: Tableau des tches
163
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
prter main-forte, de faon ce que l'une des deux
user stories puisse sortir de l'tat "en test" le plus
rapidement possible;
contrairement au tableau des tches, le tableau
kanban n'est pas "rinitialis" en dbut de chaque
itration, c'est un tableau perptuel.
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".
Il existe des contextes dans lesquels la mesure du temps de cycle et
l'utilisation de tableaux kanban (perptuel) a plus de sens que la mesure
de la vlocit chaque itration: par exemple lorsque le respect d'une
Chapitre 58: Tableau kanban
165
date de livraison prcise n'est pas une priorit, ou lorsque l'quipe
assure simultanment l'volution ou la maintenance de produits
multiples.
De faon trs schmatique, on peut considrer que l'approche
"kanban" se prte plus un mode de maintenance ou d'volution
continue, alors que l'approche par itrations se prte plus un mode
projet.
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
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.
Le terme anglais est "lead time".
Chapitre 59: Temps de cycle
167
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
"orientes utilisateurs" que sont l'ergonomie ou l'Interaction
Design ( partir de 2008)
Chapitre 60: Test d'utilisabilit
169
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
par consquent rejoint la philosophie Agile en faisant peu de
cas des rfrentiels documentaires pour le test
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.
Le rle des testeurs est souvent marginal au sein des projets de
dveloppement en France. Cependant, dans les quipes travaillant avec
des testeurs professionnels, l'approche Agile suscite souvent des
interrogations profondes sur la pertinence et l'organisation de leur
activit. L'approche "exploratoire" offre de nombreuses pistes pour
intgrer efficacement ces spcialistes dans une quipe 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.
Chapitre 61: Test exploratoire
171
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
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)
Chapitre 62: Tests fonctionnels automatiss
173
pendant quelque temps, le duo Fit/FitNesse clipse les autres
outils et s'impose en modle pour la mise en oeuvre de tests
fonctionnels Agiles
plus rcemment de nouveaux outils lis l'approche BDD ont
contribu rouvrir le dbat
L'utilisation de tests fonctionnels automatiss apporte plusieurs
bnfices, complmentaires de ceux lis aux tests unitaires:
ils encouragent une collaboration troite entre les
dveloppeurs d'une part et les clients, utilisateurs ou experts
mtier d'autre part, puisqu'ils imposent de prciser
suffisamment les exigences pour tre en mesure de les
exprimer dans un formalisme excutable
ils fournissent par la mme occasion un "contrat" clair et prcis
pour l'acceptation par le client du travail fourni par les
dveloppeurs; si le produit passe les tests fonctionnels, il est
considr adquat (mais les clients ou utilisateurs ont la
possibilit d'affiner les tests ou d'en proposer de nouveaux si
ncessaire)
ils contribuent galement limiter le nombre de dfauts et
notamment de rgressions (dfauts apparus sur des
fonctionnalits prcdemment valides)
IL CONSENTIR?
Les tests fonctionnels, contrairement aux tests unitaires, font l'objet
d'une controverse au sein de la communaut Agile, certains experts tels
que Jim Shore ou Brian Marick jugeant que les bnfices obtenus ne
justifiaient pas les cots consentir:
beaucoup d'quipes Agiles constatent que l'criture de tests
fonctionnels automatis reprsente un effort important
pour des raisons lies aux erreurs de mise en oeuvre voques
ci-dessus, la maintenance de ces tests peut galement s'avrer
contraignante et coteuse
la premire gnration d'outils, inspire de Fit/Fitnesse, a
souvent conduit des tests fonctionnels qui n'taient pas
174
accepts comme intelligibles par les clients, utilisateurs ou
experts mtier
Cependant, les volutions rcentes notamment celles des au BDD
peuvent tre de nature amliorer ce rapport cot-bnfice.
DE RECHERCHE
Automated Acceptance Testing: A Literature Review and an
Industrial Case Study, passe en revue les articles sur le sujet et
rapporte une tude de cas globalement positive
Chapitre 62: Tests fonctionnels automatiss
175
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 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
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)
une quipe utilisant des tests unitaires automatiss rcoltera
une partie des bnfices attribus au dveloppement par les
tests: rduction du nombre de dfauts, principalement
Chapitre 63: Tests unitaires automatiss
177
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
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.
Chapitre 65: Tches choisies
179
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.
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
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
Chapitre 66: User stories
181
le modle des "3C", ou "Carton, Conversation, Confirmation"
est propos par Ron Jeffries en 2001 ("Card, Conversation,
Confirmation")
la grille INVEST est dcrite par Bill Wake en 2003 ("INVEST in
Good Stories and SMART tasks")
la matrice given-when-then pour dcrire les tests de recette
est dcrite par Dan North en 2006 ("Introducing BDD")
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
dcouper une User Story sans produire un rsultat
dgrad
Avanc
je suis capable d'interprter des exigences
considres comme "non fonctionnelles" sous la
forme d'une User Story: persistance, performance,
portabilit...
je suis capable de rattacher des User Stories des
descriptions de plus haut niveau du projet: "charte
projet", etc. - et de justifier pour chaque User Story
sa pertinence et sa valeur
A titre collectif:
Dbutant
l'quipe sait organiser son activit autour des User
Stories
l'quipe est capable d'obtenir "juste temps" le dtail
ncessaire l'implmentation des User Stories, par
exemple par la prsence physique du client ou
donneur d'ordres
Intermdiaire
l'quipe formalise la totalit de son travail sous la
forme de User Stories, tout membre de l'quipe peut
rpondre la question "sur quelle User Story
travailles-tu?"
Avanc
a tout moment l'quipe est capable de rpondre la
question "quelle est la User Story la plus importante
restant faire et pourquoi?"
UTILISATION?
l'quipe utilise des outils de planification visuels (Release Plan,
Story Map, Task Board) et on peut y voir des fiches cartonnes
ou Post-It
les descriptifs de User Stories ne contiennent pas ou peu de
langage technique ("base de donnes", "cran X" ou "dialogue
Y") mais font rfrence des objectifs d'utilisateurs
183
La pratique des User Stories conduit un dveloppement incrmental, et
doit permettre d'en raliser les bnfices, notamment
une rduction des risques lis l'effet tunnel, d'autant plus
importante
que les incrments sont de petite grandeur
que les mises en production ont lieu tt et
frquemment
pour le donneur d'ordres, la possibilit de changer d'avis en
cours de route sur les dtails d'implmentation ou la priorit
donne une User Story non encore ralise
pour les dveloppeurs, l'obtention de critres d'acceptation et
de validation clairs et prcis, et la validation de leur travail au fil
de l'eau
la possibilit "d'auto-financer" le projet en ralisant trs tt les
bnfices d'une mise en exploitation rendue possible par
l'approche incrmentale
en scindant clairement le "quoi" et le "comment" (les donneurs
d'ordre doivent se cantonner dcrire le "quoi" savoir les
objectifs, les dveloppeurs restant force de proposition sur le
"comment"), permettre d'exploiter au mieux le talent et la
crativit de chacun
IL CONSENTIR?
Le dveloppement incrmental en gnral ncessite une stratgie de test
plus labore. En effet, le risque d'effets de bord lors du dveloppement
d'une fonctionnalit F2, entranant la rgression d'une fonctionnalit F1,
exige que les fonctionnalits existantes soit re-testes. Dans le cas le
plus pessimiste, le cot du test volue donc comme le carr du nombre
de fonctionnalits: on doit tester successivement F1, F1+F2, F1+F2+F3,
et ainsi de suite. Plus les incrments sont de petite grandeur, plus cet
effet est sensible.
184
(LIVRES, ARTICLES)
User Stories Applied, de Mike Cohn
Software By Numbers examine les aspects conomiques du
dveloppement itratif
DE RECHERCHE
Thoriques
Les travaux de Robert Biddle, Angela Martin, James
Noble et leurs collaborateurs sont parmi les
premiers se pencher spcifiquement sur le rle du
Client dans les approches agiles et en analyser les
mcanismes, ports par les User Stories
Empiriques
...
185
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
complte au dbut de l'itration suivante, les 3 points correspondants
pourront tre comptabiliss dans la vlocit de cette dernire. La
vlocit de l'quipe va donc "naturellement" remonter.)
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
Chapitre 67: Vlocit
187
Chapitre 68
Bibliographie
acadmique
La centaine de rfrences ci-dessous donne un aperu des quelques
pratiques Agiles qui ont le plus intress les chercheurs (et dessinent en
creux le travail restant effectuer dans ce domaine).
La slection que nous proposons s'intresse principalement aux
tudes empiriques, laissant de ct la plupart des travaux purement
conceptuels ou spculatifs qui n'ont pas fait l'objet d'une collecte de
donnes.
BDD (Behaviour-Driven Development)
Towards an empirical evaluation of behaviour-driven development
(Laplante, C.S., 2011)
Behaviour-Driven Development of Foundational UML Components
(Lazr, Ioan and Motogna, Simona and Pirv, Bazil, 2010)
Charte projet
Charters and Chartering: Immunizing Against Foreseeable Project
Failure (III, 2001)
Dveloppement par les tests
Empirical Studies for the Application of Agile Methods to Embedded
Systems (Wilking, Dirk, 2008)
188
The Effect of Test-Driven Development on Program Code (Muller,
Matthias, 2006)
Evaluation of Test Driven Development (Wasmus, Hans, 2006)
A Leveled Examination of Test-Driven Development Acceptance
(Janzen, David S. and Saiedian, Hossein, 2007)
On the Sustained Use of a Test-Driven Development Practice at IBM
(Sanchez, Julio Cesar and Williams, Laurie and Maximilien, E.
Michael, 2007)
Programmer's Expertise during Test-Driven Software Development.
(Shaochun Xu and Zendi Cui and Dapeng Liu and Xuhui Chen,
2007)
Realizing quality improvement through test driven development:
results and experiences of four industrial teams (Nagappan,
Nachiappan and Maximilien, E. Michael and Bhat, Thirumalesh
and Williams, Laurie, 2008)
Adding planned design to xp might help novices' productivity (or
might not): two controlled experiments (Noel, Ren and Valdes,
Gonzalo and Visconti, Marcello and Astudillo, Hernan, 2008)
Does Test-Driven Development Improve the Program Code?
Alarming Results from a Comparative Case Study (Siniaalto, Maria
and Abrahamsson, Pekka, 2008)
The Impact of Test Driven Development on the Evolution of a
Reusable Framework of Components - An Industrial Case Study
(Slyngstad, Odd Petter N. and Li, Jingyue and Conradi, Reidar
and Ronneberg, Harald and Landre, Einar and Wesenberg,
Harald, 2008)
The Impact of Test-Driven Development on Software Development
Productivity --- An Empirical Study (Madeyski, Lech and Szala,
Lukasz, 2007)
Effective test driven development for embedded software (Karlesky,
M. and Bereza, W. and Erickson, C., 2006)
On the Influence of Test-Driven Development on Software Design
(Janzen, D.S. and Saiedian, H., 2006)
Empirical investigation towards the effectiveness of Test First
programming (Liang Huang and Mike Holcombe, 2009)
An Experimental Evaluation of the Effectiveness and Efficiency of
the Test Driven Development (Gupta, Atul and Jalote, Pankaj,
2007)
A Prototype Empirical Evaluation of Test Driven Development
(Geras, A. and Smith, M. and Miller, J., 2004)
Chapitre 68: Bibliographie acadmique
189
A structured experiment of test-driven development (George, B.
and Williams, L., 2004)
Lessons learned from an XP Experiment with Students: Test-First
needs more teachings (Flohr, T. and Schneider, T., 2006)
Using software testing to move students from trial-and-error to
reflection-in-action (Edwards, Stephen H., 2004)
Test driven development of embedded systems using existing
software test infrastructure (Dowty, M., 2004)
A survey of evidence for test-driven development in academia
(Desai, Chetan and Janzen, David and Savage, Kyle, 2008)
The effect of experience on the test-driven development process
(Muller, Matthias M. and Hofer, Andreas, 2007)
Quality Impact of Introducing Component-Level Test Automation
and Test-Driven Development (Damm, Lars-Ola and Lundberg,
Lars, 2007)
Results from introducing component-level test automation and test-
driven development (Damm, Lars-Ola and Lundberg, Lars, 2006)
Evaluating the efficacy of test-driven development: industrial case
studies (Bhat, Thirumalesh and Nagappan, Nachiappan, 2006)
Improving Business Agility Through Technical Solutions: A Case Study
on Test-Driven Development in Mobile Software Development
(Abrahamsson, Pekka and Hanhineva, Antti and Jaalinoja, Juho,
2005)
Test Driven Development and Software Process Improvement in
China (Lui, Kim Man and Chan, Keith C.C., 2004)
An experimental evaluation of continuous testing during
development (Saff, David and Ernst, Michael D., 2004)
Using test-driven development in the classroom: providing students
with automatic, concrete feedback on performance (Edwards, S.,
2003)
Improving student performance by evaluating how well students test
their own programs (Edwards, Stephen H., 2003)
Evaluating advantages of test driven development: a controlled
experiment with professionals (Canfora, Gerardo and Cimitile,
Aniello and Garcia, Felix and Piattini, Mario and Visaggio,
Corrado Aaron, 2006)
An initial investigation of test driven development in industry
(George, Boby and Williams, Laurie, 2003)
Implications of test-driven development: a pilot study (Kaufmann,
Reid and Janzen, David, 2003)
190
Assessing test-driven development at IBM (Maximilien, E. Michael
Towards empirical evaluation of test-driven development in a
university environment (Pancur, M. and Ciglaric, M. and Trampus,
M. and Vidmar, T., 2003)
Web-CAT: A Web-based Center for Automated Testing (Shah, Anuj,
2003)
Test-Driven Development as a Defect-Reduction Practice (Williams,
Laurie and Maximilien, E. Michael and Vouk, Mladen, 2003)
Analysis and Quantification of Test Driven Development Approach
(George, B., 2002)
Experiment about test-first programming (Muller, M.M. and
Hagner, O., 2002)
An Informal Formal Method for Systematic JUnit Test Case
Generation (Stotts, P. David and Lindsey, Mark and Antley,
Angus, 2002)
The effect of unit tests on entry points, coupling and cohesion in an
introductory Java programming course (Steinberg, Daniel H.,
2001)
Integrating Unit Testing into a Software Development Team's
Process (R.A. Ynchausti, 2001)
Test-Driven Development of Relational Databases (Ambler, Scott
W., 2007)
Does Test-Driven Development Really Improve Software Design
Quality? (Janzen, D.S. and Saiedian, H., 2008)
On the effectiveness of the test-first approach to programming
(Hakan Erdogmus and Maurizio Morisio and Ieee Computer
Society and Marco Torchiano and Ieee Computer Society,
2005)
Automated Recognition of Test-Driven Development with {Z}orro
(Johnson, Philip M. and Kou, Hongbing, 2007)
The impact of test-driven development on design quality (Maria
Siniaalto, 2006)
Test-driven development: empirical body of evidence (Maria
Siniaalto, 2006)
Dveloppement par les tests client
Empirical analyses of executable acceptance test driven
development (Melnik, Grigori Igorovych, 2007)
191
Are fit tables really talking?: a series of experiments to understand
whether fit tables are useful during evolution tasks (Ricca, Filippo
and Di Penta, Massimiliano and Torchiano, Marco and Tonella,
Paolo and Ceccato, Mariano and Visaggio, Corrado Aaron,
2008)
FitClipse: a fit-based eclipse plug-in for executable acceptance test
driven development (Deng, Chengyao and Wilson, Patrick and
Maurer, Frank, 2007)
Using acceptance tests as a support for clarifying requirements: A
series of experiments (Ricca, Filippo and Torchiano, Marco and
Di Penta, Massimiliano and Ceccato, Mariano and Tonella,
Paolo, 2009)
Objets fantaisie (Mock Objects)
An empirical study of testing file-system-dependent software with
mock objects (Marri, M.R. and Tao Xie and Tillmann, N. and de
Halleux, J. and Schulte, W., 2009)
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
Combining Estimates with Planning Poker--An Empirical Study
(Molokken-Ostvold, Kjetil and Haugen, Nils Christian, 2007)
An Empirical Study of Using Planning Poker for User Story
Estimation (Haugen, Nils C., 2006)
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
The effectiveness of pair programming: A meta-analysis (Hannay, Jo
E. and Dybaa, Tore and Arisholm, Erik and Sjoberg, Dag I. K.,
2009)
193
Strengthening the Case for Pair Programming (Laurie Williams and
Robert R. Kessler and Ward Cunningham and Ron Jeffries,
2000)
The collaborative software process(sm) (Williams, Laurie Ann,
2000)
"Talking the talk": Is intermediate-level conversation the key to the
pair programming success story? (Freudenberg, S. (nee Bryant)
and Romero, P. and du Boulay, B., 2007)
Are Two Heads Better than One? On the Effectiveness of Pair
Programming (Dybaa, Tore and Arisholm, Erik and Sjoberg, Dag
I. K. and Hannay, Jo E. and Shull, Forrest, 2007)
The Social Dynamics of Pair Programming (Chong, Jan and
Hurlbutt, Tom, 2007)
Critical Personality Traits in Successful Pair Programming (Chao,
Joseph and Atli, Gulgunes, 2006)
A replicated experiment of pair-programming in a 2nd-year software
development and design computer science course (Mendes, Emilia
and Al-Fakhri, Lubna and Luxton-Reilly, Andrew, 2006)
The effects of pair-programming on individual programming skill
(Braught, Grant and Eby, L. Martin and Wahls, Tim, 2008)
Pair programming: what's in it for me? (Begel, Andrew and
Nagappan, Nachiappan, 2008)
Promiscuous pairing and beginner's mind: embrace inexperience
[agile programming] (Belshee, A., 2005)
Evaluating Pair Programming with Respect to System Complexity
and Programmer Expertise (Erik Arisholm and Hans Gallis and
Tore Dyba and Dag I.K. Sjoberg, 2007)
Pair programming improves student retention, confidence, and
program quality (C McDowell and L Werner and H E Bullock
and J Fernald, 2006)
The effects of pair-programming on performance in an introductory
programming course (C McDowell and L Werner and H Bullock
and J Fernald, 2002)
Experimental evaluation of pair programming (Jerzy Nawrocki and
Adam Wojciechowski, 2001)
Code Warriors and Code-a-Phobes: A study in attitude and pair
programming (L Thomas and M Ratcliffe and A Robertson,
2003)
Female Computer Science Students Who Pair Program Persist
(Linda Werner and Charlie McDowell and Brian Hanks, 2004)
194
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
The effects of stand-up and sit-down meeting formats on meeting
outcomes (Bluedorn, A C and Turban, D B and Love, M S,
1999)
Supporting daily scrum meetings with change structure (Rubart,
Jessica and Freykamp, Frank, 2009)
'Today' messages: lightweight group awareness via email (Brush, A.
J. and Borning, Alan, 2003)
Introduction to Stand-up Meetings in Agile Methods (Eisha Hasnain
and Tracy Hall, 2009)
Stand and Deliver: Why I Hate Stand-Up Meetings (Laplante,
Phillip A, 2003)
Tableau des tches
Drifting Toward Invisibility: The Transition to the Electronic Task
Board (Perry, Thomas, 2008)
Design and technology for Collaborage: collaborative collages of
information on physical walls (Moran, Thomas P. and Saund, Eric
and Van Melle, William and Gujar, Anuj U. and Fishkin,
Kenneth P. and Harrison, Beverly L., 1999)
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)
Tests fonctionnels automatiss
"Talking tests": a Preliminary Experimental Study on Fit User
Acceptance Tests (Marco Torchiano and Filippo Ricca and
Massimiliano Di Penta, 2007)
Automated Acceptance Testing: A Literature Review and an
Industrial Case Study (Haugset, B. and Hanssen, G.K., 2008)
196
Tests unitaires automatiss
A survey of software testing practices in Alberta (Geras, A.M. and
Smith, M.R. and Miller, J., 2004)
A replicated survey of software testing practices in the Canadian
province of Alberta: What has changed from 2004 to 2009?
(Garousi, Vahid and Varma, Tan, 2010)
Automatic Software Test Drivers (Panzl, D. J., 1978)
Automatic revision of formal test procedures (Panzl, David J., 1978)
On the effectiveness of unit test automation at Microsoft (Williams,
Laurie and Kudrjavets, Gunnar and Nagappan, Nachiappan,
2009)
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
Version 1.0 du 04/05/2011

Agile de A À Z

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Agile de A À Z

Încărcat de

Drepturi de autor:

Formate disponibile

Agile: de A Z

Rfrentiel des Pratiques Agiles: dition eBook

S-ar putea să vă placă și