scrum guide pratique.pdf

8/10/2019 scrum guide pratique.pdf

1/287


2/287

978-2-10-054833-0


3/287

Prface

Jai rencontr Claude une premire fois lors dune formation ScrumMaster que jaidonne Paris en 2005. Jai immdiatement remarqu Claude dans le groupe parson enthousiasme et sa volont de comprendre les valeurs et principes qui sont lesfondements de Scrum. Depuis Claude ne cesse de me surprendre par son engagement dfier lordre tabli et par sa gnrosit dans son travail.

Je suis personnellement fortement engag dans la communaut Agile et plusspcifiquement la communaut Scrum depuis 2001 car jai la ferme conviction quecest travers des gens qui ont intgr les valeurs et principes fondamentaux deScrum et qui les portent chaque jour dans leur travail que nous arriverons crer des

organisations de dveloppement logiciel o les rsultats, la qualit de vie et le plaisirpourront coexister de faon durable.

Je fais particulirement attention distinguer les gens de lapproche proprementdite car en ces temps o le rythme dadoption des approches agiles et en particulierScrum est ultra-acclr, et o de plus en plus de gens voient Scrum comme unoutil qui va magiquement rgler beaucoup de leurs difficults, il est fondamental decommuniquer sur les principes fondamentaux et les enjeux culturels lis son adoption.Si nous pouvions observer toutes les organisations qui ont du succs avec Scrum nous

trouverions invariablement des individus qui osent dfier lordre tabli avec tnacit,qui savent se mettre au service de lautre, se doter dune grande capacit dcoute etqui savent guider un groupe vers sa mission. De vrais ScrumMasters ! Claude est lundentre eux !

Vous aurez devin que jai t ravi lorsque Claude ma demand dcrire la prfacede son livre sur Scrum. Pourquoi ? Tout simplement parce que cest Claude ! Aussiparce que je me suis dit enfin un bouquin sur Scrum en franais. Il y a un manqueflagrant de titres en franais dans le domaine de linformatique et a ma toujours unpeu gn. Pourquoi nous francophones serions-nous moins capables dcrire ? Pourquoi

se contenter de traductions ?


4/287

IV Scrum

Claude nous offre un ouvrage en franais dune grande qualit. Il nous dmontre

travers le texte son talent de vulgarisateur. Dans un style trs accessible mais sanscompromis, il nous amne dcouvrir Scrum et comprendre comment nous pouvons

lappliquer dans nos organisations.Merci Claude et bonne lecture.

22 septembre 2009 dans un vol Montral-ParisFranois Beauregard

Fondateur de Pyxis Technologies (www.pyxis-tech.com)et deAgile Montral,formateur Scrum certifi depuis 2004.


5/287


6/287

VI Scrum

2.2.2 Activits et cycle de dveloppement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.3 Le rsultat dun sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.4 Le rsultat dune release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3 Guides pour les sprints et releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.1 Dmarrer le premier sprint au bon moment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3.2 Produire des micro-incrments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.3.3 Enchaner les sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.3.4 Utiliser le produit partiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3.5 Savoir finir la release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Chapitre 3 Le Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1 Responsabilits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1.1 Fournir une vision partage du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1.2 Dfinir le contenu du produit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1.3 Planifier la vie du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2 Comptences souhaites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2.1 Bonne connaissance du domaine mtier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2.2 Matrise des techniques de dfinition de produit. . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.3 Capacit prendre des dcisions rapidement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2.4 Capacit dtailler au bon moment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2.5 Esprit ouvert au changement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2.6 Aptitude la ngociation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.3 Choisir le Product Owner dune quipe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.3.1 Une personne disponible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.3.2 Une seule personne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.3.3 O le trouver dans lorganisation actuelle ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3.4 Une personne motive pour le rle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.4 Conseils pour progresser dans le rle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Chapitre 4 Le ScrumMaster et lquipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1 Responsabilits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.1.1 Responsabilits du ScrumMaster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.1.2 Responsabilits de lquipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44


7/287

Table des matires VII

4.2 Comptences souhaites du ScrumMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2.1 Bonne connaissance de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2.2 Aptitude comprendre les aspects techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2.3 Facilit communiquer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2.4 Capacit guider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2.5 Talent de mdiateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2.6 Tnacit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2.7 Inclination la transparence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2.8 Got tre au service de lquipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3 Choisir le ScrumMaster dune quipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3.1 Affectation au rle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3.2 O trouver la bonne personne ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.3.3 Quelquun qui incarne le changement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3.4 ScrumMaster, un tat desprit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3.5 Rotation dans le rle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.4 Conseils pour progresser dans le rle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Chapitre 5 Le backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.1 Le backlog, la liste unique des stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.1.1 Utilisateurs du backlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.1.2 Vie du backlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.1.3 Options de reprsentation du backlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2 La notion de priorit dans le backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2.1 Le sens de la priorit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2.2 Les critres pour dfinir la priorit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2.3 La gestion des priorits dans le backlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.3 Un lment du backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.3.1 Attributs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.3.2 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.3.3 Cycle de vie dun lment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.3.4 Taille des lments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.4 Guides dutilisation du backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.4.1 Partager le backlog avec toute lquipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.4.2 Bichonner le backlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65


8/287

VIII Scrum

5.4.3 Surveiller la taille du backlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.4.4 viter davoir plusieurs backlogs pour une seule quipe . . . . . . . . . . . . . . . . . . . . . 67

Chapitre 6 La planification de la release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.1 Planifier la release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.1.1 Planifier pour prvoir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.1.2 Runion ou processus ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.1.3 La participation de lquipe est requise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6.1.4 La release est planifie partir du backlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6.1.5 Place dans le cycle de vie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.2 tapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.2.1 Dfinir le critre de fin de la release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.2.2 Estimer les stories du backlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.2.3 Dfinir la dure des sprints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.2.4 Estimer la capacit de lquipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.2.5 Produire le plan de release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.3 Rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.3.1 Le plan de release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826.3.2 Burndown chart de release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.4 Guides pour la planification de release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6.4.1 Sadapter au calendrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6.4.2 Ne pas confondre valeur et cot, ni vlocit et productivit . . . . . . . . . . . . . . . . . . 87

6.4.3 Garder du mou pour les incertitudes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.4.4 Provisionner pour le feedback ultrieur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Chapitre 7 La runion de planification de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

7.1 Planifier le sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

7.1.1 Cest lquipe qui planifie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

7.1.2 Espace de travail ouvert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

7.1.3 Dure de la runion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

7.2 tapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

7.2.1 Rappeler le contexte du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

7.2.2 valuer le primtre potentiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

7.2.3 Dfinir le but du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95


9/287


10/287

X Scrum

Chapitre 9 La revue de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

9.1 La revue est base sur une dmonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

9.1.1 La revue accueille de nombreux invits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1209.1.2 Dure de la runion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

9.1.3 La revue montre le produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

9.2 tapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

9.2.1 Prparer la dmonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

9.2.2 Rappeler les objectifs du sprint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

9.2.3 Effectuer la dmonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

9.2.4 Calculer la vlocit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

9.2.5 Ajuster le plan de release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

9.3 Rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

9.3.1 Backlog de produit actualis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

9.3.2 Plan de release et burndown chart de release mis jour . . . . . . . . . . . . . . . . . . . . . 124

9.4 Guides pour la revue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

9.4.1 Drouler un scnario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

9.4.2 Inviter largement, mais expliquer que cest un produit partiel . . . . . . . . . . . . . . . . 126

9.4.3 viter de modifier le produit partiel au dernier moment . . . . . . . . . . . . . . . . . . . . . 126

9.4.4 Parler des stories, pas des tches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

9.4.5 Solliciter le feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

9.4.6 En faire la runion essentielle sur le produit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Chapitre 10 La rtrospective de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

10.1 Une pratique damlioration continue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

10.1.1 Un moment de rflexion collective la fin de chaque sprint. . . . . . . . . . . . . . . . . 131

10.1.2 Cest lquipe qui refait le match . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

1 0 . 2 t a p e s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

10.2.1 Crer un environnement propice lexpression. . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

10.2.2 Collecter les informations sur le sprint pass. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

10.2.3 Identifier des ides damlioration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

10.2.4 Regrouper les ides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

10.2.5 Dfinir lamlioration prioritaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

10.2.6 Adapter Scrum pour le prochain sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

10.3 Rsultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135


11/287

Table des matires XI

10.4 Guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

10.4.1 Ne pas en faire une sance de rglement de comptes. . . . . . . . . . . . . . . . . . . . . . . 135

10.4.2 Parler de ce qui va bien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13610.4.3 Faire aboutir les actions des rtrospectives prcdentes . . . . . . . . . . . . . . . . . . . . . . 136

10.4.4 Se concentrer sur une amlioration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

10.4.5 Mener des rtrospectives plus pousses en fin de release . . . . . . . . . . . . . . . . . . . . . 137

10.4.6 Utiliser un facilitateur externe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Chapitre 11 La signification de fini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

11.1 F ini, une pratique part entire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

11.1.1 Impact du mal fini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14011.1.2 Intrt davoir une signification de fini partage. . . . . . . . . . . . . . . . . . . . . . . . . . . 141

1 1 . 2 t a p e s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

11.2.1 Dfinir la signification de fini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

11.2.2 Publier la liste des contrles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

11.2.3 Utiliser la dfinition de fini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

11.3 Contenu de fini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

11.3.1 Fini pour une story . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14511.3.2 Fini pour un sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

11.3.3 Fini pour une release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

11.4 Guides pour une bonne pratique de fini. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

11.4.1 Faire des tranches verticales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

11.4.2 Adapter partir dune dfinition gnrique de fini. . . . . . . . . . . . . . . . . . . . . . . . . 148

11.4.3 Faire voluer la signification de fini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

11.4.4 Appliquer la pratique avec beaucoup de volont . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Chapitre 12 Adapter Scrum au contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

12.1 Pratiques agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

12.1.1 Pratiques Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

12.1.2 Pratiques complmentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

12.2 Risques dans la mise en uvre de Scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

12.3 Dfinir le contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

12.3.1 Influence de lorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

12.3.2 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157


12/287

XII Scrum

12.4 Impact du contexte sur les pratiques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

12.4.1 Impact par attribut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

12.4.2 Situation dun projet par rapport lagilit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Chapitre 13 De la vision aux stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

13.1 Le produit a une vie avant les sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

13.2 Construire une bonne vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

13.2.1 Techniques pour la vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

13.2.2 Qualits dune bonne vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

13.2.3 Une vision par release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

13.3 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

13.3.1 Justification du terme feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

13.3.2 Identification des features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

13.3.3 Attributs dune feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

13.3.4 Features et backlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

13.3.5 Features et priorit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

13.4 Rles dutilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

13.4.1 Intrt des rles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

13.4.2 Identification des rles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

13.4.3 Attributs dun rle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

13.4.4 Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

13.5 User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

13.5.1 Dfinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

13.5.2 Identifier les stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

13.5.3 Attributs dune story . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17413.5.4 Techniques de dcomposition des stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

13.5.5 Diffrence avec les use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

13.6 Amliorer lingnierie des exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

13.6.1 Exigences et spcifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

13.6.2 Traabilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

13.6.3 Exigences non fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

13.6.4 Avec quelle quipe ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179


13/287

Table des matires XIII

Chapitre 14 De la story aux tests dacceptation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

14.1 Test dacceptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

1 4 . 2 t a p e s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18314.2.1 Dfinir les conditions de satisfaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

14.2.2 crire les storytests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

14.2.3 Dvelopper la story . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

14.2.4 Passer les storytests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

14.3 Guides pour le test dacceptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

14.3.1 Se servir des tests pour communiquer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

14.3.2 Tester une story dans le sprint o elle est dveloppe. . . . . . . . . . . . . . . . . . . . . . . 18814.3.3 Ne pas stocker les bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

14.3.4 Connecter les tests dacceptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

14.3.5 Planifier le travail de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Chapitre 15 Estimations, mesures et indicateurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

15.1 Estimer la taille et lutilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

15.1.1 Estimation de la taille des stories en points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

15.1.2 Estimation de la valeur ou de lutilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

15.2 Collecter les mesures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

15.2.1 Mesures quotidiennes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

15.2.2 Mesures chaque sprint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

15.2.3 Mesures chaque release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

15.2.4 Autres mesures possibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

15.3 Utiliser les indicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

15.3.1 Indicateurs pour le suivi du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19715.3.2 Indicateurs pour le suivi du produit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

15.3.3 Indicateurs pour le suivi de la release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

15.4 Guides pour estimer, mesurer et publier les indicateurs . . . . . . . . . . . . . . . . . . . . . . 206

15.4.1 Une estimation nest pas un engagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

15.4.2 Pas de mesure du temps consomm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

15.4.3 Collecter les mesures ds le dbut dun dveloppement. . . . . . . . . . . . . . . . . . . . . 208

15.4.4 Considrer un outil pour la collecte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20815.4.5 Expliquer les indicateurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208


14/287

XIV Scrum

Chapitre 16 Scrum et lingnierie du logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

16.1 Pratiques autour du code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

16.1.1 Intgration continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21216.1.2 Pilotage par les tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

16.1.3 Programmation en binme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

16.2 Pratiques de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

16.2.1 Architecture volutive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

16.2.2 Conception mergente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

16.3 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

16.3.1 Il ny a pas de phase de maintenance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21716.3.2 Gestion des bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Chapitre 17 Scrum avec un outil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

17.1 Les outils Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

17.1.1 Les outils non informatiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

17.1.2 Les tableurs ou assimils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

17.1.3 Les outils spcifiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

17.2 Un exemple avec IceScrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

17.2.1 Les rles Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

17.2.2 Dmarrage dune release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

17.2.3 Droulement des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

17.2.4 Les tests dacceptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

17.2.5 Mesures et indicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Chapitre 18 La transition Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

18.1 Le processus de transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

18.1.1 Avec qui faire la transition ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

18.1.2 Cycle de transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

18.1.3 Backlog damlioration des pratiques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

18.1.4 Obstacles dorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

18.2 tapes du processus de transition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

18.2.1 valuer le contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

18.2.2 Prparer lapplication de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

18.2.3 Excuter Scrum sur un projet pilote. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246


15/287

Table des matires XV

18.2.4 Diffuser dans lorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

18.2.5 valuer le niveau atteint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

18.3 Impacts sur lorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25218.3.1 Lvaluation individuelle est contre-productive. . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

18.3.2 Pas de multitches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

18.3.3 Spcialistes vs gnralistes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

18.3.4 Cohabitation avec dautres processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Chapitre 19 Scrum en France . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

19.1 Scrum la franaise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

19.1.1 Utilisateurs de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25519.1.2 Retours dexprience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

19.1.3 Domaines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

19.1.4 Des particularits locales ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

19.2 Des freins la diffusion ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

19.2.1 MOA et MOE ne sont pas agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

19.2.2 Contrats au forfait, le mythe du primtre fix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

19.3 Le french flair pour Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

Rfrences bibliographiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265


16/287


17/287

Avant-propos

Depuis plus dune dizaine dannes, je conseille des entreprises et je forme destudiants sur les mthodes itratives et agiles. Depuis cinq ans, cet effort porte presque

exclusivement sur Scrum ; cela ma permis de participer une cinquantaine de projetsmens avec Scrum et de mimpliquer fortement dans le dveloppement du logiciellibre IceScrum (un outil pour Scrum1).

Sur le terrain, jai constat ce qui fonctionnait bien et ce qui fonctionnait moinsbien.travers ce livre, je souhaite vous faire partager mon exprience et les leonsapprises.

Vous y apprendrez appliquer les pratiques de Scrum en les adaptant auxcontraintes de votre environnement.

Mme si ce livre ne remplace pas une formation et encore moins une applicationconcrte, il prsente des conseils, des exemples, des retours dexprience et des guidesqui vous permettront doptimiser votre mise en uvre de Scrum.

Ce livre est destin tous ceux qui sintressent Scrum. Les novices y trouveront

une prsentation dtaille des pratiques, ceux qui en ont dj une connaissancetrouveront des conseils utiles.

Il intressera tous les membres des quipes (pas seulement les ScrumMasters) ayant

adopt Scrum ou tant sur le point de le faire, y compris les managers et les clients quisouhaitent se familiariser avec cette technique et son jargon.

Parcours de lecture : combien de sprints vous faut-il ?

Si vous cherchez une introduction brve aux mthodes agiles et Scrum, lisez leschapitres 1 et 2.

Si vous voulez connatre Scrum en dtail, lisez les chapitres 1 11. Les personnesjouant le rle de Product Owner liront en particulier le chapitre 3 et le chapitre 5, etles ScrumMasters le chapitre 4. Tous les membres de lquipe appliquant Scrum serontintresss par les chapitres 4 11.

1. Voir chapitre 17.


18/287

XVIII Scrum

4 5

6

10

11

Les chapitres relatifs aux pratiques Scrum

partir du chapitre 12 jusquau chapitre 16, laccent est mis sur les complments Scrum pour le dveloppement dun produit : le chapitre 12 prsente une approche

pour utiliser Scrum en tenant compte des contraintes des projets, les chapitres 13et 14 sont plutt destins ceux qui dfinissent le produit, les chapitres 15 et 16 auxdveloppeurs.

Le chapitre 17 prsente loutillage pour Scrum, le chapitre 18 propose des pistespour effectuer la transition dans de grandes organisations et le chapitre 19 aborde ladiffusion de Scrum en France.

Complments en ligne

Sur le sitewww.aubryconseil.com, vous trouverez les dernires informations relativesau livre, des articles complmentaires, des prcisions, des mises jour, ainsi que lesformations et les confrences de lauteur.

Remerciements

Mes relecteurs mont fourni unfeedbackprcieux, en mobligeant repenser certainesparties et en maidant les rendre plus accessibles. Je les remercie chaleureusementpour leur contribution ; il sagit dAlexandre B OUTIN, Thierry CRO S, et AntoineVERNOIS.

Je remercie galement Laure AUBRY, Jean-Pierre ODILE et Julien AUBRY quise sont investis dans la rvision du manuscrit et mont t trs prcieux par leurscommentaires.


19/287


20/287


21/287

Scrumsous la bannire de lagilit

1

1.1 LE MOUVEMENT AGILE

1.1.1 Mthode agile

Lesmthodes agilesreprsentent un mouvement novateur qui vise apporter plus devaleur aux clients et aux utilisateurs, ainsi quune plus grande satisfaction dans leurtravail aux membres de lquipe.

Le but affich dune mthode agile est de maximiser la valeur ajoute : le dve-loppement seffectuant par itrations successives, il est possible, la fin de chaqueitration, de changer les priorits en faisant en sorte que les lments apportant leplus de valeur soient raliss en premier.

Un meilleur accomplissement des personnes impliques dans un dveloppementest rendu possible par la notiondquipe auto-organise.

Une tentative de dfinition, adapte de Scott Ambler1, pourrait tre :Une mthode agile est une approche itrative et incrmentale pour le dveloppement delogiciel, ralis de manire trs collaborative par des quipes responsabilises, appliquant uncrmonial minimal, qui produisent un logiciel de grande qualit dans un dlai contraint,rpondant aux besoins changeants des utilisateurs.

Le crmonial cest ce qui dfinit les rgles sociales et conventionnelles rgissantla vie dune quipe ; sil est vrai que, pour une mthode agile, il est minimal pour

1. http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm


22/287


23/287


24/287

4 Chapitre 1. Scrum sous la bannire de lagilit

La formule du succs : agilit 1, nimporte quoi dautre 0.

Ce nest pas une dfinition, cest plutt un constat, difiant sur la place de lagilit

dans lingnierie du logiciel.

1.1.4 Pratiques agiles

Si la culture agile est nouvelle, despratiquesmaintenant qualifiesdagilesexistaientavant, pour certaines avant leManifeste agileet mme avant les premires mthodesagiles.

Un certain nombre de pratiques sont reconnues depuis longtemps par la commu-naut des spcialistes du gnie logiciel, par exemple :

livrer frquemment et rgulirement le logiciel, faire des cycles de dveloppement courts et limits dans le temps, constituer une quipe complte pour un dveloppement, grer les membres de lquipe en les responsibilisant, avoir le reprsentant des utilisateurs sur le mme site que le reste de lquipe, produire des plans plusieurs niveaux : dtaills uniquement pour le court terme,

et plus gnraux pour le moyen terme, dvelopper en intgrant le code de faon continue, faire des bilans de projet dans le but damliorer la faon de travailler.

Dautres sont apparues avec les mthodes agiles et sont devenues indiscutables,aprs avoir t prouves sur de nombreux projets :

avoir unbacklogde produit tenant compte des priorits, suivre lavancement des projets par la tenue dune runion quotidienne, crire les tests avant dcrire le code, pratiquer, de temps en temps, le travail en binme, technique qui consiste

avoir deux personnes derrire un seul cran pour partager les connaissances.

Prises individuellement, ces pratiques sont dj efficaces. Insres dans le cadrecohrent dune approche agile, elles se renforcent mutuellement, et contribuent laqualit du produit et son utilit.

Lagilit oui, la pagaille non

Des utilisateurs, brims depuis longtemps par leur direction des systmes dinformation

(DSI), dcouvrent que lagilit peut accueillir et mme favoriser les changements, ce

qui les amne penser quils peuvent tout changer tout le temps.Des managers se disent quavec lagilit, il leur sera plus facile de demander leurs

quipes de traiter une urgence par du travail supplmentaire non prvu.Non ! Lagilit favorise le changement, mais ne le rend pas gratuit ni permanent. Si la

demande de changement venue dun utilisateur est la bienvenue, sa prise en comptepasse par une gestion des priorits et elle est toujours diffre : une quipe qui travaille

ne doit pas tre perturbe nimporte quand.


25/287

1.2 Survol de Scrum 5

1.1.5 Des mthodes agiles Scrum

Les mthodes agiles existaient avant le Manifeste: Scrum et Extreme Programming

datent des annes 1990. LeLean Softwarerepose sur des bases encore plus anciennes :le systme de production dans les usines Toyota dans les annes 1950.

Il y a eu de nombreuses autres mthodes qualifies dagiles ou de semi-agiles. LeManifeste en nonant les valeurs et les principes communs a contribu les fdrertoutes derrire la mme bannire de lagilit.

Plus rcemment, lengouement pour Scrum (la ScrumMania!) a mis fin unehypothtique rivalit entre les mthodes agiles. Les tudes dopinion et les tendancesdes recherches sur le Web le montrent : Scrum est de loin la plus populaire dans lafamille des mthodes agiles.

Maintenant que Scrum a gagn1

, la difficult majeure est damener ses utilisateurs en faire un usage correct, sous la bannire de lagilit.

1.2 SURVOL DE SCRUM

Le nom vient du rugby

On prononce screum pas scrume , ni scroum .Scrum signifie mle au rugby. Scrum utilise les valeurs et lesprit du rugby et les

adapte aux projets de dveloppement. Comme le pack lors dun ballon port aurugby, lquipe charge du dveloppement travaille de faon collective, soude vers un

objectif prcis. Comme un demi de mle, le ScrumMaster aiguillonne les membresde lquipe, les repositionne dans la bonne direction et donne le tempo pour assurer

la russite du projet.

Au-del de cet accent mis sur la puissance du collectif, Scrum est un processusagile qui attaque la complexit par une approche empirique.

Scrum, un truc qui marche

On est naturellement tent de parler de mthode agile ou de processus agile pourScrum. En fait, la dfinition officielle, celle donne par la Scrum Alliance2 et sonfondateur Ken Schwaber est lgrement diffrente. Scrum nest prsent ni commeun processus ni comme une mthode.

Le plus souvent, Ken Schwaber dcrit Scrum comme un cadre (framework) ; dautres occasions il en parle comme dune voie suivre (path) ou dun outil et ilrevient processus... Un spcialiste des processus parlerait, pour Scrum, de patternde processus, orient gestion de projet, qui peut incorporer diffrentes mthodes oupratiques dingnierie.

1. lheure o jcris ces lignes (septembre 2009), mais a peut changer.2. http://www.scrumalliance.org


26/287


27/287

1.2 Survol de Scrum 7

Transparence La transparence garantit que tous les indicateurs relatifs ltatdu dveloppement sont visibles par tous ceux qui sont intresss par le rsultatdu produit. Non seulement la transparence pousse la visibilit mais ce qui est

rendu visible doit tre bien compris ; cela signifie que ce qui est vu est bien lereflet de la ralit. Par exemple, si un indicateur annonce que le produit est fini

(ou une partie seulement du produit), cela doit tre strictement quivalent lasignification de fini dfinie par lquipe.

Inspection Les diffrentes facettes du dveloppement doivent tre inspectessuffisamment souvent pour que des variations excessives dans les indicateurspuissent tre dtectes temps.

Adaptation Si linspection met en vidence que certains indicateurs sonten dehors des limites acceptables, il est probable que le produit rsultant seragalement inacceptable si on ne ragit pas ; le processus doit donc tre ajust

rapidement pour minimiser les futures dviations.Il y a trois points dinspection et dadaptation dans Scrum :

Le scrum quotidienpermet dinspecter la progression par rapport au but dusprintet de faire des adaptations qui optimisent la valeur du travail du joursuivant.

La planification et la revue de sprintsont utilises pour inspecter lavan-cement du dveloppement par rapport au but de la release et faire desadaptations sur le contenu du produit pour le prochainsprint.

La rtrospectiveinspecte la faon de travailler dans lesprintpour dterminer

quelles amliorations du processus peuvent tre faites dans le prochainsprint.

1.2.2 lments

Le cadre Scrum consiste en une quipe avec des rles bien dfinis, des blocs de temps(timeboxes) et des artefacts (figure 1.1) :

Rles Timeboxes Artefacts

Product

Owner ScrumMaster

quipe

Planification

derelease

Planificationdesprint

Scrumquotidien

Revuedesprint

Rtrospective

Backlogdeproduit

Planderelease

Plandesprint

Burndowndesprint

Burndownderelease

Figure 1.1 lments de Scrum


28/287

8 Chapitre 1. Scrum sous la bannire de lagilit

quipe et rles Lquipe a un rle capital dans Scrum : elle est constitueavec le but doptimiser la flexibilit et la productivit ; pour cela, elle sorganise

elle-mme et doit avoir toutes les comptences ncessaires au dveloppement

du produit. Elle est investie avec le pouvoir et lautorit pour faire ce quelle a faire.

Timeboxes Scrum utilise des blocs de temps pour crer de la rgularit. Lecur du rythme de Scrum est le sprint, une itration dun mois ou moins. Danschaquesprint, le cadre est donn par un crmonial lger mais prcis bas desrunions.

ArtefactsScrum exige peu dartefacts lors du dveloppement : le plus remar-quable est lebacklogde produit, pivot des diffrentes activits.

Quelques rgles liant les lments compltent ce cadre simple. Toutefois, derrire

lapparente simplicit de Scrum se cache une grande puissance pour mettre envidence le degr defficacit des pratiques de dveloppement utilises.


29/287

Des sprintspour une release

2

Jai pris part des dizaines de projets, soit en tant que dveloppeur, soit en tant que

consultant et il ny en a pas deux qui se soient drouls de la mme faon, bien quecertains aient suivi le mme processus. Il y a une grande variation dans le droulementtemporel dun projet, appel lecycle de dveloppement (ou cycle de vie).

Un cycle est dfini par desphaseset desjalons. Les phases se succdent et un jalonpermet de contrler le passage la phase suivante : une phase a des objectifs et lejalon est l pour vrifier quil ny a pas de dviation par rapport ces objectifs.

Phase

A

Phase

B PhaseC PhaseD

Temps

Figure 2.1 Dans un cycle traditionnel, chaque phase est diffrente

videmment le cycle est influenc par le modle de cycle (ou processus) quonutilise. Un modle ancien, encore rpandu en France, est lecycle en V, mais le plussouvent une entreprise, surtout si elle grande, a dfini son propre modle de cycle.

Dans certaines entreprises, lapplication du modle est fortement recommandeet dans dautres lquipe a plus de latitude. Bien souvent, et quel que soit le degr de

recommandation, jai constat quil y avait un grand cart entre le modle et sa miseen uvre sur les projets.


30/287

10 Chapitre 2. Des sprints pour une release

Il y a plusieurs raisons pour lexpliquer :

Le modle est bien souvent trop thorique, labor par des mthodologistesloigns des ralits, et inapplicable sur le terrain.

Les contrles sont difficiles faire lors des jalons, parce quils portent souventsur une multitude de documents.

Les jalons tant franchis sans difficult,lquipe accumule les travaux non faitsdes phases prcdentes.

Scrum fait partie des approches itratives et incrmentales, dont le modle de cycle

de dveloppement est bas sur une phase qui se rpte plusieurs fois successivement.Cest la notion ditration, appele sprintavec Scrum. Tous les sprintsse droulentselon le mme schma et on y fait chaque fois les mmes types de travaux.

Sprint Sprint Sprint Sprint

Temps

Figure 2.2 Avec Scrum, le processus se rpte chaque sprint

Cest une diffrence majeure avec les mthodes traditionnelles pour lesquelles les

travaux sont de nature diffrente pour chaque phase. Cela a un effet sur les objectifs dechaquesprint: ils ne sont pas dfinis par le cadre Scrum, cest lquipe qui sen charge.

Cest de ce cycle de dveloppement et de ses implications dont il est question dans

ce chapitre.

Dfinitions

Sprintest le terme utilis dans Scrum pouritration. Dans le langage Scrum, unsprint

est un bloc de temps fix aboutissant crer un incrment du produit potentiellement

livrable.Releasepeut avoir plusieurs sens :Releasecomme version Le dictionnaire du jargon informatique franais dfinitune release comme suit : version dun logiciel effectivement diffuse, donc lche

dans la nature. Synonyme de Mise sur le march . Exemple : Unix system V release4. Cette dfinition nonce clairement quil y a des versions qui ne constituent pas

desreleases.Releasecomme priode de temps Par extension, on appelle galementreleasela priode de temps qui permet de la produire. On devrait dire le cycle de production

dune release, mais lusage en anglais, et maintenant en franais, est dutiliser releasecomme priode de temps, notamment dans lexpression plan derelease. Cest ce sens,

priode de temps compose desprints,qui est utilis pourreleasedans ce livre.


31/287

2.1 Lapproche itrative et incrmentale 11

2.1 LAPPROCHE ITRATIVE ET INCRMENTALE

2.1.1 Incrment et itration

Scrum utilise une approche itrative et incrmentale pour le dveloppement dunproduit.

Incrmental

Incrmental est utilis pour mettre en vidence laccroissement du produit obtenu la fin de chaquesprint. Un processus incrmental permet de construire un produitmorceau par morceau, chaque nouvelle partie venant sajouter lexistant.

Pour lcriture de ce livre, jai utilis une approche incrmentale : jai fait un planinitial et jai rdig chapitre par chapitre, sans respecter lordre du plan, dailleurs.

La pratique dun cycle incrmental est rpandue dans les dveloppements delogiciel ; on parle souvent de lots pour les incrments qui font lobjet dun contrat.

Itratif

Itrer est laction de rpter. Dans le calcul scientifique, litration est un procdde calcul rptitif qui permet, par exemple, de trouver la racine dun nombre, dunequation, par approximations successives.

Dans le dveloppement de logiciel, le termeitrationest utilis pour dsigner unepriode de temps dans laquelle sont effectues des activits, qui seront rptes dansles prochaines itrations. Le terme est souvent associ processus.

Exemple: un article duNouvel Observateur (grand public, donc) de juillet 2008 meten exergue les itrations du processus dAmazon, qui expliquent, selon lauteur, lessuccs de lentreprise.

Un processus itratif permet de revenir sur ce qui a t fait, dans le but delamliorer ou de le complter. Cela part de lide quil est difficile, voire impossible,

de bien faire la premire fois. Lefeedbackcollect sur le rsultat dune itration permetde faire des amliorations dans la suivante. On cesse ditrer quand la qualit obtenueest juge satisfaisante.

Pour lcriture de ce livre, jai utilis une approche itrative : jai diffus le premierjet des lecteurs et grce leurfeedback, jai produit une nouvelle version.


32/287


33/287

2.1 Lapproche itrative et incrmentale 13

2.1.2 Bloc de temps

Lessprintsont tous la mme dure : Scrum sappuie sur la notion de bloc de temps

limit (timebox).Il ny a pas que lessprintsqui sonttimeboxsavec Scrum : de nombreuses activits

dun dveloppement sont bases sur cette notion. Cela se manifeste en particulier

dans les runions qui constituent le crmonial.

Pas de sprint extensible

Pour lesprint, la notion detimeboxsapplique de la faon suivante : on ne change pasla date de fin une fois que lesprinta commenc. Mme si on na pas fini tout ce quonvoulait faire, on garde la date de fin prvue.

Pourquoi ? Cela permet dviter le syndrome du presque fini (ou fini 90 %), o,finalement, la date de fin est repousse plusieurs fois.

Jai accompagn de nombreux projets, agiles ou pas. Jai eu trs souvent desdemandes dquipes venant ngocier la date dun jalon. Ces quipes me disentquelles ont un tout petit peu de retard et demandent repousser la date dune revue

de deux ou trois jours. Jur, avec ce dlai, ce serait mieux et on aurait tout ce quitait prvu.videmment la plupart du temps, aprs ce laps de temps supplmentaire,il en aurait fallu encore un peu... Les dveloppeurs ont tendance tre optimistes.

La notion de bloc de temps vite les drives : la date prvue, on fait uneinspection objective de lavancement et on ajuste en consquence la planification desprochainssprints.

Rythme rgulier

La dure dessprintsest toujours la mme, dans la mesure du possible. Lintrt est dedonner un rythme lquipe, qui va apprendre produire rgulirement.

Lobjectif est dviter des situations de sur-rgime que lquipe ne pourra pas tenir

bien longtemps. Pousser une quipe travailler au-del de son rgime de croisire ades effets de bord ngatifs sur la qualit de son travail : le nombre de dfauts augmente,

la motivation diminue, les pratiques dingnierie sont ngliges...

Au contraire, un rythme rgulier peut tre conserv longtemps, voire indfiniment.Il prsente dautres avantages : comme on connat les dates de dbut et de sprintlavance, les revues sont plus faciles organiser et les intervenants peuvent planifierleur participation.

Ressources rgulires

Le bloc de temps dlimite la quantit de travail faite pendant le sprint. Il est le mmepour tous lessprints: il dpend de la dure du sprintet de la taille de lquipe qui sontfixes toutes les deux, au moins sur une certaine priode.


34/287


Timebox

Dure

Re

ssources

Figure 2.4 Le bloc de temps

Comme pour le dveloppement de logiciel, le cot est directement corrl auxressources, le budget dunsprintpeut tre dduit de latimebox.

Il est prfrable que la composition de lquipe reste stable pendant unsprint. Il estaussi souhaitable de garder une quipe stable pour unerelease, ce qui permet davoirdestimeboxesquivalentes pour tous lessprints.

2.1.3 Dure du sprint

La dure dun mois ou moins correspond lhorizon de prdictibilit : la fin dusprint, les prvisions sont ajustes en fonction du contrle effectu sur les rsultats

obtenus. Pour les dveloppements complexes qui sont la cible privilgie de Scrum,on considre que ne pas rguler le processus pendant plus dun mois, ce serait prendretrop de risques.

Aux dbuts de Scrum, la rgle tait de faire dessprintsdun mois, sans variation.Par exemple, si le dveloppement commenait avec une anne calendaire :

premiersprintdu premier au 31 janvier, deuximesprintdu premier au 28 (ou 29) fvrier, troisimesprintdu premier au 31 mars...

Aujourdhui, on constate une tendance faire dessprintsplus courts : en effet, pourle dveloppement de logiciel, les pratiques dingnierie, comme lintgration continueet les outils associs, permettent de produire des versions partielles plus frquemment.

Quelques infos pratiquesUne enqute faite en avril 2009 sur mon blog (www.aubryconseil.com) auprs dunecentaine de personnes donnait les rsultats prsents figure 2.5.Lessprintsde deux ou trois semaines reprsentent la majorit des rponses.


35/287


36/287


37/287

2.2 Cycle de dveloppement Scrum 17

Avec Scrum, chacun des sprints a un objectif qui porte sur un produit qui fonctionne(et pas seulement sur des documents), ce qui ncessite du travail dans toutes lesactivits de dveloppement pendant unsprint.

Les activits se droulent en parallle pendant lesprint(figure 2.9) :

S

A

C

T

S

A

C

T

S

A

C

T

S

A

C

T

S

A

C

T

Sprint1 5

CycleScrum

Touteslesactivits

Figure 2.9 Dessprintset leurs activits en parallle

lautre extrme, un processus dit squentiel droule les activits en squence,avec une activit par phase (figure 2.10) :

S A C T

Uneactivitparphase

Cyclesquentiel

Figure 2.10 Phases avec des activits squentielles

Avec un processus activits squentielles, unephaseest dfinie avec un objectifexprim par une liste de documents produire ; elle dure assez longtemps quelquesmois et sa dure est variable (lquipe sarrte lorsque les objectifs sont atteints) ;le rsultat porte uniquement sur des documents au dbut, et mme assez tard dans le

dveloppement : le logiciel test nest obtenu qu la fin. Suivre au pied de la lettrecette approche revient avoir :

100 % de la spcification fonctionnelle dtaille avant de commencer le code, 100 % de la conception avant de commencer le code, 100 % du code pour commencer les tests.

Cest un modle idal mais utopique : dans la ralit on revient toujours sur lesactivits des phases prcdentes, et en particulier dans la phase de test, on revient surles spcifications, la conception et le code (figure 2.11).

S A C T

T

C

A

S

Figure 2.11 Retour sur les activits prcdentes pendant le test


38/287


Ce dcalage entre le modle et la ralit est une des raisons du retard des projets etde leur qualit mdiocre.

Avec une mthode agile comme Scrum, les activits de spcification et deconception sont continues. On part du principe que larchitecture va voluer, dans une

certaine limite, pendant la vie du projet. Lapproche est plus raliste et pragmatique.Lautre principe important est que les tests sont pratiqus ds le premiersprint.

Il existe aussi de nombreux dveloppements qui sont mens de faon chaotique,sans suivre de processus ou en le suivant larrache1. Le plus souvent, il ny a mmepas de spcification ni de conception. Lquipe se lance directement dans le codage,qui est suivi dune longue priode de test et de corrections de bugs.

Avec Scrum, la qualit nest pas nglige, et la conception fait partie des activits

de chaquesprint.

2.2.3 Le rsultat dun sprint

Linspection2, afin de faire des adaptations, est la base de la thorie de Scrum.

la fin dunsprint, le rsultat attendu est un incrment du produit final, qui estpotentiellement livrable. Cest ce que montre le clbre schma de Mike Cohn quejavais traduit en franais en 2005 (figure 2.12).

livrable

Figure 2.12 Cycle de vie Scrum simplifi lpoque du schma, en 2005, javais (mal !) traduit potentially shippable

par potentiellement utilisable. Cest potentiellementlivrable.

1. La mthode larracheest bien connue, voir http://www.la-rache.com2. Linspection du produit est dcrite dans le chapitre 9 La revue de sprint. Linspection du processusest dcrite dans le chapitre 10La rtrospective de sprint.


39/287

2.3 Guides pour les sprints et releases 19

Le produit ne doit pas tre seulement potentiellement utilisable la fin dunsprint, il doit simplement tre utilisable. Certes, il nest pas complet par rapport cequi est prvu dans larelease, mais il est livrable, au moins des utilisateurs privilgis.

Dans le cas dun dveloppement de logiciel, le minimum est davoir dploy, lafin dunsprint, le produit potentiellement livrable, avec si ncessaire la documentationpermettant de lutiliser.

2.2.4 Le rsultat dune release

Le rsultat de lareleaseest le produit livrable, fourni ses utilisateurs. La faon dont ilest fourni dpend de la nature du dploiement de ce produit.

La distinction avec le rsultat dusprintse fait sur lepotentiellement. Le but est de

faire en sorte que cette distinction soit la plus tnue possible voire quelle disparaisse.Cest trs variable selon le contexte du projet : des dploiements trs frquents sontpossibles pour des applications web hberges...

Exemple : eBay re-dploie ses applications tous les quinze jours et pour Amazoncest du dploiement continu.

...mais pas pour des applications internes ajoutes un gros systme dinformation,ni pour des systmes embarqus.

Souvent, le jalon majeur que reprsente la release correspond une annonce

marketing : loccasion de la sortie du produit, les quipes marketing prparentun matriel pour sa promotion.

2.3 GUIDES POUR LES SPRINTS ET RELEASES

Avec Scrum, la notion de cycle de vie est peu mise en vidence. Le premier articlede Ken Schwaber voquait trois phases : une premire Planning & Architecture, ladeuxime constitue dessprintset une dernire phase appeleClosure. Ces notionssont aujourdhui abandonnes. Nanmoins, il y a bien trois priodes distinctes dans

unerelease(figure 2.13) :

La priode centrale, celle dessprints. La priode avant le premiersprint. Une priode aprs le derniersprintet avant la fin de larelease.


40/287


Sprint1 Sprint2 Sprint3 Sprint4Release

Finde

releaseDbutde

releaseLessprints

Figure 2.13 Les trois priodes dune release

2.3.1 Dmarrer le premier sprint au bon moment

Le dveloppement dunereleasecommence par des travaux particuliers faire avantde lancer lessprintssuccessifs, comme constituer lquipe, dfinir la vision, produireunbackloginitial et une premire planification de la release. Si lareleaseen questionest la premire dans la vie du produit, il conviendra galement de faire des travaux de

dfinition de produit1 et darchitecture avant de lancer lessprints.

Figure 2.14 Le lancement des sprintsse prpare

La priode de temps en dbut de release est parfois appele le sprint zro. Sprintzro est trompeur parce que cette priode nest pas un sprintcomme les autres : sadure est variable, les tches quon y fait sont spcifiques de cette phase, il ny a pasle crmonial habituel des sprints, on ne produit pas une version potentiellementutilisable la fin, on ne mesure pas de vlocit...

lusage je trouve que cest une trs mauvaise appellation, dangereuse. Au-del duvocabulaire, ce quil faut bien comprendre cest quil sagit dune phase diffrentede la srie dessprintsqui va suivre. Elle est prdictive alors que la phase dessprintsest empirique, le but nest pas de produire un incrment de produit comme pour

1. Voir aussi, le chapitre 13De la vision aux stories.


41/287


chaquesprint. Le risque avecsprintzro est que cette distinction ne soit pas perueet que cette phase prparatoire soit nglige.

Le premiersprintne doit pas dmarrer trop longtemps aprs le dbut de la release(il ne sagit pas dy caser les activits de spcification et de conception dtailles),mais cela dpend du contexte : il faut videmment plus de temps dans le cas dunepremire release dun nouveau projet sappuyant sur une nouvelle technologie quepour sa nimerelease.

Ce nest pas non plus une bonne chose de dmarrer trop vite : avant que laplanification derelease ne soit labore, cest prmatur de commencer le premiersprint.

2.3.2 Produire des micro-incrmentsUnsprintne se droule pas en travaillant successivement sur les activits (spcificationpuis conception puis codage puis test) : un sprintnest pas un mini-cycle en V .Lquipe travaille pour dvelopper des fonctionnalits ds le dbut du sprint, ce quipermet de produire pendant le sprint ce quon peut appeler des micro-incrments(figure 2.15).

SprintnSprintn1

Micro-incrments

Incrment

defindesprint

Figure 2.15 Production de micro-incrments

Dans le cadre dun dveloppement logiciel, ces micro-incrments sont des ver-sions intermdiaires produites pendant le sprint. Elles sont utilises par lquipe dedveloppement et le Product Owner pour passer les tests fonctionnels.

2.3.3 Enchaner les sprints

Si on se rfre lathltisme, objet de la mtaphore, on ne peut pas sprinterpendanttoute la dure de la course de fond que constitue une release, il faut des phases dercuprations.

Ce nest pas moi qui vais dire le contraire : jai couru en longue distance. Jai encorele souvenir des entranements en fractionn : par exemple une srie de dix fois200 m avec 30 secondes de rcupration entre chaque.


42/287


Figure 2.16 La fatigue de lquipe aprs unsprint fond

Certains membres de lquipe le font savoir lors des rtrospectives : ils souhaitentdes jours de rcupration entre les sprints. Parmi toutes les quipes que jai suiviesdepuis cinq ans, la plupart se contentent dun week-end avant de repartir sur unnouveausprint : la revue et la rtrospective se font le vendredi (mais ce nest pasobligatoire de caler lessprintssur les semaines) et le prochainsprintdmarre le lundiqui suit par la runion de planification.

Dautres consacrent un jour entre chaque sprint des activits hors projet ; unequipe a instaur unbug dayintercalaire. Jai aussi connu des quipes qui choisissaientde sarrter une semaine tous les trois ou quatresprints.

Et puis certaines quipes enchanent directement : par exemple, fin de sprintlemardi, dbut du sprint suivant le mercredi matin, par exemple. Cest le mode de

fonctionnement optimal. Les situations o les quipes prouvent le besoin de sarrterentre lessprintssont souvent le reflet dun dysfonctionnement. Le termesprint, quoncourt fond et aprs lequel on rcupre, est trompeur. Un dveloppement avec Scrumsapparente plus une course un rythme rgulier, sans pause chaque tape.

2.3.4 Utiliser le produit partiel

En plus de sa prsentation la revue de sprint, on peut identifier trois usages de laversion produite en fin desprint, pour un dveloppement de logiciel.

Utilisation interne La version nest pas utilise en dehors de lquipe dedveloppement. Elle a t produite pour chercher minimiser les risques lis la technologie et la capacit de lquipe intgrer diffrents composants.


43/287


Elle nest pas livre lextrieur de lquipe. Cela est frquent au dbut dunnouveau dveloppement.

Utilisation pour feedback par des utilisateurs slectionns La version est

utilise par un client ou des utilisateurs privilgis. Cela leur donne la possibilitde la prendre en main, ce qui permet de rduire les risques portant sur linterface.

Ces utilisateurs pourront valuer la facilit dutilisation des fonctionnalits eten proposer de nouvelles. Les retours faits iront alimenter lebacklogpour priseen compte ultrieure.

Mise en production La version est mise en production ou en exploitation etutilise par ses utilisateurs finaux. Cest videmment ce quil faut viser puisquechaque nouvelle version apporte de la valeur. Autant lapporter le plus ttpossible, ds quelle est disponible. Mais ce nest gnralement pas faisable demettre en production la fin de chaque sprint: trop de temps serait pris, par

rapport la dure du sprint, pour passer les tests de recette sur tout le systme,pour dployer sur lenvironnement de production, pour crire les manuelsutilisateurs, pour prparer et donner la formation aux utilisateurs...

Cest pourquoi, dans la plupart des cas, ltat du produit la fin1 de chaquesprintest distingu de celui souhait la fin dune release.

Mais si on russit automatiser le dploiement et limiter le temps pour le faire,on peut alors mettre en production plus souvent qu la fin desreleases. Dans ce cas-l,le produit nest plus simplement potentiellement livrable la fin de chaquesprint, ilest livr. Le terme dereleasegarde son sens de priode de temps pour la planification.

2.3.5 Savoir finir la release

Faire le plus possible pendant lessprintsvite de devoir poursuivre le travail aprs ledernier sprint. Si ltat du produit partiel en fin desprintest quivalent ltat attenduen fin derelease, la fin du derniersprintconcidera avec la fin de larelease.

Ce nest pas possible dans tous les contextes et dans certains cas, il faut unepriode de temps entre la fin du dernier sprint et la fin de la release pour faire destravaux ncessaires avant la mise en production. Ces travaux varient selon le type de

dploiement : mise en production chaud, packagingdu produit, mise dispositionpar tlchargement en ligne...

Cette priode tait auparavant appelesprintde stabilisation. Ce ntait pas unebonne ide, cela laissait entendre que le logiciel ntait pas stable avant. Les termes de

sprintdereleaseou desprintde durcissement parfois voqus sont tout aussi discutables :

il vaut mieux rendre le produit plus robuste chaquesprintplutt que de le faire la fin,

si malgr tout, il y a des travaux de durcissement faire avant de livrer larelease,cela ne rentre pas dans le cadre dun sprint.

1. La signification de fini fait lobjet du chapitre 11 .


44/287


En rsum

Avec Scrum, un produit est dvelopp selon une approche itrative et incrmentale.Lesprintdonne le rythme auquel sont produites des versions partielles potentielle-ment livrables du produit. Lareleaseest la squence de sprints lissue de laquelle leproduit est livr aux utilisateurs.


45/287


46/287

26 Chapitre 3. Le Product Owner

marketing, nous essayions de le masquer, lors des prsentations aux commerciaux etaux utilisateurs.

Cest pour viter ce manque dunit dans le contenu dun produit que leProductOwnerexiste dans Scrum. Sa raison dtre cest de sassurer que le travail fait apportede la valeur aux utilisateurs. Il est responsable de la dfinition du contenu du produitet de la gestion des priorits pour son dveloppement.

Lexistence du Product Owner permet aussi dviter, comme dans mon histoire, laprdominance de la Technique dans un dveloppement de produit. Son boulot, cestde dire lquipe quel produit raliser. Il est le seul avoir cette responsabilit. Celavite les conflits dintrts survenant lorsquelle est partage entre plusieurs personnes.

lpoque, si javais connu le rle, jaurais bien aim tre Product Owner. Le temps

a pass et depuis que je pratique Scrum, cest le rle que jai le plus exerc sur desprojets. En particulier, je suis, depuis plusieurs annes, le Product Owner du produitIceScrum, un outilopen sourcede gestion de projet avec Scrum.

Cest de ce rle et de mes expriences dont il est question dans ce chapitre.

Product Owner vs directeur de produit

Jai dabord appris Scrum par la lecture de livres et darticles, tous en anglais. Jai

naturellement traduit Product Owner en propritaire de produit quand je mexprimais propos de ce rle.Le terme propritaire peut tre satisfaisant pour celui qui joue le rle : il peut dire cest

mon produit ! . Ayant fait, il y a quelques annes, des travaux sur les processus mtier

(Business Process Managementou BPM), je me souviens du rle de Process Owner,

le propritaire de processus . Mon exprience avec des propritaires de processusmincline penser que finalement cette ide de propritaire nest pas bonne. Le terme

ne reflte pas la vraie nature du rle : le Product Owner aime son produit certes, mais

il ne le possde pas plus que le reste de lquipe, et moins que ses utilisateurs.En 2005, jai suivi une formation Scrum en franais donne par Franois1 , un

Qubcois. Le support de cours tait en franais aussi. Product Owner y tait traduiten Administrateur du produit . Cet intitul na jamais pris en France et je ne croispas que nos cousins du Canada laient conserv non plus.Un peu plus tard, suite la lecture dun article de Brian Marick (How to be a ProductDirector2), jai adopt le terme directeur de produit. Jen ai parl dans plusieurs

billets de mon blog3, pendant quelques mois.

1. Franois Beauregard, prfacier de cet ouvrage.2. http://www.testing.com/cgi-bin/blog/2006/04/21# how-to-be-a-product-diretor3. www.aubryconseil.com


47/287

Le Product Owner 27

Figure 3.1 Un propritaire de produit un peu possessif

Larticle en franais de Wikipedia sur Scrum1

a repris le terme. lheure o jcrisces lignes, directeur de produit apparat toujours dans cet article, dailleurs. Ce qui faitque cette traduction de Product Owner a eu un certain succs et que je rencontre

toujours des personnes qui lutilisent. La version franaise de Scrum et XP depuis lestranches2 la reprise galement.Pourtant, jai arrt dutiliser directeur de produit pour revenir langlais Product

Owner (mais en le prononant la franaise). Le mot directeur ne passait pas dans des

organisations : celui qui tenait le rle ntait pas un directeur au sens hirarchique. Le

Product Owner donne bien la direction, mais il na pas de responsabilit hirarchiquesur des personnes.

En 2007, jai fait un petit sondage auprs des utilisateurs de Scrum et finalement cestProduct Owner qui est apparu convenir le mieux. Mme dans les administrations

franaises !Depuis je reste fidle lappellationProduct Owner, PO en abrg, et jai limpression

que cest le cas de la majorit des personnes de la communaut franaise de Scrum.

1. http://fr.wikipedia.org/wiki/Scrum2. http://henrik-kniberg.developpez.com/livre/scrum-xp/


48/287


3.1 RESPONSABILITS

Le Product Owner a desresponsabilitsimportantes, portant la fois sur la stratgie

et la tactique dans le cadre du dveloppement dun produit.Il prend des dcisions de niveau stratgique qui sont dhabitude du ressort de la

direction du projet ou des comits de pilotage. Le Product Owner dcide dans desdomaines qui sont ceux dun chef de projet traditionnel, par exemple la date delivraison du produit.

Le Product Owner prend aussi de nombreuses dcisions de niveau tactique quisont habituellement prises par une quipe de dveloppement, faute dimplication des clients . En effet, en leur absence, les dveloppeurs ont tendance faire des choixqui ne sont pas, en principe, de leur responsabilit.

Un Product Owner prsent et impliqu fera ces choix tactiques, comme parexemple lapparence et le contenu dun formulaire pour un site marchand.

Attention: mme si le Product Owner a des responsabilits, il ne faut pas le considrer

comme quelquun qui impose ses choix de faon autoritaire ; beaucoup de travaux

quil mne se font en quipe et ses dcisions sont prises, chaque fois que cest

important, en accord avec elle.

Le rle de Product Owner varie beaucoup avec le contexte de lorganisation,cependant il est possible didentifier ses responsabilits majeures :

Fournir

unevisionpartage

duproduit

Dfinir

soncontenu

Grer

soncycle

devie

Figure 3.2 Responsabilits du Product Owner

3.1.1 Fournir une vision partage du produit

Le Product Owner est responsable de dfinir lobjectif du produit et de le partager aveclquipe qui le dveloppe.

Sans tre obligatoirement un visionnaire comme Steve Jobs, le Product Owner doitavoir une bonne vision du produit. La vision se construit au dbut du dveloppementdun nouveau produit et se consolide ensuite. Elle consiste typiquement dfinir :

lnonc du problme que le produit veut rsoudre, une position du produit qui soit claire pour tout le monde, une liste des fonctionnalits essentielles.


49/287

3.2 Comptences souhaites 29

Chaque membre de lquipe et toutes les parties prenantes du projet doiventpartager la mme vision1, et cest au Product Owner de sen assurer.

3.1.2 Dfinir le contenu du produit

Le Product Owner dfinit le contenu du produit. Pour cela, il identifie les fonctionna-

lits requises et les collecte dans une liste, appele le backlogde produit2.

Concrtement, le Product Owner est responsable du backlog de produit et ycontribue de faon rgulire. En plus de son travail pour lesprintcourant, il passe unebonne partie de son temps sur les lments dubacklogprvus pour lessprintssuivants.

Comme il est moteur pour tablir ce que doit faire le produit, il est logique quilfournisse aussi ses conditions de satisfaction, qui permettront de sassurer que ce quil

demande est bien ralis : il est donc impliqu dans les tests dacceptation3.

3.1.3 Planifier la vie du produit

Cest le Product Owner qui dfinit lordre dans lequel les parties du produit serontdveloppes. Il doit alimenter lquipe avec les fonctionnalits dvelopper, selon sespriorits dfinies en fonction de la valeur quelles apportent.

Lordre de ralisation dfinit le cycle de vie du produit. Cette vie est constituedune succession de versions (lesreleases). Le Product Owner dfinit lobjectif dune

release et prend les dcisions sur son contenu et sa date de mise disposition duproduit.

En rsum, sil na pas dautorit formelle sur des personnes, le Product Owner aune grande influence sur le produit ralis.

3.2 COMPTENCES SOUHAITES

La personne idale pour jouer ce rle devrait possder les comptences prsentesfigure 3.3.

On imagine quune personne avec ce profil idal est un oiseau rare dans la plupartdes organisations.

1. Pour plus dinformations, voir le chapitre 13De la vison aux stories.2. Lebacklogfait lobjet du chapitre 5.3. Les tests dacceptation font lobjet du chapitre 14De la story aux tests.


50/287


Bonneconnaissancedudomainemtier

Matrisedestechniquesdedfinitiondeproduit

Capacit

prendre

des

dcisions

rapidement

Capacitdtailleraubonmoment

Espritouvertauchangement

Aptitudelangociation

Figure 3.3 Les comptences souhaites dun Product Owner

3.2.1 Bonne connaissance du domaine mtier

Ce quon appelle le mtier (business), et quon retrouve en franais dans lexpressioncur de mtier, constitue un domaine de connaissances en relation avec le quoi et lepourquoi dun produit. Le quoi (what), cest ce que doit faire le produit. Le pourquoi(why), cest la justification de lexistence du produit et de son contenu, en termes defonctionnalits.

Une bonne connaissance du domaine mtier est fondamentale pour le ProductOwner, puisquil est le reprsentant dans lquipe de toutes les personnes qui utilisent

ou font utiliser le produit ; celui tant dvelopp pour rendre des services cespersonnes, par exemple en automatisant des parties dun processus.

Le Product Owner peut avoir acquis cette connaissance parce quil est un desutilisateurs potentiels et cest souvent le cas dans les entreprises qui dveloppent desproduits usage interne ; dans celles produisant pour des clients externes, le ProductOwner vient souvent des quipes marketing ou produit.

On ne demande pas un Product Owner de tout connatre du domaine fonc-tionnel : sur des produits de grande taille, cela peut tre une gageure ou demander

beaucoup de temps pour tout connatre du mtier. Il sappuiera, quand cela savrerancessaire, sur les bonnes personnes pour assumer pleinement son rle.

3.2.2 Matrise des techniques de dfinition de produit

Le Product Owner dfinit ce que fait le produit. Il a besoin pour cela davoir lamatrise des techniques de collecte des besoins et de leur transformation en lmentsdu backlog de produit. Traditionnellement, dans le dveloppement de logiciel, la

discipline dingnierie des exigences (requirements engineering) est celle qui dfinit leprocessus de collecte de ce que doit faire le produit.


51/287

3.2 Comptences souhaites 31

Scrum ne prescrit pas de technique particulire pour identifier les lments dubacklog, Cependant le constat fait sur le terrain est que la pratique la plus frquemmentassocie Scrum est celle des user stories1.

La connaissance, et si possible la pratique des techniques de dfinition de produit,est requise pour le Product Owner.

3.2.3 Capacit prendre des dcisions rapidement

Choisir entre plusieurs alternatives sur des sujets dimportance varie, cela arrivequotidiennement sur un projet : pour des raisons defficacit, le Product Owner doitpouvoir le faire seul, sans en rfrer une hirarchie ou une autorit suprieure. Pourcela, il est essentiel quil ait la confiance des diffrents intervenants : il doit les voir

rgulirement, les consulter sur les lments du backlogquil connat mal et sur lespriorits pour lareleaseen cours.

Si les avis de ces intervenants sont contradictoires, ce qui ne manquera pas darriver,le Product Owner doit avoir lautorit pour dcider et fdrer les points de vue en uneseule proposition.

Il ne suffit pas quune personne dcide, il faut aussi que ses dcisions soientrespectes et appliques. Le Product Owner entrane lquipe en faisant en sorte quetout le monde adhre pleinement aux choix sur le contenu du produit.

3.2.4 Capacit dtailler au bon momen

scrum guide pratique.pdf

Documents