Scrum Et XP Depuis Les Tranchées

Scrum et XP depuis les
Tranches
Comment nous appliquons Scrum
Ecrit par :
Henrik Kniberg
2007 C4Media Inc

Tous droits rservs.
C4Media, Editeur de InfoQ.com.
Ce livre fait partie de la collection de livres InfoQ Enterprise
Software Development.
Pour plus dinformations ou pour commander ce livre ou dautres
livres InfoQ, prire de contacter books@c4media.com.
Aucune partie de cette publication ne peut tre reproduite, stocke
dans un systme de recherche, ou transmise sous aucune forme ni
aucun moyen, lectronique, mcanique, photocopiage, recodage,
scanner ou autre sans que cela ne soit autoris par les Sections
107 ou 108 du Copyright Act 1976 des Etats-Unis, ni sans
lautorisation crite pralable de lditeur.
Les termes utiliss par les entreprises pour distinguer leurs
produits sont souvent dclars comme des marques
commerciales. Dans tous les cas o C4Media Inc. est informe
dune telle dclaration, les noms de produits apparaissent avec
une Majuscule initiale ou EN TOUTES LETTRES MAJUSCULES.
Toutefois, les lecteurs devraient contacter les entreprises
appropries pour des informations plus compltes au sujet des
marques commerciales et de leur enregistrement.
Rdacteur en chef: Diana Plesa
Traducteurs:
Guillaume Mathias
Bruno Orsier
Emmanuel Etasse
Christophe Bunn
http://bruno-orsier.developpez.com
http://homoagilis.blogspot.com
Rfrence de la bibliothque du Congrs Cataloguing-inPublication :

ISBN: 978-1-4303-2264-1
Imprim dans les Etats-Unis dAmrique
Remerciements
Le premier brouillon de ce papier a t tap en un week-end seulement,
mais ce fut un sacr week-end ! Focalisation 150% :o)
Merci ma femme Sophia et mes enfants Dave et Jenny pour avoir
support mon asocialit ce week-end, et aux parents de Sophia, Eva et
Jrgen, pour tre venus aider prendre en charge la famille.
Merci galement mes collgues de Crisp Stockholm et aux gens sur le
groupe yahoo scrumdevelopment pour avoir corrig le papier et pour
mavoir aid lamliorer.
Et, finalement, merci tous mes lecteurs qui ont fourni un flux constant
de feedback utile. Je suis particulirement content dentendre que ce
papier a incit autant dentre vous essayer le dveloppement de logiciels
agile !
Table des matires

PREFACE DE JEFF SUTHERLAND
PREFACE DE MIKE COHN
iii
INTRO ............................................................................................................7
AVERTISSEMENT ..........................................................................................8
POURQUOI JAI ECRIT CECI ...........................................................................8
MAIS SCRUM, QU'EST-CE QUE C'EST ? ..........................................................9
COMMENT NOUS FAISONS LES BACKLOGS DE PRODUIT..........11
CHAMPS D'HISTOIRE SUPPLEMENTAIRES ....................................................13
COMMENT NOUS GARDONS LE BACKLOG DE PRODUIT A UN NIVEAU METIER
...................................................................................................................14
COMMENT NOUS PREPARONS LA REUNION DE PLANNING DU
SPRINT.........................................................................................................16
COMMENT NOUS FAISONS LES PLANNINGS DE SPRINT.............19
POURQUOI LE DIRECTEUR DE PRODUIT DOIT Y ASSISTER ............................19
POURQUOI LA QUALITE N'EST PAS NEGOCIABLE .........................................21
LES REUNIONS DE PLANNING DE SPRINT QUI S'ETERNISENT... .....................22
LORDRE DU JOUR DE LA REUNION DE PLANNING DE SPRINT ......................23
LE CHOIX DE LA DUREE DU SPRINT .............................................................24
LA DEFINITION DU BUT DU SPRINT .............................................................25
LE CHOIX DES HISTOIRES A INCLURE DANS LE SPRINT ................................26
COMMENT LE DIRECTEUR DE PRODUIT PEUT-IL EXERCER UNE INFLUENCE
SUR LES HISTOIRES QUI IRONT DANS LE SPRINT ?........................................27
COMMENT LES EQUIPES CHOISISSENT-ELLES LES HISTOIRES A INCLURE DANS
LE SPRINT? .................................................................................................29
POURQUOI NOUS UTILISONS DES FICHES.....................................................35
DEFINITION DE TERMINE ........................................................................38
LESTIMATION DE TEMPS AVEC LE POKER DE PLANNING ............................38
LA CLARIFICATION DES HISTOIRES .............................................................40
LA DECOMPOSITION DES HISTOIRES EN PLUS PETITES HISTOIRES................42
LA DECOMPOSITION DES HISTOIRES EN TACHES .........................................42
LE CHOIX DU LIEU ET LHEURE POUR LA MELEE QUOTIDIENNE...................44
OU TRACER LA LIMITE ? .............................................................................44
LES HISTOIRES TECHNIQUES .......................................................................45
SYSTEME DE SUIVI DE BUG VS. BACKLOG DE PRODUIT ...............................48
LA REUNION DE PLANNING DE SPRINT EST FINALEMENT TERMINEE !..........49
COMMENT NOUS COMMUNIQUONS SUR LES SPRINTS...............51
COMMENT NOUS FAISONS LES BACKLOGS DE SPRINT..............55

FORMAT DU BACKLOG DE SPRINT ...............................................................55
COMMENT LE TABLEAU DES TACHES FONCTIONNE .....................................57
EXEMPLE 1 - APRES LA PREMIERE MELEE QUOTIDIENNE ............................58
EXEMPLE 2 APRES QUELQUES JOURS .......................................................59
COMMENT LE BURNDOWN CHART FONCTIONNE .........................................61
LES SIGNAUX DAVERTISSEMENT DU TABLEAU DES TACHES ......................62
HE, ET LA TRAABILITE ?!..........................................................................64
ESTIMATIONS EN JOURS VS. HEURES...........................................................64
COMMENT NOUS ORGANISONS LE BUREAU DE LEQUIPE .......67
LE COIN CONCEPTION .................................................................................67
INSTALLEZ LEQUIPE ENSEMBLE ! ..............................................................69
GARDER LE DIRECTEUR DE PRODUIT A DISTANCE .......................................70
GARDER LES DIRECTEURS ET LES COACHS A DISTANCE ..............................70
COMMENT NOUS FAISONS LES MELEES QUOTIDIENNES..........73
COMMENT NOUS METTONS A JOUR LE TABLEAU DES TACHES .....................73
TRAITER AVEC LES RETARDATAIRES ..........................................................74
TRAITER AVEC JE NE SAIS PAS QUOI FAIRE AUJOURDHUI .....................75
COMMENT NOUS FAISONS LES DEMOS DE SPRINT......................77
POURQUOI NOUS INSISTONS POUR QUE TOUS LES SPRINTS FINISSENT PAR
UNE DEMO ..................................................................................................77
CHECKLIST POUR LES DEMOS DE SPRINT ....................................................78
SOCCUPER DES CHOSES INDEMONTRABLES .........................................78
COMMENT NOUS FAISONS LES RETROSPECTIVES DE SPRINT 81
POURQUOI NOUS INSISTONS POUR QUE TOUTES LES EQUIPES FASSENT DES
RETROSPECTIVES ........................................................................................81
COMMENT NOUS ORGANISONS LES RETROSPECTIVES .................................82
LA DIFFUSION DES ENSEIGNEMENTS TIRES ENTRE EQUIPES ........................83
CHANGER OU NE PAS CHANGER ..................................................................84
EXEMPLES DE CHOSES QUI PEUVENT REMONTER PENDANT LES
RETROSPECTIVES ........................................................................................85
RELACHER LE RYTHME ENTRE LES SPRINTS ...............................87
COMMENT NOUS FAISONS LA PLANIFICATION DE RELEASE ET
LES CONTRATS AU FORFAIT ...............................................................91
DEFINIR VOS SEUILS DACCEPTATION.........................................................91
ESTIMATION EN TEMPS DES ELEMENTS LES PLUS IMPORTANTS...................92
ESTIMER LA VELOCITE ...............................................................................94
TOUT METTRE ENSEMBLE DANS UN PLAN DE RELEASE ...............................95
ADAPTER LE PLAN DE RELEASE ..................................................................96
COMMENT NOUS COMBINONS SCRUM AVEC XP ..........................97
LA PROGRAMMATION EN BINOME ..............................................................97

LE DEVELOPPEMENT DIRIGE PAR LES TESTS (DDT) ..................................98
LA CONCEPTION INCREMENTALE..............................................................101
LINTEGRATION CONTINUE ......................................................................101
LA PROPRIETE COLLECTIVE DU CODE .......................................................102
UN ESPACE DE TRAVAIL INFORMATIF .......................................................102
LES NORMES DE CODAGE .........................................................................102
LE RYTHME SOUTENABLE / LE TRAVAIL ENERGISE ...................................103
COMMENT NOUS FAISONS LES TESTS............................................105
VOUS NE POUVEZ PROBABLEMENT PAS ELIMINER LA PHASE DE TESTS
DACCEPTATION .......................................................................................105
MINIMISEZ LA PHASE DE TESTS DACCEPTATION......................................106
AUGMENTER LA QUALITE EN METTANT DES TESTEURS DANS LEQUIPE
SCRUM .....................................................................................................107
AUGMENTER LA QUALITE EN EN FAISANT MOINS PAR SPRINT...................110
EST-CE QUE LES TESTS DACCEPTATION DEVRAIENT FAIRE PARTIE DU
SPRINT ? ...................................................................................................110
DES CYCLES DE SPRINTS VS. DES CYCLES DE TEST DACCEPTATION .........111
NE DISTANCEZ PAS LE MAILLON LE PLUS LENT DE VOTRE CHAINE ...........115
RETOUR A LA REALITE .............................................................................116
COMMENT NOUS GERONS LES EQUIPES MULTI-SCRUM.........117
COMBIEN DEQUIPES FAUT-IL CREER........................................................117
SPRINTS SYNCHRONISES OU NON ? ........................................................120
POURQUOI NOUS AVONS INTRODUIT LE ROLE DU MENEUR DEQUIPE ..121
COMMENT NOUS AFFECTONS LES PERSONNES AUX EQUIPES.....................123
EQUIPES SPECIALISEES OU NON ?...........................................................124
REARRANGER LES EQUIPES ENTRE LES SPRINTS OU PAS ? ......................127
LES MEMBRES DEQUIPE A TEMPS PARTIEL...............................................128
COMMENT NOUS FAISONS LES SCRUMS-DE-SCRUMS................................129
INTERCALER LES MELEES QUOTIDIENNES .................................................131
LES EQUIPES DE POMPIERS .......................................................................132
PARTAGER LE BACKLOG DE PRODUIT OU PAS ?......................................133
BRANCHES DE CODE .................................................................................138
RETROSPECTIVES MULTI-EQUIPES ............................................................139
COMMENT NOUS GERONS LES EQUIPES
GEOGRAPHIQUEMENT DISPERSEES ...............................................141
DELOCALISER OFFSHORE .........................................................................142
QUIPIERS TRAVAILLANT DE LA MAISON .................................................144
PENSE-BETE DU SCRUM MASTER ....................................................145
DEBUT DU SPRINT ....................................................................................145
TOUS LES JOURS .......................................................................................145
FIN DU SPRINT..........................................................................................146
MOT DE LA FIN .......................................................................................147

LECTURES RECOMMANDEES ............................................................149
A PROPOS DE LAUTEUR .....................................................................151
Prface de Jeff Sutherland

Les quipes doivent connatre les bases de Scrum. Comment est-ce que
vous crez et estimez un backlog de produit ? Comment le transformezvous en backlog d'itration ? Comment grez-vous une courbe du reste
faire et calculez la vlocit de l'quipe ? Le livre d'Henrik est un kit de
dmarrage avec les pratiques de base qui aident les quipes passer d'un
essai de Scrum une bonne implmentation de Scrum.
Une bonne implmentation de Scrum devient plus importante pour les
quipes qui cherchent des investissements financiers. En tant que coach
Agile pour un groupe investissant en capital-risque, je les aide investir
seulement dans les entreprises agiles qui appliquent bien les pratiques
agiles.
L'associ principal du groupe a demand toutes les socits au sein de
son portefeuille si elles connaissent la vlocit de leurs quipes. Elles ont
des difficults rpondre la question tout de suite. Les futures
opportunits d'investissement vont obliger les quipes comprendre leur
vlocit de dveloppement logiciel.
Pourquoi est-ce si important? Si les quipes ne connaissent pas leur
vlocit, le Directeur de produit ne peut crer de feuille de route pour le
produit avec des chances crdibles. Sans des chances fiables,
l'entreprise peut chouer et les investisseurs peuvent perdre leur argent !
Ce problme touche les grandes socits comme les petites, nouvelles ou
anciennes, finance ou non. Lors d'une discussion rcente sur
l'implmentation de Scrum de Google une confrence londonienne, j'ai
demand une audience de 135 personnes combien appliquaient Scrum et
30 ont rpondu positivement. Je leur ai ensuite demand s'ils faisaient du
dveloppement itratif selon les standards de Nokia. Le dveloppement
ii | SCRUM ET XP DEPUIS LES TRANCHEES

itratif est fondamental dans le Manifeste Agile - dlivrer tt et
frquemment du logiciel qui marche. Aprs des annes de rtrospectives
avec des centaines d'quipes Scrum, Nokia a dvelopp des exigences de
base pour le dveloppement itratif :
Les itrations doivent tre de dure fixe et infrieure six

semaines.
Le code la fin de l'itration doit tre test par le AQ et doit

fonctionner correctement.
Sur les 30 personnes qui prtendaient appliquer Scrum, seulement la

moiti affirmait se conformer au premier principe du Manifeste Agile sur
les standards Nokia. J'ai ensuite demand s'ils suivaient les standards
Nokia pour Scrum :
Une quipe Scrum doit avoir un Directeur de produit et doit

savoir qui c'est.
Le Directeur de produit doit grer un Backlog de produit avec des
estimations fournies par l'quipe.
L'quipe doit avoir une Courbe du reste faire et doit connatre
sa vlocit.
Aucune personne extrieure ne doit interfrer avec l'quipe
durant le Sprint.
L'apport du livre d'Henrik est que, si vous suivez les pratiques dcrites,
vous aurez un Directeur de produit, des estimations pour votre Backlog de
produit, une Courbe du reste faire, et vous connatrez la vlocit de
votre quipe ainsi que de nombreuses autres pratiques essentielles pour un
Scrum dangereusement oprationnel. Vous passerez le test Nokia pour
Scrum et serez digne de l'investissement dans votre travail. Si vous tes
une startup, vous pouvez mme bnficier du financement d'une socit
capital-risque. Vous serez peut-tre le futur du dveloppement logiciel et
le crateur d'une nouvelle gnration d'minents logiciels.
Jeff Sutherland,
Ph.D., Co-Crateur de Scrum
INTRO | iii
Prface de Mike Cohn

Scrum et Extreme Programming (XP) demandent tous deux aux quipes
de finir certains lments tangibles et livrables de leur travail la fin de
chaque itration. Ces itrations sont conues pour tre courtes et dure
finie. Laccent mis sur le fait de livrer du code qui marche au bout dune
courte priode de temps signifie que les quipes Scrum et XP nont pas de
temps pour faire de la thorie. Elles ne svertuent pas dessiner le
modle UML parfait dans leur outil de modlisation, crire des cahiers
des charges parfaits, ou crire du code qui pourra sadapter tous les
changements futurs imaginables. A la place, les quipes Scrum et XP se
concentrent pour que les choses soient termines. Ces quipes acceptent
quelles puissent faire des erreurs en chemin, mais elles ralisent aussi que
le meilleur moyen pour trouver ces erreurs est darrter de penser au
logiciel au niveau thorique de lanalyse et de la conception, mais plutt
de se lancer, de se salir les mains, et de commencer construire le
produit.
Cest par cette focalisation sur le faire plutt que le thoriser que
se distingue ce livre. Il est facile de sapercevoir que Henrik Kniberg la
bien compris ds le dbut. Il ne fait pas de longs discours sur ce quest
Scrum ; pour a, il se rfre des sites faciles comprendre. Au lieu de
cela, Henrik entre dans le vif du sujet et commence directement dcrire
comment son quipe gre et travaille son carnet de produit. A partir de l,
il parcourt tous les autres lments et les pratiques dun projet agile bienportant. Pas de thorie. Pas de rfrence. Pas de note de bas de page.
Aucun besoin de cela. Le livre dHenrik nest pas un expos
philosophique expliquant pourquoi Scrum marche ou pourquoi vous
voudriez utiliser ceci ou cela. Il sagit dune description sur comment une
certaine quipe agile efficace travaille.
iv | SCRUM ET XP DEPUIS LES TRANCHEES
Cest pour cette raison que le sous-titre du livre, Comment nous

appliquons Scrum , est si appropri. Ce nest peut-tre pas la faon dont
vous appliquez Scrum, cest comment lquipe dHenrik applique Scrum.
Il se peut que vous vous demandiez pourquoi vous devriez vous intresser
la faon dont une autre quipe applique Scrum. Vous devriez vous y
intresser car nous pouvons tous apprendre amliorer notre pratique de
Scrum en tirant partie des expriences des autres, spcialement lorsquils
le font bien. Il ny a pas et il ny aura jamais de liste des meilleures
pratiques Scrum car le contexte de lquipe et du projet prvaut sur
toute autre considration. A la place, ce que nous avons besoin de savoir,
ce sont les bonnes pratiques et les contextes dans lesquels elles ont russi.
Lisez assez de tmoignages dquipes qui russissent et comment elles se
sont dbrouilles et vous serez prpar pour affronter les obstacles
survenus sur votre chemin durant votre mise en uvre de Scrum et XP.
Henrik fournit une multitude de bonnes pratiques ainsi que

lindispensable contexte pour nous aider mieux comprendre comment
appliquer Scrum et XP dans les tranches de nos propres projets.
Mike Cohn
Auteur de Agile Estimating and Planning et User Stories Applied for
Agile Software Development.
Prface - H, Scrum ca marche !

Scrum ca marche ! Au moins pour nous (cest--dire mon client actuel
Stockholm, dont je nai pas lintention de mentionner le nom ici). Jespre
quil marchera pour vous aussi ! Peut-tre que ce papier vous aidera au
long du chemin.
Cest la premire fois que jai vu une mthodologie de dveloppement
(dsol Ken, un cadre) marcher exactement comme dans le bouquin. Plug
n play. Nous sommes tous heureux avec lui dveloppeurs, testeurs,
managers. Il nous a aids nous sortir dune situation difficile, et nous a
permis de maintenir une focalisation et un lan malgr de svres
turbulences du march et des rductions de personnel.
Je ne devrais pas dire que jai t surpris, mais, eh bien oui, je lai t.
Aprs avoir initialement digr quelques livres sur le sujet Scrum semblait
bien, mais prs trop bien pour tre vrai (et nous connaissons tous le
proverbe quand quelque chose semble trop beau pour tre vrai ).
Donc jtais lgitimement un peu sceptique. Mais aprs avoir appliqu
Scrum pendant un an je suis suffisamment impressionn (et la plupart des
gens dans les quipes aussi) pour que je continue probablement utiliser
Scrum par dfaut dans les nouveaux projets chaque fois quil ny a pas
une trs bonne raison de faire autrement.
1
Intro
Vous tes sur le point d'utiliser Scrum dans votre organisation. Ou peuttre vous avez dj utilis Scrum pendant quelques mois. Vous avez les
bases, vous avez lu les livres, peut-tre que vous avez mme obtenu votre
certification de Scrum Master. Flicitations !
Mais pourtant vous ressentez de la confusion.
Selon les mots de Ken Schwaber, Scrum n'est pas une mthodologie, c'est
un cadre. Ce qui signifie que Scrum ne va pas rellement vous dire
exactement ce que vous devez faire. Zut.
La bonne nouvelle c'est que je vais vous dire comment je pratique Scrum,
dans les plus petits dtails. La mauvaise nouvelle est qu'il s'agit
uniquement de comment je pratique Scrum. Cela ne signifie pas que vous
devriez faire exactement la mme chose. En fait je pourrais mme le faire
d'une autre manire si je rencontrais une autre situation.
La force et la douleur de Scrum est que vous tes obligs de l'adapter
votre situation particulire.
Mon approche actuelle de Scrum est le rsultat d'une anne
d'exprimentation dans une quipe de dveloppement d'environ 40
personnes. L'entreprise tait dans une situation difficile avec beaucoup
d'heures de travail supplmentaires, de graves problmes de qualit, des
incendies teindre constamment, des dates de livraison manques,
etc. L'entreprise avait dcid d'utiliser Scrum, mais n'avait pas termin son
implmentation, ce qui devait tre mon travail. Pour la plupart des
membres de l'quipe de dveloppement l'poque, Scrum tait juste un
trange mot la mode entendu de temps en temps dans les couloirs, sans
relle implication sur leur travail quotidien.
8 | SCRUM ET XP DEPUIS LES TRANCHEES

Sur une anne nous avons implment Scrum travers toutes les couches
de l'entreprise, essay diffrentes tailles d'quipe (3-12 membres),
diffrentes dures d'itration (2-6 semaines), diffrentes manires de
dfinir termin , diffrents formats pour les carnets de produit et les
carnets de d'itration (Excel, Jira, cartes d'index), diffrentes stratgies de
test, diffrentes faons de faire les dmonstrations, diffrentes manires
de synchroniser des quipes Scrum multiples, etc. Nous avons galement
expriment avec les pratiques XP - diffrentes manires de faire
l'intgration continue, la programmation en binme, le dveloppement
dirig par les tests, etc., et comment les combiner avec Scrum.
C'est un processus d'apprentissage constant, donc l'histoire ne s'arrte pas
ici. Je suis convaincu que cette entreprise va continuer d'apprendre (s'ils
poursuivent les rtrospectives de fin d'itration) et de dcouvrir de
nouvelles ides sur les meilleures manires d'implmenter Scrum dans
leur contexte particulier.
Avertissement
Ce document ne prtend pas reprsenter la bonne manire de pratiquer
Scrum. Il reprsente seulement une faon de pratiquer Scrum, le rsultat
d'une anne de perfectionnement constant. Vous pourriez mme dcider
que nous avons tout faux.
Tout le contenu de ce document reflte mes opinions personnelles et
subjectives, et n'est en aucune faon une dclaration officielle de Crisp ou
de mon client actuel. Pour cette raison j'ai intentionnellement vit de
mentionner des personnes ou des produits spcifiques.
Pourquoi jai crit ceci

En me formant Scrum j'ai lu les livres pertinents sur Scrum et l'agilit, je
me suis panch dans les sites et forums sur Scrum, j'ai suivi la
certification de Ken Schwaber, je l'ai mitraill de questions, et j'ai pass
beaucoup de temps discuter avec mes collgues. Toutefois l'une de mes
meilleures sources d'information a t les vraies histoires de guerre. Les
histoires de guerre transforment les Principes et Pratiques en ... eh bien ...
Comment faire en pratique. Elles m'ont aussi permis d'identifier (et
parfois d'viter) les erreurs typiques de dbutant.
Alors c'est l'occasion pour moi de donner quelque chose en retour. Voici
mon histoire de guerre.
INTRO | 9
J'espre que ce papier va susciter un feedback utile de la part de ceux qui
sont dans la mme situation. Eclairez-moi s'il vous plat !
Mais Scrum, qu'est-ce que c'est ?

Oh, dsol. Vous tes compltement dbutant en Scrum et XP ? Dans ce
cas vous pourriez avoir envie de jeter un il aux liens suivants :
http://agilemanifesto.org/
http://www.mountaingoatsoftware.com/scrum
http://www.xprogramming.com/xpmag/whatisxp.htm
Si vous tes trop impatient pour le faire, sentez-vous libres de simplement
continuer lire. La plupart du jargon Scrum est expliqu au fur et
mesure, aussi vous pourriez quand mme trouver cette lecture
intressante.
2
Comment nous faisons les backlogs de
produit
Le Backlog de produit est le cur de Scrum. C'est l o tout commence.
Le Backlog de produit est en gros une liste priorise d'exigences,
d'histoires, de caractristiques ou autre. Des choses que le client veut,
dcrites selon la terminologie du client.
Nous appelons a des histoires, ou parfois simplement des lments du
backlog.
Nos histoires incluent les champs suivants :
ID - un identifiant unique, juste un nombre auto-incrment. Cela

vite de perdre la trace des histoires quand on les renomme.
Nom - Un nom, une description courte de l'histoire. Par exemple

Voir l'historique de ses transactions . Suffisamment claire pour
que les dveloppeurs et le directeur de produit comprennent
approximativement de quoi ils parlent, et suffisamment claire
pour la distinguer des autres histoires. Normalement 2 10 mots.
Importance - l'importance attribue par le directeur de produit

cette histoire. Par exemple 10. Ou 150. leve = plus important.
o
Je fais attention d'viter le terme priorit parce que la

priorit 1 est typiquement considre comme la plus
haute priorit, ce qui est dommage si plus tard vous
dcidez que quelque chose d'autre est encore plus
important. Quelle priorit devrait-on lui attribuer ?
Priorit 0 ? Priorit -1 ?
Estimation initiale - l'valuation initiale de l'quipe sur la

quantit de travail qui est ncessaire pour implmenter cette

histoire par rapport aux autres histoires. L'unit est les points
d'histoire et correspond habituellement peu prs des jourshommes idaux .
o Demandez l'quipe si vous pouvez prendre le nombre
optimal de personnes pour cette histoire (ni trop peu ni
trop nombreux, typiquement 2), et que vous vous
enfermez dans une salle avec plein de nourriture et que
vous travaillez sans jamais tre drang, aprs combien
de jours sortiriez-vous avec une implmentation finie,
dmontrable, teste, et livrable ? . Si la rponse est
avec 3 gars enferms dans une salle a prendrait
approximativement 4 jours alors l'estimation initiale
est de 12 points d'histoire.
Le point important n'est pas d'obtenir des estimations
absolues correctes (c'est--dire que 2 points d'histoire
devraient prendre 2 jours), le point important est d'avoir
des estimations relatives correctes (c'est--dire que 2
points d'histoire devraient ncessiter peu prs la moiti
du travail de 4 points d'histoire).
Comment le dmontrer - une description succincte de comment
cette histoire sera dmontre la dmo de fin d'itration. C'est
essentiellement la spcification d'un test simple. Fais ci, ensuite
fais a, puis ceci devrait arriver .
Si vous pratiquez le DDT (Dveloppement Dirig par les Tests)
cette description peut tre utilise comme du pseudo-code pour
vos tests d'acceptance.
Notes - n'importe quelle autre info, des clarifications, des
rfrences aux autres sources d'info, etc. Normalement trs bref.
o
BACKLOG DE PRODUIT (exemple)

ID Nom
Imp
Est Dmo.
1
Dpt
30
5
Authentification,
ouvrir la page de
dpt, dposer 10,
aller sur la page du
solde et vrifier que
a a bien augment
de 10.
2
Voir
10
8
Authentification,
l'historique
cliquez sur
de ses
transactions .
Notes
Ncessite un
diagramme de
squences
UML. Ne pas
se soucier du
cryptage pour
l'instant.
Utiliser la
pagination
pour viter
COMMENT NOUS FAISONS LES BACKLOGS DE PRODUIT | 13

transactions
Faire un dpt.
Revenir aux
transactions, vrifier
que le nouveau
dpt apparat.
des requtes
volumineuses
. Conception
semblable
la page des
utilisateurs.
Nous avons expriment beaucoup d'autres champs, mais la fin, les six
champs ci-dessus taient les seuls que nous utilisions sprint aprs sprint.
Nous faisons habituellement un document Excel avec le partage activ
(c'est--dire que plusieurs utilisateurs peuvent modifier le fichier en mme
temps). Officiellement le directeur de produit possde ce document, mais
nous ne voulons pas verrouiller l'accs aux autres utilisateurs.
Rgulirement un dveloppeur veut ouvrir le document pour clarifier
quelque chose ou changer une estimation.
Pour la mme raison, nous ne plaons pas le document dans le dpt de
contrle de version ; nous le plaons dans un rpertoire partag plutt.
Ceci semble la manire la plus simple d'autoriser les modifications
simultanes sans causer des verrous ou des conflits de rconciliation.
Cependant, presque tous les autres artefacts sont placs dans le systme de
contrle de version.
Champs d'histoire supplmentaires

Parfois nous utilisons des champs supplmentaires dans le product
backlog, surtout par commodit pour le directeur de produit pour l'aider
trier ses priorits.
Catgorie - un classement approximatif de cette histoire, par

exemple back office ou optimisation . De cette faon
le directeur de produit peut facilement filtrer tous les
lments optimisation et leur affecter une priorit basse,
etc.
Composants - Habituellement reprsents par des cases
cocher dans un tableau Excel, par exemple base de
donnes, serveur, client . Ici l'quipe ou le directeur de
produit peut identifier quels composants techniques vont tre
impliqus dans l'implmentation de cette histoire. Ceci est
utile quand vous avez plusieurs quipes Scrum, par exemple
une quipe back office et une quipe client, et que vous
souhaitez rendre plus facile pour chaque quipe de dcider

quelles histoires prendre.
Demandeur - le directeur de produit peut vouloir garder une
trace de quel client ou quelle partie prenante avait demand
cet lment l'origine, dans le but de les informer sur
l'avancement.
ID de suivi de bug - si vous avez un systme de suivi des
bogues spar, comme nous faisons avec Jira, il est utile de
garder une trace de toute correspondance directe entre une
histoire et un ou plusieurs bogues.
Comment nous gardons le backlog de produit

un niveau mtier
Si le directeur de produit a un pass technique il peut vouloir ajouter des
histoires comme ajouter des indexes sur les table d'vnements .
Pourquoi veut-il faire a ? Le but rel sous-jacent est probablement
quelque chose du genre augmenter la rapidit de la recherche des
vnements sur le back office .
Il se peut que les indexes n'taient pas le goulot d'tranglement qui rendait
le formulaire lent. Il se peut que ce soit quelque chose de compltement
diffrent. L'quipe est normalement mieux place pour deviner comment
rsoudre quelque chose, aussi le directeur de produit devrait garder le
focus sur les objectifs mtiers.
Quand je vois des histoires orientes technique comme celle-ci, je pose
normalement au directeur de produit une srie de questions mais
pourquoi jusqu' ce qu'on trouve le but sous-jacent.
Ensuite on reformule l'histoire dans les termes de ce but sous-jacent
( augmenter la rapidit de la recherche des vnements sur le back
office ). La description technique d'origine finit en tant que note
( indexer la table des vnements peut peut-tre rsoudre le problme ).
COMMENT NOUS FAISONS LES BACKLOGS DE PRODUIT | 15
3
Comment nous prparons la runion de
planning du sprint
OK, le jour de planification du sprint arrive rapidement. Une leon que
nous rapprenons sans cesse est :
Leon : Faites en sorte que le backlog de produit soit en ordre avant cette
runion de planification du sprint.
Et qu'est-ce que cela signifie ? Que toutes les histoires doivent tre
parfaitement dfinies ? Que toutes les estimations doivent tre correctes ?
Que toutes les priorits doivent tre fixes ? Non, non et non ! Tout ce que
cela veut dire est :
le backlog de produit devrait exister ! (imaginez que non ?)

il devrait y avoir un backlog de produit et un directeur de produit
(par produit bien sr)
un niveau d'importance devrait avoir t attribu tous les
lments importants, et ces niveaux devraient tre diffrents.
o En fait, c'est OK si les lments de plus faible
importance ont le mme niveau, puisqu'ils ne seront
probablement pas mentionns durant la planification de
sprint de toute manire.
o Si le directeur de produit croit qu'une histoire a une
probabilit (mme trs faible) d'tre adopte dans la
prochaine itration, alors cette histoire devrait avoir un
niveau d'importance unique.
o Le niveau d'importance est utilis uniquement pour trier
les lments par importance. Donc si l'lment A a une
importance de 20 et l'lment B une importance de 100,
cela signifie simplement que B est plus important que A.
Cela ne signifie pas que B est cinq fois plus important
que A. Si B avait pour niveau d'importance 21, cela
signifierait exactement la mme chose !
COMMENT NOUS PREPARONS LA REUNION DE PLANNING DE SPRINT | 17

Il est utile de laisser des trous dans la squence des
niveaux pour le cas o un lment C arrive et est plus
important que A mais moins important que B. Bien sr
vous pourriez utiliser un niveau d'importance de 20,5
mais cela devient dplaisant, donc nous laissons des
trous la place !
le directeur de produit devrait comprendre chaque histoire
(normalement il en est l'auteur, mais il arrive que d'autres
personnes ajoutent des demandes, dont le directeur de produit
peut choisir la priorit). Il n'a pas besoin de savoir exactement ce
qui doit tre implment, mais il devrait comprendre pourquoi
l'histoire est l.
o
Note : d'autres personnes que le directeur de produit peuvent ajouter des

histoires au backlog de produit. Mais elles n'ont pas attribuer un niveau
d'importance, seul le directeur de produit en a le droit. Elles n'ont pas
ajouter d'estimations non plus, seule l'quipe en a le droit.
Voici d'autres approches que nous avons essayes :
Utiliser Jira (notre systme de suivi de bugs) pour hberger le

backlog de produit. Toutefois la plupart de nos directeurs de
produit ont trouv qu'il fallait trop de clics pour l'utiliser. Excel
est agrable et facile manipuler directement. Vous pouvez
facilement utiliser des codes de couleur, rarranger les lments,
ajouter de nouvelles colonnes ad-hoc, ajouter des notes, importer
et exporter des informations, etc.
Utiliser un outil de support de processus agile comme
VersionOne, ScrumWorks, XPlanner, etc. Nous n'avons pas
encore trouv le temps d'en tester un, mais nous le ferons
probablement.
4
Comment nous faisons les plannings de
sprint
Le planning de sprint est une runion critique, probablement l'vnement
le plus important dans Scrum (d'aprs mon opinion subjective bien sr).
Une runion de planning de sprint mal excute peut perturber un sprint
complet.
Le but de la runion de planning de sprint est de donner l'quipe
suffisamment d'informations pour qu'elle soit capable de travailler
paisiblement, sans drangements pendant quelques semaines, et de donner
au directeur de produit suffisamment de confiance pour les laisser faire.
OK, c'est un peu flou. Concrtement, la fin de cette runion on doit
avoir :

Un but pour le sprint.

Une liste des membres d'quipe (et de leur niveau d'engagement,
si ce n'est pas 100%).
Un backlog de sprint (= une liste des histoires incluses dans le
sprint).
Une date bien dfinie pour la dmonstration.
Une heure et un lieu bien dfinis pour la mle quotidienne.
Pourquoi le directeur de produit doit y assister

Quelquefois les directeurs de produits rechignent passer des heures avec
l'quipe pour faire le planning de sprint. Les gars, j'ai dj list ce que je
voulais. Je n'ai pas le temps de participer votre runion de planning .
C'est un problme vraiment srieux.
La raison pour laquelle l'quipe au complet ainsi que le directeur de
produit doivent tre cette runion de planning de sprint est que chaque

histoire contient trois variables qui dpendent fortement les unes des
autres.
La porte et l'importance sont dtermines par le directeur de produit.

L'estimation est dtermine par l'quipe. Durant une runion de planning
de sprint, ces trois variables sont affines continuellement grce au
dialogue face--face entre l'quipe et le directeur de produit.
Normalement le directeur de produit commence la runion en rsumant
son but pour le sprint et les histoires les plus importantes. Ensuite l'quipe
parcourt chaque histoire et estime le temps qu'il faudra pour la raliser, en
commenant par la plus importante. Pendant qu'ils font a, ils auront des
questions importantes sur la porte est-ce que cette histoire de
suppression d'utilisateur comprend le fait de parcourir chaque transaction
en attente pour cet utilisateur, et de l'annuler? Dans certains cas les
rponses surprendront l'quipe et la conduiront changer son estimation.
Dans d'autres cas l'estimation du temps pour une histoire ne sera pas ce
que le directeur de produit attendait. Cela peut le conduire changer
l'importance de l'histoire. Ou changer la porte de l'histoire, ce qui
conduira l'quipe r-estimer, etc, etc.
Ce type de collaboration directe est fondamental dans Scrum et en fait
dans tout dveloppement logiciel agile.
Que faire si le directeur de produit persiste dire qu'il n'a pas le temps de
participer aux runions de planning de sprint ? Habituellement j'essaie les
stratgies suivantes, dans l'ordre propos :
Essayer d'aider le directeur de produit comprendre pourquoi sa

participation directe est cruciale, et esprer qu'il change d'avis.
Essayer de convaincre quelqu'un de l'quipe de se porter
volontaire pour servir de reprsentant du directeur de produit
pendant la runion. Dire au directeur de produit : Puisque que
vous ne pouvez pas venir, nous laisserons Jeff ici prsent vous
COMMENT NOUS FAISONS LES PLANNINGS DE SPRINT | 21
reprsenter. Il aura les pleins pouvoirs pour changer la priorit et

la porte des histoires pendant la runion. Je vous suggre de
vous synchroniser avec lui le mieux possible avant la runion. Si
Jeff ne vous convient pas comme reprsentant, merci de suggrer
quelqu'un d'autre, condition que cette personne puisse rester
avec nous pour toute la dure de la runion.
Essayer de convaincre l'quipe de direction de dsigner un
nouveau directeur de produit.
Repousser le dmarrage du sprint jusqu' ce que le directeur de
produit trouve le temps de participer la runion. En attendant,
refuser de s'engager sur une quelconque livraison. Laisser
l'quipe consacrer chaque jour ce qui lui parat le plus important
ce jour-l.
Pourquoi la qualit n'est pas ngociable

Dans le triangle ci-dessus j'ai intentionnellement vit une quatrime
variable qualit.
La qualit externe est ce qui est peru par les utilisateurs du

systme. Une interface utilisateur lente et pas intuitive est un
exemple de mauvaise qualit externe.
La qualit interne fait rfrence des points qui habituellement
ne sont pas visibles par l'utilisateur, mais qui ont un profond effet
sur la maintenabilit du systme. Des choses comme la cohrence
de la conception, la couverture de test, la lisibilit du code, les
remaniements (refactoring).
En gnral, un systme avec une qualit interne leve peut tout de mme
avoir une qualit externe faible. Mais un systme avec une faible qualit
interne aura rarement une qualit externe leve. Il est difficile de btir
quelque chose de bien sur des fondations pourries.
Je traite la qualit externe comme faisant partie de la porte. Dans certains
cas il peut y avoir d'excellentes raisons pour livrer une version du systme
qui aurait une interface utilisateur lente et peu lgante, et livrer ensuite
une version nettoye plus tard. Je laisse ce compromis au directeur de
produit, puisqu'il est responsable de dfinir la porte.
Toutefois la qualit interne n'est pas sujette discussion. C'est la
responsabilit de l'quipe de maintenir la qualit du systme dans toutes
les circonstances et ceci est simplement non ngociable. Jamais.
(Eh bien, OK, presque jamais)

Alors comment faisons-nous la diffrence entre les problmes de qualit
interne et ceux de qualit externe ?
Considrons que le directeur de produit dise : OK les gars, je respecte
votre estimation de temps de 6 points d'histoire, mais je suis certain que
vous pouvez faire quelque chose de rapide pour a en moiti moins de
temps pour peu que vous y rflchissiez.
Aha ! Il est en train d'essayer d'utiliser la qualit interne comme variable.
Comment je le sais ? Parce qu'il veut que nous rduisions l'estimation de
l'histoire sans payer le prix de rduire la porte. Les mots quelque
chose de rapide devraient dclencher une alarme dans votre tte...
Et pourquoi est-ce que nous n'autorisons pas a ?
Mon exprience est que sacrifier la qualit interne est presque toujours
une trs trs mauvaise ide. Le temps conomis est largement dpass
par le cot court et long terme. Une fois qu'une base de code est
autorise commencer se dtriorer, il est trs difficile d'y remettre de
la qualit plus tard.
A la place, j'essaie de faire avancer la discussion vers la porte. Puisqu'il
est important pour vous d'avoir cette fonctionnalit rapidement, pouvonsnous rduire sa porte pour qu'elle soit plus rapide implmenter ? Peuttre que nous pourrions simplifier la gestion d'erreur et avoir 'Gestion
d'erreur avance' comme histoire utilisateur spare conserver pour plus
tard ? Ou bien pouvons-nous rduire la priorit des autres histoires pour
pouvoir nous focaliser sur celle-ci ?
Une fois que le directeur de produit a appris que la qualit interne n'tait
pas ngociable, il devient normalement assez bon manipuler les autres
variables la place.
Les runions de planning de sprint qui

s'ternisent...
La plus grande difficult des runions de planning de sprint est que :
1) les gens ne pensent pas qu'elles vont durer si longtemps
2) ... mais c'est toujours le cas !
Tout dans Scrum est en temps limit. J'adore cette rgle simple et
cohrente.

Nous essayons de nous y tenir.
Donc que faisons-nous quand la runion de planning de sprint en temps
limit est proche de sa fin et qu'il n'y a pas signe d'un but de sprint ou d'un
backlog de sprint ? Est-ce que nous courtons la runion ? Ou nous
continuons pour encore une heure ? Ou nous arrtons la runion et
continuons le jour suivant ?
Cela arrive encore et toujours, en particulier pour les nouvelles quipes.
Donc que faites-vous ? Je ne sais pas. Mais que faisons-nous? Oh, euh, eh
bien, habituellement jcourte brutalement la runion. Point final.
Laissons le sprint souffrir. Plus prcisment, je dis lquipe et le
directeur de produit alors cette runion se finit dans 10 minutes. Nous
navons pas grand-chose comme plan de sprint en fait. Est-ce que nous
faisons avec ce que nous avons, ou bien est-ce nous organisons une autre
runion de planning de sprint de 4 heures demain matin 8h ? Vous
pouvez devinez ce quils rpondent :o)
Jai essay de laisser la runion sterniser. Habituellement ca ne sert
rien car les gens sont fatigus. Sils nont pas produit un plan de sprint
dcent en 2-8 heures (ou autre limite de temps votre convenance), ils ny
arriveront probablement pas en une heure de plus. Lautre option
(organiser une nouvelle runion le jour suivant) nest pas mal non plus.
Sauf que les gens sont gnralement impatients de dmarrer le sprint, et
pas de passer encore quelques heures planifier.
Donc jcourte. Et en effet le sprint souffre. Le ct positif, toutefois, est
que lquipe a appris une leon de forte valeur, et la runion de planning
de sprint suivante sera bien plus efficace. De plus les gens rsisteront
moins quand vous proposerez une dure de runion quils auraient
auparavant considre comme trop longue.
Apprenez respecter vos limites de temps, apprenez dfinir des limites
ralistes. Ceci sapplique la fois la dure des runions et des sprints.
Lordre du jour de la runion de planning de

sprint
Avoir une sorte dordre du jour prliminaire pour cette runion rduira le
risque de ne pas respecter la limite de temps.
Voici un exemple dun plan typique pour nous.

Runion de planning de sprint : 13:00 17:00 (10 minutes de pause
toutes les heures)
13:00 13:30. Le directeur de produit dcrit le but du sprint et
rsume le backlog de produit. Le lieu, la date et lheure de la
dmonstration sont fixs.
13:30 15:00. Lquipe fait les estimations en temps, et
dcompose les lments selon les besoins. Le directeur de produit
met jour les niveaux dimportance selon les besoins. Les
lments sont clarifis. Comment dmontrer est explicit pour
chacun des lments les plus importants.
15:00 16:00. Lquipe slectionne les histoires inclure dans le
sprint. Elle fait les calculs de vlocit pour se confronter la
ralit.
16:00 17:00. On choisit le lieu et lheure pour la mle
quotidienne (sils sont diffrents du dernier sprint). On poursuit la
dcomposition des histoires en tches.
Ce plan nest en aucune faon respect trop strictement. Le Scrum master
peut allonger ou raccourcir ces limites de temps comme ncessaire au fur
et mesure que la runion progresse.
Le choix de la dure du sprint

Lun des produits de cette runion de planning de sprint est une date de
dmonstration bien dfinie. Cela signifie que vous devez dcider dune
dure de sprint.
Donc quelle la bonne dure dun sprint ?
Eh bien, les sprints courts sont bnfiques. Ils autorisent lentreprise tre
agile , cest--dire changer souvent de direction. Les sprints courts =
cycle de feedback court = des livraisons plus frquentes = plus de
feedback des clients = moins de temps pass courir dans la mauvaise
direction = apprendre et amliorer plus rapidement, etc.
Cela dit, les longs sprints sont bien aussi. Lquipe a plus temps pour
monter en puissance, ils ont plus de temps pour rcuprer des problmes
et parvenir tout de mme atteindre le but du sprint, il y a moins de
surcharge en terme de runions de planning de sprint, de dmonstrations,
etc.

En gnral les directeurs de produit aiment les sprints courts et les
dveloppeurs aiment les sprints longs. Donc la dure du sprint est un
compromis. Nous avons beaucoup expriment ce sujet et avons
dcouvert notre longueur favorite : 3 semaines. La plupart de nos quipes
(mais pas toutes) font des sprints de 3 semaines. Cest assez court pour
nous donner suffisamment dagilit dentreprise, et suffisamment long
pour permettre lquipe davoir du dbit et de rcuprer des problmes
qui surgissent au cours du sprint.
Lune de nos conclusions est : faites des expriences avec la dure des
sprints au dbut. Ne perdez pas trop de temps analyser, choisissez
simplement une dure de sprint dcente, essayez l pour un sprint ou
deux, puis changez cette dure.
Toutefois, une fois que vous avez dcid quelle dure vous prfrez,
tenez-y vous pour un bon moment. Aprs quelques mois
dexprimentation, nous avons trouv que 3 semaines ctait bien. Donc
nous faisons des sprints de 3 semaines, point final. De temps en temps
cela va paratre lgrement trop long, de temps en temps lgrement trop
court. Mais en gardant toujours cette dure, cela devient comme un
battement de cur dentreprise, dans lequel tout le monde sinstalle
confortablement. Il ny a pas de dbat au sujet de dates de livraison et
autres parce que tout le monde sait que toutes les 3 semaines il y a une
livraison, point final.
La dfinition du but du sprint

Cela arrive presque chaque fois. A un certain moment durant la runion
je demande alors quel est le but de ce sprint ? et tout le monde me
regarde fixement et le directeur de produit fronce les sourcils et se gratte
le menton.
Il se trouve quil est difficile de dterminer un but de sprint. Mais toutefois
jai dcouvert que cest vraiment payant de se forcer en trouver un. Il
vaut mieux un but demi-merdique que pas de but du tout. Le but
pourrait tre gagner plus dargent ou terminer les trois histoires les
plus prioritaires ou impressionner le PDG ou rendre le systme
suffisamment bon pour tre dploy chez un groupe de beta-testeurs ou
ajouter un support basique pour le back office ou nimporte quoi
dautre. Le point important est que le but devrait tre dfini en termes
mtier, pas en termes techniques. Cela signifie en termes que les gens en
dehors de lquipe peuvent comprendre.

Le but du sprint devrait rpondre la question fondamentale Pourquoi
faisons-nous ce sprint ? Pourquoi est-ce que nous ne partons pas tous en
vacances la place ? En fait un moyen dextraire un but de sprint du
directeur de produit est de poser littralement cette question.
Le but devrait tre quelque chose qui na pas dj t ralis.
Impressionner le PDG peut tre un bon but, mais pas sil a dj t
impressionn par le systme tel quil est maintenant. Dans ce cas tout le
monde pourrait rentrer la maison et le but du sprint serait quand mme
ralis.
Le but du sprint peut sembler bte ou forc durant le planning de sprint,
mais il sert souvent mi-sprint, quand les gens commencent devenir
perplexes sur ce quils devraient faire. Si vous avez plusieurs quipes
Scrum (comme nous) qui travaillent sur diffrents produits, il est trs utile
de lister les buts de sprint de toutes les quipes sur une seule page de wiki
(ou quivalent) et de les mettre un endroit bien visible, de telle sorte que
tout le monde dans lentreprise (pas seulement le management de haut
niveau) sache ce que lentreprise est en train de faire et pourquoi !
Le choix des histoires inclure dans le sprint

Lune des activits principales de la runion de planning de sprint est de
dcider quelles histoires inclure dans le sprint. Plus prcisment, quelles
histoires du backlog de produit il faut copier dans le backlog de sprint.

Regardez limage ci-dessus. Chaque rectangle reprsente une histoire,
trie par importance. Lhistoire la plus importante est au sommet de la
liste. La taille de chaque rectangle reprsente la taille de cette histoire
(cest--dire lestimation de temps en points dhistoire). La hauteur de la
parenthse bleue reprsente la vlocit estime de lquipe, cest--dire
combien de points dhistoire lquipe croit quelle pourra terminer durant
le prochain sprint.
Le backlog de sprint droite est un ensemble dhistoires du backlog de
produit. Il reprsente la liste des histoires sur lesquelles lquipe va
sengager durant ce sprint.
Lquipe dcide combien dhistoires vont tre prises dans le sprint. Pas le
directeur de produit ou qui que ce soit dautre.
Cela soulve deux questions :
1. Comment lquipe dcide-t-elle quelles histoires inclure dans le
sprint ?
2. Comment le directeur de produit peut-il influencer leur dcision ?
Je vais commencer par la deuxime question.
Comment le directeur de produit peut-il

exercer une influence sur les histoires qui
iront dans le sprint ?
Supposons que nous avons la situation suivante durant une
runion de planning de sprint.
Le directeur de produit est du que lhistoire D ne soit pas incluse dans le

sprint. Quelles sont ses options durant la runion ?

Une option est de redfinir les priorits. Sil donne llment D le plus
haut niveau dimportance, lquipe sera oblige de lajouter en premier
dans le sprint (et dans ce cas djecter lhistoire C).
La deuxime option est de changer la porte rduire la porte de

lhistoire A jusqu ce que lquipe croie que lhistoire D va tenir dans le
sprint.
La troisime option est de partager une histoire. Le directeur de produit

pourrait dcider quil y a certains aspects de lhistoire A qui ne sont
finalement pas si importants, et donc il partage A en deux histoires A1 et
A2 avec des niveaux dimportance diffrents.
Comme vous le voyez, bien que le directeur de produit ne puisse

normalement pas contrler la vlocit estime, il y a plusieurs moyens par
lesquels il peut exercer une influence sur les histoires qui seront prises
dans le sprint.
Comment les quipes choisissent-elles les

histoires inclure dans le sprint?
Pour cela, nous utilisons deux techniques :
1.
Lintuition
2.
Les calculs de vlocit
Estimation en utilisant lintuition

Scrum master: Eh les gars, peut-on finir lhistoire A dans ce

sprint? (montrant llment le plus important du backlog de
produit)
Lisa: Ben. Bien sr que nous pouvons. Nous avons 3 semaines,
et cest une fonctionnalit plutt facile.
Scrum master: OK, et nous rajoutons aussi lhistoire B ?
(montrons le deuxime lment le plus important)
Tom & Lisa ensemble: Pas de problme.
Scrum master: OK, et avec les histories A, B et C maintenant
?
Sam ( ladresse du Directeur de produit): Est-ce que
lhistoire C comporte une gestion avance des erreurs ?
Directeur de produit: non, vous pouvez la laisser de cot pour
le moment, implmentez juste une gestion basique des erreurs.
Sam: alors C devrait tre bonne aussi.
Scrum master: OK, et si nous ajoutons lhistoire D ?
Lisa: Hum....
Tom: Je pense que nous pouvons le faire.

Scrum master: Confiant 90% ? 50% ?

Lisa & Tom: A peu prs 90%.
Scrum master: OK, prenons D. Et si nous ajoutons lhistoire E
?
Sam: Peut-tre.
Scrum master: 90%? 50%?
Sam: Je dirais plus proche de 50%.
Lisa: Je ne suis pas sre.
Scrum master: OK, alors ne la prenons pas. Nous nous
engagerons pour A, B, C, et D. Nous finirons E bien sr si nous
le pouvons, mais personne ne devrait compter dessus, du coup
nous la laisserons en dehors du plan du sprint. Quen dtesvous?
Tout le monde: OK!
Lintuition marche plutt bien pour des petites quipes et des sprints
courts.
Estimation en utilisant les calculs de vlocit

Cette technique implique deux tapes:
1.
Dcider la vlocit estime
2.
Calculer combien dhistoires vous pouvez ajouter sans dpasser
la vlocit estime
La vlocit mesure la quantit de travail fini, o chaque lment est
pondr selon son estimation initiale.
Limage ci-dessous montre un exemple de vlocit estime au dmarrage
dun sprint et la vlocit effective la fin du sprint. Chaque rectangle est
une histoire, et le numro lintrieur est lestimation initiale de cette
histoire.

Notez que la vlocit effective est base sur les estimations initiales de
chaque histoire. Les mises jour des estimations du temps de lhistoire
faites durant le sprint sont ignores.
Dj, jentends votre objection : En quoi est-ce utile ? Une vlocit
basse ou leve peut dpendre de tout un tas de facteurs ! Des
programmeurs stupides, des estimations initiales incorrectes, glissement
de primtre, perturbations inattendues durant le sprint, etc. !
Je suis daccord, il sagit dun nombre approximatif. Mais cela reste un
nombre utile, spcialement quand il est compar rien du tout. Il vous
donne de solides faits. Quelles que soient les raisons, voici la diffrence
entre combien nous avions pens pouvoir faire et combien nous avons
rellement pu finir.
Que dire dune histoire qui est presque finie durant un sprint ? Pourquoi
ne pas compter les points partiellement accomplis pour celle-ci dans notre
vlocit effective ? Eh bien cest pour souligner le fait que Scrum (en fait
le dveloppement logiciel agile et le lean manufacturing en gnral) est
entirement focalis sur lobtention de quelque chose de compltement
termin, pouvant tre livr ! La valeur dune chose moiti fini est zro
(peut-tre en fait mme ngative). Lisez Managing the Design Factory
de Donald Reinertsen ou un des livres des Poppendieck pour en savoir
plus sur le sujet.
Alors travers quel arcane magique estimons-nous la vlocit ?
Une faon trs simple destimer la vlocit est dtudier le pass de
lquipe. Quelle a t leur vlocit durant les sprints passs ? Alors on fait
lhypothse que la vlocit sera grosso modo la mme au prochain sprint.
Cette technique est connue sous le nom de la mto de la veille. Cela est
faisable seulement avec des quipes qui ont dj fait quelques sprints (des
statistiques sont alors disponibles) et qui feront le prochain sprint de la
mme faon, avec la mme taille dquipe et dans les mmes conditions
de travail, etc. Bien sr ceci nest pas toujours le cas.
Une variante plus sophistique consiste faire un simple calcul de
ressource. Disons que nous planifions un sprint de 3 semaines (15 jours de
travail) avec une quipe de 4 personnes. Lisa est en congs durant 2 jours.
Dave est disponible seulement 50% et il sera en congs durant 1 jour.
Mettant tout cela ensemble
cela nous donnes 50 jours-homme pour ce sprint.

Est-ce cela notre vlocit estime ? Non ! Car notre unit destimation est
le point dhistoire qui, dans notre cas, correspond peu prs autant de
jours-homme idaux. Un jour-homme idal est un jour de travail,
parfaitement efficace, sans perturbation, ce qui est rare. De plus, nous
devons tenir compte de choses comme le travail inattendu qui va sajouter
au sprint, des personnes malades, etc.
Du coup, notre vlocit estime sera certainement infrieure 50. Mais de
combien infrieure ? Nous utilisons cette fin le terme facteur de
focalisation.
Le facteur de focalisation est une estimation indiquant quel point

lquipe est concentre. Un faible facteur de focalisation devrait signifier
que lquipe sattend avoir de nombreuses perturbations ou sattend ce
que ses estimations soient trop optimistes.
La meilleure faon de dterminer un facteur de focalisation raisonnable
est de regarder le dernier sprint (ou mme mieux, la moyenne des
quelques derniers sprints).
La vlocit effective est la somme des estimations initiales de toutes les

histories qui ont t termines durant le dernier sprint.
Disons que le dernier sprint a fait 18 points dhistoire avec une quipe de
3 personnes constitue de Tom, Lisa et Sam travaillant durant 3 semaines
pour un total de 45 jours-homme. Et maintenant nous essayons davoir

une ide de notre vlocit estime pour le sprint qui arrive. Pour
compliquer les choses, un nouveau gars Dave rejoint lquipe pour ce
sprint. Prenant en compte les congs et le reste nous obtenons 50 jourshomme pour le prochain sprint.
Notre vlocit estime pour le prochain sprint est donc de 20 points

dhistoire. Cela veut dire que lquipe devrait rajouter des histoires au
sprint jusqu cela atteigne environ 20.
Dans ce cas lquipe peut choisir les 4 histoires en tte pour un total de 19
points dhistoire, ou les 5 histoires en tte pour un total de 24 points.
Disons quils choisissent 4 histoires, car cela est le plus proche de 20
points. En cas de doute, choisissez moins dhistoires.
Comme ces 4 histoires font au total 19 points dhistoires, leur vlocit
estime finale pour ce sprint est 19.
La mto de la veille est une technique pratique mais utilisez la avec une
dose de bon sens. Si le dernier sprint tait anormalement mauvais car la
plupart des membres de lquipe tait malade pendant une semaine, alors
il serait prudent de considrer que vous ne serez pas malchanceux une
seconde fois et vous pourrez estimer un facteur de focalisation plus lev
pour le prochain sprint. Si lquipe a mis en place rcemment un nouveau
systme dintgration continu aussi rapide que la foudre, alors vous
pouvez probablement augmenter le facteur de focalisation en raison de
cela. Si une nouvelle personne va rejoindre lquipe, vous devez baisser le

facteur de focalisation pour prendre en compte la formation de ce dernier,
etc.
Chaque fois que cela est possible, regardez en arrire de plusieurs sprints
et faites la moyenne des chiffres afin dobtenir des estimations plus sres.
Que faire si lquipe est compltement nouvelle et que vous navez
aucune statistique? Observez le facteur de focalisation dautres quipes
sous des conditions similaires.
Que faire si vous navez pas sautre quipe observer? Devinez le facteur
de focalisation. La bonne nouvelle est que votre intuition ne jouera que
pour le premier sprint. Aprs cela vous aurez des statistiques, vous
pourrez mesurer de faon continue et amliorer votre facteur de
focalisation et la vlocit estime.
Le facteur de focalisation que jutilise par dfaut pour les nouvelles
quipes est gnralement 70%, car cest l que la plupart de nos quipes
ont abouti au fil du temps.
Quelle technique destimation utilisons-nous?

Jai mentionn plusieurs techniques au dessus lintuition, le calcul de
vlocit bas sur la mto de la veille, et le calcul de vlocit bas sur le
nombre de jours-homme disponible et lestimation du facteur de
focalisation.
Alors quelle technique utilisons-nous?
Nous combinons gnralement toutes ces techniques un certain degr.
Cela ne prend pas longtemps.
Nous regardons le facteur de focalisation et la vlocit effective du
dernier sprint. Nous regardons le total de nos ressources disponibles pour
ce sprint et estimons le facteur de focalisation. Nous discutons de la
moindre diffrence entre ces deux facteurs de concentration et procdons
des ajustements si ncessaire.
Une fois que nous avons une liste prliminaire des histoires inclure dans
le sprint, je fais une vrification lintuition. Je demande lquipe
dignorer les chiffres pour un moment et de sentir tout simplement si cela
semble tre un morceau raisonnable se mettre sous la dent pour un
sprint. Si cela semble trop gros, nous enlevons une histoire ou deux. Et
vice-versa.

A la fin de la journe, lobjectif est simplement de dcider des histoires
inclure dans le sprint. Le facteur de focalisation, la disponibilit des
ressources, et la vlocit estime sont juste des moyens pour atteindre ce
but.
Pourquoi nous utilisons des fiches

La plupart des runions de planification de sprint se droulent en se basant
sur les histoires du backlog de produit. On les estime, on redfinit leur
priorits, on les clarifie, on les dcoupe, etc..
Comment faisons-nous a en pratique ?
Eh bien, par dfaut, les quipes avaient lhabitude dallumer le projecteur
vido, de montrer le backlog sous Excel, et un gars (typiquement le
Directeur de produit ou le Scrum master) prenait le clavier, marmonnait
en parcourant chaque histoire et invitait discuter. Comme lquipe et le
Directeur de produit discutaient les priorits et les dtails le gars au
clavier mettait jour directement lhistoire dans Excel.
Cela parat bien, non ? En fait, a ne lest pas. Gnralement a craint. Et
le pire cest quen gnral lquipe ne remarque pas que a craint jusqu
ce quarrive la fin de la runion et ralise quils nont toujours pas russi
parcourir toute la liste des histoires !
Une solution qui marche beaucoup mieux consiste crer des fiches et de
les mettre au mur (ou sur une grande table).
Il sagit dune interface utilisateur suprieure compare au projecteur, car:

Tout le monde se sent plus impliqu personnellement (plutt que
juste le gars avec le clavier)
Les gens sont debout et marchent autour => ils restent veills,
plus en alerte

Plusieurs histoires peuvent tre modifies en mme temps

Changer la priorit est triviale il faut juste dplacer les fiches
Aprs la runion, les fiches peuvent tre transfres directement
vers la salle de lquipe et tre utilises comme panneau mural
des tches (voir page 45 Comment nous faisons les backlogs de
sprint)
Vous pouvez soit les crire la main ou (comme nous le faisons

habituellement) utiliser un simple script qui gnre des fiches imprimer
directement partir du backlog de produit.
PS le script est disponible sur mon blog ici

http://blog.crisp.se/henrikkniberg.
Important: Aprs la runion de planification de sprint, notre Scrum
master met jour le backlog de produit sous Excel, en respectant le
moindre changement apport physiquement sur les fiches. Oui, il sagit
dune lgre paperasserie administrative mais nous trouvons quelle est
parfaitement acceptable en considrant quel point la runion de
planification de sprint est efficace avec les fiches.
Une remarque propos du champ Importance. Il sagit de limportance
spcifie dans le backlog du produit sous Excel au moment de
limpression. Lavoir sur la fiche rend facile le tri des fiches par ordre
dimportance (en gnral nous mettons les lments les plus importants
gauche, et les moins importants droite). Cependant, une fois que les
fiches sont au mur vous pouvez ignorer le niveau dimportance et utiliser
la place lordre dans lequel les fiches sont physiquement places. Si le
Directeur de produit permute deux lments ne perdez pas de temps
mettre jour le niveau dimportance sur le papier. Veillez seulement ce

que le niveau dimportance soit mis jour dans le backlog du produit dans
Excel lissue de la runion.
Les estimations en temps sont gnralement plus facile faire (et plus
prcis) si une histoire est dcoupe en tches. En fait nous utilisons le
terme activit car le mot tches veut dire quelque chose de
compltement diffrent en sudois :o)
Cela est aussi agrable et facile faire avec nos fiches. Vous pouvez avoir
lquipe qui se divise en binmes et qui dcoupe une histoire chacun, en
parallle.
Physiquement, nous faisons cela en ajoutant de petits post-its sous chaque
histoire, chaque post-it correspondant une tche de cette historie.
Nous ne mettons pas jour le backlog du produit dans Excel avec notre
dcoupage en tche, pour deux raisons :
Le dcoupage en tches est gnralement tout fait phmre,
i.e. les tches sont frquemment modifies et raffines durant le
sprint, de telle sorte quil serait trop harassant de garder le
backlog du produit synchronis dans Excel.
Le Directeur de produit na pas besoin dtre impliqu ce
niveau de dtail de toute faon.

De la mme faon que les fiches, les post-its des tches peuvent tre
directement rutilises dans le backlog de sprint (voir page 45 Comment
nous faisons les backlogs de sprint)
Dfinition de termin
Il est important que le Directeur de produit et lquipe saccorde sur une
dfinition claire de termin. Une histoire est-elle termine lorsque tout
le code a t archiv ? Ou est-elle termine seulement quand elle a t
dploye sur un environnement de test et vrifie par une quipe de test
dintgration ? Chaque fois que cela est possible, nous utilisons la
dfinition de termin prt dployer en production mais ds fois nous
devons nous rabattre sur la dfinition de termin dploy sur serveur de
test et prt pour le test dacceptation.
Au commencement nous utilisions des checklists dtailles pour cela.
Maintenant souvent nous disons juste une histoire est termine quand le
testeur de lquipe Scrum le dit. Cest alors au testeur de sassurer que
lintention du Directeur de produit est bien compris par lquipe, et que
llment est assez termin pour satisfaire la dfinition requise de
termin.
Nous sommes venus raliser que toutes les histoires ne peuvent pas tre
traites de la mme faon. Une histoire appele Formulaire de requte
utilisateurs sera traite trs diffremment dune histoire nomme Guide
des oprations. Dans le dernier cas, la dfinition de termin pourrait
simplement tre accept par lquipe des oprations.Cest pourquoi le
bon sens est souvent meilleur que les checklists formelles.
Si la dfinition de termin vous semble souvent confuse (ce qui tait notre
cas au dbut) vous devriez probablement avoir un champ dfinition de
termin pour chaque histoire individuelle.
Lestimation de temps avec le poker de

planning
Lestimation est une activit dquipe chaque membre de lquipe est
habituellement impliqu dans lestimation de chaque histoire. Pourquoi ?
Au moment du planning, normalement nous ne savons pas

exactement qui va implmenter quelle partie de quelle histoire.

Les histoires impliquent normalement plusieurs personnes et

plusieurs sortes dexpertise (conception dinterface utilisateur,
codage, test, etc.).
Pour pouvoir fournir une estimation, un membre dquipe a
besoin dune certaine comprhension de lhistoire. En demandant
tout le monde destimer chaque lment, nous assurons que
chaque membre dquipe comprend chacun des lments. Cela
augmente la probabilit que les membres de lquipe vont saider
mutuellement durant le sprint. Cela augmente galement la
probabilit que des questions importantes sur lhistoire sont
poses tt.
En demandant tout le monde destimer une histoire nous
dcouvrons souvent des situations o deux membres de lquipe
ont des estimations extrmement diffrentes pour la mme
histoire. Cest bien mieux de dcouvrir et discuter ce genre de
choses le plus tt possible.
Si vous demandez lquipe de fournir une estimation, normalement la

personne qui comprend le mieux lhistoire va se lancer en premier.
Malheureusement cela influence fortement les estimations de tous les
autres.
Il y a une excellente technique pour viter cela elle est appele poker de
planning (terme invent par Mike Cohn je pense).
Chaque membre de lquipe reoit un jeu de 13 cartes comme montr cidessus. Chaque fois quune histoire doit tre estime, chaque membre de
lquipe slectionne une carte qui reprsente son estimation de temps (en
points dhistoire) et la place sur la table face cache. Quand tous les
membres de lquipe ont termin, toutes les cartes sur la table sont

rvles simultanment. De cette manire chaque membre de lquipe est
forc rflchir par lui-mme au lieu de sappuyer sur lestimation de
quelquun dautre.
Sil y a un gros cart entre deux estimations, lquipe discute les
diffrences et tente dlaborer une vision commune du travail impliqu
par lhistoire. Ils peuvent mme faire une sorte de dcomposition en
tches. Aprs, lquipe estime de nouveau. Cette boucle est rpte
jusqu ce que les estimations convergent, cest--dire que toutes les
estimations soient approximativement les mmes pour cette histoire.
Il est important de rappeler aux membres de lquipe quils sont l pour
estimer la quantit de travail total pour cette histoire. Pas seulement
leur part du travail. Le testeur ne devrait pas estimer uniquement la
quantit de travail de test.
Notez que la suite des nombres nest pas linaire. Par exemple il ny a
rien entre 40 et 100. Pourquoi ?
Cest pour viter un faux sentiment de prcision pour les grandes
estimations de temps. Si une histoire est estime a environ 20 points
dhistoire, il nest pas pertinent de discuter si ce devrait tre 20 ou 18 ou
21. Tout ce que nous savons, cest que cest une grosse histoire et quelle
est difficile estimer. Donc 20 est notre estimation la louche.
Vous voulez des estimations plus dtailles ? Dcoupez lhistoire en
histoires plus petites et estimez plutt les petites histoires !
Et non, vous ne pouvez pas tricher en combinant 5 et 2 pour faire un 7.
Vous devez choisir soit 5 soit 8, il ny a pas de 7.
Quelques cartes particulires :
0 = cette histoire est dj faite or cette histoire cest
pratiquement rien, juste quelques minutes de travail .
? = Je nai aucune ide. Vraiment aucune.
Tasse de caf = Je suis trop fatigu pour penser. Faisons une
courte pause.
La clarification des histoires

Le pire cest quand un membre de lquipe dmontre firement une
nouvelle fonctionnalit la dmonstration du sprint, et que le directeur de

produit fronce les sourcils et dit eh bien cest sympa, mais ce nest pas
ce que jai demand !
Comment vous assurez vous que la comprhension dune histoire par le
directeur de produit corresponde la comprhension de lquipe ? Ou que
chaque membre de lquipe a la mme comprhension de chaque
histoire ? Eh bien vous ne pouvez pas. Mais il y a quelques techniques
simples pour identifier les incomprhensions les plus flagrantes. La plus
simple des techniques est de sassurer que tous les champs sont bien
remplis pour chaque histoire (ou plus prcisment, pour chaque histoire
qui a suffisamment dimportance pour tre considre pour ce sprint).
Exemple 1:
Lquipe et le directeur de produit sont satisfaits du plan du sprint et sont
prts terminer la runion. Le Scrum master dit attendez une seconde,
cette histoire appele Ajouter un utilisateur, elle na pas destimation.
Estimons-l ! Aprs quelques tours de poker de planning, lquipe
saccorde sur 20 points tandis que le directeur de produit clate de colre
Quest-ce que ca veut dire ? . Aprs quelques minutes de discussion
anime, il savre que lquipe navait pas compris la porte de Ajouter
un utilisateur, ils pensaient que cela signifiait une belle interface web
pour ajouter, supprimer, et chercher des utilisateurs , tandis que le
directeur de produit voulait juste dire ajouter des utilisateurs en faisant
manuellement du SQL sur la BD . Ils estiment nouveau et tombent sur
5 points.
Exemple 2:
Lquipe et le directeur de produit sont satisfaits du plan du sprint et sont
prts terminer la runion. Le Scrum master dit attendez une seconde,
cette histoire appele Ajouter un utilisateur, comment faudrait-il la
dmontrer ? . Quelques grommellements sensuivent, et aprs une
minute quelquun se lve et dit eh bien, dabord on se connecte au site
web, et puis mais le directeur de produit linterrompt en disant se
connecter au site web ?! Non, non et non, cette fonctionnalit ne devrait
pas du tout concerner le site web, ce devrait tre un bte petit morceau de
script SQL pour les administrateurs .
Le Comment dmontrer dune histoire peut (et devrait) tre trs court.
Sinon vous ne finirez pas le planning du sprint temps. Essentiellement
cest une description de haut niveau en franais de comment excuter
manuellement le scnario de test le plus typique. Faire ceci, puis cela, et
alors vrifier ceci .

Jai remarqu que cette description simple fait souvent apparatre des
incomprhensions importantes sur la porte dune histoire. Cest bien de
les dcouvrir trs tt, nest-ce pas ?
La dcomposition des histoires en plus petites

histoires
Les histoires ne devraient pas tre trop petites ou trop grosses (en termes
destimations). Si vous avez un lot dhistoires 0,5 points vous allez
probablement tre une victime du micro-management. Dun autre ct,
une histoire de 40 points implique un risque lev de finir partiellement
termine, ce qui ne produit aucune valeur pour votre entreprise et
augmente simplement le travail administratif. De plus, si votre vlocit
estime est de 70 et que vos deux histoires prioritaires sont 40 points
chacune, le planning devient quelque peu difficile. Vous devez choisir
entre le sous-engagement (cest--dire prendre juste un lment) et le surengagement (cest--dire prendre les deux lments).
Je remarque quil est presque toujours possible de couper une grosse
histoire en plusieurs histoires plus petites. Faites simplement attention que
les petites histoires continuent reprsenter des livrables avec une valeur
pour le client.
Normalement nous nous efforons davoir des histoires pesant de 2 8
jours-hommes. Notre vlocit est habituellement autour de 40-60 pour une
quipe typique, ce qui nous donne quelque chose comme environ 10
histoires par sprint. Quelquefois cela descend 5 et quelquefois cela
monte 15. Cela reste un nombre de fiches cartonnes grable.
La dcomposition des histoires en tches

Attendez une seconde, quelle est la diffrence entre tches et
histoire ? Cest une trs bonne question.
La distinction est assez simple. Les histoires sont des choses livrables qui
intressent le directeur de produit. Les tches sont des choses non
livrables, ou des choses auxquelles le directeur de produit ne sintresse
pas.
Exemple de dcomposition dune histoire en histoires plus petites :
Exemple de dcomposition dune histoire en tches :
Voici quelques observations intressantes :
Les nouvelles quipes Scrum rechignent passer du temps

dcouper lavance un lot dhistoires en tches comme cela.
Certains ressentent cela comme une approche de type cycle en V.
Pour les histoires bien comprises, cest tout aussi simple de faire
ce dcoupage lavance que de le faire plus tard.
Ce type de dcoupage rvle souvent du travail supplmentaire

qui entrane une hausse de lestimation, ce qui par consquent
donne un plan de sprint plus raliste.
Ce type de dcoupage lavance rend les mles quotidiennes

visiblement plus efficaces (voir page 74 Comment nous faisons
les mles quotidiennes ).
Mme si le dcoupage est imprcis et changera une fois le travail

dmarr, les avantages ci-dessus restent valables.
Donc nous essayons davoir une limite de temps pour la runion de
planning de sprint suffisamment importante pour faire tenir tout cela, mais
si nous manquons de temps nous laissons tomber (voir O tracer la
limite ci-dessous).
Note nous pratiquons le DDT (dveloppement dirig par les tests) ce qui
en pratique signifie que la premire tche pour presque toutes les histoires

est crire un test qui choue et la dernire tche est remaniement
(refactor) (= amliorer la lisibilit du code et supprimer les
duplications).
Le choix du lieu et lheure pour la mle

quotidienne
Un lment de sortie souvent oubli de la runion de planning du sprint
est un lieu et une heure bien dfinis pour la mle quotidienne . Sans
cet lment votre sprint va faire un mauvais dpart. La premire mle
quotidienne est essentiellement le point o tout le monde dcide o
commencer travailler.
Je prfre les runions du matin. Mais, je dois ladmettre, nous navons
pas rellement essay de faire les mles quotidiennes laprs-midi ou
mi-journe.
Inconvnient des mles de laprs-midi : quand vous venez travailler le
matin, vous devez essayer de vous rappeler ce que vous avez dit hier vos
collgues au sujet de ce que vous feriez aujourdhui.
Inconvnient des mles du matin : quand vous venez travailler le
matin, vous devez essayer de vous rappeler ce que vous avez fait hier pour
pouvoir le rapporter.
Mon point de vue est que le premier inconvnient est pire, puisque la
chose la plus importante est ce que vous allez faire, pas ce que vous avez
fait.
Notre procdure par dfaut est de choisir le moment le plus tt o
personne dans lquipe ne se plaigne. Habituellement 9:00, 9:30, ou
10:00. La chose la plus importante est une heure que tout le monde dans
lquipe accepte de bon cur.
O tracer la limite ?
OK, le temps commence manquer. Parmi toutes les choses que nous
voulons faire durant le planning de sprint, quest-ce nous laissons de ct
si le temps manque ?
Eh bien, jutilise la liste de priorits suivante :

Priorit 1 : Un but de sprint et une date de dmonstration. Cest vraiment
le minimum dont vous avez besoin pour dmarrer un sprint. Lquipe a un
but, une date de fin et ils peuvent travailler directement partir du
backlog du produit. Ca craint, bien sr, et vous devriez considrer
srieusement de prvoir une nouvelle runion de planning demain, mais si
vous devez vraiment dmarrer le sprint alors cela ira probablement. Pour
tre honnte, toutefois, je nai jamais rellement dmarr un sprint avec
aussi peu dinformations.
Priorit 2 : Liste des histoires que lquipe a acceptes pour ce sprint.
Priorit 3 : Estimations remplies pour chaque histoire du sprint.
Priorit 4 : Comment dmontrer rempli pour chaque histoire du
sprint.
Priorit 5 : Les calculs de vlocit et de ressources, pour vrifier la
vraisemblance de votre plan de sprint. Cela inclue la liste des membres de
lquipe et leurs engagements (sinon vous ne pouvez pas calculer la
vlocit).
Priorit 6 : une heure et un lieu bien dfinis pour la mle quotidienne.
Cela prend juste un moment pour dcider, mais si vous manquez de temps
le Scrum master peut simplement le dcider aprs la runion et envoyer
un mail tout le monde.
Priorit 7 : Les histoires dcoupes en tches. Ce dcoupage peut sinon
tre fait quotidiennement en conjonction avec les mles quotidiennes,
mais cela va lgrement perturber le droulement du sprint.
Les histoires techniques

Voici un point complexe : les histoires techniques. Ou encore lments
non-fonctionnels ou quoi que ce soit que vous vouliez les appeler.
Je fais rfrence aux choses qui doivent tre faites mais qui ne sont pas
livrables, pas lies directement des histoires spcifiques, et qui nont pas
de valeur directe pour le directeur de produit.
Nous les appelons histoires techniques .
Par exemple :

Installer un serveur de construction (build) en continu

o Pourquoi il faut le faire : parce que cela conomise
dnormes quantits de temps pour les dveloppeurs et
rduit le risque de problmes dintgration de type bigbang la fin dune itration.
Rdiger une vue densemble de la conception du systme
o Pourquoi il faut le faire : parce que les dveloppeurs
oublient sans arrt la conception globale, et par
consquent crivent du code incohrent. Il faut un
document qui montre une vue densemble pour garder
tout le monde synchronis sur la conception.
Remanier (refactor) la couche daccs aux donnes (DAO)
o Pourquoi il faut le faire : parce que la couche daccs est
devenue vraiment embrouille et cote du temps tout le
monde cause de la confusion et des bugs pas
ncessaires. Nettoyer le code va faire conomiser du
temps tout le monde et va amliorer la robustesse du
systme.
Mettre jour Jira (systme de suivi de bugs)
o Pourquoi il faut le faire : la version actuelle est trop
bugge et lente, mettre jour fera conomiser du temps
tout le monde.
Sagit-il dhistoires au sens habituel ? Ou bien sagit-il de tches qui ne

sont pas connectes une histoire particulire ? Qui les priorise ? Est-ce
que le directeur de produit devrait tre impliqu dans ces choses ?
Nous avons beaucoup expriment avec diffrentes manires de grer les
histoires techniques. Nous avons essay de les traiter comme des histoires
de premire classe, tout comme nimporte quelle autre. Cela nallait pas,
en effet quand le directeur de produit priorisait le backlog de produit
ctait comme comparer des pommes avec des oranges. En fait, pour des
raisons videntes, les histoires techniques recevaient souvent une faible
priorit avec des motivations du type oui les gars, je suis sr quun
serveur de construction en continu est important et tout, mais
commenons dabord par construire des fonctionnalits qui rapportent des
sous, nest-ce pas ? Ensuite vous pourrez ajouter votre petit plaisir
technique, OK ? .
Dans certains cas le directeur de produit a raison, mais souvent il a tort.
Nous avons conclus que le directeur de produit nest pas toujours qualifi
pour tablir le bon compromis. Donc voici ce que nous faisons :

1) Essayer dviter les histoires techniques. Rechercher vraiment un
moyen de transformer une histoire technique en histoire normale
avec une valeur mtier mesurable. De cette manire le directeur
de produit a de meilleures chances de faire des compromis
corrects.
2) Sil nest pas possible de transformer une histoire technique en
histoire normale, voir si le travail peut tre fait en tant que tche
dans une autre histoire. Par exemple remanier la couche daccs
aux donnes pourrait tre une tche dans lhistoire diter
lutilisateur , puisquelle implique la couche daccs.
3) Si les deux mthodes ci-dessus chouent, dfinir une histoire
technique, et maintenir une liste spare de telles histoires.
Permettre au directeur de produit de la voir mais pas de lditer.
Utiliser les paramtres facteur de focalisation et vlocit
estime pour ngocier avec le directeur de produit et obtenir un
peu de temps dans le sprint pour implmenter les histoires
techniques.
Exemple (un dialogue trs similaire celui-ci sest pass durant lun de
nos plannings de sprint).
Equipe : Nous avons des trucs techniques faire. Nous
voudrions passer 10% de notre temps a, cest--dire rduire le
facteur de focalisation de 75% 65%. Est-ce OK ?
Directeur de produit : Surement pas ! Nous navons pas le
temps !
Equipe : Eh bien, regardez le sprint dernier (toutes les ttes se
tournent vers les gribouillages de vlocit sur le tableau blanc).
Notre vlocit estime tait de 80, et notre vlocit relle tait de
30, nest-ce pas ?
Directeur de produit : Exactement ! Donc nous navons pas
de temps pour faire des trucs techniques internes ! On a besoin de
nouvelles fonctionnalits !
Equipe : Eh bien, la raison pour laquelle notre vlocit sest
avre si mauvaise tait que nous avons pass normment de
temps essayer dassembler des versions cohrentes pour le
test .
Directeur de produit : Oui, et alors ?
Equipe : Eh bien, notre vlocit va probablement continuer
tre aussi mauvaise si nous ne faisons pas quelque chose.
Directeur de produit : Oui, et alors ?
Equipe : Donc nous proposons de prendre environ 10% de ce
sprint pour mettre en place un serveur de construction en continu
et dautres choses qui vont enlever cette pine de lintgration.

Cela va probablement augmenter notre vlocit dau moins 20%

pour chaque sprint suivant, indfiniment !
Directeur de produit : Vraiment ? Alors pourquoi ne lavonsnous pas fait le sprint dernier ?
Equipe : Euh parce que vous navez pas voulu
Directeur de produit : Oh, hum, trs bien, alors on dirait que
cest une bonne ide de le faire maintenant !
Bien sr lautre option est de laisser le directeur de produit en dehors du

circuit ou de lui donner un facteur de focalisation non ngociable. Mais il
ny a aucune excuse pour ne pas essayer de dabord atteindre un
consensus.
Si le directeur de produit est un gars comptent et raisonnable (et nous
avons eu de la chance ici) je suggre de le garder aussi inform que
possible, et de le laisser dcider les priorits globales. La transparence est
lune des valeurs centrales de Scrum, nest-ce-pas ?
Systme de suivi de bug vs. backlog de

produit
Voici un point pineux. Excel est un excellent support pour le backlog de
produit. Mais vous avez tout de mme besoin dun systme de suivi de
bugs, et Excel ne fera probablement pas laffaire. Nous utilisons Jira.
Donc comment amenons-nous des entres Jira dans la runion de planning
de sprint ? Je veux dire que ca ne le ferait pas de simplement les ignorer et
de se focaliser uniquement sur les histoires.
Nous avons essay plusieurs stratgies :
1) Le directeur de produit imprime les entres Jira de plus haute
priorit, les apporte la runion de planning de sprint, et les met
sur le mur avec les autres histoires (et donc spcifie
implicitement la priorit de ces lments par rapport aux autres
histoires).
2) Le directeur de produit cre des histoires qui font rfrence aux
entres Jira. Par exemple Corriger les bugs les plus critiques sur
les rapports back office, Jira-124, Jira-126 et Jira-180 .

3) La correction de bugs est considre comme tant en dehors du
sprint, cest--dire que lquipe garde un facteur de focalisation
suffisamment faible (par exemple 50%) pour garantir quils ont
du temps pour corriger les bugs. On suppose alors que lquipe
va passer un certain temps chaque sprint corriger des bugs
enregistrs dans Jira.
4) Mettre le backlog de produit dans Jira (cest--dire enterrer
Excel). Traiter les bugs comme nimporte quelle autre histoire.
Nous navons pas rellement conclu quelle stratgie est la meilleure pour
nous ; en fait cela varie dquipe en quipe et de sprint en sprint. Jai
toutefois tendance prfrer la premire stratgie. Elle est simple et
lgante.
La runion de planning de sprint est

finalement termine !
Waouh, je naurais jamais pens que ce chapitre sur les runions de
planning de sprint serait aussi long ! Je devine que cela reflte mon
opinion que la runion de planning de sprint est la chose la plus
importante que vous faites dans Scrum. Faites beaucoup defforts pour
faire ca correctement, et le reste sera tellement plus facile.
La runion de planning de sprint est russie si tout le monde (tous les
membres de lquipe et le directeur de produit) sortent de la runion avec
le sourire, et se lvent le matin suivant avec le sourire, et font leur
premire mle quotidienne avec le sourire.
Ensuite, bien sr, toutes sortes de choses peuvent se passer horriblement
mal, mais au moins vous ne pourrez pas blmer le plan du sprint :o)
5
Comment nous communiquons sur les
sprints
Il est important de tenir au courant toute l'entreprise sur ce qui se passe.
Autrement les gens se plaindront ou, pire, feront de fausses hypothses
sur ce qui se passe.
Pour cela nous utilisons une page d'information de sprint .
Parfois nous ajoutons aussi des informations qui expliquent comment

chaque user story sera dmontre.

Juste aprs la runion de planification d'itration, le ScrumMaster cre
cette page, la dpose sur le wiki, et envoie un spam toute l'entreprise.
Nous avons aussi un tableau de bord sur notre wiki qui donne des
liens vers toutes les itrations en cours.
En plus, le ScrumMaster imprime la page d'information de sprint et

l'affiche sur le mur extrieur du bureau de l'quipe. De cette faon
n'importe qui passant par l peut y jeter un il pour savoir ce que cette
quipe est en train de faire. Comme cela indique aussi o et quand ont lieu
la mle quotidienne et la dmonstration de sprint, cette personne sait o
aller pour obtenir plus d'information.
Quand l'itration approche de la fin, le ScrumMaster rappelle tout le
monde la prochaine dmo.
COMMENT NOUS COMMUNIQUONS SUR LES SPRINTS | 53

Avec tout cela, personne n'a vraiment d'excuse pour ne pas savoir ce qui
se passe.
6
Comment nous faisons les backlogs de
sprint
Vous tes arriv jusque l ? Ouf, bon travail.
Maintenant que nous avons termin la runion de planification du sprint et
parl au monde entier de notre superbe nouveau sprint, il est temps pour le
Scrum master de crer un backlog de sprint. Cela doit tre fait aprs la
runion de planification du sprint, mais avant la premire mle
quotidienne.
Format du backlog de sprint

Nous avons essay diffrents formats pour le backlog de sprint, y compris
Jira, Excel et un tableau physique des tches sur le mur. Au dbut, nous
avons utilis Excel le plus souvent, il y a disposition du public de
nombreux modles Excel pour les backlogs de Sprint, avec gnration
automatique de burndown chart et des choses comme a. Je pourrais
discuter longtemps sur la faon dont nous avons amlior notre backlog
de Sprint sous Excel. Mais je ne le ferai pas. Je ne vais mme pas mettre
un exemple ici.
A la place je vais vous dcrire en dtail ce que nous considrons tre le
format le plus efficace pour les backlogs de sprint - un tableau des tches
sur le mur !
Trouvez un grand mur inutilis ou contenant des choses inutiles comme le
logo de la socit, des vieux diagrammes ou d'affreuses peintures.
Nettoyez le mur (demandez la permission si vous le devez). Scotchez une
grande, grande feuille de papier (au moins 2 x 2 mtres, ou 3 x 2 mtres
pour une grande quipe). Puis faites ceci :
Vous pourriez utiliser un tableau blanc bien sr. Mais ce serait un peu du
gchis. Si possible, gardez les whiteboards pour les brouillons de
conception et utilisez les murs sans whiteboards pour les tableaux des
tches.
NOTE - si vous utilisez des post-its pour les tches, n'oubliez pas de les
attacher avec du vrai scotch, ou vous retrouverez un jour tous vos post-its
en tas sur le sol.
COMMENT NOUS FAISONS LES BACKLOGS DE SPRINT | 57
Comment le tableau des tches fonctionne
Vous pourriez bien sr ajouter toute sorte de colonnes. En attente pour

les tests d'intgration par exemple. Ou Annul . Cependant avant que
vous ne compliquiez les choses, rflchissez longuement. Est-ce que cet
ajout est vraiment, vraiment ncessaire ?
J'ai trouv que la simplicit est extrmement importante pour ce genre de
choses, aussi je rajoute de la complexit que lorsque ne pas le faire
devient trop coteux.
Exemple 1 - Aprs la premire mle

quotidienne
Aprs la premire mle quotidienne, le tableau des tches devrait
ressembler a :
Comme vous pouvez le voir, trois tches ont t rserves , cest--dire

que lquipe va travailler dessus aujourdhui.
Parfois, pour de grandes quipes, une tche reste coince rserv car
personne ne se souvient qui a travaill dessus. Si cela arrive frquemment
dans une quipe elle adopte gnralement une politique dtiquetage des
tches rserves en indiquant le nom de la personne qui la rserve.
Exemple 2 aprs quelques jours

Aprs quelques jours le tableau des tches devrait ressembler a :
Comme vous pouvez le voir, nous avons termin lhistoire dposer

(cest--dire quelle a t enregistre dans le rfrentiel des sources,
teste, refactore, etc). Loutil de migration est en partie fini, lhistoire
back office login est commence, et le back office user admin nest
pas entam.
Nous avons 3 lments non planifis, comme vous pouvez le voir en bas
droite. Cest utile pour se rappeler ce que lon a fait pour la rtrospective
de sprint.
Ici cest lexemple dun vrai backlog de sprint approchant la fin du sprint.
Il devient moins ordonn au fur et mesure que le sprint progresse, mais
cest bon tant que a ne dure pas longtemps. A chaque nouveau sprint
nous crons un nouveau backlog de sprint, tout propre.
Comment le burndown chart fonctionne

Regardons de plus prs le burndown chart :
Cette courbe montre que :

Le premier jour du sprint, le 1er aot, lquipe a estim quil y
avait approximativement 70 points dhistoire de reste faire.
Cest en fait la vlocit estime du sprint entier.
Le 16 aot lquipe estime quil y a approximativement 15 points
dhistoire de reste faire. La ligne de tendance en pointills
montre quils sont sur la bonne voie, cest--dire qu ce rythme
ils auront tout fini dici la fin du sprint.
Nous excluons les weekends sur laxe des abscisses puisque le travail est
rarement fait le week-end. Nous avions lhabitude dinclure les weekends
mais cela rend la courbe un peu confuse, car elle stagne les weekends
ce qui ressemble un signal davertissement.
Les signaux davertissement du tableau des

tches
Un rapide coup dil sur le tableau des tches devrait donner tout le
monde une indication sur le bon droulement du sprint. Le Scrum master
a la responsabilit de sassurer que lquipe ragit aux signaux
davertissement comme :
H, et la traabilit ?!
La meilleure traabilit que je peux offrir dans ce modle est de prendre
une photo numrique du tableau des tches chaque jour. Si vous le devez.
Je lai fait parfois mais je nai jamais eu besoin dutiliser ces photos.
Si la traabilit est trs importante pour vous, alors peut-tre que le
tableau des tches nest pas la solution qui vous convient.
Mais je suggre dessayer destimer la valeur apporte par une traabilit
dtaille du sprint. Une fois que le sprint est fini et que le code qui marche
a t livr et que la documentation a t enregistre, est-ce que a
intresse vraiment quelquun de savoir combien dhistoires taient
termines au 5e jour du sprint ? Est-ce que a intresse vraiment
quelquun de savoir quelle tait lestimation de temps pour crire un test
qui choue pour Dposer ?
Estimations en jours vs. heures

Dans la plupart des livres et articles sur Scrum vous trouverez que les
tches sont estimes en heures, pas en jours. Nous avions lhabitude de
faire ainsi. Notre formule gnrale tait : 1 jour-homme effectif = 6
heures-homme effectives.
Maintenant nous avons arrt de faire a, au moins dans la plupart de nos
quipes, pour les raisons suivantes :
Les estimations en heures-homme sont trop fines, cela engendre
trop de petites tches de 1-2 heures et entrane par consquent le
micro-management.
Ca masque le fait que tout le monde pense en jours-homme de
toutes faons, et quon multiplie juste par 6 avant dcrire en
heures-homme. Hmmmm, cette tche devrait prendre peu
prs un jour. Oh je dois crire en heures, jcrirai 6 heures
alors .
Deux units diffrentes sment la confusion. Cette estimation
tait-elle en heures-homme ou en jours-homme ? .
Donc maintenant nous utilisons les jours-homme comme base pour toutes
nos estimations de temps (bien que nous appelons a des points
dhistoire). Notre plus petite valeur est 0.5, cest--dire que toute tche
infrieure ) 0.5 est soit supprime, soit combine avec une autre tche, ou

simplement laisse avec lestimation 0.5 (il nya pas grand mal
surestimer un peu). Elgant et simple.
7
Comment nous organisons le bureau de
lquipe
Le coin conception
Jai not que beaucoup de discussions de conception les plus intressantes
et ayant le plus de valeur prennent place spontanment en face du tableau
des tches.
Pour cette raison, nous essayons darranger cet espace en coin
conception.
Cest vraiment utile. Il ny a pas de meilleur moyen pour avoir une vue
densemble du systme quen se tenant dans le coin conception, on peut

jeter un il sur les deux murs, puis jeter un il sur lordinateur et essayer
le dernier build du systme (si vous avez assez de chance pour avoir une
intgration continue, allez voir p.100 Comment nous combinons Scrum
et XP ).
Le mur de conception est juste un grand tableau blanc contenant les
schmas et les impressions des documents de conception les plus
importants (diagrammes de squences, prototypes IHM, modles mtier,
etc).
Ci-dessus : une mle quotidienne se passant dans le coin mentionn plus

haut.
Hmmmm..... ce burndown semble trop parfait et trop droit, vous ne trouvez pas ?
Mais lquipe insiste quil est authentique :o)
COMMENT NOUS ORGANISONS LE BUREAU DE LEQUIPE | 69
Installez lquipe ensemble !

Quand on en vient lorganisation des bureaux il y a une chose qui nest
jamais assez souligne.

Pour clarifier un peu, je disais

Les gens sont rticents bouger. Au moins dans les endroits o jai
travaill. Ils nont pas envie de prendre toutes leurs affaires, dbrancher le
pc, dplacer toutes leurs poubelles jusqu un nouveau bureau, et tout
rebrancher. Plus courte est la distance, plus grande est la rticence. Allez
chef, a sert quoi de bouger juste de 5 mtres ?
Quand on construit des quipes Scrum efficaces, cependant, il ny a pas
dalternative. Mettez juste lquipe ensemble. Mme si vous devez
personnellement menacer chaque personne, transporter vous-mme
tout leur barda, et effacer leurs anciennes tches de caf. Sil ny a pas
de place pour lquipe, faites-en. Nimporte o. Mme si vous devez
placer lquipe au sous-sol. Dplacez les tables, soudoyez le responsable
des bureaux, faites ce quil faut. Mettez juste lquipe ensemble.
Une fois lquipe ensemble, les gains sont immdiats. Aprs le premier
sprint dj lquipe sera daccord quil sagissait dune bonne ide de
regrouper lquipe (dexprience personnelle, il ny a rien qui dit que
votre quipe ne sera pas trop borne pour ladmettre).
Maintenant quest-ce que ensemble signifie ? Comment doit-on
disposer les bureaux ? Bien, je nai pas dopinion tranche sur la
disposition optimale des bureaux. Et mme si jen avais, je suppose que la
plupart des quipes nont pas le luxe dtre capable de dcider exactement
comment disposer leurs bureaux. Il y a habituellement des contraintes
physiques lquipe voisine, la porte des toilettes, la grosse machine au
milieu du bureau, peu importe.
Ensemble signifie :
Audibilit : Nimporte qui dans lquipe peut discuter avec
quelquun dautre sans crier ou sortir du bureau.
Visibilit : Tout le monde peut voir tout le monde. Tout le

monde peut voir le tableau des tches. Pas forcment assez prs
pour pouvoir le lire, mais au moins le voir.
Isolation : Si toute votre quipe se lve soudainement et engage
une discussion spontane et anime sur la conception, il ny a
personne dextrieur lquipe proximit qui pourrait tre
perturb. Et vice versa.
LIsolation ne signifie pas que lquipe doit tre compltement isole.

Dans un environnement de cabines ce serait suffisant si votre quipe avait
sa propre cabine et des murs de cabine suffisamment pais pour filtrer la
plupart du bruit extrieur.
Et si vous avez une quipe distribue ? Vous navez pas de chance.
Utilisez autant de moyens techniques que vous pouvez pour minimiser les
dgts vido confrence, webcams, outils de partage de bureau, etc.
Garder le directeur de produit distance

Le directeur de produit doit tre suffisamment prs pour que lquipe
puisse aller le voir et lui demander quelque chose, et pour quil puisse se
promener autour du tableau des tches. Mais il ne doit pas sasseoir avec
lquipe. Pourquoi ? Parce quil y a des chances quil ne soit pas capable
de sempcher de rentrer dans les dtails, et lquipe ne prendra pas
forme comme il faut (cest--dire atteindre une quipe soude,
autogre, hyper productive).
Pour tre honnte, cest de la spculation. Je nai pas encore vu jusque l
un cas o le directeur de produit sassoit avec lquipe, aussi je nai
aucune raison empirique pour dire que cest une mauvaise ide. Juste
linstinct et des ou-dire dautres Scrum masters.
Garder les directeurs et les coachs distance

Cest un peu dur pour moi dcrire ce propos, puisque jai t directeur
et coach...
C'tait mon job de travailler aussi prs que possible avec lquipe. Je
montais les quipes, je naviguais entre elles, je faisais du programmation
en binme avec certaines personnes, je coachais des Scrum masters,
jorganisais les runions de planification de sprint, etc. Rtrospectivement
COMMENT NOUS ORGANISONS LE BUREAU DE LEQUIPE | 71

la plupart des gens pensent que ctait une bonne chose, car javais de
lexprience avec le dveloppement logiciel agile.
Mais, ensuite, jtais (dmarrez la musique de Dark Vador) le responsable
des dveloppements, un rle de responsable fonctionnel. Ce qui signifie
pour une quipe quelle devient automatiquement moins auto-organise.
Heck, le chef est l, il a probablement des tas davis sur ce quon devrait
faire et qui devrait le faire. Je vais le laisser parler.
Mon avis est ; si vous tes Scrum coach (et peut-tre aussi un directeur),
impliquez vous autant que possible. Mais seulement pour une priode
limite, puis effacez-vous et laissez lquipe prendre forme et sautogrer.
Surveillez lquipe de temps en temps (pas trop souvent) en assistant aux
dmos de sprint et en regardant le tableau des tches et en coutant aux
mles quotidiennes. Si vous voyez des points amliorer, prenez le
Scrum master part et conseillez-le. Pas devant lquipe. Une autre
bonne ide est dassister aux rtrospectives de sprint (voir p.82
Comment nous faisons les rtrospectives de sprint), Si votre quipe
vous fait confiance, ne laissez pas votre prsence les intimider.
Pour que les quipes Scrum fonctionnent bien, assurez-vous quils ont
tout ce quil faut, puis restez lcart ( part pendant les dmos de sprint).
.
8
Comment nous faisons les mles
quotidiennes
Nos mles quotidiennes suivent peu prs le livre. Elles commencent
exactement lheure, chaque jour la mme place. Au dbut nous allions
dans une pice spare pour faire le sprint planning ( lpoque o nous
utilisions des backlogs de sprint lectroniques), mais maintenant nous
faisons les mles quotidiennes dans le bureau de lquipe pile en face du
tableau des tches. Il ny a rien de mieux.
Nous faisons les mles en nous tenant debout, ce qui diminue le risque
de dpasser les 15 minutes.
Comment nous mettons jour le tableau des

tches
Nous mettons jour le tableau des tches pendant la mle quotidienne.
Pendant que chaque personne dcrit ce quelle a fait hier et ce quelle va
faire aujourdhui, elle dplace les post-its sur le tableau des tches. Quand
elle dcrit une tche non planifie, elle colle un post-it pour a. Quand la
personne met jour son estimation de temps, elle crit la nouvelle
estimation sur le post-it et raye lancienne valeur. Parfois le Scrum Master
soccupe des post-its pendant que les personnes parlent.
Certaines quipes adoptent comme politique de mettre jour le tableau

des tches avant chaque mle. Cela fonctionne aussi. Choisissez juste
une politique est tenez-vous y.

Indpendamment du format de votre backlog de sprint, essayez
dimpliquer toute lquipe en gardant le backlog de sprint jour. Nous
avons essay des sprints o le Scrum Master est le seul maintenir le
backlog de sprint et o il doit faire le tour chaque jour et demander aux
gens leurs estimations de reste faire. Les inconvnients de cette
mthode:
Le Scrum master passe trop de temps soccuper des tches
administratives, au lieu de supporter lquipe et denlever des
obstacles.
Les membres de lquipe ne sont pas au courant du statut du
sprint, puisquils nont pas besoin de prter attention au backlog
de sprint. Ce manque de feedback rduit lagilit globale et la
concentration de lquipe.
Si le backlog de sprint est bien conu il devrait tre aussi facile pour
chaque membre de le mettre jour lui-mme.
Immdiatement aprs la mle quotidienne, quelquun additionne toutes
les estimations de temps (en ignorant celles de la colonne termin bien
sr) et marque un nouveau point sur la courbe du reste faire du sprint.
Traiter avec les retardataires

Certaines quipes ont un pot pour les pices et billets. Quand vous tes en
retard, mme si cest juste une minute, vous ajoutez un montant fixe au
pot. Aucune question nest pose. Mme si vous appelez avant la runion
pour prvenir que vous serez en retard, vous devrez quand mme payer.
Vous chappez la sentence seulement si vous avez une bonne excuse
comme un rendez-vous chez le mdecin ou votre propre mariage ou
quelque chose dans le genre.
Largent dans le pot est utilis pour les vnements collectifs. Pour
acheter des hamburgers quand nous passons des nuits jouer par exemple
:o)
Ca marche bien. Mais cest ncessaire seulement pour les quipes o les
gens sont souvent en retard. Certaines quipes nont pas besoin de ce type
de pratique.
COMMENT NOUS FAISONS LES MELEES QUOTIDIENNES | 75
Traiter avec je ne sais pas quoi faire

aujourdhui
Ce nest pas rare pour quelquun de dire Hier jai fait bla bla bla, mais
aujourdhui je nai pas la moindre ide de ce que je peux raliser (h ce
dernier vers rime). Maintenant quoi ?
Disons que Joe et Lisa sont ceux qui ne savent pas quoi faire aujourdhui.
Si je suis Scrum master je passe et laisse la personne suivante parler, mais
je note qui na rien faire. Aprs que tout le monde ait parl, je repasse
sur le tableau des tches avec toute lquipe, de haut en bas, je vrifie que
tout est synchro, que tout le monde sait ce que chaque lment signifie,
etc. Jinvite les gens rajouter des post-its. Puis je reviens vers ceux qui
ne savaient pas quoi faire maintenant que nous avons pass en revue le
tableau des tches, avez-vous une ide de ce que vous pourriez faire
aujourdhui? Avec un peu de chance ils ont une ide.
Sinon, je considre sil ny a pas une opportunit de programmation en
binme ici. Disons que Niklas est en train dimplmenter lIHM dadmin
du back-office aujourdhui. Dans ce cas je suggre poliment que peut-tre
Joe ou Lisa pourrait programmer en binme avec Niklas sur ce sujet. Ca
fonctionne en gnral.
Et si a ne fonctionne pas, voici lastuce suivante.
Scrum master : OK, qui veut nous montrer la version beta de
lapplication ? (en supposant que cest le but de litration)
Lquipe : silence confus
Scrum master : Nous ne sommes pas prts ?
Lquipe: hmm... non
Scrum master : Ah bon. Pourquoi ? Quest-ce quil reste faire ?
Lquipe : Ben nous navons mme pas de serveur de test pour la
lancer, et le script de build est cass.
Scrum master : Aha. (ajoutez deux post-its sur le mur des tches).
Joe et Lisa, comment pouvez-vous nous aider aujourdhui ?
Joe : Hmm.... au hasard je vais essayer de trouver un serveur de test
quelque part .
Lisa : ... et je vais essayer de rparer ce script de build .
Si vous avez de la chance, quelquun va effectivement faire la dmo de la
version beta que vous avez demande. Super ! Vous avez atteint le but de
votre sprint. Mais que faire si vous tes au milieu du sprint ? Facile.
Flicitez lquipe pour le travail accompli, prenez une ou deux histoires

de la section venir en bas droite du tableau des tches, et dplacezles vers la colonne non rserv . Puis refaites la mle quotidienne.
Avertissez le directeur de produit que vous avez ajout des lments au
sprint.
Mais que faire si vous navez atteint lobjectif du sprint et que Joe et Lista
continuent de refuser de se rendre utile. Je considre habituellement lune
des stratgies suivantes (aucune delle nest lgante, mais il sagit dun
dernier recours) :
La honte : Bien si tu nas aucune ide de comment aider

lquipe, je suggre que tu rentres chez toi, ou que tu lises un
bouquin ou quelque chose dautre. Ou assied-toi jusqu ce
quelquun tappelle pour laider.
Vieille cole : Assignez leur simplement une tche.
Pression collective : Dtes prenez tout votre temps Joe et Lisa,
nous resterons l jusque vous trouviez quelque chose faire qui
peut nous aider atteindre lobjectif
Servitude : Dtes Bien, vous pouvez aider lquipe
indirectement en tant les majordomes aujourdhui. Faites le caf,
donnez des massages, nettoyez les poubelles, prparez le
djeuner, et tout ce que nous pourrions demander durant la
journe. Vous pourriez tre surpris par la vitesse laquelle Joe
et Lisa russissent trouver des tches techniques utiles :o)
Si une personne vous force frquemment aller si loin, vous devriez

probablement prendre cette personne part et faire du coaching pouss. Si
le problme persiste, vous devez valuer si cette personne est importante
pour votre quipe ou pas.
Si elle nest pas importante, essayez de la dgager de votre quipe.
Si elle est importante, alors essayez de la mettre en binme avec
quelquun qui sera son berger . Joe est peut-tre un bon dveloppeur ou
architecte, cest juste quil prfre vraiment que quelquun dautre lui dise
quoi faire. Bien. Donnez Niklas la responsabilit dtre le berger
permanent de Joe. Ou prenez cette responsabilit vous-mme. Si Joe est
assez important pour votre quipe leffort sera moindre. Nous avons eu
des cas comme a et a marchait plus ou moins bien.
9
Comment nous faisons les dmos de
sprint
La dmo de sprint (ou revue de sprint comme certains lappellent) est une
partie importante de Scrum que les gens ont tendance sous-estimer.
Oh devons-nous vraiment faire cette dmo ? Il ny vraiment pas grandchose damusant montrer !
Nous navons pas le temps de prparer une &%$# de dmo!
Je nai pas le temps dassister aux dmos des autres quipes !
Pourquoi nous insistons pour que tous les

sprints finissent par une dmo
Une dmo de sprint bien faite, bien que a puisse sembler peu marquant, a
un effet profond.
Lquipe se voit attribuer le mrite pour le travail accompli. Ils se
sentent bien.
Les autres personnes dcouvrent ce que lquipe fait.
La dmo donne un retour vital de la part des intervenants.
Les dmos sont (ou devraient) tre un vnement social o les
diffrentes quipes peuvent interagir entre elles et discuter de leur
travail. Cela a de la valeur.
Faire une dmo force lquipe terminer leur travail et le livrer
(mme si cest seulement pour environnement de test). Sans
dmo, nous garderions une norme pile de choses termine
99%. Avec les dmos nous avons peut-tre moins dlments
termins, mais ils sont rellement termins, ce qui est (dans notre
cas) une bien meilleure chose que davoir une pile entire de
tches qui sont peu prs termins et qui pollueront le prochain
sprint.
Si lquipe est plus ou moins oblige de faire une dmo, si elle na pas
quelque chose qui fonctionne vraiment, la dmo sera embarrassante.

Lquipe bgaiera et hsitera pendant la dmo et les applaudissements ne
seront qu moiti sincres. Les gens se sentiront dsols pour lquipe, et
seront peut-tre irrit davoir gch du temps pour assister une dmo
aussi nulle.
Ca blesse. Mais leffet est comme une mdecine amre. Le prochain
sprint, lquipe essaiera davoir des choses vraiment termines ! Ils se
diront que bien, peut-tre nous ne pouvons montrer que 2 choses au
prochain sprint au lieu de 5, mais merde cette fois a MARCHERA ! .
Lquipe sait quelle aura faire une dmo, peu importe quoi, ce qui
augmente les chances quil y ait quelque chose dutile montrer. Jai vu
arriver cela plusieurs fois.
Checklist pour les dmos de sprint
Assurez-vous de prsenter clairement lobjectif du sprint. Sil y a

des personnes la dmo qui ne connaissent pas du tout votre
produit, prenez quelques minutes pour le prsenter.
Ne dpensez pas trop de temps prparer la dmo, surtout pas
pour une dmo tape--lil. Ignorez ce qui ne marche pas et
concentrez vous sur la dmonstration du code qui marche.
Gardez un rythme lev, autrement dit essayez de prparer une
dmo rythme plutt quune jolie dmo.
Gardez la dmo un niveau mtier, oubliez les dtails techniques.
Concentrez-vous sur ce que nous avons fait plutt que sur
comment nous lavons fait .
Si possible, laissez laudience essayer elle-mme le produit.
Ne montrez pas les tas de corrections de bugs mineurs et de
fonctionnalits insignifiantes. Mentionnez-les mais ne les
montrez pas, car a prend trop de temps et a carte lattention
des histoires plus importantes.
Soccuper des choses indmontrables

Un membre de lquipe : Je ne vais pas prsenter cet lment, parce
que ce nest pas dmontrable. Lhistoire est Amliorer la monte en
charge pour que le systme puisse supporter 10000 utilisateurs
simultanment. Je ne peux tout de mme pas inviter 10000 utilisateurs
la dmo ?
Scrum master : Cet lment est-il termin ?
Membre de lquipe. Oui, bien sr .
Scrum master: Comment le sais-tu ?
COMMENT NOUS FAISONS LES DEMOS DE SPRINTS | 79

Membre de lquipe : Jai install le systme sur un environnement de
tests de performance, jai dmarr 8 serveurs de charge et jai stress le
systme avec des requtes simultanes .
Scrum master: Mais as-tu une indication comme quoi le systme peut
supporter 10000 utilisateurs ? .
Membre de lquipe : Oui. Les machines de test sont pourries,
cependant elles ont support 50000 requtes simultanes pendant mon
test .
Scrum master: Comment le sais-tu ?
Membre de lquipe (frustr): Ben jai ce rapport ! Vous pouvez voir
par vous-mme, il montre comment le test tait configur et combien de
requtes ont t lances !
Scrum master: Excellent ! Alors voil ta dmo . Montre juste le
rapport et fais le passer dans laudience. Mieux que rien, non ? .
Membre de lquipe : Ah, cest suffisant ? Mais cest moche, il
faudrait le rendre plus prsentable..
Scrum master: OK, mais ny passe pas trop de temps. Ca na pas besoin
dtre joli, juste informatif.
10
Comment nous faisons les
rtrospectives de sprint
Pourquoi nous insistons pour que toutes les
quipes fassent des rtrospectives
La chose la plus importante propos des rtrospectives est de sassurer
quelles ont lieu.
Pour certaines raisons, les quipes ne semblent pas toujours enclines
faire des rtrospectives. Si on ne les aiguille pas dlicatement, la plupart
des quipes laissent tomber la rtrospective et passent directement au
sprint suivant. Il sagit peut-tre dun truc culturel en Sude, pas sr.
Cependant, tout le monde semble daccord, les rtrospectives sont
extrmement utiles. En fait, je dirais que la rtrospective est la seconde
partie la plus importante de Scrum (la premire tant la runion de
planification de sprint) parce que cest la meilleure chance de vous
amliorer !
Bien sr, vous navez pas besoin dune runion de rtrospective pour
avoir de bonnes ides, vous pouvez le faire dans votre baignoire la
maison ! Mais lquipe va-t-elle accepter votre ide ? Peut-tre, mais la
probabilit davoir ladhsion de lquipe est beaucoup plus importante si
lide vient de lquipe , cest--dire si elle vient pendant la
rtrospective quand tout le monde est autoris contribuer et discuter
des ides.
Sans les rtrospectives vous trouverez des quipes qui reproduiront les
mmes erreurs, encore et encore.
Comment nous organisons les rtrospectives

Le format gnral varie un peu, mais gnralement nous faisons quelque
chose comme a :
Nous allouons 1 3 heures selon le volume de discussions qui est

anticip.
Participants : le directeur de produit, lquipe complte, et moimme.
Nous allons dans une pice ferme, un coin avec un canap
confortable, un patio, ou une place du mme style. Du moment
que nous pouvons discuter sans tre drangs.
Nous ne faisons pas les rtrospectives dans le bureau de lquipe,
car lattention des membres a tendance se relcher.
Quelquun est dsign comme secrtaire.
Le Scrum master montre le sprint backlog et, avec laide de
lquipe, rsume le sprint. Les vnements et dcisions
importantes, etc.
Nous faisons des tours de table. Chaque personne a une chance
de dire, sans tre interrompu, ce quelle pense tre bien, ce
quelle pense qui peut tre mieux, et ce quelle pense qui devrait
tre diffrent pour le prochain sprint.
Nous comparons la vlocit estime et la vlocit effective. Sil y
a une grosse diffrence nous essayons danalyser pourquoi.
Quand le temps est presque coul le Scrum master essaie de
rsumer les suggestions concrtes pour amliorer le prochain
sprint.
Nos rtrospectives ne sont gnralement pas trs structures. Le thme

implicite est toujours le mme : que pouvons-nous amliorer au
prochain sprint .
Ceci est un exemple de tableau blanc lors dune rcente rtrospective :
COMMENT NOUS FAISONS LES RETROSPECTIVES DE SPRINTS | 83
Trois colonnes :
Bien : Si nous pouvions refaire le mme sprint, nous ferions ces
choses exactement pareil.
Peut mieux faire : Si nous pouvions refaire le mme sprint, nous
ferions ces choses diffremment.
Amliorations : Ides concrtes pour samliorer dans le futur.
Les colonnes 1 et 2 concernent le pass, tandis que la colonne 3 concerne
le futur.
Aprs que les membres de lquipe aient dball tous ces post-its, ils
utilisent le vote par points pour dterminer quelles amliorations
prendre en compte au prochain sprint. Chaque membre de lquipe
dispose de 3 aimants et sont invits voter pour les amliorations quils
aimeraient voir pris en compte en priorit pendant le prochain sprint.
Chaque membre peut distribuer ces aimants comme il veut, il peut mme
placer les 3 sur le mme post-it.
En se basant l-dessus ils slectionnent les 5 amliorations faire en
priorit, et les suivront la prochaine rtrospective.
Cest important de ne pas tre trop ambitieux ici. Concentrez-vous sur un
petit nombre damliorations par sprint.
La diffusion des enseignements tirs entre

quipes
Les informations tires dune rtrospective de sprint ont gnralement
beaucoup de valeur. Est-ce que cette quipe a du mal se concentrer

parce que le directeur des ventes kidnappe les programmeurs en tant
quexperts techniques dans les runions de vente. ? Cest une
information importante. Peut-tre que les autres quipes ont le mme
problme ? Devrions-nous mieux duquer la direction propos de nos
produits, afin quils puissent faire eux-mmes le support des ventes ?
Une rtrospective ne se limite pas comment cette quipe peut faire
mieux le prochain sprint, a a des implications plus larges.
Notre stratgie pour apprhender a est trs simple. Une personne (dans
ce cas, moi) assiste toutes les rtrospectives de sprint et agit comme un
pont de connaissance. Assez simple.
Une alternative serait que chaque quipe Scrum publie un rapport de
rtrospective de sprint. Nous avons essay a mais nous trouvons que peu
de gens lisent les rapports, et encore moins sy conforment. Cest
pourquoi nous faisons a de manire simple la place.
Les rgles importantes pour la personne qui fait le pont de
connaissances :
Il doit savoir couter.
Si la rtrospective est trop silencieuse, il doit tre prt poser des
questions simples mais cibles afin de stimuler les discussions au
sein du groupe. Par exemple si vous pouviez remonter le temps
et refaire le mme sprint depuis le 1er jour, quest-ce que vous
changeriez ? .
Il devrait prendre le temps daller aux rtrospectives de toutes les
quipes.
Il devrait avoir une certaine autorit, de faon mettre en uvre
les suggestions damlioration qui ne sont pas sous le contrle de
lquipe.
Cela marche assez bien mais il peut y avoir dautres approches qui
fonctionnent encore mieux. Dans ce cas, clairez-moi.
Changer ou ne pas changer

Disons que lquipe conclut que nous ne communiquons pas assez dans
lquipe, nous nous marchons dessus et nous mettons la pagaille dans la
conception des autres.
Que feriez-vous pour y remdier ? Introduire des runions quotidiennes
sur la conception ? Introduire de nouveaux outils pour faciliter la
COMMENT NOUS FAISONS LES RETROSPECTIVES DE SPRINTS | 85

communication ? Ajouter plus de pages dans le wiki ? Cest bien, peuttre. Mais encore une fois, peut-tre pas.
Nous avons observ que, dans beaucoup de cas, identifier clairement un
problme est suffisant pour quil se rsolve tout seul au prochain sprint.
Surtout si vous accrochez la rtrospective de sprint sur le mur du bureau
de lquipe (ce que nous oublions toujours de faire, honte nous !).
Chaque chose que vous introduisez a un cot, aussi avant dintroduire des
changements, envisagez de ne rien faire du tout et esprez que le
problme disparatra (ou rduira) automatiquement.
Lexemple ci-dessus ( nous ne communiquons pas assez dans
lquipe ) est un exemple typique o la meilleure solution est de ne
rien faire.
Si vous introduisez un nouveau changement chaque fois quelquun se
plaindra, les gens seront rticents remonter les problmes mineurs, ce
qui serait terrible.
Exemples de choses qui peuvent remonter

pendant les rtrospectives
Voici quelques exemples typiques de ce qui peut arriver pendant un sprint
planning, et les actions typiques.
Nous devrions passer plus de temps dcomposer

les histoires en sous-lments et tches
Cest assez courant. Chaque jour lors de la mle quotidienne, des
membres de lquipe se retrouvent dire Je ne sais pas trop quoi faire
aujourdhui . Alors aprs chaque mle quotidienne vous passez du
temps trouver des tches concrtes. Cest gnralement plus efficace de
faire a en amont.
Actions typiques : aucune. Lquipe rglera a probablement dellemme la prochaine runion de planification de sprint. Si cela se rpte,
prvoyez plus de temps pour le sprint planning.
Trop de drangements extrieurs

Actions typiques :
demandez lquipe de rduire leur facteur de focalisation pour le
prochain sprint, afin davoir un plan plus raliste
demandez lquipe de bien noter les drangements pendant le prochain
sprint. Qui les drange, combien de temps. Ca aidera rsoudre le
problme plus tard.
demandez lquipe dessayer de rediriger tous les drangements vers le
Scrum master ou le directeur de produit
demandez lquipe de dsigner une personne comme gardien , tous
les drangements sont redirigs vers lui, ainsi le reste de lquipe peut se
concentrer. Ce peut tre le Scrum master ou quelquun tour de rle.
Nous nous sommes trop engags et nous navons

termin que la moiti du travail
Actions typiques : aucune. Lquipe ne sengagera probablement pas trop
au prochain sprint. Ou du moins pas autant que cette fois.
Notre bureau est trop bruyant et bordlique

Actions typiques :
essayez de crer un meilleur environnement, ou dmnagez

lquipe. Louez une chambre dhtel. Ce que vous voulez. Voir
page 68 Comment nous organisons le bureau de lquipe ).
Si ce nest pas possible, dtes lquipe de rduire leur facteur de

focalisation, et indiquez clairement que cest cause du bruit et
du dsordre. En esprant que le directeur de produit commencera
harceler la direction ce sujet.
Heureusement je nai jamais eu menacer de dmnager lquipe. Mais je
le ferai si je le devais :o)
11
Relcher le rythme entre les sprints
Dans la vraie vie, vous ne pouvez pas sprinter tout le temps. Vous avez
besoin de vous reposer entre deux sprints. Si vous sprintez tout le temps,
vous tes en effet juste en train de faire un jogging.
Cest la mme chose avec Scrum et le dveloppement logiciel en gnral.
Les sprints sont plutt intenses. En tant que dveloppeur vous ne vous
relchez jamais, chaque jour vous devez assister cette fichue runion et
dire tout le monde ce que vous avez fait la veille. Peu auraient tendance
dire Jai pass la majeure partie de la journe mon bureau surfer sur
des blogs et siroter du capuccino.
En plus de la vraie pause elle-mme, il y a une autre bonne raison davoir
un relchement entre les sprints. Aprs la dmo du sprint et la
rtrospective, la fois lquipe et le directeur de produit seront saturs
dinformations et dides digrer. Sils se remettent immdiatement
courir et commencer planifier le sprint suivant, il est peu probable que
quiconque ait loccasion de digrer une information ou des leons
apprises, que le directeur de produit naura pas le temps dajuster ses
priorits aprs la dmo de sprint, etc.
Mauvais :
Nous essayons dinsrer du relchement avant de commencer un nouveau

sprint (plus spcifiquement, la dure aprs la rtrospective de sprint et
avant la prochaine runion de planification de sprint).

Tout au moins, nous essayons de faire en sorte que la rtrospective de
sprint et la runion de planification du sprint venir narrivent pas le
mme jour. Tout le monde devrait avoir au moins une bonne nuit de
sommeil sans sprint avant de dmarrer un nouveau sprint.
Mieux :
Encore mieux :
Une faon de faire cela sont les jours labo (ou quoique vous choisissiez
de les appeler). Ce sont des journes o les dveloppeurs sont autoriss
faire essentiellement ce quils veulent (OK, je le reconnais, inspir par
Google). Par exemple, tudier fond les derniers outils et APIs, suivre
une formation, discuter de trucs dinformatique avec les collgues, coder
un projet perso, etc.
Notre but est davoir un jour labo entre chaque sprint. De cette faon vous
avez naturellement une pause entre les sprints, et vous avez une quipe de
dveloppement qui a de relles chances de garder jour leurs
connaissances. De plus, cest un avantage plutt attractif
pour
lemployeur.
Meilleur?
Actuellement nous avons des jours labo une fois par mois. Le premier
vendredi de chaque mois pour tre prcis. Pourquoi pas entre les sprints
la place ? Eh bien, parce que jai pens que ctait important que toute
lentreprise soit en journe labo en mme temps. Autrement les gens ont
tendance ne pas le faire srieusement. Et comme nous (jusque l)
RELACHER LE RYTHME ENTRE LES SPRINTS |89

navons pas align les sprints travers tous les produits, jai du choisir
la place une journe labo indpendamment des sprints.
On pourrait un jour tenter de synchroniser les sprints travers tous les
produits (i.e. mme dmarrage et fin de sprint pour tous les produits et les
quipes). Dans ce cas nous mettrons dfinitivement un jour labo entre
chaque sprint.
12
Comment nous faisons la planification
de release et les contrats au forfait
Ds fois, on a besoin de planifier lavance plus dun sprint la fois.
Typiquement dans un contexte de contrat au forfait o on doit planifier en
avance, ou sinon on risque de signer pour quelque chose quon ne peut
dlivrer temps.
Typiquement, la planification de release est pour nous une tentative de
rpondre la question quand, au plus tard, serons-nous en mesure de
dlivrer la version 1.0 de ce nouveau systme ? .
Si vous voulez vraiment apprendre la planification de release je vous
suggre de sauter ce chapitre et la place dacheter le livre de Mike Cohn
Agile estimating and planning . Jaurais voulu avoir lu ce livre plus tt
(Je lai lu aprs que nous soyons arrivs comprendre par nous
mmes). Ma version de la planification de release est assez simpliste
mais elle devrait tre un bon point de dpart.
Dfinir vos seuils dacceptation

En plus du backlog de produit habituel, le directeur de produit dfinit une
liste des seuils dacceptation qui est une classification simple de ce que
signifient les niveaux dimportance utiliss dans le backlog de produit par
rapport aux aspects contractuels.
Voici un exemple de rgles de seuils dacceptation :
Tous les lments avec une importance >= 100 doivent tre inclus
dans la version 1.0, ou sinon nous serions condamns payer des
pnalits de retard.
Tous les lments avec une importance de 50-99 devraient tre
inclus dans la version 1.0, mais nous devrions tre en mesure de
nous en sortir en les incluant dans une release disponible court
terme.

Les lments avec une importance de 25-49 sont requis mais
peuvent tre faits dans une version future 1.1.
Les lments avec une importance <25 sont spculations et
pourraient ne jamais tre requis.
Et voici un exemple de backlog de produit, avec un code couleur bas sur
les rgles ci-dessus.
Importance
130
120
115
110
100
95
80
70
60
40
35
10
10
Nom
banane
pomme
orange
goyave
poire
raisin
cacahute
beignet
oignon
pamplemousse
papaye
myrtille
pche
Rouge = doit tre inclus dans la version 1.0 (banane poire)

Jaune = devrait tre inclus dans la version 1.0 (raisin oignon)
Vert = peut tre fait plus tard (pamplemousse pche)
Donc si nous livrons tous les lments de banane oignon temps nous
sommes sains et saufs. Si le temps se met manquer nous devrions nous
en sortir en cartant raisin, cacahute, beignet ou oignon. Tout ce qui est
en dessous doignon est du bonus.
Estimation en temps des lments les plus

importants
Afin de faire la planification de releases, le directeur de produit a besoin
destimations, au moins pour toutes les histoires qui sont incluses dans le
contrat. Tout comme la planification de sprint, il sagit dun effort mutuel
entre le directeur de produit et lquipe lquipe estime, le directeur de
produit dcrit les lments et rpond aux questions.
PLANIFICATION DE RELEASE ET CONTRATS AU FORFAIT |93

Une estimation en temps a de la valeur si elle se rvle tre proche de la
ralit, moins de valeur si elle se rvle tre cot, disons, de 30%, et
compltement sans valeur si elle na aucune relation avec la ralit.
Voici mon interprtation de la valeur dune estimation en temps en
relation avec ceux qui la calculent et combien de temps ils y passent
dessus.
Tout cela est juste une faon verbeuse de dire :

Laissez lquipe faire les estimations.
Ne leur faites pas passer trop de temps dessus.
Assurez-vous quils comprennent que les estimations en temps
sont des estimations approximatives, non des engagements.
Habituellement le directeur de produit rassemble toute lquipe dans une
pice, fournit quelques boissons, et lui explique que le but de cette
runion est destimer en temps les 20 premires (ou autre) histoires du
backlog de produit. Il aborde chaque histoire une fois, puis il laisse
lquipe retourner travailler. Le directeur de produit reste dans la pice
pour rpondre aux questions et clarifier le primtre de chaque histoire si
ncessaire. Juste comme pendant la planification du sprint, le champ
comment dmontrer est un moyen trs utile pour rduire le risque de
malentendus.
Cette runion doit tre strictement borne en temps, sans quoi les quipes
auraient tendance passer trop de temps estimer trop peu dhistoires.
Si le directeur de produit veut passer plus temps sur cela, il programme
simplement une autre runion plus tard. Lquipe doit sassurer que
limpact de ces runions sur leurs sprints en cours est clairement visible
pour le directeur produit, de telle sorte quil comprenne que leurs
estimations en temps ne sont pas gratis.

Voici un exemple qui montre quoi les estimations en temps pourraient
ressembler (en points dhistoire) :
Imp
130
120
115
110
100
95
80
70
60
40
35
10
10
Nom
Estimation
banane
12
pomme
9
orange
20
goyave
8
poire
20
raisin
12
cacahute
10
beignet
8
oignon
10
pamplemousse
14
papaye
4
myrtille
pche
Estimer la vlocit
OK, alors maintenant nous avons des sortes destimations brutes pour les
histoires les plus importantes. La prochaine tape est destimer notre
vlocit moyenne par sprint.
Cela veut dire que nous avons besoin de dfinir notre facteur de
focalisation. Voir page XXX Comment lquipe choisit les histoires
inclure dans le sprint ? .
Le facteur de focalisation revient fondamentalement se demander
quelle est la part du temps pass par lquipe consacre aux histoires
adoptes en cours ? . Ce nest jamais 100% car les quipes perdent du
temps en faisant des choses non prvues, en changeant de contexte, en
aidant les autres quipes, en lisant leurs emails, en rparant les problmes
dordinateur, en discutant politique dans la cuisine, etc.
Disons que nous dterminons un facteur de focalisation de 50% pour
lquipe (trs bas, normalement on tourne autour de 70%). Et disons que
notre sprint dure 3 semaines (15 jours) et que la taille de lquipe et 6.
PLANIFICATION DE RELEASE ET CONTRATS AU FORFAIT |95

Chaque sprint fait alors 90 jours*homme, mais produira seulement 45
jours*homme dhistoires ( cause du facteur de focalisation de 50%).
Notre vlocit estime est donc de 45 points dhistoire.
Si chaque histoire avait une estimation en temps de 5 jours (ce qui nest
pas le cas) alors cette quipe avalerait approximativement 9 histoires par
sprint.
Tout mettre ensemble dans un plan de release

Maintenant que nous avons des estimations en temps et une vlocit (45)
nous pouvons facilement dcouper le backlog de produit en plusieurs
sprints :
Imp
130
120
115
110
100
95
80
70
60
40
35
10
10
Nom
Estimation
Sprint 1
banane
12
pomme
9
orange
20
Sprint 2
goyave
8
poire
20
raisin
12
Sprint 3
cacahute
10
beignet
8
oignon
10
pamplemousse
14
Sprint 4
papaye
4
myrtille
pche
Chaque sprint contient autant dhistoires que possible dans la limite de la

vlocit estime de 45.
Maintenant on peut voir que nous aurons probablement besoin de 3
sprints pour finir tous les doit tre inclus et les devrait tre inclus .

3 sprints = 9 semaines calendaires = 2 mois calendaires. Maintenant est-ce
vraiment la date de livraison promise au client ? Cela dpend entirement
de la nature du contrat ; quel point le primtre est-il fix, etc.
Gnralement nous ajoutons une rserve significative pour nous protger
contre les mauvaises estimations en temps, les problmes imprvus, les
fonctionnalits inattendues, etc. Donc dans ce cas nous pouvons nous
mettre daccord sur une livraison dans 3 mois, ce qui nous donne 1 mois
de rserve .
Ce qui est bien cest que nous pouvons dmontrer quelque chose
dutilisable au client toutes les 3 semaines et linviter modifier ses
exigences au fur mesure que nous avanons (cela dpend bien sr du
type de contrat).
Adapter le plan de release

La ralit ne sadaptera pas un plan, cest plutt le cas inverse qui se
passe.
Aprs chaque sprint, nous regardons la vlocit effective pour ce sprint. Si
la vlocit effective tait trs diffrente de la vlocit estime, nous
revoyons la vlocit estime pour les futurs sprints et mettons jour le
plan de release. Si cela devait nous mettre en situation difficile, le
directeur de produit pourrait commencer soit ngocier avec le client, soit
voir comment il peut rduire le primtre sans rompre le contrat. Ou
peut-tre lui et lquipe trouvent le moyen daugmenter la vlocit ou le
facteur de focalisation en supprimant des obstacles srieux qui ont t
identifis durant le sprint.
Le directeur de produit pourrait appeler le client et dire Bonjour, nous
sommes un peu en retard mais je crois que nous pouvons livrer temps si
nous enlevons la fonctionnalit Pacman embarqu qui prend beaucoup
de temps dvelopper. Nous pourrons linclure dans une version qui
sortira 3 semaines aprs la premire release si vous le souhaitez .
Ce nest peut-tre pas une bonne nouvelle pour le client, mais au moins
nous sommes honntes et nous laissons le choix au client tt dans le projet
doit-on livrer les choses les plus importantes temps ou doit-on tout
livrer aprs la date prvue ? Ce nest pas un choix si difficile en
gnral :o)
13
Comment nous combinons Scrum avec
XP
Dire que Scrum et XP (eXtreme Programming) peuvent tre combins
avec profit nest pas une dclaration rellement sujette controverse. La
plupart des choses que je vois sur le net sont en faveur de cette hypothse,
donc je ne vais pas passer de temps argumenter pourquoi.
Tout de mme, je vais mentionner une chose. Scrum se concentre sur le
management et les pratiques dorganisation tandis que XP se concentre
surtout sur les pratiques de programmation concrtes. Cest pour a quils
fonctionnent bien ensemble ils concernent diffrentes zones et sont
complmentaires.
Je dclare donc formellement que jajoute ma voix aux preuves
empiriques dj existantes que Scrum et XP peuvent tre combins de
manire productive !
Je vais souligner certaines des pratiques XP les plus intressantes, et
comment elles sappliquent notre travail de tous les jours. Toutes nos
quipes nont pas russi adopter toutes les pratiques, mais au total nous
avons expriment la plupart des aspects de la combinaison XP/Scrum.
Certaines pratiques XP sont directement prises en compte par Scrum et
peuvent tre vues comme du recouvrement, par exemple Toute
lquipe , Sasseoir ensemble , Histoires et Jeu du planning .
Dans ces cas nous nous en sommes simplement tenus Scrum.
La programmation en binme
Nous avons commenc cela rcemment dans une de nos quipes. Ca a
plutt bien fonctionn en fait. La plupart de nos autres quipes ne
travaillent toujours pas beaucoup en duo, mais aprs lavoir rellement
essay avec une quipe pendant maintenant plusieurs sprints, je suis
motiv pour essayer dentraner plus dquipes faire lessai.

Quelques conclusions pour linstant sur la programmation en binme :
La programmation en binme amliore la qualit du code.
La programmation en binme amliore la focalisation de lquipe
(par exemple quand le gars derrire vous dit h est-ce que ce
truc est vraiment ncessaire pour ce sprint ? ).
Curieusement beaucoup de dveloppeurs qui sont fortement
opposs la programmation en binme ne lont pas rellement
essaye, et apprennent rapidement lapprcier une fois quils
lessayent.
La programmation en binme est puisante et ne devrait pas tre
pratique toute la journe.
Faire tourner frquemment les duos est bnfique.
La programmation en binme amliore la diffusion des
connaissances dans le groupe. De faon tonnamment rapide.
Quelques personnes ne sont simplement pas laise avec la
programmation en binme. Ne jetez pas un excellent
programmeur juste parce quil nest pas laise avec la
programmation en binme.
Les revues de code sont une alternative acceptable la
programmation en binme.
Le copilote (le type qui nutilise pas le clavier) devrait
galement avoir un ordinateur lui. Pas pour le dveloppement,
mais pour de petites activits quand cest ncessaire, pour
parcourir la documentation quand le pilote (le type au clavier)
est bloqu, etc.
Nimposez pas la programmation en binme aux gens.
Encouragez-les et fournissez les bons outils mais laissez-les
exprimenter leur propre rythme.
Le Dveloppement Dirig par les Tests (DDT)

Amen ! Ceci, pour moi, est plus important que Scrum et XP tous les deux.
Vous pouvez prendre ma maison et ma tl et mon chien, mais nessayez
pas de mempcher de faire du DDT ! Si vous naimez pas le DDT alors
ne me laissez pas entrer dans votre btiment, parce que je vais essayer
den introduire dune manire ou dune autre :o)
Voici un rsum du DDT en 10 secondes:
Le dveloppement dirig par les tests signifie que vous
crivez un test automatis, puis vous crivez juste assez de
code pour faire passer ce test, puis vous remaniez le code
COMMENT NOUS COMBINONS SCRUM AVEC XP | 99

principalement pour amliorer la lisibilit et supprimer
les duplications. Rincez et recommencez.
Quelques rflexions sur le dveloppement dirig par les tests.
Le DDT est difficile. Cela prend du temps un programmeur
pour voir la lumire. En fait, dans beaucoup de cas, le temps que
vous passez former et dmontrer na pas rellement beaucoup
dimportance dans beaucoup de cas la seule manire pour un
programmeur de voir la lumire est de le faire programmer en
duo avec quelquun de vraiment bon en DDT. Une fois quun
programmeur voit la lumire, cependant, il sera en principe
gravement infect et ne voudra jamais plus travailler dune autre
manire.
Le DDT a un effet profondment positif sur la conception du
systme.
Cela prend du temps pour avoir du DDT parfaitement au point
dans un nouveau produit, surtout des tests dintgration en boite
noire, mais le retour sur investissement est rapide.
Assurez-vous dinvestir le temps ncessaire pour que ce soit
facile dcrire des tests. Cela signifie obtenir les bons outils,
duquer les gens, fournir des classes utilitaires ou des classes de
base appropries, etc.
Nous utilisons les outils suivants pour le dveloppement dirig par les
tests :
jUnit / httpUnit / jWebUnit. Nous envisageons TestNG et
Selenium.
HSQLDB en tant que BD embarque en mmoire pour les tests.
Jetty en tant que container web embarqu en mmoire pour les
tests.
Cobertura pour les mtriques de couverture de test.
Spring pour cbler diffrents types de montages de test (avec
mocks, sans mocks, avec base de donnes externe, avec base de
donnes en mmoire, etc).
Dans nos produits les plus sophistiqus (du point de vue du DDT) nous
avons des tests dacceptation automatiss de type bote noire. Ces tests
dmarrent le systme complet en mmoire, y compris les bases de
donnes et les serveurs web, et accdent au systme en utilisant
uniquement ses interfaces publiques (par exemple HTTP).
Cela permet des cycles dveloppement-construction-test extrmement
rapides. Cela agit galement comme un filet de scurit, donnant
suffisamment de confiance aux dveloppeurs pour remanier (refactor)

souvent, ce qui signifie que la conception reste propre et simple mme
quand le systme grandit.
Le DDT sur du nouveau code

Nous pratiquons le DDT pour tous les nouveaux dveloppements, mme
si cela signifie que la mise en place initiale du projet prend plus de temps
(puisquil nous faut plus doutils et de support pour les harnais de test,
etc). Il ny a pas vraiment de question se poser, les bnfices sont
tellement importants quil ny a vraiment pas dexcuse pour ne pas faire
du DDT.
Le DDT sur du vieux code

Le DDT est difficile, mais faire du DDT sur une base de code qui na pas
t construite avec du DDT ds le dbut a cest vraiment difficile !
Pourquoi ? Eh bien, en fait, je pourrais crire beaucoup de pages sur ce
sujet, alors je pense que je vais marrter ici. Je garde cela pour mon
prochain papier le DDT depuis les tranches :o)
Nous avons pass pas mal de temps essayer dautomatiser les tests
dintgration de lun de nos systmes les plus complexes, une base de
code qui existe depuis un moment et qui tait dans un tat de pagaille
extrme et tait compltement dpourvue de tests.
A chaque release du systme nous avions une quipe de testeurs ddis
qui ralisaient un lot complet de tests de rgression et de performance.
Les tests de rgression taient essentiellement manuels. Ceci ralentissait
notablement notre cycle de dveloppement et release. Notre but tait
dautomatiser ces tests. Aprs nous tre cogn la tte contre le mur
pendant plusieurs mois, toutefois, nous navons pas beaucoup avanc.
Aprs a nous avons chang dapproche. Nous avons accept le fait que
nous tions obligs de vivre avec du test de rgression manuel, et nous
avons plutt commenc nous demander comment pouvons-nous
rendre le processus de test manuel moins consommateur de temps ?
Ctait un systme de jeu, et nous avons ralis quune bonne partie du
temps de lquipe de test tait consacre des tches de mise en place
assez triviales, comme bricoler dans le back office pour mettre en place
des tournois pour le test, ou attendre quun tournoi planifi dmarre. Donc
nous avons cr des utilitaires pour cela. Des raccourcis et des scripts
petits, facilement accessibles qui font tout le travail de base et permettent
aux testeurs de se concentrer sur le vritable test.
Cet effort a vraiment t rentable ! En fait, cest probablement ce que
nous aurions d faire au dpart. Nous tions tellement impatients

dautomatiser le test que nous avons oubli de le faire tape par tape, la
premire tape tant de construire des choses qui rendent le test manuel
plus efficace.
Leon tire : si vous tes coincs avec du test de rgression manuel, et
voulez vous en dbarrasser en lautomatisant, ne lautomatisez pas (
moins que ce soit vraiment facile). A la place, construisez des choses qui
rendent le test de rgression manuel plus facile. Ensuite, considrez
lautomatisation du vritable test.
La conception incrmentale
Cela signifie garder la conception simple au dpart et lamliorer
continuellement, plutt quessayer de tout faire parfaitement ds le dpart
et ensuite tout geler.
Nous sommes plutt bons a, cest--dire que nous passons un temps
raisonnable remanier et amliorer la conception existante, et que nous
passons rarement du temps faire de grandes conceptions lavance.
Quelques fois nous chouons bien sr, par exemple en permettant une
conception branlante de simplanter trop fortement, si bien que le
remaniement devient un gros projet. Mais tout bien considr nous
sommes raisonnablement satisfaits.
Lamlioration continue de la conception est principalement un effet de
bord automatique du DDT.
Lintgration continue
La plupart de nos produits ont un systme dintgration continue plutt
sophistiqu, bas sur Maven et QuickBuild. Cela est trs efficace et fait
conomiser du temps. Cest la solution ultime au bon vieux problme h
mais a marche sur ma machine . Notre serveur de build en continu sert
de juge ou point de rfrence partir duquel on peut dterminer la
sant de toutes nos bases de code.
Chaque fois que quelquun enregistre quelque chose dans le systme de
gestion de version, le serveur de build en continu reconstruit tout partir
de zro sur un serveur partag, et excute tous les tests. Si quelque chose
ne va pas il envoie un email notifiant toute lquipe que le build a chou,
en indiquant quel changement dans le code a cass le build, des liens sur
les rapports de test, etc.

Chaque nuit le serveur de build en continu va reconstruire le produit
partir de zro et va publier les binaires (fichiers de type .EAR, .WAR,
etc.), la documentation, les rapports de test, les rapports de couverture de
test, les rapports de dpendance, etc, sur notre portail interne de
documentation. Certains produits vont aussi tre dploys
automatiquement sur un environnement de test.
Mettre en place tout cela a reprsent beaucoup de travail, mais chaque
minute passe en valait la peine.
La proprit collective du code

Nous encourageons la proprit collective du code mais toutes les quipes
ne lont pas encore adopte. Nous avons dcouvert que la programmation
en binme avec rotations frquentes des duos conduit automatiquement
un niveau lev de proprit collective du code. Les quipes avec ce
niveau lev de proprit collective ont prouv quelles taient trs
robustes, par exemple leur sprint ne meurt pas juste parce quune
personne cl est malade.
Un espace de travail informatif

Toutes les quipes ont accs des tableaux blancs et de lespace sur des
murs vides, et en font un assez bon usage. Dans la plupart des pices vous
trouverez les murs couverts de toutes sortes dinformations sur le produit
et le projet. Le plus gros problme est les vieux dchets qui saccumulent
sur les murs, il faudra peut-tre introduire un rle de nettoyeur dans
chaque quipe.
Nous encourageons lutilisation de tableaux de tches, mais toutes les
quipes ne les ont pas encore adopts. Voir page 68 comment nous
organisons le bureau de lquipe.
Les normes de codage

Rcemment nous avons commenc dfinir des normes de codage. Trs
utiles, nous aurions d le faire plus tt. Cela ne prend presque pas de
temps du tout, il faut juste commencer simple et les laisser se dvelopper.
Ecrivez juste les choses qui ne sont pas videntes pour tout le monde et
reliez-les des supports existants chaque fois que cest possible.

La plupart des programmeurs ont leur propre style de codage bien distinct.
De petits dtails comme comment ils grent les exceptions, comment ils
commentent le code, quand ils retournent null, etc. Dans certains cas la
diffrence na pas dimportance, dans dautres cas elle peut conduire
une conception systme gravement incohrente et du code trs difficile
lire. Des normes de codage sont trs utiles dans ce cas, du moins tant que
vous vous concentrez sur les choses qui importent.
Voici quelques exemples de nos normes :

Vous pouvez violer nimporte laquelle de ces rgles, mais

assurez-vous quil y a une bonne raison et documentez-l.
Utilisez les conventions de codage de Sun par dfaut :
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
Ne jamais, jamais, jamais, attraper des exceptions sans les
relancer ou enregistrer la pile dappel dans un journal.
log.debug() cest bien, mais simplement ne perdez pas cette pile
dappel.
Utilisez linjection de dpendances base sur les accesseurs pour
dcoupler les classes les unes des autres (sauf bien sr quand un
couplage fort est dsir).
Evitez les abrviations. Les abrviations bien connues comme
ADO sont acceptables.
Les mthodes qui retournent des collections ou des tableaux ne
devraient pas retourner null. Retournez des collections et des
tableaux vides la place de null.
Le rythme soutenable / le travail nergis

Beaucoup de livres sur le dveloppement logiciel agile prtendent que le
dpassement des horaires est contre-productif dans le dveloppement
logiciel.
Aprs quelques expriences non dsires sur la question, je ne peux
qutre daccord de tout cur !
Il y a peu prs un an une de nos quipes (la plus grosse) faisait une
quantit dmente dheures supplmentaires. La qualit de la base de code
existante tait dprimante et ils devaient passer la plupart de leur temps
teindre les incendies. Lquipe de test (qui faisait aussi des heures
supplmentaires) navait aucune chance de faire srieusement le travail
dassurance qualit. Nos utilisateurs taient mcontents et les tablodes
nous mangeaient vivants.

Aprs quelques mois nous avons russi ramener le nombre dheures
des niveaux dcents. Les gens travaillent le nombre normal dheures (sauf
quelquefois dans des situations critiques). Et, surprise, la productivit et la
qualit se sont amliores de manire notable.
Bien sr, la rduction des heures de travail na t en aucune manire le
seul aspect ayant conduit cette amlioration, mais nous sommes tous
convaincus quelle a jou un grand rle.
14
Comment nous faisons les tests
Cest la partie la plus difficile. Je ne sais pas si cest la partie la plus
difficile de Scrum, ou juste la partie la plus difficile du dveloppement
logiciel en gnral.
Le test est la partie qui va probablement varier le plus entre diffrentes
organisations. Cela dpendra du nombre de testeurs que vous avez, de
lampleur de lautomatisation de vos tests, de quel type de systme vous
avez (juste server+application web ? ou bien vous tes un diteur de
logiciel vendu dans des botes ?), de la dure des cycles de release, de la
criticit du logiciel (un serveur de blog vs. un systme de contrle de vol),
etc.
Nous avons pas mal expriment sur la manire de faire des tests dans
Scrum. Je vais essayer de dcrire ce que nous avons fait et appris jusque
l.
Vous ne pouvez probablement pas liminer la

phase de tests dacceptation
Dans le monde Scrum idal, un sprint produit une version de votre
systme potentiellement dployable. Alors il ny a qu le dployer, nestce-pas ?
Faux.
Daprs notre exprience, cela ne fonctionne gnralement pas. Il y aura
de mchants bugs. Si la qualit a une valeur quelconque pour vous, il faut
une sorte de phase de test dacceptation manuelle. Cest le moment o des
testeurs ddis, qui ne font pas partie de lquipe, martlent le systme
avec ces types de tests que lquipe Scrum navait pas imagins, ou
navait pas eu le temps de faire, ou pour lesquels elle navait pas le
matriel ncessaire. Les testeurs accdent au systme exactement comme
les utilisateurs finaux, ce qui signifie quils doivent le faire manuellement
(en supposant que votre systme est destin des utilisateurs humains).
Lquipe de test va trouver des bugs, lquipe Scrum va devoir faire des
releases de corrections de bugs, et tt ou tard (jespre tt) vous pourrez
livrer aux utilisateurs finaux une version corrige 1.0.1, au lieu de la
version instable 1.0.0.
Quand je dis phase de tests dacceptation , je fais rfrence la priode
complte de tests, dbogage, et nouvelles releases jusqu ce quil y ait
une version suffisamment bonne pour la production.
Minimisez la phase de tests dacceptation

La phase de tests dacceptation fait mal. On sent clairement quelle nest
pas agile. Bien quil ne soit pas possible de lliminer, nous pouvons (et
COMMENT NOUS FAISONS LES TESTS | 107

nous y parvenons) essayer de la minimiser. Plus prcisment, de
minimiser la quantit de temps ncessaire pour la phase de tests
dacceptation. Ce rsultat est obtenu en :
Maximisant la qualit du code produit par lquipe Scrum
Maximisant lefficacit du travail de test manuel (cest--dire
trouver les meilleurs testeurs, leur donner les meilleurs outils,
sassurer quils rapportent les tches consommatrices de temps
qui pourraient tre automatises)
Alors comment maximisons-nous la qualit du code produit par lquipe
Scrum ? Eh bien, il y a plein de manires. En voici deux qui marchent trs
bien daprs nous :
Mettre des testeurs dans lquipe Scrum
En faire moins par sprint
Augmenter la qualit en mettant des testeurs

dans lquipe Scrum
Oui, jentends bien les deux objections :

Mais cest vident ! Les quipes Scrum sont supposes tre
multifonctions.
Les quipes Scrum sont supposes tre sans rle. On ne peut
pas avoir quelquun qui serait uniquement un testeur !
Laissez-moi clarifier. Ce que je veux dire par testeur dans ce cas est
une personne dont le talent principal est le test , plutt que une
personne dont le rle est seulement de tester .
Les dveloppeurs sont souvent dassez mauvais testeurs. Surtout les
dveloppeurs testant leur propre code.
Le testeur est le gars qui signe officiellement

En plus dtre juste un membre de lquipe, le testeur a un boulot
important. Cest le gars qui dcide quand cest termin. Rien nest

considr comme termin dans un sprint tant que lui na pas dit que
ctait termin. Jai dcouvert que les dveloppeurs disent souvent que
quelque chose est termin alors que ce ne lest pas rellement. Mme si
vous avez une dfinition de termin trs claire (et vous devriez
vraiment en avoir une, voir page 40 la dfinition de termin ), les
dveloppeurs vont loublier frquemment. Nous programmeurs sommes
des gens impatients et nous dsirons passer la tche suivante ds que
possible.
Mais alors comment M. T (notre testeur) sait-il que quelque chose est
termin ? Eh bien, avant tout, il devrait (surprise) le tester ! Dans
beaucoup de cas, il savre que quelque chose considr comme
termin par un dveloppeur nest mme pas testable. Parce que son
travail na pas t enregistr dans le systme de gestion de sources, parce
quil na pas t dploy sur le serveur de tests, ou parce quil nest pas
possible de lexcuter, etc. Une fois que M. T a test la fonctionnalit, il
devrait parcourir la check-list dfinissant termin (si vous en avez
une) avec le dveloppeur. Par exemple si la dfinition de termin
exige quil devrait y avoir une note de release, alors M. T vrifie quil y a
bien une note de release. Sil existe une sorte de spcification plus
formelle pour la fonctionnalit (cest rare dans notre cas) alors M. T
vrifie cela galement. Etc.
Un effet de bord positif de tout cela est que lquipe a maintenant un gars
qui est parfaitement au point pour organiser la dmonstration du sprint.
Que fait le testeur quand il ny a rien tester ?

Cette question est pose sans arrt. M. T : H Scrum master, il ny a rien
tester en ce moment, alors quest-ce que je dois faire ? Il peut falloir
une semaine avant que lquipe ne termine la premire histoire, donc que
devrait faire le testeur pendant ce temps ?
Eh bien, tout dabord, il devrait prparer les tests. Cest--dire crire les
spcifications de test, prparer un environnement de test, etc. Donc quand
un dveloppeur a quelque chose de prt tester, il ne devrait pas y avoir
dattente, M. T devrait commencer tester immdiatement.
Si lquipe pratique le DDT alors des gens passent du temps crire du
code de test depuis le premier jour. Le testeur devrait programmer en duo
avec les dveloppeurs qui crivent du code de test. Si le testeur ne sait pas
programmer, alors il devrait tout de mme programmer en duo avec les
dveloppeurs, sauf quil devrait seulement jouer le rle du navigateur et
laisser le clavier au dveloppeur. Un bon testeur imagine gnralement

des types de test diffrents de ceux dun bon dveloppeur, si bien quils
sont complmentaires lun de lautre.
Si lquipe ne pratique pas le DDT, ou sil ny a pas assez dcriture de
cas de tests pour occuper tout le temps du testeur, il devrait simplement
faire ce quil peut pour aider lquipe atteindre le but du sprint. Tout
comme nimporte quel autre membre de lquipe. Si le testeur peut
programmer cest super. Sinon, votre quipe devra identifier toutes les
tches hors programmation qui doivent tre faites dans le sprint.
Durant la dcomposition des histoires en tches pendant la runion de
planning de sprint, lquipe a tendance se focaliser sur les tches de
programmation. Toutefois, habituellement il y a beaucoup de tches hors
programmation qui doivent tre faites dans le sprint. Si vous passez du
temps essayer didentifier les tches hors programmation durant la
phase de planning du sprint, il y a des chances pour que M. T soit capable
de contribuer pas mal, mme sil ne sait pas programmer et sil ny a pas
de tests faire tout de suite.
Exemples de tches hors programmation qui doivent souvent tre faites
dans un sprint :
Mettre en place un environnement de test.
Eclaircir les spcifications.
Discuter les dtails de dploiement avec le service Oprations.
Ecrire les documents de dploiement (notes de release, demandes
de commentaires, ou quoi que ce soit que votre organisation
fasse).
Grer les contacts avec des ressources externes (concepteurs
dIHM par exemple).
Amliorer les scripts de build.
Raffiner la dcomposition des histoires en tches.
Identifier les questions cls poses par les dveloppeurs et obtenir
des rponses.
Dun autre ct, que faisons-nous si M. T devient un goulet
dtranglement ? Disons que nous sommes au dernier jour du sprint et que
soudainement beaucoup de choses sont faites et que M. T na aucune
chance de tout tester. Que faisons-nous ? Eh bien nous pourrions
transformer tout le monde dans lquipe en assistants de M. T. Il dcide ce
quil doit faire lui-mme, et il dlgue le travail de base au reste de
lquipe. Voil en quoi consiste une quipe multifonctionnelle !

Donc oui, M. T joue un rle spcial dans lquipe, mais il est tout de
mme autoris faire dautres travaux, et les autres membres de lquipe
sont tout de mme autoriss faire son travail.
Augmenter la qualit en en faisant moins par

sprint
On en revient la runion de planning de sprint. Pour faire court,
nessayez pas de faire rentrer trop dhistoires dans le sprint. Si vous avez
des problmes de qualit, ou de longs cycles de test dacceptation, faites
en moins par sprint ! Cela va presque automatiquement conduire une
qualit plus leve, des cycles de test dacceptation plus courts, moins de
bugs affectant les utilisateurs finaux, et une productivit plus leve dans
le long terme puisque lquipe peut se focaliser tout le temps sur de
nouveaux trucs au lieu de corriger de vieux trucs qui cassent sans arrt.
Cest presque toujours plus rentable de construire moins, mais de le
construire stable, plutt que de construire beaucoup de choses et densuite
avoir faire des hot-fix dans la panique.
Est-ce que les tests dacceptation devraient

faire partie du sprint ?
Nous hsitons beaucoup ici. Certaines de nos quipes incluent les tests
dacceptation dans le sprint. Toutefois la plupart de nos quipes ne le font
pas, pour deux raisons :
Un sprint est dure limite. Le test dacceptation (selon ma
dfinition qui inclut le dbogage et les nouvelles releases) est trs
difficile limiter dans le temps. Que faire si le dlai est dpass
et que vous avez toujours un bug critique ? Allez-vous livrer le
produit en production avec un bug critique ? Allez-vous attendre
jusquau sprint suivant ? Dans la plupart des cas les deux
solutions sont inacceptables. Donc nous ny incluons pas le test
dacceptation manuel.
Si vous avez plusieurs quipes Scrum travaillant sur le mme
produit, le test dacceptation manuel doit tre effectu sur le
rsultat combin des deux quipes. Si les deux quipes ont fait
lacceptation manuelle durant le sprint, vous avez quand mme
besoin dune quipe pour tester la release finale, qui est le build
intgrant le travail des deux quipes.
Cela nest en aucune faon une solution parfaite mais elle est
suffisamment bonne pour nous dans la plupart des cas.
Des cycles de sprints vs. des cycles de test

dacceptation
Dans un monde McScrum parfait vous navez pas besoin de phases de test
dacceptation puisque chaque quipe Scrum livre une nouvelle version de
votre systme prte pour la production aprs chaque sprint.
Eh bien voici une image plus raliste :
Aprs le sprint 1, une version 1.0.0 bugge est livre. Durant le sprint 2,
des rapports de bugs commencent arriver et lquipe passe la majeure
partie de son temps dbugger et est force de faire mi-sprint une
release 1.0.1 de correction de bugs. Ensuite la fin du sprint 2 ils livrent
une nouvelle version 1.1.0 avec de nouvelles fonctionnalits, qui est bien
sr encore plus bugge puisquils ont eu encore moins de temps pour la
faire correctement cette fois-ci tant donn toutes les perturbations venant
de la release prcdente. Etc etc.
Les hachures rouges dans le sprint 2 symbolisent le chaos.
Pas trs joli nest-ce pas ? Eh bien, ce qui est triste cest que le problme
perdure mme si vous avez une quipe de test dacceptation. La seule
diffrence est que la plupart des rapports de bugs vont venir de lquipe
de test au lieu de clients finaux mcontents. Cest une norme diffrence
sur le plan commercial, mais pour les dveloppeurs cela revient peu prs
la mme chose. Sauf que les testeurs sont habituellement moins
agressifs que les utilisateurs finaux. Habituellement.
Nous navons trouv aucune solution simple ce problme. Cependant

nous avons beaucoup expriment avec diffrents modles.
Avant tout, nouveau, il faut maximiser la qualit du code que lquipe
Scrum dlivre. Le cot de trouver et corriger les bugs trs tt, durant un
sprint, est bien plus faible en comparaison du cot de les trouver et
corriger aprs.
Mais il reste le fait que, mme si on peut minimiser le nombre de bugs, il
y aura toujours des rapports de bugs qui arriveront aprs quun sprint soit
termin. Comment grons-nous cela ?
Approche 1 : Ne commencez pas construire de

nouvelles choses avant que les anciennes ne soient
en production
Ca a lair bien nest-ce pas ? Avez-vous ressenti vous aussi ce sentiment
de satisfaction ?
Nous avons t proches dadopter cette approche plusieurs fois, et avons
conu de beaux modles sur la manire de le faire. Toutefois nous avons
toujours chang davis quand nous avons ralis linconvnient. Il nous
faudrait ajouter une priode de release sans limite de temps entre les
sprints, pendant laquelle nous ferions seulement du test et du dbogage
jusqu ce que nous puissions faire une release de production.

Nous navons pas aim lide davoir des priodes sans limite de temps
entre les sprints, principalement parce que cela casserait le rythme
rgulier des sprints. Il ne serait plus possible de dire toutes les 3
semaines nous dmarrons un nouveau sprint . De plus, cela ne rsout pas
compltement le problme. Mme si nous avons une priode de release, il
y aura toujours des rapports de bugs urgents qui arriveront de temps en
temps, et il nous faut tre prt les grer.
Approche 2 : OK pour commencer construire de

nouvelles choses, mais priorisez la mise en
production des anciennes
Cest notre approche prfre. En tout cas pour le moment.
Fondamentalement, quand nous finissons un sprint nous commenons le
suivant. Mais nous nous attendons passer un certain temps dans le sprint
suivant corriger des bugs du dernier sprint. Si le sprint suivant est
srieusement endommag cause du temps quil a fallu pour corriger des
bugs du sprint prcdent, nous valuons pourquoi cela est arriv et
comment nous pouvons amliorer la qualit. Nous nous assurons que les
sprints sont suffisamment longs pour survivre une bonne priode de
correction de bugs du sprint prcdent.
Progressivement, sur une priode de pas mal de mois, la quantit de temps
passe corriger des bugs des sprints prcdents a diminu. De plus nous
avons pu impliquer moins de gens quand des bugs arrivaient, si bien quil
ntait pas ncessaire de perturber lensemble de lquipe chaque fois.
Maintenant nous sommes un niveau plus acceptable.
Durant les runions de planning de sprint nous fixons le facteur de

focalisation une valeur suffisamment basse pour prendre en compte le
temps que nous nous attendons passer corriger des bugs du sprint
dernier. Avec le temps les quipes sont devenues assez bonnes cette
estimation. La mtrique de vlocit aide beaucoup (voir page 31
Comment lquipe dcide quelles histoires inclure dans le sprint ? ).
Mauvaise approche se focaliser sur la construction

de nouvelles choses
Cela signifie en effet se focaliser sur la construction de nouvelles choses
plutt que darriver mettre les anciennes en production. Qui voudrait
faire a ? Pourtant nous avons souvent fait cette erreur au dbut, et je suis
sr que beaucoup dautres entreprises lont faite aussi. Cest une maladie
lie au stress. Beaucoup de managers ne comprennent pas que, quand tout
le codage est fini, vous tes gnralement encore loin de la release de
production. Du moins pour les systmes complexes. Donc le manager (ou
le directeur de produit) demande lquipe de continuer ajouter de
nouvelles choses alors que le fardeau de vieux code presque-prt-pour-larelease devient de plus en plus lourd, et ralentit tout.
Ne distancez pas le maillon le plus lent de

votre chane
Disons que le test dacceptation est votre maillon le plus lent. Vous
navez pas assez de testeurs, ou la priode de test dacceptation dure
longtemps cause la qualit lamentable du code.
Disons que votre quipe de test dacceptation peut tester au plus 3
fonctionnalits par semaine (non, nous nutilisons pas les fonctionnalits
par semaine comme mtrique ; jutilise le terme juste pour cet exemple).
Et disons que vos dveloppeurs peuvent dvelopper 6 nouvelles
fonctionnalits par semaine.
Il va tre tentant pour les managers ou directeurs de produit (ou peut tre
mme pour lquipe) de planifier le dveloppement de 6 nouvelles
fonctionnalits par semaine.
Ne le faites surtout pas ! La ralit va vous rattraper dune manire ou
dune autre, et ca va faire mal.
Plutt, planifiez 3 nouvelles fonctionnalits par semaine, et passez le reste
du temps rduire le goulet dtranglement du test. Par exemple :
Faire travailler quelques dveloppeurs comme testeurs (oh ils
vont vous adorer pour cela).
Implmenter des outils et scripts qui rendent le test plus facile.
Ajouter plus de code de test automatis.
Augmenter la longueur des sprints et inclure le test dacceptation
dans les sprints.

Dfinir certains sprints comme des sprints de test pendant

lesquels lquipe complte travaille comme une quipe de test
dacceptation.
Embaucher plus de testeurs (mme si cela signifie supprimer des
postes de dveloppeurs)
Nous avons essay toutes ces solutions (sauf la dernire). La meilleure

solution long terme est bien sr les points 2 et 3, cest--dire de
meilleurs outils et scripts ainsi que lautomatisation des tests.
Les rtrospectives sont un bon forum pour identifier le maillon le plus lent
dans la chane.
Retour la ralit
Je vous ai probablement donn limpression que nous avons des testeurs
dans toutes les quipes Scrum, que nous avons de grosses quipes de test
dacceptation pour chaque produit que nous livrons aprs chaque sprint,
etc.
Eh bien, nous ne les avons pas.
Nous avons quelquefois russi faire tout cela, et nous en avons vu les
effets positifs. Mais nous sommes encore loin dun processus dassurance
qualit acceptable, et nous avons encore beaucoup apprendre dans ce
domaine.
15
Comment nous grons les quipes
multi-Scrum
Beaucoup de choses deviennent plus difficiles quand vous avez plusieurs
quipes Scrum qui travaillent sur le mme projet. Ce problme est
universel et na pas vraiment de lien avec Scrum. Plus de dveloppeurs =
plus de complications.
Nous avons (comme dhabitude) fait des essais. Au plus nous avions une
quipe de 40 personnes environ qui travaillaient sur le mme projet.
Les questions cls sont :
Combien dquipes faut-il crer ?
Comment rpartir les personnes dans les quipes ?
Combien dquipes faut-il crer

Si traiter avec plusieurs quipes Scrum est si dur, pourquoi sembter ?
Pourquoi ne pas mettre tout le monde dans la mme quipe ?
La plus grosse quipe Scrum que nous avons eu faisait environ 11
personnes. Ca fonctionnait, mais pas trs bien. Les mles quotidiennes
avaient tendance trainer au-del de 15 minutes. Les membres de
lquipe ne savaient pas ce que les autres faisaient, il pouvait y avoir de la
confusion. Ctait difficile pour le Scrum master de garder tout le monde
concentr sur lobjectif, et de trouver le temps dadresser tous les
obstacles qui taient remonts.
Lalternative est de diviser lquipe en deux. Mais est-ce mieux ? Pas
ncessairement.
Si lquipe est exprimente et confortable avec Scrum, et sil y a une
approche logique de dcouper la feuille de route en deux pistes distinctes,
et que les deux pistes ne concernent pas le mme code source, alors je

dirais que cest une bonne ide de diviser lquipe. Sinon je considrerais
de rester avec une quipe, malgr le dsavantage des grosses quipes.
Mon exprience est quil est prfrable davoir peu dquipes mme trop
grosses que davoir plein de petites quipes qui interfrent les unes les
autres. Crez de petites quipes seulement si elles nont pas besoin
dinteragir entre elles !
Equipes virtuelles
Comment savoir si vous prenez la bonne ou mauvaise dcision par rapport
au compromis entre grosses quipes vs beaucoup dquipes ?
Si vous gardez les yeux et les oreilles ouvertes vous aurez remarqu la
formule quipes virtuelles .
Exemple 1: Vous choisissez davoir une grande quipe. Mais quand vous
regardez qui parle qui pendant litration, vous notez que lquipe est
effectivement divise en deux sous-quipes.
Exemple 2: Vous choisissez davoir trois quipes plus petites. Mais

quand vous regardez qui parle qui pendant litration, vous notez que les
quipes 1 et 2 discutent entre elles tout le temps, tandis que lquipe 3
travaille de manire isole.
COMMENT NOUS GERONS LES EQUIPES MULTI-SCRUM | 119

Quest-ce que a signifie ? Que votre stratgie de division des quipes
nest pas bonne ? Oui, si les quipes virtuelles semblent plutt
permanentes. Non, si vos quipes virtuelles semblent tre temporaires.
Regardez lexemple 1. Si les deux sous-quipes virtuelles ont tendance
changer de temps en temps (cest--dire que les personnes bougent entre
les sous-quipes virtuelles) alors vous avez probablement pris la bonne
dcision en les regroupant dans une quipe Scrum unique. Si les deux
sous-quipes restent les mmes pendant toute litration, vous voudrez
probablement les sparer en deux vraies quipes Scrum pour la prochaine
itration.
Maintenant regardez lexemple 2. Si lquipe 1 et 2 discutent entre elles
(mais pas lquipe 3) durant toute litration, vous voudrez probablement
regrouper lquipe 1 et lquipe 2 en une quipe Scrum unique la
prochaine itration. Si lquipe 1 et lquipe 2 discutent beaucoup entre
elles pendant la premire moiti de litration, et quensuite lquipe 1 et
lquipe 3 discutent entre elles pendant la seconde moiti de litration,
alors vous devriez considrer de fusionner les trois quipes en une, ou
juste les laisser en trois quipes. Abordez la question durant la
rtrospective ditration et laissez les quipes dcider elles-mmes.
La division des quipes est lune des parties vraiment difficiles de Scrum.
Ne rflchissez pas trop ou noptimisez pas trop. Exprimentez, gardez un
il sur les quipes virtuelles, et soyez sr que vous prenez suffisamment
de temps pour discuter de ce genre de choses pendant les rtrospectives.
Tt ou tard vous trouverez la bonne solution votre situation. Le plus
important est que les quipes soient confortables et nhsitez pas entre les
deux trop souvent.
La taille optimale de lquipe

La plupart des livres que jai lus affirment que la taille optimale de
lquipe est quelque part autour de 5 9 personnes.
Daprs ce que jai vu jusquici je ne peux qutre daccord. Mme si je
dirai plutt 3 8 personnes. En fait, je crois que a vaut le cot
datteindre des quipes de cette taille.
Disons que vous avez une unique quipe Scrum de 10 personnes.
Considrons que lon jecte les deux membres les plus mdiocres. Oups,
ai-je vraiment dit a ?

Disons que vous avez deux produits diffrents, avec une quipe de 3
personnes par produit, et les deux avancent trop lentement. Ca peut tre
une bonne ide de les fusionner en une seule quipe de 6 personnes
responsable des deux produits. Dans ce cas laissez partir lun des deux
directeurs de produit (ou donnez lui un rle consultatif ou autre chose).
Disons que vous avez une seule quipe Scrum de 12 personnes, car le
code est dans un tat tellement lamentable quil ny a pas moyen pour 2
quipes diffrentes de travailler dessus indpendamment. Faites de
srieux efforts pour corriger le code (au lieu de construire de nouvelles
fonctionnalits) jusqu ce que vous puissiez diviser lquipe. Cet
investissement sera probablement amorti rapidement.
Sprints synchroniss ou non ?

Disons que vous avez trois quipes Scrum qui travaillent sur le mme
projet. Leurs sprints devraient-ils tre synchroniss, cest--dire
commencer ou finir ensemble ? Ou devraient-ils se chevaucher ?
Notre premire approche tait les sprints qui se chevauchent (en
respectant les dures).

Ca sonne bien. A nimporte quel moment il y aurait un sprint sur le point
de finir et un nouveau sprint sur le point de commencer. La charge de
travail du directeur de produit serait galement rpartie dans le temps. Il y
aurait des nouvelles versions en continu. Des dmonstrations toutes les
semaines. Allluia.
Oui, je sais, mais a semblait vraiment convaincant lpoque !
Nous avions juste commenc faire a quand un jour jai eu lopportunit
de parler avec Ken Schwaber (en conjonction avec ma certification
Scrum). Il fit remarquer que ctait une mauvaise ide, quil serait
tellement mieux de synchroniser les sprints. Je ne me rappelle pas ces
arguments exacts, mais aprs la discussion jtais convaincu.
Cest la solution que nous avons utilise depuis, et nous ne lavons jamais
regrett. Je ne saurai jamais si la stratgie des sprints qui se chevauchent
aurait choue, mais je pense que oui. Les avantages des sprints
synchroniss sont :
Il y a un moment naturel o lon peut rarranger les quipes
entre les sprints ! En chevauchant les sprints, il ny a pas moyen
de rarranger les quipes sans perturber au moins une quipe au
milieu du sprint.
Toutes les quipes peuvent travailler vers un objectif commun sur
un sprint et faire les runions de planification de sprint ensemble,
ce qui mne une meilleure collaboration entre quipes.
Il y a moins de travail administratif, cest--dire moins de
runions de planification de sprint, de dmonstrations de sprint,
et de releases.
Pourquoi nous avons introduit le rle du

meneur dquipe
Disons que nous avons un seul produit avec trois quipes.
Le gars en rouge marqu P est le Directeur de produit. Les gars en noir

marqus S sont les Scrum Masters. Les autres sont les troufions... euh...
les membres respectables dquipe.
Avec cette constellation, qui dcide quelles personnes devraient tre dans
quelle quipe ? Le directeur de produit ? Les trois Scrum masters
ensemble ? Ou chaque personne choisit son quipe ? Mais alors que faire
si tout le monde veut tre dans lquipe 1 (parce que le Scrum master 1 est
tellement avenant)?
Que faire si plus tard il savre impossible davoir plus de deux quipes
en parallle sur ce code, et quil soit ncessaire de les transformer en 2
quipes de 9 personnes au lieu de des quipes de 6 personnes. Cela
signifie 2 Scrum masters. Alors lequel des 3 Scrum masters sera relev de
sa fonction ?
Dans beaucoup dentreprises ce sont des questions assez sensibles.
Il est tentant de laisser le directeur de produit faire les affectations et
raffectations. Mais ce nest pas vraiment le travail du directeur de
produit, nest-ce pas ? Le directeur de produit est lexpert mtier qui dit
lquipe dans quelle direction elle doit courir. Il ne devrait pas vraiment
tre impliqu dans les dtails. Surtout sil sagit dun poulet (si vous
avez entendu la mtaphore du poulet et du cochon, sinon tapez chicken
and pig sous google).
Nous avons rsolu ce problme en introduisant le rle du meneur
dquipes . Cela correspond ce que vous pourriez appeler le Scrum
des Scrum masters ou le chef ou le Scrum master principal etc. Il
na mener aucune quipe, mais il est responsable des problmes
transverses aux quipes comme qui devrait tre le Scrum master pour
chaque quipe, combien de personnes devraient tre divises en quipes,
etc.

Nous avons eu du mal trouver un bon nom pour ce rle. Le meneur
dquipes tait le moins mauvais nom que nous avons pu trouver.
Cette solution a bien march pour nous et je peux la recommander
(indpendamment du nom que vous choisissez pour ce rle).
Comment nous affectons les personnes aux

quipes
Il y a deux grandes stratgies pour affecter les personnes aux quipes,
lorsque vous avez de multiples quipes sur le mme produit.
Laisser une personne dsigne faire laffectation, par exemple le
meneur dquipes que jai mentionn ci-dessus, le directeur
de produit, ou le manager fonctionnel (sil est assez impliqu
pour pouvoir prendre de bonnes dcisions).
Laisser les quipes le faire eux-mmes.
Nous les avons essayes toutes les trois. Trois ? Oui. Stratgie 1, Stratgie
2 et une combinaison des deux.
Nous avons trouv que la combinaison des deux fonctionnait mieux.
Avant la runion de planification de sprint, le meneur dquipes lance une
runion daffectation des quipes avec le directeur de produit et tous les
Scrum masters. Nous discutons du dernier sprint et dcidons si une
raffectation est ncessaire. Peut-tre voulons-nous fusionner deux
quipes, ou transfrer des personnes dune quipe vers une autre. Nous
nous dcidons sur quelque chose et nous le mettons par crit comme une
proposition daffectation dquipe, que nous apportons la runion de
planification du sprint.
La premire chose que nous faisons pendant la runion de planification de
sprint est de parcourir les lments de plus haute priorit dans le backlog
de produit. Le meneur dquipe dit ensuite quelque chose dans le genre :
Bonjour tout le monde. Nous suggrons laffectation dquipe suivante
pour le prochain sprint.
Comme vous le voyez, cela signifierait une rduction du nombre

dquipes, passant de 4 3. Nous avons list les membres pour chaque
quipe. Groupez-vous sil-vous-plat et mettez-vous devant une section du
mur.
(le meneur dquipes attend pendant que les personnes se baladent dans la
pice, aprs un moment il y a 3 groupes, chacun se tenant devant une
section du mur vide).
Maintenant cette division dquipes est prliminaire ! Cest juste un
point de dpart, pour gagner du temps. Au fur et mesure que la runion
de planification de sprint progresse vous tes libre de vous balader vers
une autre quipe, de diviser votre quipe en deux, fusionner avec une
autre quipe, ou ce que vous voulez. Faites preuve de bon sens en vous
basant sur les priorits du directeur de produit.
Cest ce que nous avons trouv qui fonctionne le mieux. Un certain
niveau de contrle centralis au dbut, suivi par un certain niveau
doptimisations dcentralises aprs.
Equipes spcialises ou non ?

Disons que votre technologie consiste en trois principaux composants :
Et disons que vous avez 15 personnes travaillant sur le produit, aussi vous
ne voulez vraiment pas en faire une seule quipe Scrum. Quelles quipes
crez-vous ?
Approche n1: quipes spcialises par composant

Une approche est de crer des quipes spcialises par composant telles
quune quipe client , une quipe serveur et une quipe BD .
Cest comme a que nous avons commenc. Ca ne fonctionnait pas trs

bien, du moins pas quand la plupart des histoires impliquaient plusieurs
composants.
Par exemple disons que nous avons une histoire appele tableau
daffichage o les utilisateurs peuvent poster des messages aux autres .
Cette fonctionnalit de tableau daffichage impliquerait de mettre jour
linterface utilisateur ct client, ajouter la logique ct serveur, et ajouter
des tables dans la base de donnes.
Cela signifie que les trois quipes lquipe client, lquipe

serveur, et lquipe BD doivent collaborer pour que cette
histoire soit termine. Pas terrible.
Approche n2: quipes transversales aux composants
Une seconde approche est de crer des quipes transversales aux
composants, cest--dire des quipes qui ne sont lies aucun composant.

Si beaucoup de vos histoires impliquent plusieurs composants cette
stratgie de division dquipes fonctionnera mieux. Chaque quipe peut
implmenter une histoire complte incluant la partie client, la partie
serveur et la partie base de donnes. Les quipes peuvent ainsi travailler
plus indpendamment des autres, ce qui est une Bonne Chose.
Lune des premires choses que nous faisons quand nous avons introduit
Scrum tait de dmanteler ces quipes spcialises par composant
(approche 1) et de crer des quipes transversales aux composants la
place (approche 2). Cela rduit le nombre de cas o nous ne pouvons
finir cet lment parce que nous attendons que les gars ct serveur
fassent leur partie.
Cependant, nous assemblons parfois des quipes temporaires spcialises
par composant quand le besoin est fort.
Rarranger les quipes entre les sprints ou

pas ?
Chaque sprint est gnralement assez diffrent des autres, selon le type
des histoires qui ont la plus haute priorit ce moment particulier. Par
consquent, la cration de lquipe optimale peut tre diffrente pour
chaque sprint.
En fait, presque tous les sprints nous disions quelque chose comme ce
sprint ntait pas vraiment un sprint normal parce que (bla bla bla).....
Aprs quelques temps nous avons abandonn la notion de sprint
normal . Il ny a pas de sprint normal. Comme il ny a pas de famille
normale ou de personne normale .
Sur un sprint ce peut tre une bonne ide davoir une quipe client
seulement, constitue de tous ceux qui connaissent bien le code client. Au
prochain sprint ce peut tre une bonne ide davoir deux quipes
transversales en divisant le groupe client.
Lun des aspects cls de Scrum est la formation de lquipe , cest-dire si une quipe apprend travailler ensemble au cours des sprints ils
deviendront gnralement trs proches. Ils apprendront obtenir un flux
de groupe et atteindront un niveau de productivit incroyable. Mais cela
prend quelques sprints pour y parvenir. Si vous narrtez pas de changer
les quipes nous nobtiendrez jamais une quipe vraiment soude.

Aussi si vous voulez rarranger les quipes, soyez sr de mesurer les
consquences. Est-ce un changement long terme ou court terme ? Si
cest un changement court terme considrez de le laisser tomber. Si cest
un changement long terme, allez-y.
Une exception lorsque vous commencez appliquer Scrum avec une
grande quipe pour la premire fois. Dans ce cas il vaut probablement
mieux exprimenter un peu avec les divisions dquipes jusqu ce que
vous trouviez quelque chose de confortable pour tous. Assurez-vous que
tout le monde comprenne que cest OK davoir tout faux les quelques
premires fois, du moment que vous continuez de vous amliorer.
Les membres dquipe temps partiel

Je ne peux que confirmer ce que les livres Scrum disent avoir des
membres dune quipe Scrum temps partiel nest gnralement pas une
bonne ide.
Disons que vous tes sur le point de prendre Joe en tant que membre
temps partiel dans votre quipe Scrum. Rflchissez bien avant. Avezvous vraiment besoin de Joe dans votre quipe ? Etes-vous sr de ne pas
pouvoir prendre Joe temps plein ? Quels sont ses autres engagements ?
Est-ce que quelquun dautre peut prendre le relai sur les autres
engagements de Joe et laisser Joe un rle plus passif, de support, tout en
respectant ses engagements ? Est-ce que Joe peut rejoindre votre quipe
plein temps pour le prochain sprint, et dans le mme temps transfrer ses
autres responsabilits quelquun dautre ?
Parfois il ny a pas de solution. Vous avez dsesprment besoin de Joe
parce que cest le seul DBA de limmeuble, mais les autres quipes ont
autant besoin de lui alors il ne sera jamais affect plein temps sur votre
quipe, et la socit ne peut prendre plus de DBAs. Trs bien. Cest un
cas valide pour lavoir temps partiel (cest dailleurs exactement ce qui
sest pass pour nous). Mais assurez-vous de faire cette valuation
chaque fois.
En gnral je prfre avoir une quipe de 3 personnes plein temps que
de 8 temps partiel.
Si vous avez une personne qui va partager son temps entre plusieurs
quipes, comme le DBA mentionn plus haut, cest une bonne ide de
lassigner lorigine une quipe. Trouvez lquipe qui aura le plus
besoin de lui, et faites-en son quipe maison . Quand personne dautre

ne lembarque, il assistera aux mles quotidiennes de cette quipe, aux
runions de planification de sprint, aux rtrospectives, etc.
Comment nous faisons les Scrums-de-Scrums

Le Scrum-des-Scrums est simplement une runion rgulire dans laquelle
tous les Scrum masters se rassemblent pour parler.
A un moment donn, nous avions quatre produits, dont trois dentre eux
avait une seule quipe Scrum, et le dernier avait 25 personnes rparties
dans plusieurs quipes Scrum. Quelque chose comme ceci :
Cela signifie que nous avions 2 niveaux de Scrums-de-Scrum. Nous

avions un Scrum-de-Scrums de niveau produit compos des quipes
du produit D, et un Scrum-de-Scrums niveau global compos de tous
les produits.
Scrum-de-Scrums de niveau produit

Cette runion est trs importante. Nous en faisons une par semaine,
parfois plus souvent. Nous y discutons des problmes dintgration, des
problmes dquilibrage de la charge des quipes, des prparations pour la
prochaine runion de planification de sprint, etc. Nous y allouons 30
minutes mais elles sont frquemment dpasses. Une alternative serait
davoir le Scrum-de-Scrums tous les jours, mais nous navons jamais pu
russir essayer a.
Lordre du jour de notre Scrum-de-Scrums est :

1) Tour de table, chacun dcrit ce que son quipe a accompli durant la
dernire semaine, ce quil prvoit de finir cette semaine, et quels sont
leurs obstacles.
2) Le moindre souci inter-quipe doit y tre rapport, par exemple des
problmes dintgration.
Lordre du jour du Scrum-de-Scrums nest pas vraiment important pour
moi, la chose importante est que vous teniez rgulirement les runions
Scrum-de-Scrums.
Scrum-de-Scrums de niveau global

Nous appelons cette runion Le pouls. Nous avons fait cette runion
avec de nombreux format, avec diffrent types de participants.
Tardivement nous avons laiss tomber le concept dans sa globalit et
lavons remplac par une runion gnrale hebdomadaire (eh bien, toutes
les personnes impliques dans le dveloppement) la place. 15 minutes.
Comment ? 15 minutes ? Runion gnrale ? Tous les membres de toutes
les quipes de tous les produits ? Est-ce que a marche ?
Oui a marche si vous (ou qui que ce soit qui mne la runion) tes strict
vis--vis de sa dure pour la garder courte.
Le format de la runion est :
1) Les nouvelles rcentes du responsable du dveloppement. Des infos sur
les vnements venir par exemple.
2) Tour de table. Une personne de chaque groupe dun produit indique ce
quils ont fini la semaine passe, ce quils comptent finir cette semaine, et
le moindre problme. Dautres personnes sexpriment aussi (responsable
CM, responsable QA, etc.).
3) Nimporte qui dautre est libre dajouter de linformation ou de poser
des questions.
Il sagit dun forum pour de linformation brve, pas de discussion ni de
cogitations. En le laissant comme cela, 15 minutes gnralement suffisent.
Parfois nous dpassons, mais trs rarement plus de 30 minutes au total. Si
des discussions intressantes surviennent je les suspends et invite ceux qui
sont intresss poursuivre la discussion aprs la runion.
Pourquoi faisons-nous une runion gnrale pouls ? Parce que nous
avons remarqu que dans les Scrums-de-Scrums niveau global il tait
question de reporting la plupart du temps. Nous avons rarement eu de
vraies discussions dans ce groupe. De plus, de nombreuses personnes en

dehors du groupe taient demandeurs de ce type dinformation.
Fondamentalement, les quipes veulent savoir ce que font les autres
quipes. Du coup nous nous sommes dit que si nous allions nous runir et
passer du temps sinformer les uns les autres sur ce que fait chaque
quipe, alors pourquoi ne pas laisser venir tout le monde tout simplement.
Intercaler les mles quotidiennes

Si vous avez beaucoup dquipes Scrum pour un seul produit, et quils
font tous la mle quotidienne en mme temps, vous avez un problme.
Le directeur de produit (et les gens fouineurs comme moi) peuvent
seulement assister une mle quotidienne par jour.
Nous demandons alors aux quipes dviter davoir les mles
quotidiennes en mme temps.
Lexemple de calendrier ci-dessus correspond la priode durant laquelle

nous avions des mles quotidienne dans des bureaux spars, plutt que
dans le bureau des quipes. Les runions durent normalement 15 minutes
mais chaque quipe se rserve un espace de 30 minutes au cas o il y
aurait besoin de dpasser lgrement.
Cest extrmement intressant pour deux raisons :
1. Les gens comme le directeur de produit et moi-mme pouvons
visiter toutes les mles quotidiennes dans une seule matine. Il
ny a pas de meilleur moyen dobtenir une vision raliste de ltat
du sprint, et des menaces cls.
2. Les quipes peuvent visiter les mles quotidiennes des autres
quipes. Cela narrive pas trop souvent, mais de temps en temps
deux quipes vont travailler sur une zone similaire, et ainsi
quelques membres se rendent visite dans les mles pour rester
synchroniss.

Linconvnient cest moins de libert pour lquipe ils ne peuvent pas
choisir le moment quils prfrent pour la mle. Toutefois cela ne sest
pas rvl tre un vritable problme pour nous.
Les quipes de pompiers

Nous avons eu une situation ou un gros produit tait incapable dadopter
Scrum parce que les membres de lquipe passaient beaucoup trop de
temps faire les pompiers, cest--dire corriger des bugs dans la
panique dans leur systme livr prmaturment. Ctait un vrai cercle
vicieux, ils taient si occups teindre les incendies quils navaient pas
le temps de travailler proactivement pour prvenir les feux (cest--dire
amliorer la conception, automatiser les tests, crer des outils de
surveillance, des outils dalarme, etc.).
Nous avons gr ce problme en crant une quipe de pompiers ddie, et
une quipe Scrum ddie.
Le travail de lquipe Scrum tait (avec la bndiction du directeur de
produit) dessayer de stabiliser le systme, et effectivement de prvenir
les incendies.
Lquipe de pompiers (nous les appelons support en ralit) avait deux
boulots :
1) Combattre les incendies.
2) Protger lquipe Scrum de toutes les sortes de perturbations, ce qui
inclut des choses comme parer des demandes de nouvelles fonctionnalits
ad-hoc provenant de nulle part.
Lquipe de pompiers tait place au plus prs de la porte ; lquipe
Scrum tait place au fond de la pice. Ainsi lquipe de pompiers pouvait
en fait protger physiquement lquipe Scrum des perturbations venant
par exemple de vendeurs impatients ou de clients mcontents.
Des dveloppeurs seniors taient placs dans les deux quipes, de telle
sorte quune quipe ne soit pas trop dpendante des comptences cls de
lautre quipe.
Ctait en fait une tentative de rsoudre un problme damorage de
Scrum. Comment pouvons nous commencer Scrum si lquipe na aucune
chance de planifier son travail plus dun jour lavance ? Notre stratgie a
donc t, comme mentionn ci-dessus, de partager le groupe.

Cela a plutt bien fonctionn. Comme lquipe Scrum avait reu du temps
pour travailler de manire proactive, ils ont finalement russi stabiliser
le systme. Pendant ce temps lquipe de pompiers avait compltement
abandonn la notion dtre capable de planifier lavance, ils travaillaient
uniquement de manire ractive, et corrigeaient juste la crise en cours.
Bien sr lquipe Scrum ntait pas compltement labri des
perturbations. Frquemment lquipe de pompiers devait impliquer des
personnes cls de lquipe Scrum, ou au pire lquipe en entier.
Nanmoins, aprs quelques mois, le systme tait suffisamment stable
pour que nous puissions enterrer lquipe de pompiers et crer des quipes
Scrum supplmentaires la place. Les pompiers taient plutt heureux de
ranger leurs casques abims et de rejoindre des quipes Scrum la place.
Partager le backlog de produit ou pas ?

Disons que vous avez un produit et deux quipes Scrum. Combien de
backlogs de produit devriez-vous avoir ? Combien de directeurs de
produit ? Nous avons valu trois modles pour cela. Le choix a un gros
effet sur la manire dont les runions de planning de sprint sont conduites.
Stratgie 1: un directeur de produit, un backlog

Cest le modle Il nen restera quUn . Notre modle prfr.
Le bon ct de ce modle est quil laisse les quipes se former peu prs
elles-mmes sur la base des priorits actuelles du directeur de produit. Le
directeur de produit peut se concentrer sur ce dont il a besoin, et peut
laisser les quipes dcider comment partager le travail.
Pour tre plus concret, voici comment la runion de planning de sprint

fonctionne pour cette quipe :
La runion de planning de sprint a lieu dans un centre de confrence
externe.
Juste avant la runion, le directeur de produit dsigne un mur comme le
mur du backlog de produit et y fixe des histoires dutilisateur (fiches
cartonnes), ordonnes par priorit relative.
Il continue en ajouter jusqu ce que le mur soit rempli, ce qui
habituellement constitue plus de travail que possible pour un sprint.
Chaque quipe Scrum slectionne une section de mur vide pour elle, et y
poste son nom dquipe. Cest leur mur dquipe . Chaque quipe
prend alors des histoires sur le mur de backlog de produit, en commenant

par les histoires de plus haute priorit, et place les fiches cartonnes sur
son propre mur dquipe.
Cest illustr par le diagramme ci-dessous, avec les flches jaunes qui
symbolisent le flux des fiches depuis le mur de backlog de produit vers les
murs des quipes.
Au fur et mesure de la progression de la runion, le directeur de produit

et les quipes marchandent sur les fiches cartonnes, les dplacent entre
les quipes, les dplacent vers le haut ou le bas pour changer les priorits,
les dcoupent en lments plus petits, etc. Aprs une heure environ,
chaque quipe a une premire version candidate de backlog de sprint sur
leur mur dquipe. Aprs cela, les quipes travaillent indpendamment, et
font la dcomposition en tches et lestimation en temps.
Cest bordlique et chaotique et puisant, mais galement efficace et

amusant et social. Quand le temps imparti est coul, toutes les quipes
ont gnralement suffisamment dinformations pour commencer leur
sprint.
Stratgie 2: un directeur de produit, plusieurs

backlogs
Dans cette stratgie, le directeur de produit maintient plusieurs backlogs
de produit, un par quipe. Nous navons pas vraiment essay cette
approche, mais nous en avons t proches. Cest en fait notre plan de
secours au cas o la premire approche choue.
La faiblesse de cette stratgie est que le directeur de produit assigne les
histoires aux quipes, un travail que les quipes sont probablement plus
qualifies faire elles-mmes.
Stratgie 3 : plusieurs directeurs de produit, un

backlog par directeur
Cest comme la seconde stratgie, un backlog de produit par quipe, mais
avec un directeur de produit par quipe galement !
Nous navons jamais fait cela, et nous ne le ferons probablement jamais.

Si les deux backlogs de produit impliquent la mme base de code, cela va
probablement causer de srieux conflits dintrt entre les deux directeurs
de produit.
Si les deux backlogs de produit impliquent des bases de code spares,
alors cela revient partager le produit total en sous-produits spars, et

les grer indpendamment. Cela signifie que nous sommes revenus la
situation une quipe un produit , ce qui est lgant et facile.
Branches de code
Avec plusieurs quipes qui travaillent sur la mme base de code, il est
invitable davoir grer des branches de code dans le systme de gestion
de configurations. Il y a beaucoup de livres et darticles sur la manire de
grer plusieurs personnes travaillant sur la mme base de code, donc je
nirais pas dans les dtails ici. Je nai rien de nouveau ou de
rvolutionnaire ajouter. Toutefois je vais rsumer quelques unes des
plus importantes leons que nos quipes ont apprises jusque l.
Soyez strict et gardez la ligne principale (ou tronc) dans

un tat cohrent. Cela signifie, au minimum, que tout
devrait compiler et que tous les tests unitaires devraient
passer. Il devrait tre possible de crer une version
livrable fonctionnelle nimporte quel moment. De
prfrence, le systme de build en continu devrait
construire et dployer automatiquement sur un
environnement de test toutes les nuits.
Etiquetez chaque version livre. Chaque fois que vous
livrez une version pour les tests dacceptation ou pour la
production, assurez-vous quil y a une tiquette de
version sur votre ligne principale, tiquette qui identifie
exactement ce qui a t livr. Cela signifie que vous
pouvez, nimporte quel point dans le futur, revenir en
arrire et crer une branche de maintenance depuis cette
tiquette.
Crez de nouvelles branches uniquement quand cest
ncessaire. Une bonne rgle empirique est de crer une
nouvelle branche de code uniquement quand vous ne
pouvez pas utiliser une ligne de code existante sans
violer la politique de cette ligne. En cas de doute, ne
crez pas de branche. Pourquoi ? Parce que chaque
branche active est couteuse en administration et
complexit.
Utilisez les branches principalement pour sparer
diffrents cycles de vie. Vous pouvez dcider ou non
davoir chaque quipe Scrum sur a propre ligne de code.
Mais si vous mlangez des corrections court terme avec
des changements long terme dans la mme ligne de
code, vous trouverez trs difficile de livrez les
corrections court terme !

Synchronisez souvent. Si vous travaillez sur une branche,

synchronisez avec la ligne principale chaque fois que
vous quelque chose qui compile. Tous les matins quand
vous arrivez au travail, synchronisez depuis la ligne
principale sur votre branche, de telle sorte que votre
branche soit jour par rapport aux modifications des
autres quipes. Si fusionner cest lenfer, acceptez
simplement le fait que cela aurait t bien pire
dattendre.
Rtrospectives multi-quipes
Comment faisons nous les rtrospectives de sprint quand plusieurs
quipes travaillent sur le mme produit ?
Immdiatement aprs la dmonstration du sprint, aprs les
applaudissements et le mlange gnral, chaque quipe part dans une
pice rserve pour elle, ou pour un endroit confortable lextrieur. Elles
font leurs rtrospectives peu prs comme je lai dcrit page 82
Comment nous faisons les rtrospectives de sprint .
Durant la runion de planning de sprint ( laquelle toutes les quipes
participent, puisque nous faisons des sprints synchroniss pour chaque
produit), la premire chose que nous faisons est de laisser un porte-parole
par quipe faire un rsum des points cls de leur rtrospective. Cela
prend environ 5 minutes par quipe. Ensuite nous avons une discussion
ouverte pendant 10 20 minutes. Puis nous faisons une pause. Ensuite
nous commenons le planning de sprint proprement dit.
Nous navons pas essay dautres manires, ceci marche suffisamment
bien. Le plus gros inconvnient est quil ny a pas de temps libre aprs la
rtrospective, et avant le planning. (voir page 88 Relcher le rythme
entre les sprints )
Pour les produits une seule quipe, nous ne faisons pas ce rsum de
rtrospective durant la runion de planning de sprint. Cela nest pas
ncessaire, puisque tout le monde tait prsent lors de la rtrospective du
sprint.
16
Comment nous grons les quipes
gographiquement disperses
Que se passe-t-il lorsque des membres de lquipe sont dans des lieux
gographiques diffrents ? Le plus gros de la magie de Scrum et XP
sappuie sur des quipiers colocaliss qui collaborent troitement en
programmant par paires et en se runissant chaque jour.
Nous avons des quipes spares gographiquement les unes des autres,
ainsi que des quipiers qui travaillent de chez eux de temps en temps.
Notre stratgie est alors assez simple. Nous employons toutes les ficelles
imaginables pour maximiser la bande passante utilise par les quipiers
spars physiquement, pour communiquer entre eux. Je ne parle pas
seulement de bande passante en termes de Mbits/seconde (bien que celleci soit videmment importante galement). Je parle de bande passante en
termes de communication, au sens plus large :

La capacit programmer par paires.

La capacit se rencontrer en tte--tte lors de la mle
quotidienne.
La capacit discuter en tte--tte tout moment.
La capacit se rencontrer physiquement et en dehors du
contexte du travail.
La capacit runir toute lquipe, de faon impromptue.
La capacit accder la mme vue du Sprint Backlog, du Sprint
Burndown, du Backlog des produits et dautres sources
dinformation.
Certaines des mesures que nous avons implmentes (ou que nous
sommes en train dimplmenter, elles ne sont pas encore toutes
oprationnelles) sont :
Une webcam et un casque avec microphone chaque station de
travail.
Des salles de confrence quipes pour la communication

distance avec des webcams, des microphones de confrence, des
ordinateurs allums en permanence, des logiciels de partage des
postes de travail, etc.
Des fentres distantes . De grands crans dans chaque lieu,
montrant en permanence une vue des autres lieux. Un peu comme
une fentre virtuelle entre deux services. Vous pouvez vous faire
des signes. Vous pouvez voir qui est son poste et qui parle
qui. Le but est de crer le sentiment que h, nous sommes tous
dans le mme bateau .
Des programmes dchange, lors desquels des personnes
provenant des divers lieux se rendent visite rgulirement.
En utilisant ces techniques ainsi que dautres, nous commenons

lentement mais srement nous habituer organiser des runions de
planification du sprint, des dmonstrations, des rtrospectives, des mles
quotidiennes, etc. avec les quipiers disperss gographiquement.
Comme dhabitude, cest une histoire dexprimentation. Inspecte =>
adapte => inspecte => adapte => inspecte => adapte => inspecte => adapte =>
inspecte => adapte
Dlocaliser Offshore
Nous avons plusieurs quipes offshore et exprimentons depuis un
certain temps des faons de grer la situation avec Scrum.
Il existe ici deux stratgies principales : des quipes spares et des
quipiers spars.
COMMENT NOUS GERONS LES EQUIPES DISPERSEES | 143
La premire stratgie, des quipes spares, est un choix incontestable.

Cependant, nous avons commenc par la seconde stratgie, des quipiers
spars. Pour cela, il y a plusieurs raisons.
1. Nous voulons que les quipiers se connaissent bien entre eux.
2. Nous voulons une excellente infrastructure de communication entre
les deux lieux et voulons fortement inciter les quipes la mettre en
place.
3. Au dbut, lquipe offshore est trop petite pour constituer une
quipe Scrum efficace elle seule.
4. Nous nenvisagerons la cration dquipes offshore quau terme
dune priode dchange intense des connaissances.

A long terme, il se peut que nous nous dirigions vers la stratgie des
quipes spares .
quipiers travaillant de la maison

Le travail accompli la maison peut tre quelquefois trs bon. Il arrive
daccomplir plus de programmation en un jour la maison quen toute
une semaine au bureau. Du moins si vous navez pas denfants :o)
Pourtant, lun des fondements de Scrum est que toute lquipe devrait tre
colocalise physiquement. Alors que fait-on ?
En gros nous laissons les quipes dcider delles-mmes quand et quelle
frquence il est acceptable de travailler de la maison. Certains quipiers
travaillent rgulirement de la maison afin dviter les longs trajets. Nous
encourageons cependant les quipes tre colocalises physiquement la
plupart du temps.
Lorsque les quipiers travaillent de la maison, ils participent la mle
quotidienne via un appel Skype (quelquefois avec vido). Ils sont en ligne
toute la journe via la messagerie instantane. Pas aussi bien que dtre
dans la mme pice, mais suffisant.
Nous avons une fois essay le concept de dsigner le mercredi comme
tant le jour de focalisation. En gros cela voulait dire si vous aimeriez
travailler de la maison, cest trs bien, mais faites-le le mercredi. Et restez
en contact avec votre quipe . Cela a assez bien fonctionn avec lquipe
sur laquelle nous lavons essay. En gnral la plupart des quipiers
restaient chez eux le mercredi et taient productifs, tout en collaborant
assez bien. Puisque cela ne durait quun jour, les quipiers restaient peu
prs synchroniss entre eux. Mais pour une raison inconnue, ce concept
na pas vraiment pris dans les autres quipes.
En gnral, le fait que des personnes travaillent de chez eux ne nous a pas
vraiment pos de problme.
17
Pense-bte du Scrum Master
Dans cet ultime chapitre, je vais vous montrer notre pense-bte du
Scrum master, qui inventorie les routines administratives les plus
courantes pour nos Scrum Masters. Des choses qui soublient facilement.
Nous passons sur les vidences telles que supprimer les obstacles
rencontrs par lquipe .
Dbut du Sprint

Aprs la runion de planification du Sprint, crer une page

dinformation du Sprint.
o Ajouter un lien cette page depuis le tableau de bord sur
le wiki.
o Imprimer la page et lafficher sur le mur prs de lquipe
et dun lieu de passage.
Envoyer un e-mail chacun pour annoncer quun nouveau Sprint
a dmarr. Y inclure le but du Sprint ainsi quun lien vers la page
dinformation du Sprint.
Mettre jour le document des statistiques du Sprint. Ajouter
votre vlocit estime, la taille de lquipe, la dure du Sprint,
etc.
Tous les jours

Sassurer que la Mle quotidienne commence et finit lheure.

Sassurer que les histoires sont ajoutes/supprimes du Sprint
Backlog autant que ncessaire pour respecter le planning du
Sprint.
o Sassurer que le directeur de produit est inform de ces
modifications.

Sassurer que lquipe tient le Backlog et le Burndown du Sprint

jour.
Sassurer que les problmes/obstacles sont rsolus ou
communiqus au directeur de produit et/ou au responsable du
dveloppement.
Fin du Sprint

Organisez une dmonstration publique lissue du Sprint.

Tout le monde devrait tre inform de la tenue de la
dmonstration un ou deux jours avant.
Organisez une rtrospective du Sprint en prsence de toute
lquipe et du directeur de produit. Invitez galement le
responsable du dveloppement afin quil puisse propager les
leons apprises.
Mettez jour le document des statistiques du Sprint. Ajoutez-y
la vlocit effective ainsi que les points cls de la rtrospective.
18
Mot de la fin
Eh bien ! Je naurais jamais cru que a deviendrait aussi long.
Jespre que ce papier vous a donn des ides utiles, que Scrum soit
nouveau pour vous ou que vous soyez un vtran chevronn.
Parce que Scrum doit tre faonn diffremment pour chaque
environnement, il est difficile de dbattre objectivement des meilleures
pratiques en gnral. Nanmoins, je suis intress par vos remarques.
Dites-moi en quoi votre approche diffre de la mienne. Donnez-moi des
ides damlioration !
Nhsitez pas me contacter henrik.kniberg@crisp.se.
Je garde aussi un il sur scrumdevelopment@yahoogroups.com.
Si vous avez aim ce livre, vous aurez peut-tre envie de jeter un il
mon blog de temps en temps. Jespre y ajouter des articles sur Java et le
dveloppement informatique agile.
http://blog.crisp.se/henrikkniberg/
Ah oui, et noubliez pas

Ce nest jamais quun boulot, non ?
Lectures recommandes
Voici quelques livres qui mont donn beaucoup dinspiration et dides.
Hautement recommands !
A propos de lauteur
Henrik Kniberg (henrik.kniberg@crisp.se) est un consultant chez Crisp
Stockholm (www.crisp.se), spcialis dans Java et le dveloppement
informatique Agile.
Ds lapparition des premiers livres sur XP et du manifeste agile, Henrik
adopta les principes agiles et essaya dapprendre les appliquer de faon
efficace dans diffrents types dorganisations. En tant que cofondateur et
Directeur Technique de Goyada entre 1998 et 2003, il et amplement
lopportunit dexprimenter avec le dveloppement dirig par les tests
ainsi que dautres pratiques agiles, alors quil construisait et manageait
une plateforme technique et une quipe de dveloppement de 30
personnes.
Fin 2005, Henrik effectua une mission en tant que responsable du
dveloppement dans une socit sudoise dans le domaine du jeu. La
socit tait en situation de crise avec des problmes organisationnels et
techniques urgents. Par lutilisation de Scrum et XP comme outils, Henrik
aida la socit sortir de sa crise en implmentant des principes agiles
tous les niveaux de la socit.
Un vendredi de novembre 2006, Henrik tait alit avec de la fivre et
dcida de prendre quelques notes sur ce quil avait appris pendant lanne
passe. Mais une fois quil et commenc crire, il ne pouvait plus
sarrter et aprs avoir tap sur son clavier et dessin pendant trois jours,
les notes initiales staient transformes en un article de 80 pages intitul
Scrum et XP depuis les Tranches , qui ventuellement devint ce livre.
Henrik adopte une approche holistique et apprcie de jouer diffrents
rles tels que manager, dveloppeur, Scrum Master, professeur et
entraneur. Aider les socits dvelopper des applications et des quipes
excellentes le passionne, adoptant tout rle quil juge ncessaire.
Henrik a grandi Tokyo et vit maintenant Stockholm avec son pouse
Sophia et leurs deux enfants. Durant son temps libre, il compose de la
musique et joue de la basse et du clavier avec des groupes locaux.
Pour plus dinformation, visitez http://www.crisp.se/henrik.kniberg

Scrum Et XP Depuis Les Tranchées

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Scrum Et XP Depuis Les Tranchées

Transféré par

Droits d'auteur :

Formats disponibles

Scrum et XP depuis les

2007 C4Media Inc

Rfrence de la bibliothque du Congrs Cataloguing-inPublication :

Table des matires

PREFACE DE MIKE COHN

COMMENT NOUS FAISONS LES BACKLOGS DE SPRINT..............55

LA PROGRAMMATION EN BINOME ..............................................................97

MOT DE LA FIN .......................................................................................147

Prface de Jeff Sutherland

ii | SCRUM ET XP DEPUIS LES TRANCHEES

Les itrations doivent tre de dure fixe et infrieure six

Le code la fin de l'itration doit tre test par le AQ et doit

Sur les 30 personnes qui prtendaient appliquer Scrum, seulement la

Une quipe Scrum doit avoir un Directeur de produit et doit

Prface de Mike Cohn

iv | SCRUM ET XP DEPUIS LES TRANCHEES

Cest pour cette raison que le sous-titre du livre, Comment nous

Henrik fournit une multitude de bonnes pratiques ainsi que

Prface - H, Scrum ca marche !

8 | SCRUM ET XP DEPUIS LES TRANCHEES

Pourquoi jai crit ceci

Mais Scrum, qu'est-ce que c'est ?

ID - un identifiant unique, juste un nombre auto-incrment. Cela

Nom - Un nom, une description courte de l'histoire. Par exemple

Importance - l'importance attribue par le directeur de produit

Je fais attention d'viter le terme priorit parce que la

Estimation initiale - l'valuation initiale de l'quipe sur la

12 | SCRUM ET XP DEPUIS LES TRANCHEES

BACKLOG DE PRODUIT (exemple)

COMMENT NOUS FAISONS LES BACKLOGS DE PRODUIT | 13

Champs d'histoire supplmentaires

Catgorie - un classement approximatif de cette histoire, par

14 | SCRUM ET XP DEPUIS LES TRANCHEES

souhaitez rendre plus facile pour chaque quipe de dcider

Comment nous gardons le backlog de produit

COMMENT NOUS FAISONS LES BACKLOGS DE PRODUIT | 15

le backlog de produit devrait exister ! (imaginez que non ?)

COMMENT NOUS PREPARONS LA REUNION DE PLANNING DE SPRINT | 17

Note : d'autres personnes que le directeur de produit peuvent ajouter des

Utiliser Jira (notre systme de suivi de bugs) pour hberger le

Un but pour le sprint.

Pourquoi le directeur de produit doit y assister

20 | SCRUM ET XP DEPUIS LES TRANCHEES

La porte et l'importance sont dtermines par le directeur de produit.

Essayer d'aider le directeur de produit comprendre pourquoi sa

COMMENT NOUS FAISONS LES PLANNINGS DE SPRINT | 21

reprsenter. Il aura les pleins pouvoirs pour changer la priorit et

Pourquoi la qualit n'est pas ngociable

La qualit externe est ce qui est peru par les utilisateurs du

22 | SCRUM ET XP DEPUIS LES TRANCHEES

Les runions de planning de sprint qui

COMMENT NOUS FAISONS LES PLANNINGS DE SPRINT | 23

Lordre du jour de la runion de planning de

24 | SCRUM ET XP DEPUIS LES TRANCHEES

Le choix de la dure du sprint

COMMENT NOUS FAISONS LES PLANNINGS DE SPRINT | 25

La dfinition du but du sprint

26 | SCRUM ET XP DEPUIS LES TRANCHEES

Le choix des histoires inclure dans le sprint

COMMENT NOUS FAISONS LES PLANNINGS DE SPRINT | 27

Comment le directeur de produit peut-il

Le directeur de produit est du que lhistoire D ne soit pas incluse dans le

28 | SCRUM ET XP DEPUIS LES TRANCHEES