Vous êtes sur la page 1sur 287

978-2-10-054833-0

Prface

Jai rencontr Claude une premire fois lors dune formation ScrumMaster que jai donne Paris en 2005. Jai immdiatement remarqu Claude dans le groupe par son enthousiasme et sa volont de comprendre les valeurs et principes qui sont les fondements de Scrum. Depuis Claude ne cesse de me surprendre par son engagement der lordre tabli et par sa gnrosit dans son travail. Je suis personnellement fortement engag dans la communaut Agile et plus spciquement la communaut Scrum depuis 2001 car jai la ferme conviction que cest travers des gens qui ont intgr les valeurs et principes fondamentaux de Scrum 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 plaisir pourront coexister de faon durable. Je fais particulirement attention distinguer les gens de lapproche proprement dite car en ces temps o le rythme dadoption des approches agiles et en particulier Scrum est ultra-acclr, et o de plus en plus de gens voient Scrum comme un outil qui va magiquement rgler beaucoup de leurs difcults, il est fondamental de communiquer 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 der lordre tabli avec tnacit, qui savent se mettre au service de lautre, se doter dune grande capacit dcoute et qui savent guider un groupe vers sa mission. De vrais ScrumMasters ! Claude est lun dentre eux ! Vous aurez devin que jai t ravi lorsque Claude ma demand dcrire la prface de son livre sur Scrum. Pourquoi ? Tout simplement parce que cest Claude ! Aussi parce que je me suis dit enn un bouquin sur Scrum en franais. Il y a un manque agrant de titres en franais dans le domaine de linformatique et a ma toujours un peu gn. Pourquoi nous francophones serions-nous moins capables dcrire ? Pourquoi se contenter de traductions ?

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 sans compromis, 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-Paris Franois Beauregard Fondateur de Pyxis Technologies (www.pyxis-tech.com) et de Agile Montral, formateur Scrum certi depuis 2004.

Table des matires

Prface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

III

Avant-propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII Chapitre 1 Scrum sous la bannire de lagilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Le mouvement agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 1.1.2 1.1.3 1.1.4 1.1.5 Mthode agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manifeste agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lagilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pratiques agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Des mthodes agiles Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 1 2 3 4 5 5 6 7 9 11 11 13 14 15 15

1.2 Survol de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 1.2.2 Thorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapitre 2 Des sprints pour une release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Lapproche itrative et incrmentale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 2.1.2 2.1.3 Incrment et itration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bloc de temps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dure du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2 Cycle de dveloppement Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Laspect temporel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

VI

Scrum

2.2.2 2.2.3 2.2.4

Activits et cycle de dveloppement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le rsultat dun sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le rsultat dune release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16 18 19 19 20 21 21 22 23 25 28 28 29 29 29 30 30 31 31 31 32 32 33 34 36 36 36 41 42 42 44

2.3 Guides pour les sprints et releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 Dmarrer le premier sprint au bon moment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Produire des micro-incrments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enchaner les sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Utiliser le produit partiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Savoir nir la release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapitre 3 Le Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Responsabilits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 3.1.2 3.1.3 Fournir une vision partage du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dnir le contenu du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Planier la vie du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2 Comptences souhaites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 Bonne connaissance du domaine mtier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Matrise des techniques de dnition de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . Capacit prendre des dcisions rapidement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Capacit dtailler au bon moment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Esprit ouvert au changement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aptitude la ngociation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3 Choisir le Product Owner dune quipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 3.3.2 3.3.3 3.3.4 Une personne disponible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Une seule personne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . O le trouver dans lorganisation actuelle ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Une personne motive pour le rle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4 Conseils pour progresser dans le rle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapitre 4 Le ScrumMaster et lquipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Responsabilits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 4.1.2 Responsabilits du ScrumMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Responsabilits de lquipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Table des matires

VII

4.2 Comptences souhaites du ScrumMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6 4.2.7 4.2.8 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 Bonne connaissance de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aptitude comprendre les aspects techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Facilit communiquer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Capacit guider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Talent de mdiateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tnacit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inclination la transparence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Got tre au service de lquipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Affectation au rle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . O trouver la bonne personne ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Quelquun qui incarne le changement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ScrumMaster, un tat desprit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rotation dans le rle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44 45 45 45 46 46 46 47 47 47 47 48 49 49 50 50 55 56 58 58 60 60 60 60 62 62 62 63 63 64 65 65 65

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

4.4 Conseils pour progresser dans le rle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapitre 5 Le backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Le backlog, la liste unique des stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 5.1.2 5.1.3 5.2.1 5.2.2 5.2.3 5.3.1 5.3.2 5.3.3 5.3.4 5.4.1 5.4.2 Utilisateurs du backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vie du backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Options de reprsentation du backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le sens de la priorit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Les critres pour dnir la priorit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . La gestion des priorits dans le backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Attributs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cycle de vie dun lment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Taille des lments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Partager le backlog avec toute lquipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bichonner le backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

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

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

VIII

Scrum

5.4.3 5.4.4

Surveiller la taille du backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viter davoir plusieurs backlogs pour une seule quipe . . . . . . . . . . . . . . . . . . . . .

66 67 69 70 70 70 71 71 72 73 73 75 78 80 81 82 82 83 86 86 87 87 88 89 90 90 91 92 93 93 94 95

Chapitre 6 La planication de la release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Planier la release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 6.1.2 6.1.3 6.1.4 6.1.5 Planier pour prvoir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Runion ou processus ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . La participation de lquipe est requise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . La release est planie partir du backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Place dans le cycle de vie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.2 tapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 Dnir le critre de n de la release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estimer les stories du backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dnir la dure des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estimer la capacit de lquipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Produire le plan de release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.3 Rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 6.3.2 Le plan de release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Burndown chart de release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.4 Guides pour la planication de release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.1 6.4.2 6.4.3 6.4.4 Sadapter au calendrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ne pas confondre valeur et cot, ni vlocit et productivit . . . . . . . . . . . . . . . . . . Garder du mou pour les incertitudes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Provisionner pour le feedback ultrieur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapitre 7 La runion de planication de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1 Planier le sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1.1 7.1.2 7.1.3 Cest lquipe qui planie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Espace de travail ouvert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dure de la runion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.2 tapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.1 7.2.2 7.2.3 Rappeler le contexte du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . valuer le primtre potentiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dnir le but du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Table des matires

IX

7.2.4 7.2.5 7.2.6 7.2.7

Identier les tches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estimer les tches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prendre des tches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sengager collectivement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

95 96 97 98 98 98 99 100 100 101 101 101 102 102 103 105 106 106 107 108 108 109 110 111 111 111 112 114 114 114 115 116 117

7.3 Rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.1 7.3.2 7.4.1 7.4.2 7.4.3 7.4.4 7.4.5 7.4.6 7.4.7 Plan de sprint initial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backlog et burndown charts actualiss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prparer le backlog de produit en anticipation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Laisser lquipe dcider du primtre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Laisser lquipe identier les tches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dcomposer en tches courtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prendre un engagement raisonnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Garder du mou dans le plan de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Faire de la conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.4 Guides pour la planication de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapitre 8 Le scrum quotidien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1 Une runion quotidienne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.1 8.1.2 8.2.1 8.2.2 8.2.3 8.3.1 8.3.2 8.3.3 Le sprint appartient lquipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Un crmonial balis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Se runir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rpondre aux trois questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Statuer sur latteinte des objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le plan de sprint actualis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le burndown chart de sprint actualis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . La liste des obstacles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.2 tapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.3 Rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.4 Guides pour le scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.1 8.4.2 8.4.3 8.4.4 8.4.5 Sen tenir un quart dheure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ne sintresser quau reste faire, pas au temps pass . . . . . . . . . . . . . . . . . . . . . Faire le suivi des tches avec les tats plutt que les heures . . . . . . . . . . . . . . . . . . Veiller nir les stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Organiser des variations dans le droulement du scrum . . . . . . . . . . . . . . . . . . . . .

Scrum

Chapitre 9 La revue de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1 La revue est base sur une dmonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.1 9.1.2 9.1.3 9.2.1 9.2.2 9.2.3 9.2.4 9.2.5 9.3.1 9.3.2 9.4.1 9.4.2 9.4.3 9.4.4 9.4.5 9.4.6 La revue accueille de nombreux invits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dure de la runion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . La revue montre le produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prparer la dmonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rappeler les objectifs du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Effectuer la dmonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Calculer la vlocit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ajuster le plan de release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backlog de produit actualis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Plan de release et burndown chart de release mis jour . . . . . . . . . . . . . . . . . . . . . Drouler un scnario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inviter largement, mais expliquer que cest un produit partiel . . . . . . . . . . . . . . . . viter de modier le produit partiel au dernier moment . . . . . . . . . . . . . . . . . . . . . Parler des stories, pas des tches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Solliciter le feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . En faire la runion essentielle sur le produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

119 119 120 120 121 121 121 122 122 123 123 124 124 124 125 125 126 126 127 127 127 129 130 131 131 132 132 133 133 133 134 134 135

9.2 tapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.3 Rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Chapitre 10 La rtrospective de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1 Une pratique damlioration continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.1 Un moment de rexion collective la n de chaque sprint . . . . . . . . . . . . . . . . . 10.1.2 Cest lquipe qui refait le match . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 tapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.1 Crer un environnement propice lexpression . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.2 Collecter les informations sur le sprint pass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.3 Identier des ides damlioration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.4 Regrouper les ides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.5 Dnir lamlioration prioritaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.6 Adapter Scrum pour le prochain sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3 Rsultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Table des matires

XI

10.4 Guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4.1 Ne pas en faire une sance de rglement de comptes . . . . . . . . . . . . . . . . . . . . . . . 10.4.2 Parler de ce qui va bien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4.3 Faire aboutir les actions des rtrospectives prcdentes . . . . . . . . . . . . . . . . . . . . . . 10.4.4 Se concentrer sur une amlioration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4.5 Mener des rtrospectives plus pousses en n de release . . . . . . . . . . . . . . . . . . . . . 10.4.6 Utiliser un facilitateur externe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapitre 11 La signication de ni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Fini, une pratique part entire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.1 Impact du mal ni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.2 Intrt davoir une signication de ni partage . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 tapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.1 Dnir la signication de ni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.2 Publier la liste des contrles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.3 Utiliser la dnition de ni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Contenu de ni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3.1 Fini pour une story . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3.2 Fini pour un sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3.3 Fini pour une release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.4 Guides pour une bonne pratique de ni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.4.1 Faire des tranches verticales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.4.2 Adapter partir dune dnition gnrique de ni . . . . . . . . . . . . . . . . . . . . . . . . . 11.4.3 Faire voluer la signication de ni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.4.4 Appliquer la pratique avec beaucoup de volont . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapitre 12 Adapter Scrum au contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.1 Pratiques agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.1.1 Pratiques Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.1.2 Pratiques complmentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2 Risques dans la mise en uvre de Scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3 Dnir le contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3.1 Inuence de lorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3.2 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

135 135 136 136 137 137 137 139 139 140 141 142 142 143 144 144 145 146 147 147 147 148 149 149 151 152 152 153 154 155 156 157

XII

Scrum

12.4 Impact du contexte sur les pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.1 Impact par attribut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.2 Situation dun projet par rapport lagilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapitre 13 De la vision aux stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.1 Le produit a une vie avant les sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.2 Construire une bonne vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.2.1 Techniques pour la vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.2.2 Qualits dune bonne vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.2.3 Une vision par release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.3 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.3.1 Justication du terme feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.3.2 Identication des features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.3.3 Attributs dune feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.3.4 Features et backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.3.5 Features et priorit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.4 Rles dutilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.4.1 Intrt des rles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.4.2 Identication des rles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.4.3 Attributs dun rle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.4.4 Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.5 User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.5.1 Dnition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.5.2 Identier les stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.5.3 Attributs dune story . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.5.4 Techniques de dcomposition des stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.5.5 Diffrence avec les use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.6 Amliorer lingnierie des exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.6.1 Exigences et spcications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.6.2 Traabilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.6.3 Exigences non fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.6.4 Avec quelle quipe ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

158 158 162 165 165 166 166 167 167 168 168 169 170 170 170 171 171 172 172 172 173 173 174 174 175 176 176 176 176 177 179

Table des matires

XIII

Chapitre 14 De la story aux tests dacceptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.1 Test dacceptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.2 tapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.2.1 Dnir les conditions de satisfaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.2.2 crire les storytests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.2.3 Dvelopper la story . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.2.4 Passer les storytests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.3 Guides pour le test dacceptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.3.1 Se servir des tests pour communiquer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.3.2 Tester une story dans le sprint o elle est dveloppe . . . . . . . . . . . . . . . . . . . . . . . 14.3.3 Ne pas stocker les bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.3.4 Connecter les tests dacceptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.3.5 Planier le travail de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapitre 15 Estimations, mesures et indicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.1 Estimer la taille et lutilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.1.1 Estimation de la taille des stories en points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.1.2 Estimation de la valeur ou de lutilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.2 Collecter les mesures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.2.1 Mesures quotidiennes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.2.2 Mesures chaque sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.2.3 Mesures chaque release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.2.4 Autres mesures possibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.3 Utiliser les indicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.3.1 Indicateurs pour le suivi du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.3.2 Indicateurs pour le suivi du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.3.3 Indicateurs pour le suivi de la release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.4 Guides pour estimer, mesurer et publier les indicateurs . . . . . . . . . . . . . . . . . . . . . . 15.4.1 Une estimation nest pas un engagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.4.2 Pas de mesure du temps consomm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.4.3 Collecter les mesures ds le dbut dun dveloppement . . . . . . . . . . . . . . . . . . . . . 15.4.4 Considrer un outil pour la collecte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.4.5 Expliquer les indicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

181 182 183 183 184 186 186 188 188 188 189 189 190 191 192 192 193 196 196 196 197 197 197 197 198 205 206 206 207 208 208 208

XIV

Scrum

Chapitre 16 Scrum et lingnierie du logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.1 Pratiques autour du code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.1.1 Intgration continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.1.2 Pilotage par les tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.1.3 Programmation en binme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.2 Pratiques de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.2.1 Architecture volutive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.2.2 Conception mergente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.3 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.3.1 Il ny a pas de phase de maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.3.2 Gestion des bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapitre 17 Scrum avec un outil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.1 Les outils Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.1.1 Les outils non informatiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.1.2 Les tableurs ou assimils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.1.3 Les outils spciques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.2 Un exemple avec IceScrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.2.1 Les rles Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.2.2 Dmarrage dune release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.2.3 Droulement des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.2.4 Les tests dacceptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.2.5 Mesures et indicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapitre 18 La transition Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.1 Le processus de transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.1.1 Avec qui faire la transition ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.1.2 Cycle de transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.1.3 Backlog damlioration des pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.1.4 Obstacles dorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.2 tapes du processus de transition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.2.1 valuer le contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.2.2 Prparer lapplication de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.2.3 Excuter Scrum sur un projet pilote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

211 212 212 213 214 215 216 216 217 217 217 221 221 221 222 223 224 224 225 235 237 238 241 241 242 242 243 243 243 243 244 246

Table des matires

XV

18.2.4 Diffuser dans lorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.2.5 valuer le niveau atteint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3 Impacts sur lorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.1 Lvaluation individuelle est contre-productive . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.2 Pas de multitches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.3 Spcialistes vs gnralistes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.3.4 Cohabitation avec dautres processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapitre 19 Scrum en France . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19.1 Scrum la franaise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19.1.1 Utilisateurs de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19.1.2 Retours dexprience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19.1.3 Domaines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19.1.4 Des particularits locales ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19.2 Des freins la diffusion ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19.2.1 MOA et MOE ne sont pas agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19.2.2 Contrats au forfait, le mythe du primtre x . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19.3 Le french air pour Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rfrences bibliographiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

247 249 252 252 252 253 253 255 255 255 256 256 258 258 258 260 262 264 265

Avant-propos

Depuis plus dune dizaine dannes, je conseille des entreprises et je forme des tudiants sur les mthodes itratives et agiles. Depuis cinq ans, cet effort porte presque exclusivement sur Scrum ; cela ma permis de participer une cinquantaine de projets mens avec Scrum et de mimpliquer fortement dans le dveloppement du logiciel libre IceScrum (un outil pour Scrum1 ). Sur le terrain, jai constat ce qui fonctionnait bien et ce qui fonctionnait moins bien. travers ce livre, je souhaite vous faire partager mon exprience et les leons apprises. Vous y apprendrez appliquer les pratiques de Scrum en les adaptant aux contraintes de votre environnement. Mme si ce livre ne remplace pas une formation et encore moins une application concrte, il prsente des conseils, des exemples, des retours dexprience et des guides qui 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 connaissance trouveront 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 qui souhaitent 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 les chapitres 1 et 2. Si vous voulez connatre Scrum en dtail, lisez les chapitres 1 11. Les personnes jouant le rle de Product Owner liront en particulier le chapitre 3 et le chapitre 5, et les ScrumMasters le chapitre 4. Tous les membres de lquipe appliquant Scrum seront intresss par les chapitres 4 11.
1. Voir chapitre 17.

XVIII

Scrum

4ScrumMaster

5Backlogdeproduit

3ProductOwner

G D E F H M I A B C

J L

2Sprintsetreleases

Release Sprint 1 Sprint2 Sprint 3 Sprint4

6Planification derelease

11Significationdefini 7Planification desprint

Sprint 2
8Scrumquotidien 9Revue 10Rtrospective

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 13 et 14 sont plutt destins ceux qui dnissent le produit, les chapitres 15 et 16 aux dveloppeurs. Le chapitre 17 prsente loutillage pour Scrum, le chapitre 18 propose des pistes pour effectuer la transition dans de grandes organisations et le chapitre 19 aborde la diffusion de Scrum en France.
Complments en ligne Sur le site www.aubryconseil.com, vous trouverez les dernires informations relatives au livre, des articles complmentaires, des prcisions, des mises jour, ainsi que les formations et les confrences de lauteur.

Remerciements
Mes relecteurs mont fourni un feedback prcieux, en mobligeant repenser certaines parties et en maidant les rendre plus accessibles. Je les remercie chaleureusement pour leur contribution ; il sagit dAlexandre B OUTIN, Thierry C ROS, et Antoine V ERNOIS. Je remercie galement Laure AUBRY, Jean-Pierre O DILE et Julien AUBRY qui se sont investis dans la rvision du manuscrit et mont t trs prcieux par leurs commentaires.

Avant-propos

XIX

Jean-Claude G ROSJEAN et Philippe K RUCHTEN ont particip chacun la rdaction dun chapitre et sa relecture, je leur en suis trs reconnaissant. Je suis galement reconnaissant Franois B EAUREGARD davoir relu ce livre et dy avoir contribu en crivant la prface. Un grand merci Patrice C OURTIADE , lauteur des dessins qui apportent une touche de lgret un sujet forcment srieux. Je remercie mon diteur Jean-Luc B LANC de mavoir fait conance. Je remercie galement Vronique M ESSAGER R OTA et Pascal R OQUES, deux auteurs, pour les conseils quils mont donns sur la rdaction dun livre, ainsi que toutes les personnes que jai rencontres lors de mes formations et interventions sur les projets. Merci enn Ruth pour son soutien sans faille au cours des nombreuses journes, soires et week-ends que jai passs crire et rcrire ce livre.

1
Scrum sous la bannire de lagilit

1.1 LE MOUVEMENT AGILE


1.1.1 Mthode agile
Les mthodes agiles reprsentent un mouvement novateur qui vise apporter plus de valeur aux clients et aux utilisateurs, ainsi quune plus grande satisfaction dans leur travail aux membres de lquipe. Le but afch dune mthode agile est de maximiser la valeur ajoute : le dveloppement seffectuant par itrations successives, il est possible, la n de chaque itration, de changer les priorits en faisant en sorte que les lments apportant le plus de valeur soient raliss en premier. Un meilleur accomplissement des personnes impliques dans un dveloppement est rendu possible par la notion dquipe auto-organise. Une tentative de dnition, adapte de Scott Ambler1 , pourrait tre : Une mthode agile est une approche itrative et incrmentale pour le dveloppement de logiciel, ralis de manire trs collaborative par des quipes responsabilises, appliquant un crmonial minimal, qui produisent un logiciel de grande qualit dans un dlai contraint, rpondant aux besoins changeants des utilisateurs. Le crmonial cest ce qui dnit les rgles sociales et conventionnelles rgissant la vie dune quipe ; sil est vrai que, pour une mthode agile, il est minimal pour

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

Chapitre 1. Scrum sous la bannire de lagilit

la documentation, il existe bien pour le ct social (on parle de crmonial Scrum propos des runions), mais avec des rgles nouvelles.

1.1.2 Manifeste agile


Le terme agile est apparu dans le domaine du logiciel en 2001 avec le Manifeste agile1 . Le mouvement a pris de lampleur depuis quelques annes, il est maintenant diffus, au-del des pionniers, dans de trs nombreuses organisations impliques dans le dveloppement de logiciel. Le Manifeste fdre le mouvement agile avec un ensemble de valeurs et de principes.
Valeurs du Manifeste agile Publi au dbut des annes 2000, le Manifeste

agile dnit une attitude de raction par rapport des processus lourds et bureaucratiques, en vogue lpoque (et parfois encore aujourdhui). La position prise par rapport ces processus ne dnit pas les valeurs intrinsques de lagilit, mais des valeurs relatives : Les personnes et leurs interactions sont plus importantes que les processus et les outils. Un logiciel qui fonctionne prime sur de la documentation. La collaboration est plus importante que le suivi dun contrat. La rponse au changement passe avant le suivi dun plan. Avec ces prceptes, pleins de bon sens, le Manifeste agile reprsente un coup de balancier, comme on en voit rgulirement dans lindustrie du logiciel, pour promouvoir des processus plus lgers.
Les principes du Manifeste agile Le Manifeste nonce douze principes :

Satisfaire le client en livrant tt et rgulirement des logiciels utiles, qui offrent une vritable valeur ajoute. Accepter les changements, mme tard dans le dveloppement. Livrer frquemment une application qui fonctionne. Collaborer quotidiennement entre clients et dveloppeurs. Btir le projet autour de personnes motives en leur fournissant environnement et support, et en leur faisant conance. Communiquer par des conversations en face face. Mesurer la progression avec le logiciel qui fonctionne. Garder un rythme de travail durable. Rechercher lexcellence technique et la qualit de la conception. Laisser lquipe sauto-organiser. Rechercher la simplicit. intervalles rguliers, rchir aux moyens de devenir plus efcace.
1. http://www.agilemanifesto.org

1.1 Le mouvement agile

Cette liste, pas plus que le Manifeste, ne dnit une mthode agile. Il ny a dailleurs pas une seule mthode, ni un emploi quon pourrait qualier dorthodoxe. Si les valeurs et les principes sont universels, la faon de les mettre en uvre sur des projets varie. Cette application se fait par lintermdiaire de ce quon appelle les pratiques. Les pratiques agiles, qui ne sont pas voques dans le Manifeste, constituent la partie essentielle de ce livre.

1.1.3 Lagilit
En fdrant les mthodes agiles, le Manifeste agile constitue lacte de naissance dun nouveau mouvement, lagilit. Jim Highsmith1 dnit lagilit par rapport au changement :
Lagilit est la capacit favoriser le changement et y rpondre en vue de sadapter

au mieux un environnement turbulent.


Finalement, lagilit permet dembrasser le changement plutt que de lui rsister. Dans notre poque de linformation, lavantage comptitif vient de la vitesse et de la

exibilit.
Lagilit permet donc de sadapter plus vite au changement. Cependant, tous les environnements des organisations ne sont pas turbulents : en tout cas, il y en a qui sont moins soumis aux changements que dautres, qui ne sont pas dans un milieu concurrentiel. Cela ne signifie pas que lagilit nest pas ncessaire ces projets et ces organisations, mais que la faon de lappliquer doit tre adapte leur contexte (voir le chapitre 12).

Une nouvelle culture


Avec ses valeurs et ses principes, on peut considrer lagilit comme une nouvelle culture du dveloppement. Les valeurs de lagilit peuvent prsenter un caractre indniablement subversif pour certaines organisations, mais on sait que les valeurs sont assez vite rcupres. Audel des ides, lagilit, en particulier avec Scrum, vhicule un vocabulaire nouveau. En quelque sorte, le vocabulaire contribue renforcer lide du changement de culture. Il importe de tenir compte des aspects culturels dans la formation et la transition lagilit : on ne change pas facilement de culture.

Place de lagilit
Pour illustrer la position de lagilit dans le dveloppement de logiciel, je reprends une phrase de Tom de Marco2 , quon ne peut pas suspecter dtre un zlateur de lagilit :
1. http://www.jimhighsmith.com/ 2. De Marco, cit par Highsmith, est un expert du gnie logiciel connu depuis plus de 25 ans : http://en.wikipedia.org/wiki/Tom_DeMarco.

Chapitre 1. Scrum sous la bannire de lagilit

La formule du succs : agilit 1, nimporte quoi dautre 0. Ce nest pas une dnition, cest plutt un constat, diant sur la place de lagilit dans lingnierie du logiciel.

1.1.4 Pratiques agiles


Si la culture agile est nouvelle, des pratiques maintenant qualies dagiles existaient avant, pour certaines avant le Manifeste agile et mme avant les premires mthodes agiles. Un certain nombre de pratiques sont reconnues depuis longtemps par la communaut 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 un backlog de 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 efcaces. Insres dans le cadre cohrent dune approche agile, elles se renforcent mutuellement, et contribuent la qualit 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 compte passe par une gestion des priorits et elle est toujours diffre : une quipe qui travaille ne doit pas tre perturbe nimporte quand.

1.2 Survol de Scrum

1.1.5 Des mthodes agiles Scrum


Les mthodes agiles existaient avant le Manifeste : Scrum et Extreme Programming datent des annes 1990. Le Lean Software repose 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 qualies dagiles ou de semi-agiles. Le Manifeste en nonant les valeurs et les principes communs a contribu les fdrer toutes derrire la mme bannire de lagilit. Plus rcemment, lengouement pour Scrum (la ScrumMania !) a mis n une hypothtique rivalit entre les mthodes agiles. Les tudes dopinion et les tendances des recherches sur le Web le montrent : Scrum est de loin la plus populaire dans la famille des mthodes agiles. Maintenant que Scrum a gagn1 , la difcult 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 au rugby, lquipe charge du dveloppement travaille de faon collective, soude vers un objectif prcis. Comme un demi de mle, le ScrumMaster aiguillonne les membres de 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 processus agile 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 pour Scrum. En fait, la dnition ofcielle, celle donne par la Scrum Alliance2 et son fondateur Ken Schwaber est lgrement diffrente. Scrum nest prsent ni comme un 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 il revient processus... Un spcialiste des processus parlerait, pour Scrum, de pattern de processus, orient gestion de projet, qui peut incorporer diffrentes mthodes ou pratiques dingnierie.
1. lheure o jcris ces lignes (septembre 2009), mais a peut changer. 2. http://www.scrumalliance.org

Chapitre 1. Scrum sous la bannire de lagilit

Quon le dsigne comme un cadre, un pattern de processus, une mthode, voire un truc, Scrum dnit des lments qui feront partie du processus appliqu pour dvelopper un produit. Ces lments sont en petit nombre, le cadre impos par Scrum tant trs lger : gure plus que des itrations, des runions au dbut et la n de chacune, un backlog de produit et trois rles. Ce ct minimaliste, plus les succs sur le terrain, donnent croire que Scrum est un truc qui marche.

Scrum en bref
Si la vraie nature de Scrum est difcile dnir, il est beaucoup plus simple dexpliquer la mcanique de mise en uvre :
Scrum sert dvelopper des produits, gnralement en quelques mois. Les

fonctionnalits souhaites sont collectes dans le backlog de produit et classes par priorit. Cest le Product Owner qui est responsable de la gestion de ce backlog. Une version (release) est produite par une srie ditrations dun mois1 appeles des sprints. Le contenu dun sprint est dni par lquipe, avec le Product Owner, en tenant compte des priorits et de la capacit de lquipe. partir de ce contenu, lquipe identie les tches ncessaires et sengage pour raliser les fonctionnalits slectionnes pour le sprint. Pendant un sprint, des points de contrle sur le droulement des tches sont effectus lors des mles quotidiennes (scrums). Cela permet au ScrumMaster, lanimateur charg de faire appliquer Scrum, de dterminer lavancement par rapport aux engagements et dappliquer, avec lquipe, des ajustements pour assurer le succs du sprint. la n de chaque sprint, lquipe obtient un produit partiel (un incrment) qui fonctionne. Cet incrment du produit est potentiellement livrable et son valuation permet dajuster le backlog pour le sprint suivant.

1.2.1 Thorie
Les premires exprimentations de Scrum datent de 1993 et le premier article2 est paru en 1995, pour la confrence OOPSLA3 ; sign de Ken Schwaber, il prsente Scrum comme un processus empirique adapt aux dveloppements de produits complexes. Scrum a son origine dans la thorie de contrle empirique des processus. Les trois piliers de la thorie sont la transparence, linspection et ladaptation du processus dont Scrum fournit le cadre :

1. On peut remarquer que lusage de Scrum volue : par exemple, une pratique courante aujourdhui est davoir des sprints de deux semaines alors que la dure initiale tait un mois. 2. http://jeffsutherland.com/oopsla/schwapub.pdf 3. Object-Oriented Programming, Systems, Languages & Applications.

1.2 Survol de Scrum

Transparence La transparence garantit que tous les indicateurs relatifs ltat

du dveloppement sont visibles par tous ceux qui sont intresss par le rsultat du produit. Non seulement la transparence pousse la visibilit mais ce qui est rendu visible doit tre bien compris ; cela signie que ce qui est vu est bien le reet de la ralit. Par exemple, si un indicateur annonce que le produit est ni (ou une partie seulement du produit), cela doit tre strictement quivalent la signication de ni dnie par lquipe. Inspection Les diffrentes facettes du dveloppement doivent tre inspectes sufsamment souvent pour que des variations excessives dans les indicateurs puissent tre dtectes temps. Adaptation Si linspection met en vidence que certains indicateurs sont en dehors des limites acceptables, il est probable que le produit rsultant sera galement 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 quotidien permet dinspecter la progression par rapport au but du sprint et de faire des adaptations qui optimisent la valeur du travail du jour suivant. La planication et la revue de sprint sont utilises pour inspecter lavancement du dveloppement par rapport au but de la release et faire des adaptations sur le contenu du produit pour le prochain sprint. La rtrospective inspecte la faon de travailler dans le sprint pour dterminer quelles amliorations du processus peuvent tre faites dans le prochain sprint.

1.2.2 lments
Le cadre Scrum consiste en une quipe avec des rles bien dnis, des blocs de temps (timeboxes) et des artefacts (gure 1.1) :

Rles
Product Owner ScrumMaster quipe

Timeboxes
Planification de release Planification de sprint Scrum quotidien Revue de sprint Rtrospective

Artefacts
Backlog de produit Plan de release Plan de sprint Burndown de sprint Burndown de release

Figure 1.1 lments de Scrum

Chapitre 1. Scrum sous la bannire de lagilit

quipe et rles Lquipe a un rle capital dans Scrum : elle est constitue

avec le but doptimiser la exibilit 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. Le cur du rythme de Scrum est le sprint, une itration dun mois ou moins. Dans chaque sprint, le cadre est donn par un crmonial lger mais prcis bas des runions. Artefacts Scrum exige peu dartefacts lors du dveloppement : le plus remarquable est le backlog de 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 en vidence le degr defcacit des pratiques de dveloppement utilises.

2
Des sprints pour une release

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 que certains aient suivi le mme processus. Il y a une grande variation dans le droulement temporel dun projet, appel le cycle de dveloppement (ou cycle de vie). Un cycle est dni par des phases et des jalons. Les phases se succdent et un jalon permet de contrler le passage la phase suivante : une phase a des objectifs et le jalon est l pour vrier quil ny a pas de dviation par rapport ces objectifs.
Phase A Phase B

Phase C

Phase D

Temps

Figure 2.1 Dans un cycle traditionnel, chaque phase est diffrente

videmment le cycle est inuenc par le modle de cycle (ou processus) quon utilise. Un modle ancien, encore rpandu en France, est le cycle en V, mais le plus souvent une entreprise, surtout si elle grande, a dni son propre modle de cycle. Dans certaines entreprises, lapplication du modle est fortement recommande et 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 mise en uvre sur les projets.

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 mthodologistes

loigns des ralits, et inapplicable sur le terrain. Les contrles sont difciles faire lors des jalons, parce quils portent souvent sur une multitude de documents. Les jalons tant franchis sans difcult, lquipe accumule les travaux non faits des 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 sprint avec Scrum. Tous les sprints se droulent selon 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 de chaque sprint : ils ne sont pas dnis 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 Sprint est le terme utilis dans Scrum pour itration. Dans le langage Scrum, un sprint est un bloc de temps fix aboutissant crer un incrment du produit potentiellement livrable. Release peut avoir plusieurs sens : Release comme version Le dictionnaire du jargon informatique franais dfinit une release comme suit : version dun logiciel effectivement diffuse, donc lche dans la nature. Synonyme de Mise sur le march . Exemple : Unix system V release 4 . Cette dfinition nonce clairement quil y a des versions qui ne constituent pas des releases. Release comme priode de temps Par extension, on appelle galement release la 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 release comme priode de temps, notamment dans lexpression plan de release. Cest ce sens, priode de temps compose de sprints, qui est utilis pour release dans ce livre.

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 dun produit.

Incrmental
Incrmental est utilis pour mettre en vidence laccroissement du produit obtenu la n de chaque sprint. Un processus incrmental permet de construire un produit morceau par morceau, chaque nouvelle partie venant sajouter lexistant. Pour lcriture de ce livre, jai utilis une approche incrmentale : jai fait un plan initial et jai rdig chapitre par chapitre, sans respecter lordre du plan, dailleurs. La pratique dun cycle incrmental est rpandue dans les dveloppements de logiciel ; on parle souvent de lots pour les incrments qui font lobjet dun contrat.

Itratif
Itrer est laction de rpter. Dans le calcul scientique, litration est un procd de calcul rptitif qui permet, par exemple, de trouver la racine dun nombre, dune quation, par approximations successives. Dans le dveloppement de logiciel, le terme itration est utilis pour dsigner une priode de temps dans laquelle sont effectues des activits, qui seront rptes dans les prochaines itrations. Le terme est souvent associ processus.
Exemple : un article du Nouvel Observateur (grand public, donc) de juillet 2008 met en exergue les itrations du processus dAmazon, qui expliquent, selon lauteur, les succs de lentreprise.

Un processus itratif permet de revenir sur ce qui a t fait, dans le but de lamliorer ou de le complter. Cela part de lide quil est difcile, voire impossible, de bien faire la premire fois. Le feedback collect sur le rsultat dune itration permet de faire des amliorations dans la suivante. On cesse ditrer quand la qualit obtenue est juge satisfaisante. Pour lcriture de ce livre, jai utilis une approche itrative : jai diffus le premier jet des lecteurs et grce leur feedback, jai produit une nouvelle version.

12

Chapitre 2. Des sprints pour une release

Itratif et incrmental
Scrum combine les deux approches avec la notion de sprint :
lissue du sprint, il y a un incrment de produit qui est ralis, le feedback sollicit sur cet incrment permet de le perfectionner dans un

prochain sprint. En rsum, un sprint est une itration qui produit un nouvel incrment (incrmental) et peut aussi enrichir un incrment dun sprint prcdent (itratif). Pour lcriture de ce livre, jai utilis une approche itrative et incrmentale : en fait, je nai pas diffus le premier jet de tout le livre mes lecteurs, mais celui dun chapitre. Comme jai suivi Scrum pour ce projet de rdaction, dans un sprint je travaillais sur la premire version dun nouveau chapitre et aussi sur la rvision dun chapitre suite au retour dun ou plusieurs lecteurs. Les organisations qui font des dveloppements de logiciel en passant par la production dune maquette, celles qui procdent par lots, celles qui produisent une ou plusieurs versions intermdiaires disent volontiers quelles appliquent un processus itratif et incrmental. Elles ne sont pas agiles pour autant.

Cycle agile
Quelles sont les caractristiques du cycle de vie Scrum, en plus dtre itratif et incrmental, qui justient le qualicatif dagile ?
Des itrations plus courtes : les sprints durent au maximum un mois. Une squence plus stricte : les sprints ne se chevauchent pas. Un rythme rgulier : les sprints ont toujours la mme dure.

Incrmental

Lot 1

Lot 2 Lot 3 Temps

Agile

Sprint

Sprint

Sprint

Sprint Temps

Figure 2.3 Diffrences entre incrmental et agile

2.1 Lapproche itrative et incrmentale

13

2.1.2 Bloc de temps


Les sprints ont tous la mme dure : Scrum sappuie sur la notion de bloc de temps limit (timebox).
Il ny a pas que les sprints qui sont timeboxs avec 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 le sprint, la notion de timebox sapplique de la faon suivante : on ne change pas la date de n une fois que le sprint a commenc. Mme si on na pas ni tout ce quon voulait faire, on garde la date de n prvue. Pourquoi ? Cela permet dviter le syndrome du presque ni (ou ni 90 %), o, nalement, la date de n est repousse plusieurs fois. Jai accompagn de nombreux projets, agiles ou pas. Jai eu trs souvent des demandes dquipes venant ngocier la date dun jalon. Ces quipes me disent quelles 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 qui tait 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 une inspection objective de lavancement et on ajuste en consquence la planication des prochains sprints.

Rythme rgulier
La dure des sprints est toujours la mme, dans la mesure du possible. Lintrt est de donner 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 a des 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 indniment. Il prsente dautres avantages : comme on connat les dates de dbut et de sprint lavance, les revues sont plus faciles organiser et les intervenants peuvent planier leur participation.

Ressources rgulires
Le bloc de temps dlimite la quantit de travail faite pendant le sprint. Il est le mme pour tous les sprints : il dpend de la dure du sprint et de la taille de lquipe qui sont xes toutes les deux, au moins sur une certaine priode.

14

Chapitre 2. Des sprints pour une release

Ressources

Timebox

Dure

Figure 2.4 Le bloc de temps

Comme pour le dveloppement de logiciel, le cot est directement corrl aux ressources, le budget dun sprint peut tre dduit de la timebox. Il est prfrable que la composition de lquipe reste stable pendant un sprint. Il est aussi souhaitable de garder une quipe stable pour une release, ce qui permet davoir des timeboxes quivalentes pour tous les sprints.

2.1.3 Dure du sprint


La dure dun mois ou moins correspond lhorizon de prdictibilit : la n du sprint, 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 prendre trop de risques. Aux dbuts de Scrum, la rgle tait de faire des sprints dun mois, sans variation. Par exemple, si le dveloppement commenait avec une anne calendaire :
premier sprint du premier au 31 janvier, deuxime sprint du premier au 28 (ou 29) fvrier, troisime sprint du premier au 31 mars...

Aujourdhui, on constate une tendance faire des sprints plus courts : en effet, pour le dveloppement de logiciel, les pratiques dingnierie, comme lintgration continue et les outils associs, permettent de produire des versions partielles plus frquemment.
Quelques infos pratiques Une enqute faite en avril 2009 sur mon blog (www.aubryconseil.com) auprs dune centaine de personnes donnait les rsultats prsents figure 2.5. Les sprints de deux ou trois semaines reprsentent la majorit des rponses.

2.2 Cycle de dveloppement Scrum

15

Figure 2.5 Sondage sur la dure des sprints

2.2 CYCLE DE DVELOPPEMENT SCRUM


2.2.1 Laspect temporel
Phases et jalons
Dans chaque processus de dveloppement, il existe des jalons majeurs et des jalons mineurs. Avec Scrum le jalon mineur est la n du sprint et le jalon majeur est la production de la release.
Release Sprint 1 Sprint 2 Sprint 3 Sprint 4

Figure 2.6 Une release et ses sprints

Une release est une srie de sprints qui se termine quand les incrments successifs constituent un produit qui prsente sufsamment de valeur ses utilisateurs. La dure des releases est dnie par lquipe et le Product Owner. La tendance est raccourcir ces dures : pour de nombreuses quipes, une release dure environ trois mois, avec des sprints de deux ou trois semaines. Cela permet de drouler de quatre six sprints dans une release. Il ny a pas de chevauchements : on ne commence pas un sprint tant que le prcdent nest pas termin et, en principe, le nouveau dmarre immdiatement aprs le prcdent. Les sprints senchanent sans dlai : le nouveau dmarre immdiatement aprs le prcdent.

16

Chapitre 2. Des sprints pour une release

Sprint 1 Sprint 2

Sprint 3

Sprint 4

Figure 2.7 Les sprints sont squentiels

Sprint 1 Dlai

Sprint 2

Sprint 3

Figure 2.8 Les sprints senchanent

Arrter le sprint plutt que ltendre


La date de n du sprint est xe au dbut du sprint (elle est mme dnie avant). Elle ne change pas, mme si lquipe ne ralise pas tout ce quelle imaginait faire. Lvaluation de n de sprint permettra dinspecter ce qui a t fait et den tirer des consquences pour la suite. Il peut arriver que lquipe narrive pas produire un incrment potentiellement livrable la n du sprint et nait rien de montrable. Heureusement, cest trs rare. Cela peut tre d des difcults techniques ou des perturbations importantes qui changent le but du sprint. Dans ce cas, lorsque lquipe se rend compte quelle ne pourra pas prsenter quelque chose la n du sprint, une possibilit est darrter immdiatement le sprint en cours. Lquipe repart aussitt dans un nouveau sprint, avec un primtre adapt qui tient compte des difcults rencontres.
Ce conseil peut tre suivi pour une quipe qui fait des sprints dun mois et se rend compte de son impasse au milieu du sprint. Pour des dures de sprint plus courtes, il est plus simple dattendre la fin normale du sprint et de tirer les enseignements lors de la rtrospective.

2.2.2 Activits et cycle de dveloppement


Un cycle de dveloppement se prsente comme un enchanement de phases dans lesquelles on effectue des activits. Pour un dveloppement de logiciel, les activits sont gnralement :
Spcication fonctionnelle (requirements) Architecture (conception) Codage (et test unitaire) Test (dintgration et de recette)

Pour simplier, je vais utiliser les lettres S A C T pour dsigner ces activits dans les schmas.

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 les activits de dveloppement pendant un sprint. Les activits se droulent en parallle pendant le sprint (gure 2.9) :
Toutes les activits
Sprint 1 S A C T S A C T S A C T S A C T S A C T 5

Cycle Scrum

Figure 2.9 Des sprints et leurs activits en parallle

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

Cycle squentiel

Une activit par phase


Figure 2.10 Phases avec des activits squentielles

Avec un processus activits squentielles, une phase est dnie avec un objectif exprim par une liste de documents produire ; elle dure assez longtemps quelques mois 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 n. Suivre au pied de la lettre cette approche revient avoir :
100 % de la spcication 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 les activits des phases prcdentes, et en particulier dans la phase de test, on revient sur les spcications, la conception et le code (gure 2.11).
T S A C T
C
A
S

Figure 2.11 Retour sur les activits prcdentes pendant le test

18

Chapitre 2. Des sprints pour une release

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

Avec une mthode agile comme Scrum, les activits de spcication et de conception 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 premier sprint. Il existe aussi de nombreux dveloppements qui sont mens de faon chaotique, sans suivre de processus ou en le suivant larrache 1 . Le plus souvent, il ny a mme pas de spcication 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 chaque sprint.

2.2.3 Le rsultat dun sprint


Linspection2 , an de faire des adaptations, est la base de la thorie de Scrum. la n dun sprint, le rsultat attendu est un incrment du produit nal, qui est potentiellement livrable. Cest ce que montre le clbre schma de Mike Cohn que javais traduit en franais en 2005 (gure 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 potentiellement livrable.

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

2.3 Guides pour les sprints et releases

19

Le produit ne doit pas tre seulement potentiellement utilisable la n dun sprint, il doit simplement tre utilisable. Certes, il nest pas complet par rapport ce qui est prvu dans la release, mais il est livrable, au moins des utilisateurs privilgis. Dans le cas dun dveloppement de logiciel, le minimum est davoir dploy, la n dun sprint, le produit potentiellement livrable, avec si ncessaire la documentation permettant de lutiliser.

2.2.4 Le rsultat dune release


Le rsultat de la release est le produit livrable, fourni ses utilisateurs. La faon dont il est fourni dpend de la nature du dploiement de ce produit. La distinction avec le rsultat du sprint se fait sur le potentiellement. 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 sont possibles pour des applications web hberges...
Exemple : eBay re-dploie ses applications tous les quinze jours et pour Amazon cest 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 prparent un 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 article de Ken Schwaber voquait trois phases : une premire Planning & Architecture, la deuxime constitue des sprints et une dernire phase appele Closure. Ces notions sont aujourdhui abandonnes. Nanmoins, il y a bien trois priodes distinctes dans une release (gure 2.13) :
La priode centrale, celle des sprints. La priode avant le premier sprint. Une priode aprs le dernier sprint et avant la n de la release.

20

Chapitre 2. Des sprints pour une release

Release Sprint1 Sprint2 Sprint3 Sprint4

Dbut de release

Les sprints

Fin de release

Figure 2.13 Les trois priodes dune release

2.3.1 Dmarrer le premier sprint au bon moment


Le dveloppement dune release commence par des travaux particuliers faire avant de lancer les sprints successifs, comme constituer lquipe, dnir la vision, produire un backlog initial et une premire planication de la release. Si la release en question est la premire dans la vie du produit, il conviendra galement de faire des travaux de dnition de produit1 et darchitecture avant de lancer les sprints.

Figure 2.14 Le lancement des sprints se prpare

La priode de temps en dbut de release est parfois appele le sprint zro. Sprint zro est trompeur parce que cette priode nest pas un sprint comme les autres : sa dure est variable, les tches quon y fait sont spciques de cette phase, il ny a pas le crmonial habituel des sprints, on ne produit pas une version potentiellement utilisable la n, on ne mesure pas de vlocit... lusage je trouve que cest une trs mauvaise appellation, dangereuse. Au-del du vocabulaire, ce quil faut bien comprendre cest quil sagit dune phase diffrente de la srie des sprints qui va suivre. Elle est prdictive alors que la phase des sprints est empirique, le but nest pas de produire un incrment de produit comme pour
1. Voir aussi, le chapitre 13 De la vision aux stories.

2.3 Guides pour les sprints et releases

21

chaque sprint. Le risque avec sprint zro est que cette distinction ne soit pas perue et que cette phase prparatoire soit nglige. Le premier sprint ne doit pas dmarrer trop longtemps aprs le dbut de la release (il ne sagit pas dy caser les activits de spcication et de conception dtailles), mais cela dpend du contexte : il faut videmment plus de temps dans le cas dune premire release dun nouveau projet sappuyant sur une nouvelle technologie que pour sa nime release. Ce nest pas non plus une bonne chose de dmarrer trop vite : avant que la planication de release ne soit labore, cest prmatur de commencer le premier sprint.

2.3.2 Produire des micro-incrments


Un sprint ne se droule pas en travaillant successivement sur les activits (spcication puis conception puis codage puis test) : un sprint nest pas un mini-cycle en V . Lquipe travaille pour dvelopper des fonctionnalits ds le dbut du sprint, ce qui permet de produire pendant le sprint ce quon peut appeler des micro-incrments (gure 2.15).
Incrment de fin de sprint Micro-incrments

Sprint n  1

Sprint n

Figure 2.15 Production de micro-incrments

Dans le cadre dun dveloppement logiciel, ces micro-incrments sont des versions intermdiaires produites pendant le sprint. Elles sont utilises par lquipe de dveloppement 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 sprinter pendant toute la dure de la course de fond que constitue une release, il faut des phases de rcuprations. Ce nest pas moi qui vais dire le contraire : jai couru en longue distance. Jai encore le souvenir des entranements en fractionn : par exemple une srie de dix fois 200 m avec 30 secondes de rcupration entre chaque.

22

Chapitre 2. Des sprints pour une release

Figure 2.16 La fatigue de lquipe aprs un sprint fond

Certains membres de lquipe le font savoir lors des rtrospectives : ils souhaitent des jours de rcupration entre les sprints. Parmi toutes les quipes que jai suivies depuis cinq ans, la plupart se contentent dun week-end avant de repartir sur un nouveau sprint : la revue et la rtrospective se font le vendredi (mais ce nest pas obligatoire de caler les sprints sur les semaines) et le prochain sprint dmarre le lundi qui suit par la runion de planication. Dautres consacrent un jour entre chaque sprint des activits hors projet ; une quipe a instaur un bug day intercalaire. Jai aussi connu des quipes qui choisissaient de sarrter une semaine tous les trois ou quatre sprints. Et puis certaines quipes enchanent directement : par exemple, n de sprint le mardi, dbut du sprint suivant le mercredi matin, par exemple. Cest le mode de fonctionnement optimal. Les situations o les quipes prouvent le besoin de sarrter entre les sprints sont souvent le reet dun dysfonctionnement. Le terme sprint, quon court fond et aprs lequel on rcupre, est trompeur. Un dveloppement avec Scrum sapparente 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 identier trois usages de la version produite en n de sprint, pour un dveloppement de logiciel.
Utilisation interne La version nest pas utilise en dehors de lquipe de

dveloppement. Elle a t produite pour chercher minimiser les risques lis la technologie et la capacit de lquipe intgrer diffrents composants.

2.3 Guides pour les sprints et releases

23

Elle nest pas livre lextrieur de lquipe. Cela est frquent au dbut dun nouveau dveloppement. Utilisation pour feedback par des utilisateurs slectionns La version est utilise par un client ou des utilisateurs privilgis. Cela leur donne la possibilit de la prendre en main, ce qui permet de rduire les risques portant sur linterface. Ces utilisateurs pourront valuer la facilit dutilisation des fonctionnalits et en proposer de nouvelles. Les retours faits iront alimenter le backlog pour prise en compte ultrieure. Mise en production La version est mise en production ou en exploitation et utilise par ses utilisateurs naux. Cest videmment ce quil faut viser puisque chaque nouvelle version apporte de la valeur. Autant lapporter le plus tt possible, ds quelle est disponible. Mais ce nest gnralement pas faisable de mettre en production la n 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 manuels utilisateurs, pour prparer et donner la formation aux utilisateurs... Cest pourquoi, dans la plupart des cas, ltat du produit la n1 de chaque sprint est distingu de celui souhait la n 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 n des releases. Dans ce cas-l, le produit nest plus simplement potentiellement livrable la n de chaque sprint, il est livr. Le terme de release garde son sens de priode de temps pour la planication.

2.3.5 Savoir finir la release


Faire le plus possible pendant les sprints vite de devoir poursuivre le travail aprs le dernier sprint. Si ltat du produit partiel en n de sprint est quivalent ltat attendu en n de release, la n du dernier sprint concidera avec la n de la release. Ce nest pas possible dans tous les contextes et dans certains cas, il faut une priode de temps entre la n du dernier sprint et la n de la release pour faire des travaux ncessaires avant la mise en production. Ces travaux varient selon le type de dploiement : mise en production chaud, packaging du produit, mise disposition par tlchargement en ligne... Cette priode tait auparavant appele sprint de stabilisation. Ce ntait pas une bonne ide, cela laissait entendre que le logiciel ntait pas stable avant. Les termes de sprint de release ou de sprint de durcissement parfois voqus sont tout aussi discutables :
il vaut mieux rendre le produit plus robuste chaque sprint plutt que de le faire

la n,
si malgr tout, il y a des travaux de durcissement faire avant de livrer la release,

cela ne rentre pas dans le cadre dun sprint.

1. La signication de ni fait lobjet du chapitre 11 .

24

Chapitre 2. Des sprints pour une release

En rsum
Avec Scrum, un produit est dvelopp selon une approche itrative et incrmentale. Le sprint donne le rythme auquel sont produites des versions partielles potentiellement livrables du produit. La release est la squence de sprints lissue de laquelle le produit est livr aux utilisateurs.

3
Le Product Owner

Il y a quelques annes, je travaillais chez un diteur de logiciel. Plus exactement un diteur de gnie logiciel qui ralisait et commercialisait des outils de modlisation. Le poste que joccupais sappelait Marketing Produit. Dans dautres entreprises, on parle de chef de produit. la direction marketing, nous faisions des tudes de march, nous animions des groupes dutilisateurs, nous dnissions notre vision des nouveaux produits et nous en faisions la promotion. Je moccupais dun produit, aujourdhui disparu, comprenant un diteur graphique, un simulateur et un gnrateur de code. La cible principale tait le secteur des tlcoms. Javais t moi-mme dveloppeur et chef de projet dans le domaine des tlcoms, et donc je connaissais bien les utilisateurs potentiels du produit. Avec le rle que javais, je les reprsentais en quelque sorte. Jessayais de faire prendre en compte leurs besoins dans le produit. Le produit tait dvelopp par une quipe de la direction technique. Je ne la voyais pas trs souvent, je ne les connaissais mme pas tous. Je voyais un peu plus souvent le chef de projet. Lui et le directeur technique avaient aussi leurs ides sur le produit. Comme ctait une socit dirige par la Technique, ctait souvent eux qui avaient le dernier mot pour mettre ce quils avaient dcid dans le produit. Il y avait aussi les commerciaux qui, pour essayer de vendre leurs clients, allaient voir directement le chef de projet, ou le directeur technique, voire le PDG. Je ntais mis au courant quaprs, sans pouvoir revenir sur les dcisions prises. Le rsultat de ces apports diffrents la dnition du produit tait un manque dhomognit. Le produit comportait des fonctions trs puissantes. Par exemple de la simulation exhaustive de modles bass sur des machines tats. De ce fait, il ntait pas simple utiliser. Les fonctions proposes ne tenaient pas rellement compte des besoins des utilisateurs. Le produit tait nalement bancal, mme si, au

26

Chapitre 3. Le Product Owner

marketing, nous essayions de le masquer, lors des prsentations aux commerciaux et aux utilisateurs. Cest pour viter ce manque dunit dans le contenu dun produit que le Product Owner existe dans Scrum. Sa raison dtre cest de sassurer que le travail fait apporte de la valeur aux utilisateurs. Il est responsable de la dnition du contenu du produit et de la gestion des priorits pour son dveloppement. Lexistence du Product Owner permet aussi dviter, comme dans mon histoire, la prdominance de la Technique dans un dveloppement de produit. Son boulot, cest de dire lquipe quel produit raliser. Il est le seul avoir cette responsabilit. Cela vite les conits 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 des projets. En particulier, je suis, depuis plusieurs annes, le Product Owner du produit IceScrum, un outil open source de 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 Management ou BPM), je me souviens du rle de Process Owner, le propritaire de processus . Mon exprience avec des propritaires de processus mincline 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 traduit en Administrateur du produit . Cet intitul na jamais pris en France et je ne crois pas 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 Product Director2 ), 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-diretor 3. www.aubryconseil.com

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 jcris ces lignes, directeur de produit apparat toujours dans cet article, dailleurs. Ce qui fait que 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 les tranches2 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 hirarchique sur des personnes. En 2007, jai fait un petit sondage auprs des utilisateurs de Scrum et finalement cest Product Owner qui est apparu convenir le mieux. Mme dans les administrations franaises ! Depuis je reste fidle lappellation Product 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/Scrum 2. http://henrik-kniberg.developpez.com/livre/scrum-xp/

28

Chapitre 3. Le Product Owner

3.1 RESPONSABILITS
Le Product Owner a des responsabilits importantes, 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 des domaines qui sont ceux dun chef de projet traditionnel, par exemple la date de livraison du produit. Le Product Owner prend aussi de nombreuses dcisions de niveau tactique qui sont habituellement prises par une quipe de dveloppement, faute dimplication des clients . En effet, en leur absence, les dveloppeurs ont tendance faire des choix qui ne sont pas, en principe, de leur responsabilit. Un Product Owner prsent et impliqu fera ces choix tactiques, comme par exemple 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 didentier ses responsabilits majeures :
Fournir une vision partage du produit Grer son cycle de vie

Dfinir son contenu

Figure 3.2 Responsabilits du Product Owner

3.1.1 Fournir une vision partage du produit


Le Product Owner est responsable de dnir lobjectif du produit et de le partager avec lquipe qui le dveloppe. Sans tre obligatoirement un visionnaire comme Steve Jobs, le Product Owner doit avoir une bonne vision du produit. La vision se construit au dbut du dveloppement dun nouveau produit et se consolide ensuite. Elle consiste typiquement dnir :
lnonc du problme que le produit veut rsoudre, une position du produit qui soit claire pour tout le monde, une liste des fonctionnalits essentielles.

3.2 Comptences souhaites

29

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

3.1.2 Dfinir le contenu du produit


Le Product Owner dnit le contenu du produit. Pour cela, il identie les fonctionnalits requises et les collecte dans une liste, appele le backlog de produit2 . Concrtement, le Product Owner est responsable du backlog de produit et y contribue de faon rgulire. En plus de son travail pour le sprint courant, il passe une bonne partie de son temps sur les lments du backlog prvus pour les sprints suivants. Comme il est moteur pour tablir ce que doit faire le produit, il est logique quil fournisse 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 dnit lordre dans lequel les parties du produit seront dveloppes. Il doit alimenter lquipe avec les fonctionnalits dvelopper, selon ses priorits dnies en fonction de la valeur quelles apportent. Lordre de ralisation dnit le cycle de vie du produit. Cette vie est constitue dune succession de versions (les releases). Le Product Owner dnit lobjectif dune release et prend les dcisions sur son contenu et sa date de mise disposition du produit. En rsum, sil na pas dautorit formelle sur des personnes, le Product Owner a une grande inuence sur le produit ralis.

3.2 COMPTENCES SOUHAITES


La personne idale pour jouer ce rle devrait possder les comptences prsentes gure 3.3. On imagine quune personne avec ce prol idal est un oiseau rare dans la plupart des organisations.

1. Pour plus dinformations, voir le chapitre 13 De la vison aux stories. 2. Le backlog fait lobjet du chapitre 5. 3. Les tests dacceptation font lobjet du chapitre 14 De la story aux tests.

30

Chapitre 3. Le Product Owner

Bonne connaissance du domaine mtier Matrise des techniques de dfinition de produit Capacit prendre des dcisions rapidement Capacit dtailler au bon moment Esprit ouvert au changement Aptitude la ngociation
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 lexpression cur de mtier, constitue un domaine de connaissances en relation avec le quoi et le pourquoi dun produit. Le quoi (what), cest ce que doit faire le produit. Le pourquoi (why), cest la justication de lexistence du produit et de son contenu, en termes de fonctionnalits. Une bonne connaissance du domaine mtier est fondamentale pour le Product Owner, puisquil est le reprsentant dans lquipe de toutes les personnes qui utilisent ou font utiliser le produit ; celui tant dvelopp pour rendre des services ces personnes, par exemple en automatisant des parties dun processus. Le Product Owner peut avoir acquis cette connaissance parce quil est un des utilisateurs potentiels et cest souvent le cas dans les entreprises qui dveloppent des produits usage interne ; dans celles produisant pour des clients externes, le Product Owner vient souvent des quipes marketing ou produit. On ne demande pas un Product Owner de tout connatre du domaine fonctionnel : 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 savrera ncessaire, sur les bonnes personnes pour assumer pleinement son rle.

3.2.2 Matrise des techniques de dfinition de produit


Le Product Owner dnit ce que fait le produit. Il a besoin pour cela davoir la matrise des techniques de collecte des besoins et de leur transformation en lments du backlog de produit. Traditionnellement, dans le dveloppement de logiciel, la discipline dingnierie des exigences (requirements engineering ) est celle qui dnit le processus de collecte de ce que doit faire le produit.

3.2 Comptences souhaites

31

Scrum ne prescrit pas de technique particulire pour identier les lments du backlog, Cependant le constat fait sur le terrain est que la pratique la plus frquemment associe Scrum est celle des user stories 1 . La connaissance, et si possible la pratique des techniques de dnition 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 arrive quotidiennement sur un projet : pour des raisons defcacit, le Product Owner doit pouvoir le faire seul, sans en rfrer une hirarchie ou une autorit suprieure. Pour cela, il est essentiel quil ait la conance des diffrents intervenants : il doit les voir rgulirement, les consulter sur les lments du backlog quil connat mal et sur les priorits pour la release en 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 une seule proposition. Il ne suft pas quune personne dcide, il faut aussi que ses dcisions soient respectes et appliques. Le Product Owner entrane lquipe en faisant en sorte que tout le monde adhre pleinement aux choix sur le contenu du produit.

3.2.4 Capacit dtailler au bon moment


Avec une approche agile, la spcication des exigences nest pas dtaille ds le dbut du dveloppement. Un gros travail pour tout spcier au commencement du projet (BRUF, Big Requirements Up Front) nest pas recommand. Comme tout nest pas prcis au dpart, le Product Owner doit savoir, en fonction de lavancement, quel moment dtailler des lments du backlog de produit. Pour cela, il doit faire preuve danticipation. La notion de priorit entre les lments du backlog va ly aider : ce qui est le plus prioritaire doit tre prt en premier. Concrtement, cela signie quil va passer du temps simpliquer sur les travaux courants, comme les autres membres de lquipe, mais quune bonne partie de son temps porte aussi sur le futur du produit dans les semaines ou les mois qui viennent. Le Product Owner dcompose et dtaille, au bon moment, le contenu du produit.

3.2.5 Esprit ouvert au changement


Loutil principal du Product Owner, le backlog de produit, est vivant et volue pendant toute la vie du projet. Cela constitue une diffrence fondamentale avec la pratique souvent ancre dans la culture des organisations qui consiste essayer de ger les spcications au dbut.
1. Cette pratique est dtaille dans le chapitre 13 De la vision aux stories.

32

Chapitre 3. Le Product Owner

Un bon Product Owner sadapte et prend en compte le feedback qui remonte suite aux livraisons rgulires des versions du produit. Ajuster la vision et mettre jour le backlog sont la preuve de son ouverture au changement. Il va mme jusqu solliciter des ides de changement auprs des utilisateurs et de lquipe.
Attention : il ne faut pas comprendre la capacit au changement comme le droit de changer davis tout moment. Un Product Owner garde le cap : sa vision ne varie pas fondamentalement pendant le dveloppement. Ouvert au changement, le Product Owner ne doit cependant pas tre une girouette.

3.2.6 Aptitude la ngociation


Le Product Owner dcide des priorits en fonction de la valeur ajoute, cependant ce nest pas le seul paramtre prendre en compte. En particulier au dbut du projet, il doit tenir compte des risques techniques. Un dialogue avec lquipe est ncessaire pour pondrer les critres de choix lors de ltablissement des priorits. Au dbut dun dveloppement, si lquipe nest pas encore constitue, la discussion se fera avec la personne en charge de larchitecture. Cette concertation pralable permet au Product Owner dtre mieux arm pour dnir les priorits. Lors des sances destimation et de planication quil effectue en compagnie de lquipe, le Product Owner doit faire preuve de pdagogie pour expliquer ce quil propose dajouter au produit et convaincre lquipe que les priorits quil propose sont les bonnes. Pendant le dveloppement, il est souhaitable que le Product Owner rencontre souvent le reste de lquipe. Il vient normalement au scrum quotidien et cest une bonne habitude quil reste discuter avec les dveloppeurs la suite de cette runion. Cest loccasion dcouter leurs propositions sur le produit et ils ont souvent de trs bonnes ides. Il peut se mettre en binme avec un dveloppeur, pour que celui-ci lui montre sur son environnement de dveloppement le fonctionnement dune story. Le Product Owner ngocie frquemment avec lquipe et doit faire preuve de force de conviction auprs des dveloppeurs pour justier ses prises de position.

3.3 CHOISIR LE PRODUCT OWNER DUNE QUIPE


Au moment o se met en place la premire exprimentation de Scrum, il nexiste pas de Product Owner dans lorganisation. Il faut donc trouver la bonne personne pour tenir le rle. Les organisations tant extrmement diverses, les possibilits de choix sont trs variables. On peut se baser sur les comptences souhaites du Product Owner prsentes plus haut. Seulement, il nest pas vident de trouver quelquun qui possde toutes ces qualits, et mme si on le trouve, il nest pas forcment disponible pour tenir le rle sur un projet.

3.3 Choisir le Product Owner dune quipe

33

3.3.1 Une personne disponible


En effet, sa disponibilit pour le rle est une condition sine qua non pour quune personne devienne Product Owner. On considre gnralement que le travail, pour une quipe de sept dix personnes, ncessite une affectation plein-temps.

Disponibilit continue
Le Product Owner fait partie de lquipe et participe aux runions du crmonial. Par opposition ce qui se passe pour un projet classique, o lintervention du client (ou de son reprsentant) est importante au dbut et la n, limplication du Product Owner est continue sur tous les sprints. On peut mme estimer que, plus la n de la release se rapproche, plus le temps que le Product Owner devrait consacrer au projet augmente : en effet, les priorits deviennent plus difciles dcider, les validations plus nombreuses devoir tre faites...

Participation au crmonial Scrum


Le Product Owner est un membre de lquipe part entire, il est tenu de participer aux runions Scrum. Le constat fait sur le terrain est que cette rgle, pourtant essentielle, nest pas toujours respecte. Parfois au moment de choisir le Product Owner, il arrive quon me demande quelle est son implication minimale : comme la personne susceptible de tenir le rle a dautres activits (par exemple, il est galement utilisateur de lancienne version du produit), on cherche, tort, limiter le temps quil passera sur le projet, en particulier dans les runions avec lquipe. Pour un projet avec des sprints de deux semaines, voil un exemple de la participation dun Product Owner aux runions Scrum que jai constate :
runion de planication de sprint : environ deux heures ; scrums quotidiens, deux fois par semaine (cest un minimum) : 60 minutes pour

quatre sances ;
revue de sprint : 60 minutes ; rtrospective : 30 minutes.

Dans ce cas optimiste, cela fait quatre heures et demie, soit un peu plus de 5 % de son temps. Cela peut varier entre 5 et 10 %.

Implication au jour le jour


En plus de participer ces runions, le Product Owner se doit aussi de :
mettre jour le backlog de produit, ajuster les priorits, rpondre aux questions sur le produit,

34

Chapitre 3. Le Product Owner

dnir les tests dacceptation, passer ces tests ou sassurer quils sont bien passs.

titre dexemple, voici quelques indications chiffres sur le temps que passe un Product Owner sur un produit, chez un diteur de logiciel : il est environ le tiers de son temps avec les utilisateurs ou le management produit, collecter des informations ou donner des explications, et le reste sur le projet, participer aux travaux de lquipe, dont la moiti pour le travail sur le sprint courant et lautre moiti pour anticiper les sprints suivants.

Figure 3.4 Rpartition typique des activits dun Product Owner

3.3.2 Une seule personne


Parler dune seule voix
Lhistoire qui suit illustre lintrt davoir un seul interlocuteur face lquipe de dveloppement pour les questions qui relvent de ce que doit faire le produit. Une quipe Scrum avait demand me rencontrer pour me poser des questions sur le produit, aprs une runion quils avaient eue avec leur Product Owner, qui les avait envoys vers moi. Il se trouve que je connaissais bien le domaine pour avoir t le Product Owner sur un dveloppement prcdent du produit. Jai donc rencontr lquipe et rpondu leurs questions qui taient nombreuses et portaient sur des user stories propos desquelles ils mont demand des prcisions. Les rponses que jai donnes taient orientes selon mes ides sur le produit. Seulement leur Product Owner leur avait demand de me voir pour une seule question, bien prcise. Je ne lai su quaprs, lquipe ne me la pas dit et ma pos plein dautres questions. Rsultat : jai orient lquipe dans une voie qui ntait pas celle de son Product Owner et celui-ci a eu ensuite beaucoup de mal safrmer et mettre en avant sa vision.

3.3 Choisir le Product Owner dune quipe

35

Il faut parler dune seule voix une quipe et cette voix, cest celle du Product Owner de lquipe. Sil dcide de faire intervenir dautres personnes sur des domaines complmentaires aux siens, il vaut mieux quil soit prsent aussi, sinon il lui sera difcile de sapproprier le produit.

Ne pas dlguer trop de responsabilits


Comme il est difcile de trouver toutes les qualits attendues dans une seule personne, peut-on les partager entre plusieurs ? Si le Product Owner nest pas sufsamment disponible pour assumer ses responsabilits, est-il alors envisageable davoir dans lquipe un Product Owner dlgu ?
Exemple : dans le cas dune socit de services qui ralise un produit pour un client, le Product Owner est normalement dans lorganisation du client. Si lquipe considre quil nest pas suffisamment prsent, elle sera tente de dsigner un Product Owner dlgu (proxy) en son sein.

Cela peut fonctionner un temps, mais le risque dans ce cas est de soumettre lquipe deux sons de cloche et de la perturber quand le vrai Product Owner sexprime aprs son dlgu. Et surtout cest contraire une pratique essentielle des mthodes agiles : une quipe complte inclut le reprsentant des utilisateurs ou clients. Lide dun Product Owner dlgu nest quun pis-aller quil est prfrable dviter. Si le Product Owner dsign ne simplique pas assez, mieux vaut avoir une approche radicale : arrter le dveloppement en attendant quune bonne solution soit trouve, comme trouver un vritable remplaant.

Un groupe de PO doit avoir un responsable


Sur de gros projets, peut-on envisager davoir plusieurs Product Owners, voire une quipe de PO ? Dans de nombreuses organisations, il semble difcile de trouver une personne sufsamment disponible pour tre Product Owner. Apparemment il serait plus facile den trouver plusieurs temps partiel pour se partager le rle. Il y a aussi des cas o la connaissance est dissmine entre plusieurs personnes. Cest particulirement vrai dans les grands projets ou lorsque le produit fait partie dune ligne de produits. Il est alors tentant de constituer un groupe, qui pourrait tre appel groupe de Product Owners. Le problme avec un groupe de Product Owners, cest que la responsabilit ne rside plus dans une seule personne. Or cest justement pour viter les inconvnients dus aux conits cause dintrts contradictoires, aux dcisions ralenties, aux difcults prioriser, que Scrum recommande une seule personne pour le rle de Product Owner. Comme le dit Ken Schwaber : Le Product Owner est une personne, pas un comit. Comment avoir une quipe de Product Owners tout en suivant ce conseil ? En ayant dans le groupe une personne tant le Super Product Owner, qui est l pour

36

Chapitre 3. Le Product Owner

donner la vision globale et pour arbitrer. Une quipe Scrum possde un et un seul Product Owner.

3.3.3 O le trouver dans lorganisation actuelle ?


Le Product Owner est chercher dans un service qui est en contact avec les utilisateurs ou qui les reprsente, donc gnralement une entit autre que celle des membres de lquipe de dveloppement. Par exemple, chez un diteur de logiciel, il est probable que le Product Owner soit issu du service marketing ou produit. Venant dune entit o lide de produit est dj trs forte, il y a de bonnes chances que cette personne possde dj quelques comptences requises pour tre un bon Product Owner. Cest dans ce cadre que jai rencontr les meilleurs Product Owners, avec une bonne culture produit. Dans les grandes entreprises qui ont des utilisateurs internes, il parat logique quun Product Owner soit choisi dans le service o sont les utilisateurs et leurs reprsentants. Quelquun qui a t analyste mtier (Business Analyst), en assistance ce quon appelle la matrise douvrage (AMOA), ou chef de projet utilisateurs est un bon candidat pour ce rle. Dans ce type dorganisation jai rencontr des Product Owners qui avaient plus de difcults bien jouer leur rle, notamment par manque de disponibilit.

3.3.4 Une personne motive pour le rle


Dans une quipe Scrum, le Product Owner est souvent choisi aprs le ScrumMaster, avec une culture de Scrum et de lagilit parfois supercielle. Il pourra recevoir des complments de formation plus tard, mais ce qui importe lors du choix, cest son adhsion aux valeurs et principes vhiculs par le mouvement agile. On ne peut pas tre un bon Product Owner si on nest pas motiv pour le rle.

3.4 CONSEILS POUR PROGRESSER DANS LE RLE


Le rle de Product Owner est probablement celui qui est le plus difcile tenir dans une quipe. Les projets Scrum qui sont en chec le sont souvent cause du manque de savoir-faire du Product Owner. Une des raisons ( mon avis la principale) pour expliquer pour ces checs est le manque danticipation sur les sprints suivants. Voici quelques pistes pour progresser dans le rle de Product Owner et viter des checs.

3.4 Conseils pour progresser dans le rle

37

Se former au rle de Product Owner


Devenir un bon Product Owner ncessite des comptences particulires quune formation spcique au rle peut aider acqurir. En particulier ceux qui ont appris Scrum sur le tas peuvent avoir besoin dtre recadrs sur les fondamentaux. Une technique trs utile au Product Owner pour dcrire les lments du backlog est celle des user stories. Elle facilite la gestion de projet et permet davoir des tests dacceptation tracs par rapport aux lments du backlog de produit. En complment, lacquisition des pratiques de dnition de produit, incluant la vision, lui permettra dapprhender une approche descendante, utile pour le dveloppement dun nouveau produit. Une bonne formation doit inclure lapprentissage de ces techniques, de prfrence avec des ateliers de travail en groupe. Une fois form, le Product Owner comprendra pourquoi son rle demande une grande disponibilit. Il aura plus darguments pour obtenir cette disponibilit. Pour apprendre concrtement le rle, en particulier dans les organisations o le clivage entre utilisateurs et informaticiens est fort (de type MOA/MOE), il est encore plus efcace dtre accompagn dans sa mise en uvre sur un projet. Un coach externe apporte sa connaissance et son exprience du rle ce qui permet de progresser rapidement grce un travail en binme.

Simpliquer dans les tests dacceptation


Cest la responsabilit du Product Owner de sassurer que le travail fait par lquipe est ni la n dun sprint. Cest en exposant ses conditions de satisfaction que le Product Owner formule lquipe le comportement quil attend dune fonctionnalit. Cest en vriant que ces conditions sont bien remplies quil peut sassurer de leur bonne n. Ces conditions peuvent tre exprimes de manire informelle, ce qui est dj un moyen pour amliorer la communication ; une approche plus aboutie est de les formaliser en tests dacceptation : lintrt est que ces tests pourront tre automatiss et passs rgulirement. Cette transformation de conditions mtier dans le langage des utilisateurs en tests excutables constitue lapproche appele ATDD (Acceptance Test Driven Development, pilotage par les tests dacceptation1 ), qui est porteuse de gains de productivit et de qualit. Cette approche repose sur des langages et des outils dans lesquels un Product Owner doit simpliquer.

Collaborer avec lquipe


Le Product Owner nest pas simplement le reprsentant des clients et utilisateurs. Il fait partie de lquipe et participe activement aux travaux pendant un sprint. Sa prsence physique rgulire avec lquipe a un impact sur son rle :

1. Le test dacceptation est prsent dans le chapitre 14 De la story aux tests.

38

Chapitre 3. Le Product Owner

Sil est install avec lquipe, dans le mme espace de travail, cest la situation

idale. Cependant il suft quil soit assez proche pour que lquipe puisse aller le voir et lui demander des prcisions, et dans lautre sens, quil puisse rencontrer facilement lquipe. Il peut sasseoir de temps en temps ct dun membre de lquipe pour rentrer dans les dtails dune story. Si le Product Owner est distance et ne voit pas physiquement lquipe, la mise en uvre du rle sera plus dlicate, mais il existe des solutions, notamment avec des outils de travail collaboratif en ligne, pour pallier son manque de prsence physique. En collaborant avec lquipe, le Product Owner apprendra couter ce quont dire les dveloppeurs. Il comprendra mieux leurs proccupations de dlai et de qualit. Ainsi il sera moins sujet leur imposer une pression ngative en les poussant livrer toujours plus de fonctionnalits. De plus, le travail en commun permet la crativit des dveloppeurs de se manifester.

Utiliser le produit
Un bon Product Owner aime son produit. Sil lutilise tous les jours, il y a des chances quil soit incit faire en sorte quil soit de qualit et quil discerne bien la valeur ajoute par les fonctions dans le backlog. Bien connatre son produit lui donnera une position respecte par tous et facilitera ses prises de dcision. Cest aussi la fonction du Product Owner de faire des dmonstrations lextrieur et de prsenter le produit aux utilisateurs.

Impliquer les parties prenantes


Le Product Owner est un reprsentant : pour bien exercer son rle, il doit communiquer avec ceux quil reprsente. Il reprsente non seulement les utilisateurs du produit nal, mais aussi le client ou sponsor et les autres personnes impliques dans le produit. Il les invite la revue de chaque n de sprint. Il doit vraiment les inciter y venir car cette revue est un moment dinspection collectif de ltat du produit. En complment, le Product Owner peut organiser des sances de travail pour prparer la feuille de route (roadmap) du produit portant sur les futures versions.

Planifier moyen terme


Une des pratiques de Scrum les moins utilises, daprs les sondages (et mon exprience), est la production dun plan de release. Cest pourtant un moyen de donner une direction lquipe et de la communiquer aux parties prenantes. Le Product Owner est moteur dans cette qute davoir un horizon qui va au-del du sprint courant.

3.4 Conseils pour progresser dans le rle

39

Utiliser un outil pour grer le backlog


Loutil du Product Owner est le backlog de produit. Un backlog est une liste qui peut tre gre de multiples faons. Cependant, au bout dun peu de pratique Scrum, il devient ncessaire de disposer dun outil1 pour grer la traabilit, tre assist dans le suivi des lments du backlog, faire des plans et produire des graphiques.

En rsum
Dans une quipe Scrum qui dveloppe un produit, le Product Owner est la personne qui reprsente le mtier . Il apporte sa vision lquipe et dnit les priorits de faon obtenir un produit ayant le maximum de valeur. Limplication dun bon Product Owner est capitale pour assurer le succs du projet. En dnissant sa vision sur le produit, il donne limpulsion lquipe. En faisant la promotion du rsultat de chaque sprint auprs des utilisateurs, il fournit lquipe une reconnaissance qui la motive. En collaborant avec lquipe, il fait converger les nergies pour maximiser la valeur ajoute au produit.

1. Les outils sont prsents dans le chapitre 17.

4
Le ScrumMaster et lquipe

Lorsquon voque un projet dvelopp par un groupe de personnes, une pense trs rpandue est de considrer quune personne identie doit tre responsable de lquipe. Traditionnellement, ce rle est appel chef de projet. En France, le rle de chef de projet est solidement ancr dans la culture du dveloppement. En voici deux exemples :
Certains tudiants en informatique, passant un entretien pour rentrer dans une

cole, mettent un point dhonneur dire que leur objectif est de devenir chef de projet ds leur entre dans la vie professionnelle. Probablement parce que des enseignants croyant bien faire leur ont inculqu cette notion de lambition. En tant que membre du jury devant lequel ils passent, je considre pourtant quune meilleure ambition serait de mettre en avant leur capacit travailler en quipe. Rcemment, au cours dune prsentation de Scrum dans une grande entreprise publique, tous les participants sauf un se sont prsents, lors du tour de table, comme chefs de projet. Souvent dans les entreprises qui font appel la dlgation de personnel, il ne reste que des chefs de projet dans lorganisation. Jai jet un froid quand, en dcrivant les rles dans une quipe Scrum, jai annonc labsence de chef de projet. Pas de chef de projet dans Scrum ! Le rle est limin. Le travail et les responsabilits dun chef de projet ne disparaissent pas pour autant dans les projets Scrum. Une grande partie est dvolue au Product Owner, une autre partie est laisse lquipe. Un des principes de Scrum est lauto-organisation : il signie que les membres de lquipe sorganisent eux-mmes et nont pas besoin dun

42

Chapitre 4. Le ScrumMaster et lquipe

chef qui leur assigne le travail faire. ScrumMaster nest donc pas un nouveau nom pour chef de projet.
Le ScrumMaster a pour responsabilit essentielle daider lquipe appliquer Scrum et ladapter au contexte. Il a une grande influence sur la faon de travailler, sur le processus, comme le Product Owner en a une sur le produit. Ce qui pourrait conduire qualifier le ScrumMaster de Process Owner par quivalence.

Cest de ce rle emblmatique de Scrum, dont il est question dans ce chapitre. Nous y aborderons aussi le rle de lquipe Scrum, dont le comportement est fortement inuenc par ce quest un ScrumMaster.
Dfinition ScrumMaster, cest un nom original, voire dcal. Mme pour un anglophone. Scrum signifie mle au rugby, donc littralement ScrumMaster signifie le matre de la mle. Cest effectivement trs original, mais cela naide pas beaucoup comprendre le rle. Je crois que personne na essay dadopter une traduction franaise pour ScrumMaster. Lusage est de conserver le terme dans les pays francophones. Cela a lavantage de bien montrer que cest un rle nouveau qui implique du changement par rapport aux pratiques habituelles de gestion dquipe. On trouve de nombreuses analogies pour expliquer le rle de ScrumMaster, en voici deux : Pour rester dans le rugby, Scrum se rfre aux huit membres du pack dans le rugby quinze. Le poste de demi de mle est celui qui se rapproche le plus de lide de ScrumMaster. Cest lui qui fait avancer son pack, le guide dans la progression, demande le ballon au bon moment. Ken Schwaber, un des auteurs de Scrum, compare le ScrumMaster un chien de berger qui veille sur son troupeau de moutons. Certains considrent que le berger constituerait une meilleure analogie pour le rle de ScrumMaster.

4.1 RESPONSABILITS
4.1.1 Responsabilits du ScrumMaster
Ses responsabilits gnrales sont les suivantes :
veiller la mise en application de Scrum, par exemple en faisant en sorte que

les diffrentes runions aient lieu et quelles se fassent dans le respect des rgles ; encourager lquipe apprendre, et progresser, en fonction du contexte du projet, dans les pratiques dingnierie ; faire en sorte dliminer les obstacles qui pourraient freiner lavancement, par exemple en protgeant lquipe des interfrences extrieures pendant le droulement dun sprint ; inciter lquipe devenir autonome.

4.1 Responsabilits

43

Le dveloppement avec Scrum se fait par une succession de sprints. Les responsabilits du ScrumMaster sappliquent pendant les sprints mais commencent sexercer mme avant le lancement du premier.

Avant le premier sprint


Le ScrumMaster est souvent la premire personne dsigne dans lquipe. Il peut donc tre impliqu dans la constitution de lquipe. Il arrive quil participe au choix, toujours dlicat, du Product Owner. Cest galement lui quchoira le plus souvent la responsabilit de sassurer que la logistique, en particulier les bureaux et leur agencement, est adapte aux pratiques de travail en quipe.

Tches priodiques pendant les sprints


Le ScrumMaster met Scrum en application. Il organise et anime les runions qui constituent le crmonial dun sprint. Il fait en sorte que ces runions aient lieu et quelles soient efcaces. Il y joue un rle de facilitateur, littralement celui qui facilite les choses .

limination des obstacles


Scrum est un processus empirique et part le rituel des runions, lenchanement des tches nest pas dni lavance dans un sprint ; mais cest lquipe, et non pas le ScrumMaster qui le dcidera de faon opportuniste, en fonction de lavancement. En plus de cet indterminisme sur le droulement des tches, il se produit toujours des vnements pendant un dveloppement. Parmi ces vnements, certains sont susceptibles de ralentir ou de bloquer le travail de lquipe. Dans le jargon Scrum, ils sont appels des obstacles (impediments). Les obstacles peuvent tre de nature et dimportance trs variables.
Exemple : un dveloppeur se casse le bras au ski, le serveur SVN est en panne, le composant attendu dune autre quipe nest pas prt...

Cest au ScrumMaster didentier les obstacles mis en vidence par lapplication de Scrum et de sassurer de leur limination. Cest une activit curative : le ScrumMaster fait tout pour viter quils ralentissent durablement lquipe. Il sappuie sur des comptences internes lquipe ou va chercher des comptences externes si cest ncessaire pour solutionner un problme. Le ScrumMaster soccupe galement du prventif : certains vnements ne constituent pas des obstacles mais pourraient le devenir. Il doit sefforcer de protger lquipe, en diffrant les impacts ngatifs de futurs vnements sur sa capacit produire. travers la description de ses responsabilits, on voit que le rle tranche avec lide quon se fait dun chef omnipotent. Une diffrence marquante est que ce nest pas lui qui organise le travail des membres de lquipe.

44

Chapitre 4. Le ScrumMaster et lquipe

4.1.2 Responsabilits de lquipe


Une des missions du ScrumMaster est de motiver lquipe pour quelle devienne autonome et responsable.

Figure 4.1 Un ScrumMaster nergique donne limpulsion un membre de lquipe

Le rle de lquipe est essentiel : cest elle qui va raliser le produit, en dveloppant un incrment chaque sprint. Elle est investie avec le pouvoir et lautorit pour le faire de la faon la plus efcace. Pour cela, elle sorganise elle-mme et doit avoir toutes les comptences ncessaires au dveloppement du produit. Il ny a pas de rles spcialiss dans une quipe, elle doit possder les comptences ncessaires pour accomplir le travail faire : on dit quelle est multifonctionnelle. Cest lquipe qui dnit elle-mme la faon dont elle organise ses travaux, ce nest pas le ScrumMaster (ni le Product Owner). Chaque membre de lquipe apporte son expertise, la synergie amliorant lefcacit globale. Les responsabilits de lquipe sont donc trs importantes. Lorigine du nom Scrum, le rugby, rappelle dailleurs le rle central de lquipe.

4.2 COMPTENCES SOUHAITES DU SCRUMMASTER


La faon dont le rle de ScrumMaster est jou dpend de la taille de lquipe, de la complexit technique du produit raliser, ainsi que de limportance du changement induit par le passage Scrum dans lorganisation. Cependant, on peut dgager les comptences attendues dun ScrumMaster (gure 4.2).

4.2 Comptences souhaites du ScrumMaster

45

Bonne connaissance de Scrum Aptitude comprendre les aspects techniques Facilit communiquer Capacit guider Talent de mdiateur Tnacit Inclination la transparence Got tre au service de lquipe
Figure 4.2 Les comptences souhaites dun ScrumMaster

4.2.1 Bonne connaissance de Scrum


Sil y a une personne qui doit bien matriser Scrum dans une quipe, cest le ScrumMaster. Au-del de la simple connaissance livresque de Scrum, il est prfrable quil ait dj une exprience de sa mise en uvre, pour viter dappliquer des rgles sans discernement, car il est toujours ncessaire dadapter Scrum au contexte. Sa connaissance ne doit pas sarrter son rle, mais englober lensemble du cadre Scrum. En particulier, il devra sintresser aux valeurs et aux principes de Scrum pour tre capable de les promouvoir auprs de lquipe.

4.2.2 Aptitude comprendre les aspects techniques


Il nest pas ncessaire pour un ScrumMaster de bien connatre le domaine de lapplication dvelopper. Une exprience dans le mtier peut cependant faciliter la communication avec le Product Owner et mieux impliquer lquipe dans la recherche de la valeur pour le produit. On ne demande pas non plus un ScrumMaster dtre un cador en technique. Le ScrumMaster sappuie sur des experts pour les aspects techniques pointus. Cependant des connaissances dans les technologies utilises permettent de mieux apprhender les problmes rencontrs par son quipe. Cela facilite la communication, en particulier avec les geeks quon rencontre dans certaines quipes, et rend plus aise lidentication des obstacles quils rencontrent.

4.2.3 Facilit communiquer


Des talents de communication sont ncessaires. Le ScrumMaster est amen discuter frquemment avec lquipe et aussi avec le management.

46

Chapitre 4. Le ScrumMaster et lquipe

Ces discussions ont lieu dans diffrents contextes, ce qui ncessite de sa part dadapter le style de communication :
il doit savoir obtenir la conance quand il est en face face avec un membre de

lquipe ;
il fait en sorte que les runions du crmonial, en prsence de nombreuses

personnes, se droulent efcacement ;


il est tenace et ferme dans ses demandes au management, sans pour autant tre

intransigeant.

4.2.4 Capacit guider


Il inuence lquipe et cest un meneur dhommes qui sait motiver une quipe, pour quelle arrive au rsultat. Mais il doit arriver ses ns par la persuasion, sans imposer ses dcisions : un ScrumMaster ne dispose daucune autorit hirarchique sur lquipe. Pendant un sprint, il guide lquipe vers le respect de lobjectif essentiel, qui est de livrer un produit qui apporte de la valeur avec une utilisation optimale des ressources.

4.2.5 Talent de mdiateur


Le travail le plus important du ScrumMaster est dliminer les obstacles. Parmi ceux-ci, un certain nombre est d des conits entre personnes. Lors dun diffrend entre des membres de lquipe, il joue le rle de mdiateur pour aider les personnes concernes trouver une solution acceptable. Il pousse au consensus. En cas de dsaccord persistent, il peut proposer une mesure plus radicale, comme changer une personne dquipe. En cas de conit dune personne avec le Product Owner, il devra sefforcer de ne pas prendre systmatiquement parti contre le Product Owner : il ne faut pas crer une opposition entre les dveloppeurs et les utilisateurs (un des principes de lagilit est lquipe complte, dont le but est dviter cette opposition). Jai connu un ScrumMaster qui avait mal compris son rle. Sous prtexte de considrations techniques, il sopposait au Product Owner, essayant dempcher une mise en production. Sil est normal quil existe une tension entre les deux rles, ce nest pas le ScrumMaster qui est responsable de la vie du produit. Il devrait simplement se limiter exposer le point de vue de lquipe.

4.2.6 Tnacit
Le ScrumMaster fait son possible pour viter que des obstacles aient un impact sur la progression de lquipe. Parfois, des obstacles ne peuvent tre limins que par lintervention de personnes faisant partie dautres quipes ou par le management. Ces personnes sont souvent difciles rencontrer et encore plus convaincre dagir rapidement. Un ScrumMaster nabandonne pas la premire adversit. Il doit se montrer opinitre et poursuivre sa qute sans relche, jusqu llimination des problmes qui freinent lquipe.

4.3 Choisir le ScrumMaster dune quipe

47

4.2.7 Inclination la transparence


Par rapport au rle de chef de projet, celui de ScrumMaster est davantage sur laccompagnement de lquipe que sur le suivi individuel. Les mesures faites avec Scrum sont collectives. Elles sont ncessaires pour suivre la progression de lquipe et produire des graphiques, comme les rapports davancement. Le ScrumMaster sassure de leur communication, notamment auprs du management. Scrum propose un cadre mthodologique qui contribue une grande transparence. Le ScrumMaster est garant de cette transparence dans lavancement de lquipe. Dailleurs, un apport fondamental de Scrum est de rvler les dysfonctionnements au plus tt. La responsabilit du ScrumMaster nest pas de les masquer, mais au contraire de les mettre en vidence.

4.2.8 Got tre au service de lquipe


La diffrence radicale entre le ScrumMaster et le chef de projet est que le ScrumMaster nest pas un chef : il ne commande pas, il nimpose pas, il ne contraint pas. Au-del de la diffrence de nom, il sagit dune diffrence de style. Il est au service de lquipe, quil soutient dans la rsolution des conits et dont il encourage la prise dautonomie vers une auto-organisation. Il doit faire preuve dhumilit et ne pas se mettre en avant :
ce nest pas lui qui russit si le projet avance bien : cest lquipe, ce nest pas la faute des autres membres de lquipe si le projet a des difcults :

cest aussi sa responsabilit.

4.3 CHOISIR LE SCRUMMASTER DUNE QUIPE


Le rle de ScrumMaster nexiste pas dans les organisations actuelles. Il faut donc trouver la personne qui va le mieux convenir pour jouer ce rle. De prfrence, elle sera choisie laune des comptences souhaites. Il faut aussi savoir quelle sera son implication pour identier la bonne ressource.

4.3.1 Affectation au rle


Pour une quipe Scrum typique (de six dix personnes), une seule personne joue ce rle sur un projet.

Le ScrumMaster fait partie de lquipe : il sengage avec les autres. Il doit rgulirement rencontrer physiquement les membres de lquipe, il ne reste pas dans son bureau. Dans de petites quipes, le ScrumMaster peut aussi participer aux travaux de dveloppement. Il prend alors des tches du sprint comme les autres membres de

48

Chapitre 4. Le ScrumMaster et lquipe

lquipe, mais cela doit rester limit : le rle de ScrumMaster prend du temps et il est prioritaire sur ses autres tches. En revanche, il vaut mieux viter quune personne soit :
le ScrumMaster de plusieurs quipes, en mme temps ScrumMaster et Product Owner de lquipe.

4.3.2 O trouver la bonne personne ?


Cela dpend de la structure des organisations. Pour certaines quipes, cest un dveloppeur expriment qui devient le ScrumMaster. Mais dans la majorit de celles pour lesquelles jai travaill, cest un ancien chef de projet qui a pris le rle. Par exemple, dans les grandes organisations, un chef de projet informatique (CPI) devient naturellement ScrumMaster. Dans le cas dorganisation culture hirarchique forte, le rle de ScrumMaster impacte les fondements de la gouvernance : Scrum reprsente un changement radical.
Thorie X et Y1 La thorie X induit un cercle vicieux dans lequel lorganisation est construite sur des rgles strictes et des contrles svres : les employs sadaptent en choisissant de travailler au minimum, et en adoptant une attitude passive. Ils fuient alors les responsabilits puisque le systme est rpressif, et donc non scurisant pour les prises de risque. Ceci conforte les dirigeants dans leurs convictions, ce qui les incite renforcer les rgles et les contrles. Au contraire, la thorie Y introduit un systme vertueux dans lequel lorganisation est construite autour de principes de confiance, de dlgation et dautocontrle : les employs utilisent cette libert supplmentaire pour mieux simpliquer dans le travail. Ils prennent alors des initiatives, acceptent les responsabilits et vont mme jusqu les rechercher. Ceci conforte les dirigeants dans leurs convictions, ce qui les incite maintenir la confiance, la dlgation et lautocontrle. Le rle de ScrumMaster sinscrit dans la ligne Y. On comprend que les organisations o la gouvernance a dvelopp les prsupposs de la thorie X auront un peu plus de mal devenir agiles. Cela ne veut pas dire que ce nest pas possible, ce sera plus long et plus difficile puisquil faudra faire voluer les cultures. Parce que vouloir tre agile en gardant une gouvernance proche de la thorie X, cest contradictoire.

1. http://fr.wikipedia.org/wiki/Th%C3%A9orie_X_et_th%C3%A9orie_Y

4.3 Choisir le ScrumMaster dune quipe

49

Dans une organisation avec une gouvernance forte, lexistence simultane des deux rles (ScrumMaster et chef de projet) est temporairement possible. De nombreuses activits habituelles de gestion de projet comme le reporting, la participation au comit de pilotage, le budget et la gestion des ressources humaines sont faites par chef de projet tandis que le ScrumMaster se consacre uniquement lanimation de lquipe. Cependant cette cohabitation ne peut tre que provisoire et uniquement pour faciliter la transition dune organisation Scrum.

4.3.3 Quelquun qui incarne le changement


Le terme ScrumMaster est sujet caution, dans sa partie master (matre). Le langage inuence le comportement : mme si lappellation ScrumMaster est nouvelle, le terme master naide pas toujours les organisations changer de paradigme durablement. Dans certaines organisations culture hirarchique, le rle de ScrumMaster, matre de Scrum peut tre peru comme un rle de responsable, dirigeant des personnes. Jai aussi vu des ScrumMasters retombant dans les habitudes du chef de projet traditionnel, avec des quipes acceptant cet tat de fait, parce que cest leur faon habituelle de travailler. Cest pourquoi la personne devenant ScrumMaster doit avoir bien compris lessence du rle pour tre lincarnation du changement quil reprsente.

4.3.4 ScrumMaster, un tat desprit


La bonne personne pour jouer le rle a un tat desprit appropri. Il mest arriv de rencontrer des ScrumMasters naturels. Ceux dont on se dit, comme pour Oblix : ils sont tombs dedans quand ils taient petits.

Quelques traits permettent de dceler ces ScrumMasters en puissance :


la capacit percevoir les motions dans lquipe, la curiosit et lenvie dapprendre, linclination penser que les gens font de leur mieux dans leur travail, lenvie de changer les choses qui ne vont pas bien, lorientation vers le collectif, la prise de risques.

50

Chapitre 4. Le ScrumMaster et lquipe

4.3.5 Rotation dans le rle


Dans une quipe, la personne qui joue le rle de ScrumMaster peut tourner : chaque sprint ou au bout de quelques sprints, cest une autre personne qui devient ScrumMaster. Cela se produit dans les projets que jencadre avec des tudiants. videmment tous les membres dune quipe dtudiants sont dans la mme classe et ont, a priori, la mme exprience. Aucun dentre eux na jamais t ScrumMaster auparavant, ni chef de projet dailleurs. Le choix du ScrumMaster est fait par lquipe, les enseignants ninterviennent pas. Lorsque le projet avance, je propose, si lquipe ne le demande pas elle-mme, que ce rle soit affect tour de rle. Le choix est laiss lapprciation de lquipe. Bon an mal an, il y a environ la moiti des quipes qui pratiquent la rotation de ScrumMaster. Dans les autres quipes, on prfre garder le ScrumMaster actuel, probablement parce quil a dgag une autorit naturelle et des aptitudes pour ce rle. ScrumMaster est un rle dynamique, dans la mesure o la personne affecte ce rle peut varier dans le temps. Cela permet de ragir si la personne qui tient le rle a des difcults.

4.4 CONSEILS POUR PROGRESSER DANS LE RLE


Le rle de ScrumMaster est difcile tenir quand on dbute dans Scrum. Des difcults peuvent apparatre cause du ScrumMaster qui remplit mal son rle, par exemple sil ne fait pas conance aux membres de lquipe et dcide sa place. Pour viter de connatre des checs dans vos projets, voici quelques pistes pour progresser dans le rle de ScrumMaster.

Parfaire sa connaissance de Scrum


tre un bon ScrumMaster ncessite une culture agile et une matrise de Scrum. Cela sapprend dabord en appliquant bien sr, mais aussi en lisant des livres ou des articles. La participation des confrences o sont prsents des retours dexprience est particulirement enrichissante. Il existe aussi des groupes dutilisateurs, comme le Scrum User Group franais1 .

Se former au rle de ScrumMaster


Au-del de la simple connaissance de Scrum, devenir un bon ScrumMaster ncessite des comptences particulires quune formation spcique peut aider acqurir. En particulier ceux qui nont pas suivi une formation au dpart et ont appris leur rle sur le tas peuvent avoir besoin dtre recadrs, aprs quelques mois de pratique.

1. Pour en savoir plus : www.frenchsug.org.

4.4 Conseils pour progresser dans le rle

51

Dans certaines socits, gnralement des petites, la personne qui devient ScrumMaster tait situe, dans la hirarchie, sous lautorit de celle qui est le Product Owner. Une bonne connaissance du rle lui permettra de safrmer, ce qui aura pour effet de limiter un pouvoir excessif du Product Owner.

Se faire assister par un coach


Pour apprendre le rle, la meilleure solution est dtre accompagn dans sa mise en uvre sur le projet par un expert. Cest particulirement important pour de grandes organisations dans lesquelles la culture traditionnelle des projets est fortement marque. Certaines de ces organisations semblent rsister de faon coriace au changement et le coaching des ScrumMasters y est indispensable dans les premires expriences de Scrum.

Favoriser lanalyse des causes des problmes


Lorsquun obstacle est dtect, lidentication de ses causes profondes permet dviter quil ne se reproduise. En favorisant lanalyse causale, un ScrumMaster permettra lquipe de progresser dans ses pratiques, grce la capitalisation faite de faon collective.

Pratiquer lart du possible


Le ScrumMaster a pour mission de faire appliquer Scrum, mais une posture trop radicale peut conduire au rejet de Scrum. Il doit tenir compte du contexte de lorganisation. En particulier, dans sa responsabilit de protger lquipe des perturbations, le ScrumMaster doit savoir jusquo il est possible daller, face une organisation qui narrive pas changer ses habitudes rapidement. Comme le dit Ken Schwaber : un ScrumMaster mort1 nest plus utile .

Favoriser lauto-organisation de lquipe


Le ScrumMaster fait tout pour que lquipe prenne de lautonomie, il laide apprendre Scrum et mettre en place les meilleures pratiques dingnierie. Cela demande beaucoup dinvestissement, en particulier au dbut, et surtout si lquipe connat mal Scrum. Mais si cela russit lquipe sauto-organise et a moins besoin de lui. lextrme, alors quil est impossible de se passer dun Product Owner, il est envisageable davoir une quipe Scrum sans ScrumMaster, dans certains cas bien particuliers. Attention : il faut se rappeler que ScrumMaster est un rle plein-temps pour une quipe standard qui dmarre avec Scrum. Les situations prsentes ci-aprs reprsentent des cas particuliers.
Trs petite quipe Dans le cas dune toute petite quipe, jusqu trois

personnes, on peut se passer dun ScrumMaster.


1. En fait dans Agile Project Management with Scrum, il dit (page 33) quun chien de berger mort est un chien de berger inutile.

52

Chapitre 4. Le ScrumMaster et lquipe

Cest ce qui sest pass pendant certaines priodes sur le projet IceScrum pour lequel je suis le Product Owner. Il est arriv que lquipe ne compte, pendant quelques sprints, que deux ou trois personnes, en plus de moi. Il sest avr inutile de dsigner un ScrumMaster. Cest vrai que, de plus, le fait de dvelopper un outil ddi Scrum leur procure une bonne connaissance de la mthode, ce qui nous amne la deuxime situation o une quipe peut se passer de ScrumMaster.
quipe mature avec Scrum Une quipe exprimente qui a acquis un niveau

dauto-organisation trs lev peut fonctionner sans ScrumMaster. Si lquipe sorganise elle-mme, que tout le monde adhre aux principes agiles, le rle de ScrumMaster devient superu. La quantit de temps disponible ncessaire dun ScrumMaster diminue dans le temps, en fait, loppos de ce qui se passe avec le Product Owner, dont limplication augmente au fur et mesure de lavancement du projet.

Product Owner

ScrumMaster

Figure 4.3 Implication compare du Product Owner et du ScrumMaster

Lorsquun ScrumMaster saperoit quil nest plus indispensable, cest probablement quil a russi. Comme le dit Charles Piaget dans le lm Les LIP : un leader sait quil a russi quand on na plus besoin de lui ou en tout cas quand sa voix ne compte que pour un, comme celle de tout le monde dans le groupe1 . Cest srement plus facile mettre en place dans le dveloppement de logiciel que dans la production de montres. Cest paradoxal : un ScrumMaster qui a russi devient inutile dans son quipe... il a russi obtenir une quipe qui na plus besoin de lui et doit se saborder. Il peut alors :
aller coacher une autre quipe, redevenir simple dveloppeur sil tait la fois ScrumMaster et membre actif de

lquipe. Dans le cas dune quipe o le ScrumMaster est en mme temps dveloppeur, une phase intermdiaire de maturit avant la disparition du rle est de pratiquer la rotation : le rle de ScrumMaster tourne dans lquipe.
1. Dans lexprience des LIP, cela peut tre efcace : en quelques semaines dimagination au pouvoir, les quipes en autogestion de chez LIP ont produit autant de montres quen une anne normale de production.

4.4 Conseils pour progresser dans le rle

53

Matriser le reporting
La tendance des chefs de projet traditionnels est de faire beaucoup de reporting. Avec Scrum, la faon de produire des indicateurs1 est diffrente et cela est fait rapidement : pas besoin de passer beaucoup de temps faire des consolidations. Il y a une forte orientation rsultat : lavancement est fait sur ce qui est rellement ni et visible.

En rsum
Le ScrumMaster ne gre pas des ressources interchangeables, mais les hommes et les femmes de lquipe. Son rle essentiel est de les faire progresser collectivement pour la russite du projet. Les mthodes agiles reprennent lide dorganisation sans hirarchie autoritaire : on y parle dquipe investie avec le pouvoir et lautorit pour faire ce quelle a faire ou qui sorganise par elle-mme. Cest une des diffrences majeures avec les mthodes traditionnelles. Elle est mise en pratique avec le ScrumMaster qui nest pas un chef mais un facilitateur.

1. Voir le chapitre 15 Estimations, mesures et indicateurs.

5
Le backlog de produit

Aprs avoir dcid de lancer le dveloppement dun produit, la difcult fondamentale est de transformer lide de dpart en quelque chose dutilisable par lquipe de dveloppement. Dans les projets traditionnels, cette transformation se fait entirement au dbut du projet et se concrtise dans un document, qui dcrit ce que va faire le produit, quelles sont ses fonctions et quel est son comportement. Dans ma carrire, jai pass du temps rdiger de gros documents de spcication1 . Notamment pour un projet dans les tlcoms, jai labor le document de spcication, appel lpoque spcication externe du systme. Je faisais de mon mieux pour imaginer le comportement du produit. Comme jtais un utilisateur potentiel du systme produire, puisquil sagissait de tlphonie, cela facilitait mes rexions. Je discutais frquemment avec le chef de produit et le service marketing. Je faisais des versions frquentes de ce document en essayant davoir du feedback du marketing. Mme sil tait plutt rare, javanais bien dans la rdaction du document. Cela ma apport beaucoup sur la connaissance du produit et jai pu transmettre cette connaissance aux dveloppeurs de lquipe, plus oralement, par des discussions rgulires, que par leur lecture du document. Cela a fonctionn : le produit a t dvelopp et, aprs quelques mois, commenait fonctionner. Et puis un jour, alors que nous avions commenc les tests dintgration, la direction a dcid de constituer une quipe pour les tests fonctionnels du produit. Le nouveau responsable des tests a videmment voulu avoir accs aux spcications du produit.
1. Il existe diffrentes appellations de spcication dans le cas dun dveloppement de logiciel : spcication fonctionnelle, spcication externe du logiciel, spcication technique du besoin du logiciel (STBL), en anglais Software Requirement Specication (SRS).

56

Chapitre 5. Le backlog de produit

Le gros document produit quelques mois auparavant et dont jtais plutt er ne lui a pas vraiment convenu. Cest vrai quil ntait pas facile de rentrer dans les 200 pages pour quelquun qui ne connaissait pas bien le domaine. Il fallait aussi faire le tri entre ce qui tait dans le document et ce qui tait dans le produit tester, car le dveloppement se faisait en deux incrments et le document portait sur le tout. Et bien sr, le document ntait plus tout fait jour. Le constat courant dans le domaine du logiciel est quun gros document de spcication labor au dbut est difcile maintenir, quil nest pas trs utile pour le dveloppement et encore moins pour les tests.
La dmarche est fondamentalement diffrente avec Scrum.

Une quipe Scrum ne produit pas une documentation faite au dbut du projet, qui dcrit en dtail toutes les spcications fonctionnelles. Elle collecte les fonctions essentielles et les rafne progressivement. Loutil de collecte sappelle le backlog de produit.
Backlog, ny aurait-il pas un mot pour le dire en franais ? Avant de connatre le terme backlog, jutilisais la notion de rfrentiel des exigences. Dailleurs sur le premier projet que jai accompagn dans la transition Scrum, cest ce terme qui a t utilis plutt que backlog. Mais le sens nest pas le mme : littralement le backlog est la liste des choses en attente. Une tentative de traduction de backlog en franais a t de lappeler carnet de produit. Cela na pas vraiment perc, mme pas au Qubec o nos cousins sont pourtant de fervents adeptes de la francisation des mots issus de langlais. Lusage courant de la communaut francophone Scrum est de ne pas traduire backlog. Attention : les prsentations et articles sur Scrum en anglais prsentent deux backlogs, le backlog de produit et le backlog de sprint.

Dans ce chapitre, il nest question que du backlog de produit. Plus gnralement dans ce livre, quand jutilise backlog, cest du backlog de produit quil sagit. Dailleurs pour viter les confusions, je ne parle pas de backlog de sprint, mais de plan de sprint. Le risque de confusion est moindre en anglais, avec Product Backlog et Sprint Backlog, le premier mot faisant la diffrence.

5.1 LE BACKLOG, LA LISTE UNIQUE DES STORIES


La notion de backlog nest pas trs difcile comprendre : cest une liste dont les lments sont rangs par priorit.

5.1 Le backlog, la liste unique des stories

57

Figure 5.1 Jai dit de travailler sur le backlog, pas black dog ! (Black dog est un morceau clbre du groupe Led Zeppelin.)

Scrum nimpose pas de pratique pour identier et nommer les lments du backlog. Lusage le plus courant est de dnir un lment comme tant une story.

Priorit dcroissante

A B C D E F G H I

J K L

Stories

Figure 5.2 Un backlog de produit

Dfinition La technique des user stories est frquemment associe Scrum. Seulement, dans un backlog, toutes les histoires (stories) ne sont pas relatives des utilisateurs (user ), certaines sont caractre technique, par exemple. Cest pourquoi jutiliserai le terme gnral de story pour parler dun lment du backlog de produit.

Dans un backlog de produit, les stories sont ranges selon lordre envisag pour leur ralisation. Cette notion de priorit, qui nest pas usuelle dans les documents de spcication, prend une grande importance dans le dveloppement itratif. Pour un produit, il existe un et un seul backlog (cest pour cela quon dit backlog de produit). On y trouve rassembl ce qui est dordinaire dispers dans plusieurs documents ou dans plusieurs outils.

58

Chapitre 5. Le backlog de produit

5.1.1 Utilisateurs du backlog


Le backlog sert communiquer : il est utilis largement, car au carrefour de plusieurs activits :
la gestion de projet, car le backlog est la base pour la planication ; lingnierie des exigences, puisquon y collecte ce que doit faire le produit ; la conception et le codage des stories slectionnes pour un sprint ; le test, qui permettra de sassurer que les stories sont bien nies dans un sprint.

Mme si cest le Product Owner qui en est responsable et qui dnit les priorits, le backlog est partag entre toutes les personnes de lquipe. Le backlog est galement visible des personnes extrieures lquipe qui sont intresses par le dveloppement du produit : clients, utilisateurs, managers, marketing, oprations... Tout ce monde y a accs, ce qui favorise la transparence et facilite le feedback, qui se concrtise par lajout de nouvelles stories.

5.1.2 Vie du backlog


Le backlog suit la vie du produit quil dcrit, il volue avec lui ; il peut donc avoir une dure de vie trs longue, courant sur de nombreuses releases.

mergence progressive
Plutt que dessayer de tout ger dans le dtail au dbut, le contenu du backlog est dcompos progressivement. Jai particip de nombreuses dnitions et spcications dexigences dans diffrents domaines du dveloppement de logiciel. Le constat a toujours t le mme : il est impossible de connatre toutes les exigences ds le dbut dun projet. En rchissant longtemps et en essayant dimaginer les situations dans lesquelles se trouveront les utilisateurs, on peut bien sr dcouvrir un bon nombre dexigences signicatives, mais il en existera toujours qui mergeront plus tard : mme en se mettant dans la peau des utilisateurs, on ne pourra pas les spcier ni mme les identier lavance. Seul le feedback sur une version partielle permettra de savoir ce que les utilisateurs attendent rellement. Plus rcemment, jtais le Product Owner dune quipe Scrum et jaurais t bien incapable de dnir prcisment au dbut ce quest nalement le produit aujourdhui, mme si javais des ides et que javais rdig un document donnant la vision que jen avais. Non seulement il naurait pas t possible de spcier en dtail les exigences, mais cela aurait t du gaspillage, car les changements ont t nombreux et frquents. Dans un dveloppement agile, le changement est possible et mme encourag. Il ne cote presque rien, tant quil porte sur un lment pour lequel on a fait peu deffort.

5.1 Le backlog, la liste unique des stories

59

Le contenu du backlog merge progressivement, juste temps. Ce concept est la base de Scrum et des mthodes agiles. Pour un nouveau produit, cette mergence dcoule dune approche descendante o les stories sont dcomposes progressivement.

Changements continuels
Le backlog nest pas un document g, il nest jamais complet ou ni tant que vit le produit, il volue continuellement : des lments sont ajouts, des lments sont supprims, des lments sont dcomposs ou les priorits ajustes.

Ajout

A B C G D E F H I

J K L Suppression

Changement de priorit

Figure 5.3 Les changements dans le backlog : ajout, suppression et changement de priorit

Le Product Owner peut le modier souvent, voire quotidiennement, en fonction du feedback. Cependant, les modications les plus importantes surviennent au cours des runions de n de sprint et de dbut du suivant.
Par exemple, lors de la revue de sprint, il est ajust en fonction du produit obtenu la fin du sprint : les stories finies sont enleves. Attention : ce changement continuel na pas dimpact sur lquipe qui dveloppe ; pendant un sprint, la partie du backlog sur laquelle lquipe travaille est gele.

Utilisation continue
Le backlog est labor dans une forme initiale avant le lancement du premier sprint : il permet de planier la release1 . Il sert pendant les sprints pour connatre les stories en cours de dveloppement. Par exemple, lors de la runion de planication en dbut de sprint, il est utilis pour dcider du sous-ensemble qui sera ralis pendant le sprint.
1. Pour en savoir plus, lire les chapitres 6 La planication de la release et 13 De la vision aux stories.

60

Chapitre 5. Le backlog de produit

5.1.3 Options de reprsentation du backlog


Un backlog est une liste qui peut tre gre de multiples faons. Aux premiers temps des mthodes agiles, les stories taient identies par des cartes (des ches bristol) et la priorit dnie par lordre dans lequel les cartes taient ranges. Cependant, le besoin dun outil informatique1 vient assez vite pour grer le backlog, tre assist dans le suivi, faire des plans et produire des graphiques. Les outils permettent de produire plus facilement les artefacts drivs du backlog :
Le plan de release est une projection du contenu du backlog sur les sprints de la

release. Le burndown chart de release est un graphe, mis jour la n de chaque sprint, bas sur la taille courante du backlog de produit.

5.2 LA NOTION DE PRIORIT DANS LE BACKLOG


Le backlog est la liste unique de tout ce qui est faire, ce qui donne beaucoup dimportance la notion de priorit.

5.2.1 Le sens de la priorit


Que signifie la priorit ? Dire que la story A est plus prioritaire que la story B signifie que A sera ralise avant B. Les priorits sont utilises pour dfinir lordre de ralisation.

nimporte quel moment de la vie du produit, on sait que les stories les plus prioritaires du backlog sont candidates tre dveloppes dans le prochain sprint. Les stories moins prioritaires seront dveloppes plus tard, dans des sprints futurs. Elles peuvent donc tre moins dtailles et tre dans un tat diffrent, avec des attributs moins prcis. En rsum, la priorit permet de constituer le ux de stories qui va alimenter lquipe. Lordre peut changer tant que lquipe na pas commenc dvelopper la story.

5.2.2 Les critres pour dfinir la priorit


La priorit a un impact sur le contenu du produit partiel qui est ralis la n de chaque sprint. Pourquoi considrer quil vaut mieux avoir la n dun sprint un produit avec la story A plutt quavec la story B ?

1. La prsentation des outils est faite au chapitre 17 Scrum avec un outil

5.2 La notion de priorit dans le backlog

61

Backlog

A B C G D E F H M I

J L

Le flux de stories alimente les sprints


Release Sprint 1 Sprint 2 Sprint 3 Sprint 4

Figure 5.4 Priorit et sprints

La priorit dpend de diffrents critres qui varient avec le temps. On a vu que les mthodes agiles avaient pour but de maximiser la valeur, ce qui en fait un critre majeur pour dnir la priorit. Cependant cette notion de valeur nest rellement applicable que sur des grandes fonctions en nombre limit (features) et sert essentiellement guider dans lordre de dcomposition. En rythme de croisire un backlog contient frquemment 50 lments dont certains dtaills, cela demande une approche plus large pour tablir les priorits. Les critres suivants poussent donner une grande priorit une story :
Le risque quelle permet de rduire Lobjectif est de rduire lexposition au

risque le plus rapidement possible. Des stories permettant de valider des choix techniques structurants sont monnaie courante dans les premiers sprints dun nouveau dveloppement innovant. Lincertitude sur des besoins des utilisateurs quelle permettra de diminuer Quand un utilisateur dsire une fonctionnalit mais ne sait pas de quelle faon le service doit tre rendu, la solution est de lui montrer rapidement une version pour obtenir du feedback. La connaissance apporte par le dveloppement des stories relatives cette fonctionnalit est une occasion damliorer le produit. La qualit laquelle elle contribue Les travaux visant garantir la qualit du produit devraient tre prioritaires. Par exemple, si une rtrospective a mis en vidence la ncessit dautomatiser les tests, la story correspondant aura une priorit leve. Les dpendances entre stories Si une story A ne peut tre dveloppe que si une autre story B existe, la story B doit tre plus prioritaire que A. Cest seulement une fois que ces critres sont pris en compte que la compltude fonctionnelle (et donc la valeur pour le client) devient prpondrante.

62

Chapitre 5. Le backlog de produit

5.2.3 La gestion des priorits dans le backlog


Toute lquipe participe la dnition des priorits, mais cest en dernier lieu le Product Owner qui en est responsable.
Techniques de gestion des priorits dans le backlog Lutilisation dlments physiques, comme des cartes ou des Post-it, facilite le rangement par priorit. Avec un outil comme un tableur, il est possible dajouter une colonne Priorit, et de donner une valeur pour chaque lment du backlog. Il est alors facile dordonner la liste sur cette colonne priorit. Mais lutilisation dun nombre fini et limit de valeurs pour la priorit, ne rsout pas tout car au moment de trier il y a des lments ex quo. Il y a aussi un risque de confusion entre la priorit et la valeur ajoute, qui, comme nous lavons vu, nest pas le seul facteur pour dfinir la priorit. Cest pourquoi la pratique la plus efficace est, plutt que donner une valeur, dordonner tout simplement la liste des lments du plus prioritaire au moins prioritaire. Les tableurs le permettent gnralement mais les outils ddis Scrum offrent plus de facilits pour cela. Dans ce cas, la priorit nest pas un attribut explicite. Elle est implicite, donne par lordre de rangement dans le backlog. On ne peut donc pas avoir deux lments avec la mme priorit.

5.3 UN LMENT DU BACKLOG


5.3.1 Attributs
Scrum ne dnit pas strictement les attributs dun lment de backlog. Le choix est laiss aux quipes, en fonction du contexte. Je conseille aux quipes avec lesquelles je travaille dutiliser les attributs suivants :
Story Nom Identifiant Description Type (user, technique, dfaut) tat Taille
Figure 5.5 Une story avec ses principaux attributs

Je vais dtailler les trois derniers attributs un peu plus loin. Dautres attributs peuvent tre utiles : lestimation de sa valeur ajoute, le crateur et la date de cration, une estimation de sa frquence dexcution sur le produit dploy (une

5.3 Un lment du backlog

63

user story peut se drouler selon le cas plusieurs fois par jour ou une fois par semaine), le rle associ (lutilisateur qui est linitiative de la story). Il faut ajouter les conditions permettant de considrer que la story est nie. Ces conditions sont essentielles pour lacceptation de la story la n du sprint. Chacune correspond en fait un cas de test qui peut tre dcrit de faon plus ou moins formelle. Un haut niveau de formalisation facilite lautomatisation des tests dacceptation1. Lors de la vie de la story, on y associera : le sprint dans lequel la story est planie et les tches permettant de la raliser.

5.3.2 Types
Il est courant est didentier plusieurs types de story, ma recommandation est den utiliser trois :
User story Elle dcrit un comportement du produit visible pour les utilisateurs

et qui leur apporte de la valeur ou de lutilit.


Story technique Elle est invisible pour les utilisateurs mais visible par lquipe

de dveloppement. Elle est ncessaire pour pouvoir dvelopper certaines user stories, son utilit est donc indirecte. Dfaut Il est relatif un comportement visible des utilisateurs mais qui enlve de la valeur au produit. En dveloppement de logiciel, on parle couramment de bug. Avec Scrum, on ne se proccupe pas de savoir si une anomalie correspond un bug ou une demande dvolution du produit. Peu importe, cest un dfaut qui demande du travail. Le dfaut va dans le backlog et, par facilit de langage, nous allons considrer que cest aussi une story, de type dfaut.
Pour un nouveau produit, la majorit des lments du backlog sont des user stories. La proportion est variable selon le contexte technique. Pour un produit qui est dj utilis, le nombre de dfauts peut tre significatif.

5.3.3 Cycle de vie dun lment


La vie dun lment du backlog est dnie par les tats prsents gure 5.6. La vie dune story est soumise quelques rgles : une story nest estime que si elle a t accepte ; une story ne peut tre planie que si elle est estime ; une story ne peut devenir en cours qui si elle est planie ; la n dun sprint la story en cours devient nie.
En principe, une story finie ne fait plus partie du backlog, mais elle est souvent conserve pour garder une trace de ce qui a t fait.

1. Les tests dacceptation sont prsents en dtail dans le chapitre 15.

64

Chapitre 5. Le backlog de produit

Cr

Accept

Estim

Planifi

En cours

Fini

Figure 5.6 Cycle de vie simplifi dun lment : Cr (par nimporte qui) ; Accept (par le Product Owner) ; Estim (par lquipe dans une sance de planning poker ) ; Planifi (associ un sprint futur lors de la planification de release) ; En cours (dvelopp dans le sprint courant) ; Fini (termin, selon la signification de fini).

partir de ces tats, il est possible de ltrer les lments du backlog, par exemple pour obtenir celles en cours. Selon ltat des stories, on peut identier quatre grandes parties dans un backlog, selon les accs :
une personne qui veut savoir ce qui est en cours de dveloppement dans le sprint

en cours ltrera le backlog uniquement sur les stories en cours ; quelquun qui veut connatre les prvisions moyen terme est intress par les stories planies, qui constituent le plan de release ; le Product Owner dans son travail danticipation sur les futurs sprint va consulter la partie du backlog quil faut peut-tre dcomposer, complter ou estimer ; tout le monde peut avoir envie de connatre les stories nies dans les sprints passs.

5.3.4 Taille des lments


Un backlog contient des lments de taille diffrente, ce qui est ret par la valeur de lattribut taille :
Un lment prioritaire, plac en tte de la liste, va tre bientt dvelopp. Il

convient quil soit sufsamment dtaill pour tre compris et ralis par lquipe. ce niveau on a une story de petite taille, qui est prte pour le prochain sprint. Un lment au milieu du backlog ne sera dvelopp que dans quelques sprints. cette place les stories sont de taille moyenne et peuvent encore tre dcomposes. Un lment plac en n de la liste sera dvelopp plus tard. On y trouve des stories de plus grande taille qui seront dcomposes ultrieurement.

3 2

3 2

3 2

Figure 5.7 Taille typique des lments du backlog (les lments les plus fins ont une taille de un) : on voit que la taille est plus grande pour les lments les moins prioritaires

5.4 Guides dutilisation du backlog

65

5.4 GUIDES DUTILISATION DU BACKLOG


5.4.1 Partager le backlog avec toute lquipe
Constituer et faire vivre le backlog favorise la collaboration : le Product Owner est moteur, mais toute lquipe contribue la dcouverte des stories et utilise le backlog. La facilit avec laquelle le backlog est partag dpend dans une large mesure de loutil utilis pour le grer : plus il sera facile dy accder plus il y aura des chances que les personnes lutilisent frquemment. Si lquipe se lapproprie, cela permet de renforcer sa connaissance du produit et la motive obtenir ce qui est identi. En plus des runions balises, dautres points de rencontre de toute lquipe ont lieu, qui portent sur le backlog :
Ateliers La premire fois, le backlog de produit est labor par des ateliers

permettant didentier les lments, les ordonner par priorit et les estimer. Communication en face face Tout nest pas crit dans le backlog : une story est lobjet de discussions pendant le sprint o elle est dveloppe. Cela permettra de la faire passer de lesprit du Product Owner celui du dveloppeur, tout en laissant ce dernier une marge de manuvre pour sa ralisation.

5.4.2 Bichonner le backlog


Bichonner signie entourer de soins dlicats et attentifs et cest exactement ce que doit faire le Product Owner pour son backlog. Il le triture, il le nettoie, il le range et fait en sorte que ce soit un outil toujours oprationnel. Un backlog jour, cela implique notamment que des stories soient insres (ou retires) quand cest ncessaire et quelles soient ordonnes par priorit, la bonne granularit, estimes et dtailles au bon niveau, avec lquipe.

Ajouter et retirer
Puisque les mthodes agiles favorisent le changement, le backlog est le rceptacle des nouvelles stories qui en sont le reet. De nouvelles stories sont identies mais dautres peuvent disparatre, parce quelles ne sont plus considres utiles par le Product Owner.

Dcomposer et dtailler
Une story insre dans le backlog peut tre de grande taille. Elle est dabord dcompose en stories de plus petite taille. Cette dcomposition progressive prcde le rafnement dune story, lorsquon lui apporte plus de dtails, gnralement sous forme de cas de tests dacceptation.

66

Chapitre 5. Le backlog de produit

Dcomposition

B C

Dtail de A

Test1 Test2 Test3

Figure 5.8 Dcomposition et dtail dune story

Changer les priorits


Un Product Owner est amen changer lordre des priorits pour plusieurs raisons :
chaque fois quune story est ajoute dans le backlog, il faut lui donner une priorit,

par rapport aux autres lments : elle ne se place pas forcment en dernier ; une meilleure connaissance dune story ; une dcouverte dun bug ou le besoin dune tude ; lestimation de la taille dune story ; son utilit potentielle peut changer au l du temps ; la planication dun sprint peut changer les priorits pour ajuster le primtre lengagement de lquipe.

5.4.3 Surveiller la taille du backlog


Le backlog ne doit pas comporter trop dlments. Sur sa partie active, celle qui porte sur les lments qui sont raliser, donc sans considrer celles qui sont nies ni celles en cours, il est conseill de rester moins dune cinquantaine dlments. Cela est possible parce que les lments se dcomposent progressivement si on utilise une approche descendante. Cette approche de dcomposition progressive est naturelle au dbut du dveloppement dun produit. Si le backlog est constitu sur un produit existant ou commenc sans dnir une vision, il y a des risques quil contienne trop dlments.

Ne pas copier les gros documents de spcification


Quand une quipe dmarre avec Scrum, il peut exister des documents de spcication traditionnels dj rdigs, avec peut-tre des centaines dexigences identies et numrotes. Il est tentant den faire des entres du backlog. Les mettre dans le backlog sans discernement rendrait le backlog ingrable. Dune part, parce quil y aurait trop dlments, dautre part, parce quil faut structurer les lments introduits dans le backlog.

5.4 Guides dutilisation du backlog

67

La solution est alors danalyser le document pour vrier sa compatibilit avec une approche agile. Si ce nest pas le cas, il vaut mieux sen servir comme point de dpart pour partir sur une identication des stories puis sen dbarrasser.

Ne pas insrer tout le stock de bugs


Sur des projets, on trouve parfois des stocks de bugs rsiduels normes que lquipe a du mal liminer. Cest dailleurs souvent pour essayer de rgler le problme que lquipe passe Scrum. Seulement, transfrer des centaines de bugs dun bugtracker dans le backlog nest srement pas une bonne ide, pour les mmes raisons de taille : un tri pralable simpose avant de les inclure.

Nettoyer en profondeur
ct des changements au jour le jour, il peut y avoir besoin dun gros mnage dans le backlog. Cette mise jour, faire de prfrence la n dune release, permet de supprimer, par exemple :
des stories qui restent toujours au fond du backlog, probablement parce quelles

ne sont nalement pas utiles, des doublons.

5.4.4 viter davoir plusieurs backlogs pour une seule quipe


La rgle est davoir un backlog par produit, une autre rgle est davoir une quipe pour dvelopper un produit, avec la recommandation que lquipe est temps plein sur un seul projet. De nombreuses organisations passant Scrum sont dans un schma o une seule quipe travaille sur plusieurs projets en mme temps. Bien souvent elles abordent la transition Scrum en faisant un backlog par projet. Si la taille de lquipe ne dpasse pas la taille standard dune quipe Scrum, ce nest pas la bonne approche : les problmes de priorit ne seront pas rsolus (sans oublier les autres inconvnients du multiprojets pour une personne). Une meilleure solution de transition est de rester dans le cadre : une quipe un backlog.

68

Chapitre 5. Le backlog de produit

En rsum
Le backlog de produit est la liste des futures ralisations de lquipe. Cest llment pivot dun dveloppement avec Scrum en ce qui concerne le contenu du produit et la gestion de projet. Cette liste unique des choses faire, ranges par priorit, est au cur de la mcanique de mise en uvre de Scrum lors des sprints : elle permet de dnir le produit partiel vis et de faire la planication. Le backlog de produit est pour beaucoup dans llgance et la simplicit du cadre de dveloppement que constitue Scrum.

6
La planification de la release

Ceux qui ne connaissent pas bien les mthodes agiles pensent parfois, tort, quelles ne permettent pas de planier, parce que a change tout le temps . Ils ont bien compris que le client pouvait faire des changements et en dduisent trop rapidement : quoi sert de faire des plans sils sont remis en question sans arrt ? Dautres qui appliquent Scrum depuis peu ont bien compris quil y avait de la gestion de projet pendant le sprint, mais ne voient pas encore lintrt de la planier la release. Pourtant, agile ou pas, il est toujours ncessaire davoir des prvisions sur le moyen terme.
Imaginons un projet de dveloppement dune application pour une socit qui organise des vnements. Des questions ne manqueront pas de se poser sur le futur, comme par exemple : Pourrons-nous utiliser la gestion des inscriptions en ligne pour la confrence de mars ? Dans combien de temps aurons-nous la possibilit de diffuser des confrences en streaming ? Quel est le budget ncessaire pour dvelopper la version de mars de lapplication ?

Ce chapitre montre comment la planication de release permet de rpondre ces questions.

70

Chapitre 6. La planification de la release

Dfinitions Une release est la priode de temps constitue de sprints utilise pour planifier moyen terme. La vlocit est la mesure de la partie du backlog de produit qui est ralise par lquipe pendant un sprint. Les mesures de vlocit sont utilises pour planifier. Un burndown chart est une reprsentation graphique du reste faire dans une priode, actualis aussi souvent que possible et permettant de montrer la tendance. Dans le cas dun burndown chart de sprint, la mise jour est quotidienne, et le burndown chart de release, qui nous intresse dans ce chapitre, est actualis chaque sprint.

6.1 PLANIFIER LA RELEASE


6.1.1 Planifier pour prvoir
Dans tous les projets, on fait des plans, pour essayer de prvoir ce que va contenir un produit ou quelle date il sortira sur le march. Avec Scrum, la planication de release a les mmes objectifs : fournir lquipe et aux parties prenantes des informations sur le contenu des sprints constituant la release. Il y a cependant deux diffrences fondamentales avec les approches classiques :
il y a deux niveaux de plan1 et le plan de release est gros grain, le plan nest pas fait une fois pour toutes au dbut du projet, il volue.

Le plan de release est certes labor une premire fois au dbut du dveloppement dun produit, mais de manire plus lgre quavec une approche traditionnelle, et il est mis jour chaque sprint.

6.1.2 Runion ou processus ?


Dans le livre Agile Project Management with Scrum de Ken Schwaber (2004), la planication de release tait peine voque. Le Guide Scrum de la Scrum Alliance dat de mai 20092 , toujours crit par Ken Schwaber, la mentionne explicitement comme faisant partie du crmonial (les timeboxes). Mais il ne la dtaille pas beaucoup ; la diffrence des autres runions du crmonial, la planication de release est peu balise. Dailleurs dans les enqutes sur les usages de Scrum ou de lagilit, on constate que la planication de release est une des pratiques les moins rpandues. En fait, la planication de release correspond plus un processus et elle ne se rduit pas en une seule runion. Une grande partie de leffort ncessaire pour produire le plan de release est consacre lestimation : pour planier, il faut dabord estimer. Avec Scrum et les
1. Lautre est le plan de sprint pour le court terme. 2. Guide Scrum : http://www.scrumalliance.org/resources

6.1 Planifier la release

71

mthodes agiles, lestimation est collective, elle slabore lors de runions o toute lquipe participe. Ce sont ces runions qui rythment le processus de planication de la release.
1 Dfinir le critre de fin 3 Dfinir la dure des sprints

Backlog

2 Estimer les stories

Backlog estim

5 Planifier la release

Plan de release

4 Estimer la capacit de lquipe


Figure 6.1 Le processus de planification de release

La planication de release repose sur lestimation et demande de dnir deux variables, la dure du sprint et la capacit de lquipe, avant de planier.

6.1.3 La participation de lquipe est requise


Toute lquipe Scrum participe la planication de la release. Lquipe considre est lquipe complte, avec le ScrumMaster et le Product Owner. Lhabitude prise par des managers, avant de passer Scrum, de faire des plans seuls ou en comit restreint en dbut de projet peut les pousser planier la release sans faire participer lquipe. En effet dans la gestion de projet traditionnelle, ce type de plan est labor par un ou plusieurs experts de lestimation et de la planication. Avec Scrum, cest diffrent, les estimations sont faites par lquipe et aussi la planication de release qui en dcoule. Cest un point fondamental de lestimation agile : cest lquipe qui la fait, car ceux qui excutent les tches de ralisation sont les mieux placs pour en connatre les difcults.

6.1.4 La release est planifie partir du backlog


La planication de release utilise le backlog de produit que le Product Owner a prpar en ordonnant les stories par priorit. Un backlog peut contenir 50 lments, voire plus, mais la subtilit est que tout nest pas dcompos au mme niveau : on a besoin davoir une dcomposition trs ne, en petites stories, uniquement pour ce qui sera fait dans les prochains sprints. Pour le reste, la dcomposition sarrte lorsque lestimation de llment est possible. Cela donne un backlog avec les petites stories devant et les grandes qui attendent leur tour derrire.

72

Chapitre 6. La planification de la release

6.1.5 Place dans le cycle de vie


La planication de release commence pour la premire fois avant le dbut du premier sprint, et ensuite elle a lieu au cours de chaque sprint. La pratique la plus efcace est de tenir une runion quelques jours avant la n du sprint (et le dbut du prochain).
La premire fois

Sprint

Sprint 4

Figure 6.2 Quand faire la planification de release

La runion de planication de release ne se droule pas de faon aussi uniforme que les autres runions Scrum. On peut distinguer la premire, avant le dbut du premier sprint, de celles faites au cours de chaque sprint.

La premire fois, avant le premier sprint


La premire planication de release demande plus defforts que les suivantes. laborer pour la premire fois un plan de release est difcile : il faut dj disposer du backlog initial et il est souvent ncessaire pour cela dorganiser plusieurs ateliers. Une fois le backlog prt, aprs une premire passe sur les priorits et sur les estimations, la premire runion de planication de release peut se tenir. Cest une sorte de runion de lancement de release (release kickoff meeting) permettant lquipe de drouler les tapes du processus de planication de release.
Attention : si la release comporte de nombreux sprints, il nest pas utile de faire une planification en dtaillant les stories pour tous les sprints. Avoir un horizon prcis deux ou trois sprints est suffisant sachant que la planification de release est ajuste chaque sprint : les stories dcomposer le seront au moment adquat.

chaque sprint
Dans les sprints successifs de la release, le travail faire pour ajuster le plan de release dpend de la quantit de changements survenus. Les changements dont il est question sont ceux qui ncessitent destimer ou r-estimer : une nouvelle story, des stories qui rsultent dune dcomposition, une modication substantielle dune story existante. Tout cela fait varier la taille du backlog

6.2 tapes

73

Sprint fini

Horizon

Release Sprint 1 Sprint 2 Sprint 3 Sprint 4

Figure 6.3 Horizon du plan de release

et a un impact sur le plan de release. Une modication dans les priorits du backlog est aussi un changement qui modie le plan de release.
Planification de release pendant un sprint Pour mettre jour la planification de release, je recommande de faire une runion, un peu avant la fin du sprint. Lors de cette runion, les tapes de la planification sont droules, mais uniquement sur ce qui a chang depuis le dbut du sprint. Elle a un intrt supplmentaire : quand le Product Owner prsente les stories quil pense inclure dans le prochain sprint, lquipe peut se prononcer sur sa perception de la story. Soit lquipe confirme quelle est prte tre incluse dans le prochain sprint, soit elle considre que la prsentation faite par le Product Owner est insuffisante et ne permet pas linclusion de llment dans le sprint venir. Dans ce cas, il restera quelques jours au Product Owner pour complter la connaissance relative cette story. Sil ne peut pas le faire avant le dbut du sprint, llment ne sera pas inclus dans ce sprint. Dure : une heure maximum. Ce temps pass en runion est largement compens par la diminution de la dure de la planification du sprint et par le temps gagn sur la comprhension du travail faire. Quand : il faut tenir cette runion un peu avant la fin du sprint. Pas trop tard pour laisser un peu de temps au Product Owner sil lui faut approfondir des stories. Pas trop tt pour avoir une ide de ce qui sera effectivement fini la fin du sprint. Pour des sprints qui durent trois semaines, je conseille de la tenir trois jours avant la revue de fin.

Lors de la revue de sprint et de la planication du sprint suivant, le plan de release peut tre lgrement ajust, en fonction des rsultats et du nouvel engagement de lquipe.

6.2 TAPES
6.2.1 Dfinir le critre de fin de la release
Une release est une squence de sprints, mais quand nit-elle ? Pour dcider de larrt des sprints et de la n dune release, il existe plusieurs possibilits.

74

Chapitre 6. La planification de la release

Finir quand le backlog est vide


Ceux qui sont habitus dvelopper partir dune spcication contenant tout ce quil y a faire seront tents de dire que la release sarrtera quand le backlog de produit sera vide. Mais le backlog est vivant et, nalement, il se rapproche dun ot continu toujours aliment. Ce nest donc pas une bonne ide que de vouloir vider le backlog. Jai connu une quipe qui a essay pendant 18 sprints, sans succs ! Une variante est de slectionner un sous-ensemble du backlog pour la release. Comme les lments sont rangs par priorit, il suft de xer une limite en disant : on sarrtera l pour la release courante, les stories suivantes seront faites dans la release suivante . Cest ce quon appelle une release primtre x. La planication de la release a alors pour objectif destimer la date de n.

Release 1

Release 2

Backlog

3 2

3 2

3 2

Primtre fix pour la release 1


Figure 6.4 La release primtre fix

Attention : mme restreint de cette faon, le primtre dune release peut toujours voluer, il serait stupide de figer le backlog en refusant un changement qui apporte de la valeur.

Fixer la date lavance


Une meilleure faon de procder est de dnir une date de n et de sy tenir, en reprenant lide de la timebox. Lobjectif de la planication dune release date xe est alors destimer quel contenu sera fourni la date prvue. La release date xe prsente de nombreux avantages :
elle donne un objectif prcis et gnralement pas trop lointain, ce qui motive

plus lquipe ; elle demande obligatoirement une rexion pousse sur les priorits des lments du backlog par le Product Owner ; des lments du backlog prsentant nalement peu dintrt ne seront pas intgrs dans la release ;

6.2 tapes

75

on passe gnralement moins de temps estimer et planier, puisque la date de

livraison est connue. Un autre avantage est le rythme donn par des releases rgulires : une organisation shabituera cette frquence, qui cadence le travail de lquipe mais aussi celui des utilisateurs et de leurs reprsentants.

Release 1

Release 2

Sprint 1

Sprint 2

Sprint 3

Sprint 4

Sprint 1

Sprint 2

Date fixe
Figure 6.5 La release date fixe

Il y a des variantes possibles pour dnir la n dune release :


Attendre quelques sprints pour dcider. Une fois la dcision prise, on se retrouve

dans une des deux situations prcdentes. Arrter la release quand le produit partiel a sufsamment de valeur. Arrter la release quand le budget est consomm. La release date xe et dure uniforme, par exemple une release tous les trois mois, est la formule la plus facile mettre en uvre. Pour prendre une mtaphore sportive, la release date xe sapparente au test de Cooper. Ce test tait pratiqu autrefois larme : il sagit de parcourir la plus grande distance possible en douze minutes. La release primtre x se rapprocherait dune course sur une distance dnie, par exemple un 5 000 mtres.

6.2.2 Estimer les stories du backlog


Chaque story du backlog doit tre estime si on veut en tenir compte dans la planication. Lestimation dont il est question ici est celle relative leffort fournir pour la dvelopper. En effet, les stories dans le backlog ne sont pas toutes de mme taille et on ne peut pas simplement se baser sur le nombre de stories faire pour planier. La technique utilise pour estimer nest pas impose dans Scrum. Lusage le plus frquent est de faire une estimation collective au cours dune sance appele planning poker et destimer la taille plutt que la dure.

76

Chapitre 6. La planification de la release

La technique du planning poker1 ( http://www.planningpoker.com/detail.html) connat un succs grandissant auprs des quipes Scrum (en fait, il ne sagit pas de poker ni de planning, un nom plus appropri serait estimation de backlog ). Cest une sance destimation en groupe, avec des cartes, qui combine le jugement dexpert et lestimation par analogie.
Droulement du planning poker Chaque participant reoit un jeu de cartes. Sur chaque carte il y a une valeur possible pour lestimation dune story. Le Product Owner prsente la story. Les membres de lquipe posent des questions pour bien la comprendre et dbattent brivement. Tous les participants prsentent en mme temps la carte choisie pour lestimation. Le groupe discute des diffrences ventuelles. On recommence jusqu arriver une convergence des estimations pour la story, puis on passe la suivante.

Comme il est plus facile de faire des estimations sur une chelle prdnie plutt que davoir sa disposition tous les entiers, la suite de Fibonacci est gnralement utilise : 1, 2, 3, 5, 8, 13.
De nombreux jeux de cartes ont fait leur apparition et sont vendus sur Internet ou fournis par des sponsors lors de confrences. La suite de Fibonacci est complte avec 0 et 1 2 pour les petites stories et 20, 40 et 100 pour les grandes.

Figure 6.6 Des cartes de planning poker (http://www.tekool.net/blog/2009/07/21/printable-agile-planning-poker/)

1. Pour plus dinfos, lire : http://www.planningpoker.com/detail.html

6.2 tapes

77

Pour commencer la sance, il faut dnir un talon. Cest simplement une story connue de tous, pour laquelle lquipe dcide en commun dune valeur arbitraire.
Il est prfrable de choisir une story de taille moyenne et de lui donner une valeur de 2, 3 ou 5, pour laisser le spectre ouvert vers le haut et vers le bas.

Lestimation par comparaison est facilite par lusage de Post-it pour chacune des stories du backlog : on fait des ranges pour chaque valeur possible dune estimation.
1 story story story story 2 story story 3 story story story 5 story story 8 story 13 story

story
Figure 6.7 Stories ranges par niveau destimation au cours du planning poker

Comme toutes les stories dj estimes sont visibles, cela facilite les estimations des suivantes et permet de raccourcir le temps consacr au planning poker en cas de divergence. Il arrive galement que lquipe ajuste a posteriori une estimation lorsquelle la compare dautres ayant obtenu la mme estimation lors du planning poker. Pour que cette technique soit efcace, il faut avoir dj une bonne dnition du produit, avoir constitu un backlog et avoir ordonn les lments par priorit. Cest alors la meilleure technique destimation que jaie pratique. En plus de laspect estimation, elle favorise une discussion riche entre lquipe et le Product Owner. Quelques leons tires des nombreuses sessions de planning poker que jai animes1 : cest facile organiser, il suft de disposer dun jeu de cartes par personne ; il y a rarement besoin de revoter une seconde fois, les discussions suite au premier vote sufsent gnralement pour converger ; la rexion par analogie est souvent utilise dans les discussions aprs le premier vote ;
1. Mme dans de grandes administrations ou des banques, nous avons sorti les cartes de poker !

78

Chapitre 6. La planification de la release

la technique de dcomposition des stories (elle peut tre applique pendant la runion) amliore la qualit des estimations ; quand lquipe est perplexe avant destimer, cest le signe que la story est vraiment trop vague et que le Product Owner devrait lapprofondir.

Figure 6.8 Des cartes au travail, oui mais pour planifier !

6.2.3 Dfinir la dure des sprints


Lorsquon se lance dans le dveloppement agile, une des premires questions laquelle il faut rpondre concerne la dure des itrations. Il ny a pas de rponse universelle, chaque projet est diffrent et doit dnir sa faon de travailler. Sil existe un consensus de la communaut agile pour prconiser que toutes les itrations doivent tre de mme dure et quune itration est un bloc de temps x, il y a des variations sur la dure dune itration. Scrum recommandait, jusqu il y a quelques annes, des sprints dun mois. La pratique actuelle dans les dveloppements avec Scrum, cest moins : la plupart des projets ont des sprints de deux ou trois semaines. Les critres retenir pour dnir la bonne dure sont :
Limplication des clients et utilisateurs Il faut tenir compte de leur disponibi-

lit utiliser les versions partielles produites la n de chaque sprint.

6.2 tapes

79

Le cot supplmentaire engendr par le sprint Un sprint ajoute du travail

supplmentaire pour prparer le produit partiel, faire les tests de non-rgression, prparer la dmonstration et pour les revues de n et de dbut de sprint. La taille de lquipe Plus il y a de personnes dans lquipe, plus il faudra de temps pour se synchroniser. La dure maximum pour prendre en compte un changement Il faut tenir compte du fait que cette dure peut aller jusqu deux fois la dure dun sprint (le changement est demand pendant litration n et dvelopp au plus tt dans litration n +1). La date de n de la release La release devrait comporter au moins quatre sprints pour que lquipe commence bncier des avantages de litratif. Donc si la date de n est dans deux mois, il est prfrable davoir des sprints de deux semaines ou moins. Le maintien de la motivation de lquipe Un sprint avec une dure trop longue est sujet ne pas avoir une distribution uniforme du travail pendant litration ce qui conduit travailler dans lurgence la n. La stabilit de larchitecture Ce sera difcile dobtenir un produit qui fonctionne dans une dure courte si larchitecture nest pas stable.

Comme le dit Thierry Cros1 : une dure dune semaine pour les sprints, cest le mieux, dans les contextes o cest possible. Quand ce nest pas possible, alors on envisage deux semaines. Si une dure de deux semaines semble difcile dans le contexte, on passe trois. En gnral, la dure dun sprint est un multiple de nombre de semaines, on ne fait pas des sprints de 13 jours ou 17 jours.
Exemple de dures frquemment utilises dans les quipes :
3 moispour une release Release S print 1 S print 2 S print 3 S print 4

S print 5

2 semaines pour un sprint

5 sprints dansune release

Figure 6.9 Dures de releases et de sprints usuelles

1. Dure du sprint : http://etreagile.thierrycros.net

80

Chapitre 6. La planification de la release

6.2.4 Estimer la capacit de lquipe


Vlocit et capacit
Dfinition La vlocit, mesure de la partie de backlog ralise par lquipe pendant un sprint, se calcule juste aprs la dmonstration lors de la revue de sprint. La capacit de lquipe est une prvision de ce que lquipe est capable de faire pendant un sprint. Elle se base sur la vlocit, selon le principe de la mto de la veille : lquipe devrait faire dans un sprint peu prs autant quelle a fait dans le prcdent.

La vlocit est une mesure : il faut que lquipe ait vcu une exprience commune pour lavoir collecte. Quand un dveloppement commence et quune nouvelle quipe vient dtre constitue, elle na pas de pass, elle na donc pas de vlocit connue. Si on veut quand mme faire un plan de release, sans attendre de drouler un ou deux sprints, il faut estimer sa capacit produire. Une faon de faire est de simuler la runion de planication du premier sprint : lquipe tudie quelques stories parmi les plus prioritaires du backlog, les dcompose en tches et estime la dure de ces tches. En les rapportant la taille des stories en points, il est possible dobtenir une valeur pour la capacit de lquipe.
Exemple : trois stories sont tudies, qui avaient t estimes respectivement 3, 2 et 5 points. Les tches identifies pour ces stories sont estimes 30 heures. Lquipe dispose de 300 heures pour le sprint. La capacit estime est de 300/30*10 soit 100 points.

Le chiffre obtenu contient une grande part dincertitude. Il ne doit absolument pas tre pris pour un engagement. Cest seulement une premire valeur qui permet de construire le plan de release initial. Il ne faut pas confondre estimation et engagement. Un plan de release se base sur des estimations et il peut, ventuellement, permettre de prendre des engagements. Une fois que la srie des sprints a commenc, la vlocit est mesure la n de chaque sprint lors de la revue. La vlocit est volatile et, surtout au dbut dune release avec une nouvelle quipe, elle peut varier sensiblement entre des sprints conscutifs. Il faut plusieurs sprints pour avoir des mesures pertinentes. Pour le plan de release, on dnit la capacit en faisant la moyenne des vlocits mesures sur les sprints depuis le dbut, ou seulement sur celle des trois derniers sprints, selon la conance quon a dans les premires valeurs.

6.2 tapes

81

Figure 6.10 Graphe de vlocit : la capacit utilise pour la planification de release est de 22 pour le schma.

Ne pas surestimer la fiabilit de la mesure


La vlocit est bien une mesure qui se collecte pour chaque sprint, cependant il ne faut pas perdre de vue quelle est base sur des estimations, celles faites sur la taille des stories. Si la vlocit augmente, il ny a pas moyen de savoir si cest d une amlioration de la productivit ou des estimations imprcises. Il est aussi possible daugmenter articiellement la vlocit, jai connu un chef de projet, qui navait pas encore lesprit de ScrumMaster, pousser des r-estimations la hausse avant chaque sprint parce quil croyait habile dafcher une vlocit qui augmente, en rejetant sur le Product Owner laugmentation du nombre de points faire au total. La vlocit varie, alors que les ressources restent xes : cela illustre que la capacit de lquipe volue et met en vidence lintrt destimer la taille plutt que leffort.
Attention : la vlocit est une mesure de lquipe, pas de personnes individuelles.

6.2.5 Produire le plan de release


Une fois quon a droul les trois premires tapes du processus, la production du plan de release est un jeu denfant (sil aime les mathmatiques). On prend le backlog prioris et estim. On commence par le premier sprint de la release. On y associe les stories en commenant par la plus prioritaire. On continue dans ce sprint en additionnant le taille en points des stories jusqu arriver la capacit de lquipe. Quand on y arrive, on passe au sprint suivant.

82

Chapitre 6. La planification de la release

Exemple : la vlocit moyenne est de dix, ce qui conduit prendre dix comme capacit de lquipe. Pour les sprints planifier, dix points de backlog sont affects en suivant les priorits.
10

10
10 Sprint fini 2 2 5

5
3 2 3

3 2

Release Sprint 1 Sprint 2 Sprint 3 Sprint 4

3 2

2 Sprints futurs

Vlocit = 10

Figure 6.11 Planification de release

Cest simple et dailleurs certains outils permettent de faire la planication automatique de la release. Une intervention manuelle savre quand mme utile :
si on ne tombe pas juste sur la capacit en ajoutant une story au sprint : il faut

dcider si on se place plutt en dessous, plutt en dessus ou si on prend une story moins prioritaire mais qui permet dtre plus proche de la capacit ; parce que la vue du plan de release pousse faire des ajustements : lart de la priorit est dlicat et voir le contenu des sprints amne parfois lquipe faire de nouveaux arbitrages dans le plan de release.

6.3 RSULTATS
6.3.1 Le plan de release
Un plan de release prsente les sprints venir et le contenu prvu de ces sprints, dni par les stories associes. Un plan de release a deux caractristiques nouvelles par rapport aux plans quon fait habituellement dans les projets :
Il est orient vers les clients et les utilisateurs pour que ceux-ci comprennent

limpact des changements proposs : plutt que de voir des tches qui ne leur parlent pas, ils y trouvent des stories qui devraient les intresser davantage.

6.3 Rsultats

83

Il est mis jour rgulirement : plutt quun plan dtaill fait lavance qui

devient la rfrence intouchable, le plan de release volue pour tenir compte des changements. Les informations contenues dans le plan de release servent anticiper les interdpendances. Dans un dveloppement il arrive que les travaux dune quipe dpendent de ceux faits par une autre quipe. Cest frquent quand plusieurs quipes travaillent sur le mme produit ou quand le logiciel dun systme embarqu dpend du matriel. Le plan de release permet didentier les points de synchronisation ncessaires et danticiper en adaptant les priorits.
Sprint fini Release Sprint 1 Sprint 2 Sprint 3 Sprint 4

K L M

P Q

Stories associes aux sprints

Figure 6.12 Un plan de release

Prsent sous forme de tableau, un plan de release est facile comprendre. Il constitue un outil de communication important avec tous les intervenants du projet. Le plan de release est visible, soit en tant afch dans lespace collaboratif de lquipe, soit, si lquipe est disperse, en tant facilement accessible en ligne (voir g. 6.13 exemple dun plan ralis avec IceScrum). La release apparat dans le bandeau suprieur, avec sa date de n. En dessous, les sprints sont prsents de faon squentielle de gauche droite, avec pour chacun le but, la capacit prvue et les dates de dbut et n. Les lments du backlog planis (associs aux sprints) sont estims en points. Le type dlment (user story, story technique ou dfaut) est montr par les icnes en haut gauche des Post-it.

6.3.2 Burndown chart de release


Un burndown de release est un indicateur graphique bas sur la mesure de ce qui reste faire. Un point dans le graphe est ajout pour chaque sprint : la valeur de labscisse correspond la taille de la partie du backlog qui reste faire dici la n de la release. Pour lobtenir il faut donc une liste de ce qui reste faire et une mesure de la taille de chaque lment, ce quon trouve dans le backlog de produit. quoi sert le burndown chart de release ?
montrer lavancement rel, en tout cas le meilleur quon ait, puisquil est bas

sur la distinction entre ce qui est compltement ni et ce qui reste.

84

Chapitre 6. La planification de la release

Figure 6.13 Un plan de release avec IceScrum

montrer la tendance et par l se poser des questions sur la faon de continuer.

Figure 6.14 Un burndown chart de release

Si la release est primtre x, le burndown permet destimer la date de n (gure 6.15). Si la release est date xe, le burndown permet destimer le contenu qui sera ni cette date. Le schma de la gure 6.16 illustre, pour une release date xe, le nombre de points rsiduels obtenus en prolongeant la tendance des premires itrations.

6.3 Rsultats

85

En fonction de ce que prsente le burndown, des dcisions peuvent tre prises plus facilement pour ajuster lobjectif de la release. Le burndown est limit1 dans les informations quil apporte : il ne fait pas apparatre les variations dues aux modications de primtre.
Exemple : si lors de litration 3 le graphe montre quon est pass de 140 points au dbut 134 la fin, on ne sait pas si la vlocit est de 6 ou si elle est en fait plus leve et combine des ajouts de nouvelles stories faire pour la release.

Tendance

Date actuelle

Date de fin estime

Figure 6.15 Date dduite du burndown

Tendance

Partie du backlog hors release Date actuelle Date de fin de release fixe lavance

Figure 6.16 Contenu dduit du burndown

1. Pour en savoir plus, voir les autres graphiques, chapitre 15.

86

Chapitre 6. La planification de la release

6.4 GUIDES POUR LA PLANIFICATION DE RELEASE

essayer Sadapter au calendrier Provisionner pour du feedback ultrieur

viter Confondre valeur et cot, vlocit et productivit Ne pas garder de mou pour les incertitudes

6.4.1 Sadapter au calendrier


La pertinence de la vlocit repose sur une dure xe des sprints associe une composition de lquipe qui ne change pas : des ressources identiques dun sprint lautre. Agile ou pas, la planication agile doit tenir compte des vnements connus lavance, comme les ponts en mai ou les vacances de membres de lquipe qui peuvent inuencer la quantit de ressources disponibles.
Exemple : une quipe de cinq personnes qui fait habituellement des sprints de trois semaines dispose de cinq fois cinq fois trois soit 75 jours de ressources. Elle commence un nouveau sprint le 28 avril et les membres de lquipe font les ponts de mai. Pour avoir peu prs les mmes ressources que pour les autres sprints, il est logique de passer la dure de ce sprint quatre semaines. Cela devrait tre anticip dans le planning de la release.

La dure peut exceptionnellement varier pour garder les ressources peu prs stables pour tous les sprints.

6 personnes

Sprint m

Sprint n

4 personnes

2 semaines

3 semaines

Figure 6.17 Ressources stables pendant les vacances de deux personnes au sprint n

Si la taille de lquipe volue pendant la release, la mesure de la vlocit est videmment moins able : une personne en plus ou en moins, cela a un impact sur sa capacit, en particulier pour les petites quipes. Un autre inconvnient est dordre collectif : un nouvel arrivant doit apprendre sintgrer dans lquipe, cela lui demande du temps et lquipe y consacre aussi du temps.

6.4 Guides pour la planification de release

87

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


Une story a deux attributs diffrents : un porte sur la valeur quelle apporte, un autre sur sa taille. Ce sont deux notions distinctes qui sont parfois confondues. Il ny a pas toujours une corrlation entre les deux : deux stories de mme taille peuvent avoir des valeurs ajoutes bien diffrentes. De la mme faon, la vlocit ne doit pas tre confondue avec la productivit. Ce sont deux mesures diffrentes, contrairement des ides rpandues, et il arrive mme quune augmentation de la vlocit aille de pair avec une diminution de la productivit. La dnition classique de la productivit, cest le quotient de rsultat/temps pass produire. La notion est surtout utilise en conomie pour montrer que lutilisation de machines permet de rduire le temps de production. Lestimation en points porte sur le cot de dveloppement, et donc la vlocit aussi. La dnition de la productivit parle de rsultat. mon avis, ce nest pas le cot quil faudrait utiliser mais la valeur ajoute. La mesure de la valeur apporte par chaque sprint, faite de cette faon, se rapprocherait plus de la productivit au sens utilis en conomie.

6.4.3 Garder du mou pour les incertitudes


Dans le plan de release, tout est bas sur lestimation des stories du backlog. Mme si lestimation est collective et faite par ceux qui ralisent, il y a une part dincertitude, en particulier au dbut dune release. Pour en tenir compte, il est indispensable de garder du mou (un buffer) dans les plans :
pour une release primtre x, le mou consiste en du temps ; pour une release date xe, le mou porte sur des stories.
Incertitude sur les estimations

Release R Timebox de 100

10

Figure 6.18 Garder du mou pour les incertitudes dans une release date fixe

Dans lexemple de la gure 6.18, la vlocit moyenne est de 20 et il reste cinq sprints avant la n de la release. Sans mou, le plan prvoit que 100 points du backlog seront inclus dans la release. Avec un mou de 10 %, la prvision de 90 points prend en compte le risque li aux estimations. Le pourcentage de mou se rduit lapproche de la n de release.

88

Chapitre 6. La planification de la release

6.4.4 Provisionner pour le feedback ultrieur


Une erreur classique lorsquon fait ses premires armes en planication de release est doublier le feedback. Le feedback est une pratique essentielle du dveloppement agile : il permet damliorer le produit en prenant en compte les retours des utilisateurs. Mais cela a un cot quil ne faut pas oublier dans le plan de release. La prise en compte concrte du feedback, ce sont de nouvelles stories ajoutes dans le backlog, quil convient destimer et de prioriser. Si le Product Owner considre que cela est prioritaire, et cest souvent le cas, limpact sera de repousser dautres stories plus loin dans le backlog.
Le feedback se dcline en des demandes dvolution sur des stories existantes et, ventuellement, en de nouvelles stories. Cela peut consister aussi en des dfauts sur des stories, ce quon appelle communment des bugs dans le dveloppement de logiciel.

Provision pour feedback

Release R 15 10 Timebox de 100

Figure 6.19 Garder du mou pour le feedback

Dans la gure 6.19, le mou cumule lincertitude sur les estimations et la provision pour le feedback. Avec un mou total de 25 %, la prvision devient 75 points de stories dici la n de la release.

En rsum
Une caractristique importante des mthodes agiles est leur capacit prendre en compte les changements. Cela implique que les plans sont remis jour rgulirement. Cest particulirement vrai pour le plan de release, qui est actualis chaque sprint. Cette adaptation au changement saccompagne danticipation : le plan de release permet de prendre des dcisions sur le produit.

7
La runion de planification de sprint

Dans le domaine de lestimation et de la planication, de nombreuses anecdotes illustrent les difcults rencontres, en voici deux :
Certains programmeurs, investis dans le travail sur leur code, naiment pas trop

quon leur demande quand ils auront ni. Parfois en insistant plusieurs jours, on peut obtenir, aprs un ronchonnement, je vais essayer de terminer demain et le lendemain on croise les doigts. Certains chefs de projet font la planication tout seuls, ils identient des grandes tches, les chiffrent et les affectent aux personnes de leur quipe. Si les tches navancent pas comme prvu, le chef de projet aura beau rler, les quipiers diront que les estimations ntaient pas ralistes. Cest pour prvenir ce genre de situations que la runion de planication de sprint existe. La planication de sprint est base sur lide quon ne peut pas prvoir de faon prcise au-del dun certain horizon. Lhorizon pour la planication dtaille correspond au sprint. Cette runion met en vidence, peut-tre encore plus que pour la planication de release, le rle essentiel de lquipe dans llaboration des plans. Le travail du sprint appartient lquipe : ce nest pas un chef qui dnit ce quil y a faire, cest lquipe qui sorganise elle-mme. Au-del de sa fonction premire de planication, la runion est un rituel qui prpare lquipe travailler de faon collective pendant le sprint, comme les prparatifs dans les vestiaires amnent une quipe de rugby rentrer dans son match.

90

Chapitre 7. La runion de planification de sprint

7.1 PLANIFIER LE SPRINT


Le dogme est de considrer quil y a deux parties distinctes dans la runion :
la premire pour avoir une bonne ide du primtre et dnir le but du sprint, la seconde consacre lidentication des tches ncessaires pour latteindre et

leur estimation. Cette distinction ne correspond pas toujours lusage sur le terrain et, mon avis, contribue la confondre avec la planication de la release. Le backlog de produit est indispensable pour faire la planication de sprint. Pour une runion efcace, il doit tre prt, cest--dire :
Les stories ranges par priorit. Les plus prioritaires estimes. Celles associes au sprint qui commence sufsamment dtailles et connues.

Si la planication de release1 a t pratique correctement, le backlog sera prt. La runion a lieu juste aprs la n du sprint prcdent et utilise aussi les rsultats de la revue : la vlocit du dernier sprint permet de calibrer celui qui commence. Le rsultat tangible de cette runion est un plan, contenant la liste des tches du sprint. Mais le plan nest pas lessentiel, ce qui compte cest la planication : les rexions collectives faites au cours de ce rituel soudent lquipe vers lobjectif du sprint.

7.1.1 Cest lquipe qui planifie


Lquipe complte, y compris le Product Owner, participe toute la runion.
La prsence du Product Owner est difficile conserver sur toute la dure : comme la runion est longue et comporte des discussions techniques, la tentation est forte, pour certains Product Owners, de nassister quau dbut de la runion et de sclipser quand commence lidentification des tches. Mme dans la seconde partie, il est indispensable quil soit prsent pour rpondre aux questions que lquipe va invitablement se poser. Il est obligatoire quil soit prsent la fin de la runion, lors de lengagement de lquipe sur un primtre.

Des experts peuvent tre invits intervenir, ponctuellement, pour apporter des claircissements sur des aspects fonctionnels ou techniques. Il ny a pas dautres personnes invites.

1. La planication de release fait lobjet du chapitre 6.

7.1 Planifier le sprint

91

7.1.2 Espace de travail ouvert


Lidal est que lquipe dispose dun espace de travail ouvert (on parle aussi de plateau projet). Du point de vue logistique, cela signie une salle, avec les postes de travail disposs de faon favoriser la communication, et une zone dafchage. Un tableau accroch au mur rpond ce besoin, condition quil soit sufsamment grand, visible de tous et dispose dun espace libre permettant dy accder facilement.
Tableau des tches mural Un tableau de tches sert montrer lavancement des travaux pendant le sprint, cest une reprsentation physique du plan de sprint. Il est labor lors de la runion de planification du sprint. Pour chaque story slectionne, lquipe identifie les tches correspondantes. Sur le tableau, les stories et les tches sont places avec des Post-it. Ltat des tches est reconnu selon la place de la tche dans des zones reprsentant chaque tat : faire, en cours et finie.

Les tches peuvent tre disposes de deux faons :


Tableau disposition verticale (gure 7.1) : les tableaux de tches sont

disposs sur un mur, avec en lignes les stories et leurs tches associes et en colonnes les tats des tches.
Sprint 3 : dbut le 13/9, fin le 27/9 But : blabla
faire
tche tche tche tche tche

En cours

Fini

story
tche tche

story
tche

Figure 7.1 Tableau des tches vertical

Tableau disposition horizontale (gure 7.2) : en haut, les stories slectionnes

pour le sprint, en dessous sont disposes les tches qui y correspondent. Elles sont ranges dans les grandes zones horizontales selon leur tat : les tches faire, puis les tches en cours et en bas les tches nies. Les tches qui gurent droite reprsentent les tches dites storyless, cest--dire qui ne sont pas en relation avec une user story.

92

Chapitre 7. La runion de planification de sprint

Sprint 3 : dbut le 13/9, fin le 27/9 But : blabla story


tche tche

story
tche tche tche tche

faire
tche tche

En cours

tche

tche

Fini

Figure 7.2 Tableau des tches horizontal

Lintrt de se tenir devant ce tableau est de le remplir avec les informations constituant le plan de sprint pendant la runion.
Et si toute lquipe nest pas dans le mme bureau ? Dans ce cas, on utilisera un outil informatique pour collecter les tches. Voir le chapitre 17 Scrum avec un outil.

7.1.3 Dure de la runion


La planication de sprint est une sance de travail collectif, limite dans le temps, comme toutes les runions du crmonial Scrum. Ken Schwaber donne une limite de huit heures pour cette runion, pour des sprints dun mois : quatre heures pour la premire partie et quatre heures pour la seconde. Ces chiffres sont ajuster en fonction de la dure du sprint : limiter 2*n heures, n tant le nombre de semaines dans le sprint. Pour un sprint de deux semaines, la runion a une limitation quatre heures. Ou dit autrement, la runion ne doit pas dpasser 5 % de la dure du sprint. Il sagit de dure maximum et la dure moyenne est infrieure si le backlog est bien prpar avant la runion. Daprs mon exprience, il vaut mieux viter de dpasser une demi-journe pour cette runion, sinon la motivation de quelques personnes risque de baisser. condition de faire une planication de release correcte, on y arrive, mme pour des sprints de trois semaines. La runion est la premire activit du sprint qui commence.

7.2 tapes

93

Runion de planification

Sprint

Figure 7.3 La place de la runion dans le sprint

7.2 TAPES
La premire partie est consacre au quoi : le primtre et le but, la seconde au comment, avec notamment lidentication des tches.
Rappeler le contexte du sprint valuer le primtre potentiel

Dfinir le but du sprint

Identifier les tches

Estimer les tches

Prendre des tches

S'engager collectivement

Figure 7.4 Les tapes de la planification de sprint

7.2.1 Rappeler le contexte du sprint


Le Product Owner rappelle la place de ce sprint dans la release en cours (chaque sprint a un numro squentiel qui lui est affect) ; il annonce la date de n, en fonction de la dure usuelle.
Si la dure nest pas exactement celle dfinie pour les sprints, toute lquipe doit en connatre les raisons et y adhrer. Cela peut tre d des vacances, des absences ponctuelles, des jours fris...

94

Chapitre 7. La runion de planification de sprint

Sprint 3 Dbut 2 septembre - Fin le 15 septembre Disponibilit de lquipe : CJ : 10 j DB : 9j HG : 10j AS : 10j TF : 5j CB :10j
Figure 7.5 Contexte dun sprint

7.2.2 valuer le primtre potentiel


Il sagit de prciser le primtre envisag pour ce sprint, cest--dire les lments du backlog de produit qui vont tre raliss.
Dans le cas o les membres de lquipe ne sont pas plein temps sur le projet, il est utile de noter leur disponibilit prvue pour ce sprint. Cela permet de mettre en vidence les ressources dont dispose lquipe.

Le primtre est dni en slectionnant la premire story en haut de la liste ordonne constituant le backlog de produit, puis la suivante, ainsi de suite jusqu ce que le total corresponde la capacit de lquipe. Les stories en question sont prsentes par le Product Owner lquipe et le dialogue qui sinstalle permet toute lquipe den acqurir une bonne connaissance.
Si la planification de release a t bien effectue, cette tape consiste essentiellement valider collectivement le sous-ensemble du backlog prvu pour ce sprint. Dans ce cas, la premire partie de la runion sera rapide et nous serons bien en de de la limite des quatre heures.

Il sagit dune premire valuation de la capacit, permettant de poursuivre la runion. Le primtre pourra encore tre ajust avant la n de la runion.
Rgle Cest le Product Owner qui dfinit les priorits et donc lordre des stories candidates tre dans le sprint. Cest lquipe qui est la seule dcider du primtre, cest--dire arrter la liste des stories candidates.

Le primtre consiste en une liste de stories extraites du backlog de produit (en gnral, cinq dix stories). La mesure du primtre, obtenue en faisant la somme de la taille des stories, correspond la capacit pour ce sprint. Bien entendu, la dnition du primtre tient compte de la vlocit des sprints prcdents, mais plutt pour avoir un ordre de grandeur que de faon prcise.

7.2 tapes

95

7.2.3 Dfinir le but du sprint


Le but est nonc en une phrase qui montre lobjectif principal du sprint. Le but dun sprint est labor par lquipe, partir dune proposition du Product Owner. Il porte le plus souvent sur un domaine fonctionnel (au dbut du projet, lors des premiers sprints de la premire release dun nouveau produit, le but peut tre orient sur des considrations techniques).
Exemples : but du sprint 2 authentification des utilisateurs, but du sprint 5 mettre en place le connecteur Mylyn, but du sprint 93 raliser la sortie PDF des informations du projet...

7.2.4 Identifier les tches


La suite de la runion a pour objectif de dnir comment lquipe sorganise pour raliser les stories slectionnes. Pour cela, on part de la liste labore lors de ltape prcdente ; chaque story est prsente par le Product Owner et tudie par lquipe qui identie les tches ncessaires pour sa ralisation. Cela force toute lquipe discuter pour claircir des points de solution par rapport cette story, en demandant si ncessaire au Product Owner des prcisions sur le comportement attendu. La liste des tches se construit progressivement avec lexamen des stories slectionnes, puis en compltant avec des tches indpendantes des stories. Dans les deux cas, lidentication des tches sappuie sur la signication de ni1 pour lquipe.

Tches dduites des stories


Lensemble des activits de dveloppement seront droules lors dun sprint ce qui conduit identier les tches pour les raliser. Toutes les activits lies au dveloppement dune story doivent tre prises en compte, y compris les lectures de documents ou de code si cela fait partie de la dnition de ni de lquipe. Ce travail fait en commun pour identier les tches permet toute lquipe dtre implique. Elle acquiert ainsi une bonne connaissance des stories tudies et surtout de la faon de les raliser dans le produit : pendant cette runion, lquipe fait de la conception.

Tches indpendantes des stories


En plus de celles qui dcoulent des stories, il convient galement didentier les tches transverses qui ne sont pas associes une story spcique (on parle aussi de tches storyless).

1. La signication de ni fait lobjet du chapitre 11.

96

Chapitre 7. La runion de planification de sprint

On peut identier plusieurs types pour ces tches :


Pour un vnement ponctuel et exceptionnel survenant durant le sprint.

Exemple : une confrence pour laquelle il faut prparer une dmo spcique. Rcurrentes, qui proviennent gnralement de la signication de ni. Exemple : le travail faire pour dployer le logiciel, chaque n de sprint, sur un serveur de test. Pour liminer des obstacles identis dans le sprint prcdent et pas encore limins. Pour une action dcide lors de la rtrospective. Pour amliorer la qualit du produit.

Les tches indpendantes des stories peuvent varier chaque sprint, mais il est prfrable que la quantit de travail pour les raliser reste peu prs stable : elle a un impact indirect sur la vlocit.
Doit-on mettre les runions dans la liste des tches ? Les runions Scrum ne sont pas incluses dans la liste des tches, mais les autres ventuelles runions de travail sur un sujet technique ou fonctionnel le sont.

Pour une quipe de cinq personnes et des sprints de deux semaines, on peut sattendre identier une quarantaine de tches pour un sprint.

7.2.5 Estimer les tches


Lestimation du temps passer sur une tche est faite collectivement, par lquipe. Il nest pas ncessaire de passer beaucoup de temps discuter dune estimation : lobjectif principal est de nir une tche (et nalement une story) pas de lestimer. Les tches sont estimes en heures. Il est conseill davoir des tches sufsamment petites pour quelles soient nies en une journe de travail (si une tche obtient une estimation suprieure deux jours de travail, il convient de la dcomposer en tches plus petites). La liste des tches constitue lors de la runion de planication nest pas ge : des tches peuvent tre ajoutes, dautres supprimes et dautres dcomposes pendant le sprint.
Variante Les quipes exprimentes peuvent se passer de lestimation en heures des tches : elles grent les tches de faon binaire : pas finie ou finie, ou avec trois tats ( faire, en cours et finie).

7.2 tapes

97

7.2.6 Prendre des tches


Ce sont les membres de lquipe qui prennent eux-mmes les tches. Il nest pas utile daboutir lattribution de toutes les tches : il suft que chacun ait du travail pour les premiers jours du sprint ; laffectation des autres tches est diffre, elles seront prises pendant le sprint en fonction des disponibilits des membres de lquipe.
Et si une tche pnible mais importante nest prise par personne ? Dans les dveloppements traditionnels, il y a des tches considres comme ingrates (par exemple faire des tests unitaires, du reporting et autres documentations) pour lesquelles il semble difficile de trouver un volontaire. Cest en gnral le chef de projet qui les affecte de faon autoritaire. En fait, jai ctoy de nombreuses quipes qui passaient Scrum et je nai jamais constat le phnomne des tches pnibles que personne ne voudrait prendre. Il y a plusieurs raisons pour que a ne se produise pas lors de lapplication de Scrum : Il ny a pas de tches pnibles. En effet, le dcoupage en tches est fait de faon radicalement diffrente. Lors de la runion de planification, les tches sont identifies partir des stories slectionnes et servent clairement finir quelque chose. Il ny a pas de tches non corrles aux rsultats concrets, comme par exemple lorsquon demande quelquun dcrire la fin du projet des jeux de tests unitaires simplement parce que cest demand dans le processus. Si une tche est malgr tout considre comme pnible, elle sera courte. En effet, une tche dans un sprint reprsente une journe de travail pour une personne. Cela sera peru comme beaucoup moins pnible que, par exemple, la tche dcriture dune documentation de conception pendant dix jours dans une approche traditionnelle. Le passage dun mode directif un mode autonome responsabilise chacun. Le fait que les tches soient identifies en commun pousse les trouver moins ingrates que si elles sont imposes. Lintrt dune tche pour lavancement du projet est plus explicite. Cela vite les tches considres comme embtantes et qui, en plus, ne semblent pas utiles du point de vue de celui qui la fait. Lestimation de leffort est faite en commun et, de plus, il ny a pas de relev du temps pass sur une tche : Scrum ne se proccupe que du reste faire pour finir la tche, qui peut tre actualis. Cela met moins de pression au ralisateur de la tche que si le dlai lui est impos. Laffectation des tches aux membres de lquipe nest pas faite lavance. Les tches sont prises de faon opportuniste en fonction de lavancement des travaux. La question de qui va prendre une tche a une rponse quasi naturelle en fonction de la disponibilit et de la comptence, ce qui vite les tergiversations.

Il est frquent quil faille revoir le primtre aprs la dcomposition en tches. Avec une ide plus prcise du travail faire, lquipe peut dcider den faire plus ou moins que le primtre valu en dbut de runion. Cest une des raisons pour laquelle le Product Owner doit rester dans la deuxime partie de la runion.

98

Chapitre 7. La runion de planification de sprint

7.2.7 Sengager collectivement


Pour nir la runion, lquipe sengage raliser les stories slectionnes. Lengagement collectif est important pour motiver lquipe. Il peut permettre de dceler des rticences de certains, quil est prfrable de prendre en compte avant de nir la runion. Avant de demander lengagement, le ScrumMaster annonce la capacit prvue pour ce sprint en la calculant partir des stories dans le primtre. Mme sil peut y avoir de lgres variations, il est important que cette capacit reste dans une fourchette raisonnable par rapport la vlocit moyenne des derniers sprints.

7.3 RSULTATS
Le rsultat principal est le plan de sprint, qui contient la liste des tches avec leurs attributs, sous une forme facilement visible ou accessible.

7.3.1 Plan de sprint initial


Le plan sappuie sur la liste des tches. Une tche est du travail faire pendant le sprint. Pendant la runion, cette liste est produite et chaque tche peut avoir les attributs suivants :
Un nom et la description du travail faire Il suft gnralement davoir un

nom permettant didentier la tche et, ventuellement, du texte collect lors de la runion permettant de comprendre le travail faire. La story associe une story sont en gnral associes plusieurs tches. part les tches dites storyless, toutes les tches sont associes une story. Le reste faire estim pour la tche, en heures Lestimation de leffort ncessaire pour raliser la tche est faite pendant la runion. Cela donne une premire valeur, sachant que le reste faire peut tre actualis pendant le sprint. La personne qui prend la tche pour la raliser Une tche peut tre ralise par une ou plusieurs personnes. Toutes les tches ne sont pas prises la n de la runion, seules le sont un petit sous-ensemble permettant chacun davoir du travail pour le jour qui vient.
Pour chaque story, on retrouve des tches similaires : concevoir, coder lIHM, coder la couche mtier, faire les tests unitaires...

Pour les quipes qui sont regroupes dans le mme espace, le plan est afch sur un tableau mural. Sur ce tableau seront galement nots le but du sprint et les dates de dbut et de n. Selon la taille de lquipe, une ou plusieurs stories peuvent tre commences ds le dbut du sprint, en sortant de la runion. Ce sont les tches associes ces stories qui sont commences en premier.

7.3 Rsultats

99

En tout cas, il ne faut pas commencer toutes les tches ds le dbut du sprint. Pendant le sprint, les tches seront prises de faon opportuniste : quand une personne nit une tche, elle consulte la liste des tches qui restent libres et en prend une, en tenant compte des priorits du sprint.

7.3.2 Backlog et burndown charts actualiss


lissue de la runion, le backlog de produit est actualis, toutes les stories associes au sprint qui dmarre changent dtat : elles passent en cours. La mise jour du backlog est loccasion de prendre un clich de ltat du dveloppement. Dans ce clich de mesures gure en premire place la capacit que lquipe pense assurer pendant le sprint qui commence. Dautres mesures permettent de collecter des informations sur le backlog, permettant dajuster le plan de release, et sur le sprint :
le reste faire dans le backlog de produit pour la n de la release, le nombre dheures de travail faire, en faisant le total des estimations de

chaque tche. partir de ces mesures, des rapports graphiques peuvent tre commencs ou mis jour :
On ajoute un nouveau point dans le burndown chart de release, avec le reste

faire dans le backlog de produit. On met le premier point du burndown chart de sprint avec le reste faire (en heures) dans la liste des tches.

Sprints Burndown de release Burndown de sprint

Jours

Figure 7.6 Mise jour des burndowns

100

Chapitre 7. La runion de planification de sprint

7.4 GUIDES POUR LA PLANIFICATION DE SPRINT


essayer Prparer le backlog en anticipation Dcomposer en tches courtes Garder du mou Faire de la conception viter Dcider du primtre la place de lquipe Ne pas laisser lquipe identifier les tches Prendre un engagement draisonnable

7.4.1 Prparer le backlog de produit en anticipation


Une runion de planication de sprint ne peut se drouler dans de bonnes conditions et aboutir au rsultat souhait dans la bote de temps (timebox) alloue que si le backlog de produit est dans un tat le permettant. La prparation du backlog, cest du travail qui est fait pendant le sprint prcdent, pour arriver la runion avec une liste dans laquelle les stories sont priorises et estimes. Ce travail, linitiative du Product Owner, implique aussi toute lquipe ; on considre raisonnable quelle passe 10 % de son temps en anticipation sur le sprint suivant. Si lquipe considre quune story du backlog nest pas comprhensible et quelle nest pas en mesure didentier les tches, le Product Owner est invit revoir sa copie pour le prochain sprint, cest mieux que de passer la moiti de la runion dessus. Une bonne pratique de la planication de release permet de ne pas en arriver cette extrmit.

Dcomposer en histoires courtes


La mcanique de Scrum repose sur la ralisation de stories pendant un sprint : la n du sprint, les stories doivent tre nies. Il convient donc que les stories soient sufsamment petites pour tre nies pendant la dure du sprint choisie.
Quelques chiffres pour donner une ide de ce que signifie petit, avec lhypothse quune quipe de cinq personnes qui droule des sprints de deux semaines ralise dix stories dans un sprint. Une story moyenne demande environ quatre jours deffort pour son dveloppement, dans le cas o lquipe travaille 80 % sur leur dveloppement.

Penser aux stories techniques et aux dfauts


Le travail didentication des tches se fait partir de stories slectionnes pour ce sprint. La liste comporte une majorit de tches associes une et une seule story, qui sont le reet du travail faire pour raliser cette story. Si le backlog est fait correctement, il contiendra, en plus des user stories, des stories techniques et des dfauts. Il y a, bien sr, des tches identier pour tous les types de stories. En gnral, selon la dnition de ni, une quipe trouve entre quatre et dix

7.4 Guides pour la planification de sprint

101

tches par user story. Pour les stories techniques et les dfauts, le nombre de tches associes est plus faible. Parfois il ny aura quune seule tche par story.

7.4.2 Laisser lquipe dcider du primtre


Ce nest pas le ScrumMaster qui dcide de ce qui doit tre fait. Ce nest pas non plus le Product Owner qui impose lquipe le primtre du sprint en lui donnant la liste des stories raliser. Lors de la runion, le Product Owner prsente les stories par priorit dcroissante et lquipe dit stop ! quand elle pense que sa besace est assez charge pour le sprint. Un Product Owner peut avoir tendance demander un primtre plus large, en insistant pour ajouter une story ou deux. Ce nest pas une bonne pratique car cela risque davoir un effet ngatif sur la motivation de lquipe moyen terme, si elle ne tient pas ses objectifs. En revanche, les discussions peuvent amener lquipe proposer des changements dans les priorits pour faire passer une story non prvue la place dune autre dans le sprint. Cest au Product Owner daccepter ou pas.

7.4.3 Laisser lquipe identifier les tches


Des ScrumMasters soucieux defcacit aprs une runion de planication de sprint trop longue peuvent dcider, la prochaine fois, darriver avec une liste des tches dj prte. Il est possible que la runion soit effectivement raccourcie, mais cela a linconvnient norme de moins impliquer lquipe. En effet, si les tches sont dj identies, voire affectes, lquipe va se sentir moins responsabilise. Ce serait un retour un schma de gestion de projet avec un chef. Cela se passait peu prs comme a dans un projet itratif, avant Scrum : quelques jours avant la n de litration n, le chef de projet prpare le plan de litration n + 1, tout seul (au mieux il le montre aux membres de lquipe) ; lors de la revue de litration n, le plan de litration n + 1 fait partie des livrables prsents au management et compte tenu des retours faits lors de la revue, le chef de projet ajuste le plan qui sapplique pour litration. La pratique Scrum dune quipe autonome et responsabilise rend caducs ces allers-retours entre le chef de projet, les membres de lquipe et le management.

7.4.4 Dcomposer en tches courtes


Dans la plupart des organisations, avant de passer Scrum, la gestion des projets est base sur une dcomposition en tches plus longues que celle conseille dans les sprints : lhabitude est de dnir des tches de plusieurs jours voire plusieurs semaines. Avec Scrum, une tche prend en moyenne un jour. Un bon principe est davoir une tche nie le lendemain du jour o a elle a t commence. Cest un constat qui peut tre fait lors du scrum quotidien.

102

Chapitre 7. La runion de planification de sprint

Cela veut dire que non seulement leffort pour raliser la tche est limit, mais que cet effort est condens sur un jour au lieu dtre morcel en petites priodes sur plusieurs jours.

7.4.5 Prendre un engagement raisonnable


Mme sans la pression du Product Owner, une quipe qui dbute avec Scrum a tendance, par excs doptimisme, sengager sur plus de stories que ce quelle peut raisonnablement raliser en un sprint.
Le primtre sur lequel sengage lquipe est la capacit prvue. Cest la fin du sprint, lors de la revue, quest mesure la vlocit relle de lquipe.

Sil peut arriver que la vlocit mesure soit infrieure la capacit estime, cela ne doit pas tre systmatiquement le cas, surtout aprs plusieurs sprints. Une quipe doit apprendre tenir ses engagements. Cet apprentissage passe par la mise en place de pratiques correctives lors de la rtrospective et par un engagement raisonnable.

7.4.6 Garder du mou dans le plan de sprint


Mme si on a mis en place une stratgie de rduction des risques, des vnements inattendus viennent toujours freiner lavancement du sprint, en bloquant ou ralentissant une ou plusieurs tches en cours. Pour empcher ces vnements de remettre en cause les engagements, il faut garder du mou lorsquon planie le sprint. Dans la planication dun sprint, le mou, cest du temps non affect, qui reste disponible pour pallier les impondrables. Concrtement le mou est la diffrence entre les ressources de lquipe et le total des heures associes aux tches du sprint lors de la runion de planication.
Mou

Sprint 3 Timebox de 432h

Figure 7.7 Garder du mou dans le plan de sprint

Exemple : si lquipe a 432 heures disponibles pour le sprint et que le total des estimations sur les tches atteint 400, il ny a pas assez de mou et les objectifs du sprint ne pourront pas srement tre tenus.

7.4 Guides pour la planification de sprint

103

On peut diffrencier plusieurs types de mou dans le plan de sprint :


Pour les incertitudes dans les estimations sur les tches. Pour le travail en anticipation sur le sprint suivant. Pour les impondrables susceptibles de se produire.

Le pourcentage de mou varie selon le contexte, la moyenne que jai constate stablit environ 30 %. Dans le cas o lquipe assure, en plus du dveloppement, le support dune version en production, incluant la gestion des incidents, le pourcentage est plus lev. Une quipe exprimente prend du mou mais na pas besoin de connatre sa taille ni de suivre son volution pendant le sprint.

Figure 7.8 Trop de mou dans le plan !

7.4.7 Faire de la conception


Une erreur classique des quipes novices en Scrum est de se lancer corps perdu dans la ralisation des stories. Le dveloppement de logiciel ncessite de la rexion. Mme si Scrum nvoque pas explicitement de pratiques dingnierie, il est ncessaire de faire de la conception. Avec les mthodes agiles, la conception nest pas faite une fois pour toutes au dbut du projet, elle est faite tout le temps. Chaque sprint comporte des activits de conception.

104

Chapitre 7. La runion de planification de sprint

La runion de planication de sprint est le moment idal pour faire de la conception collective. En effet, lidentication des tches ncessite de rchir la faon dont une story va tre conue. Les discussions qui sengagent permettent de partager la connaissance de cette conception entre tous les membres de lquipe. Llaboration dun modle graphique, comme un diagramme de squence UML, permet de mieux partager cette connaissance. La modlisation agile se fait avec un outillage lger : par exemple, un diagramme dessin la main, labor en groupe et qui restera coll au mur pendant le sprint pour rester visible de tous.

En rsum
La planication du sprint est la premire runion du sprint et cest aussi la plus dlicate : son bon droulement conditionne le succs du sprint. Pour la russir, il convient de ne pas la voir uniquement comme une sance de planication, mais aussi comme un exercice collectif pendant lequel lquipe apprend sauto-organiser et partager la connaissance sur le produit.

8
Le scrum quotidien

Il y a des grands projets pour lesquels tout allait bien et on apprend un jour, en coutant la radio le matin, quils ont subitement des mois de retard. Toutes les personnes ayant suivi des projets ont vcu ce genre de choses, mme sur des projets plus petits : tout se passe bien, pas de problme, les indicateurs sont au vert et puis tout dun coup, on apprend quil va y avoir un gros retard. Ce nest pas le retard en soi qui est gnant, cest de ne le savoir quau moment o on ne peut plus le cacher et quil est trop tard pour ragir. Frederic Brooks, lauteur de Mythical Man Month, qui on demandait comment fait un projet pour avoir un an de retard, rpondait il y a plus de 20 ans En prenant un jour de retard, puis un autre... 1 . Cest pour viter ce genre de surprise que le scrum quotidien a lieu tous les jours. Ce nest pas lunique raison dtre du scrum quotidien : cest aussi pour dvelopper lesprit collectif et garder lquipe concentre sur lobjectif du sprint. Scrum, cest la mle au rugby, symbole de la pousse collective. Cest lobjectif de ce chapitre de prsenter cette pratique trs reprsentative de Scrum. Dans son sillage nous aborderons galement plusieurs pratiques connexes comme lespace de travail collaboratif, llimination des obstacles et le burndown chart de sprint.

1. http://courses.cs.vt.edu/cs1104/HLL/Brooks.html, voir [page 153].

106

Chapitre 8. Le scrum quotidien

Dfinitions La runion quotidienne se nomme officiellement le Daily Scrum meeting en anglais. La Scrum Alliance utilise simplement daily scrum et je vais reprendre cette appellation en parlant de scrum quotidien en franais. Le terme scrum est utilis au Qubec par les journalistes. Un exemple trouv par Google : Je viens dassister mon premier scrum. Une quinzaine de journalistes entourent Franois Legault... . Toujours au Qubec, certains ragissent contre ce nologisme. Dans un article pourquoi pas en franais ? , on suggre de sen passer et dutiliser mle de presse. Car la traduction de scrum en franais, cest mle. Jai essay un temps dutiliser la mle quotidienne comme traduction de daily scrum, mais a na pas march : au nord de Montauban, appeler une runion mle a un ct peu rassurant pour les participants. Dit-on un scrum ou une scrum ? Dans une quipe, on me demande quelle heure est la scrum aujourdhui. Dans une autre quipe, on dit le scrum est 10 heures. Mon choix est pour le scrum. En revanche, la mthode ponyme scrit Scrum avec une majuscule et na pas de genre. Cette runion sappelle standup meeting dans Extreme Programming, ce qui fait bien faire comprendre quon reste debout. Un obstacle est une situation ou un vnement qui peut empcher ou retarder la progression du travail prvu au cours du sprint. Dans la littrature Scrum en anglais, le mot pour obstacle est impediment . Exemples dobstacle : un dveloppeur narrive pas commiter ses modifications sur le serveur SVN, la licence de loutil de test xyz a expir, un membre de lquipe sest cass le bras au ski pendant le week-end.

8.1 UNE RUNION QUOTIDIENNE


Le scrum est plutt facile dcrire : un point de rencontre o tous les membres de lquipe rpondent trois questions simples et actualisent le plan de sprint. Son but principal est doptimiser la probabilit que lquipe atteigne les objectifs du sprint. Les moyens pour atteindre ce but consistent en :
liminer les obstacles nuisant la progression de lquipe. Garder lquipe concentre sur lobjectif du sprint. valuer lavancement du travail pour le sprint en cours. Communiquer objectivement sur lavancement.

8.1.1 Le sprint appartient lquipe


Toute lquipe participe la runion. Le ScrumMaster sassure que la runion a lieu et que les rgles sont respectes. Pendant la runion, il na pas dautre responsabilit particulire : le scrum est un des moyens permettant daller vers plus dauto-organisation,

8.1 Une runion quotidienne

107

ce nest pas une runion pour faire un compte-rendu au ScrumMaster. La prsence du Product Owner est fortement souhaite. Les personnes extrieures lquipe peuvent assister, mais nont pas le droit de parler.
La distinction entre lquipe et les autres personnes a pour objectif de montrer que seuls les membres de lquipe rellement engags dans les travaux du sprint sont mme de savoir quelle attitude avoir devant une situation donne. Cela est illustr dans lhistoire Pigs and chickens , le genre de fable dont raffolent les Amricains, tel point quon la retrouve dans un cartoon1 . Les Franais amateurs de rugby pourront prfrer cette vrit pour illustrer la distinction : pendant le match, le jeu appartient aux joueurs .

8.1.2 Un crmonial balis


Lieu : si lquipe dispose dun espace de travail ouvert avec un tableau mural o est afche la liste des tches, cest lendroit idal pour y tenir le scrum quotidien.
Le plan de sprint avec sa liste des tches est actualis pendant le sprint : quand un membre de lquipe finit une tche, il met jour la liste (sans forcment attendre le prochain scrum), quand il commence une nouvelle tche aussi. Ceux qui ont des tches en cours au moment du scrum doivent mettre jour le reste faire sur ces tches ou au moins y avoir rflchi pour la runion.

Si toutes les personnes de lquipe ne sont pas dans le mme espace physique, le scrum se fait avec des outils de vidoconfrence ou audioconfrence. Dure : le scrum dure moins dun quart dheure. Frquence : le scrum est quotidien.
Scrum

Sprint

Figure 8.1 Le scrum a lieu tous les jours du sprint

1. On trouve mme une traduction http://www.implementingscrum.com/translations/

en

franais

de

ce

cartoon :

108

Chapitre 8. Le scrum quotidien

Est-il obligatoire de faire le scrum tous les jours ? Il est prfrable de faire la runion tous les jours. Le succs de lapplication de Scrum sur un projet passe par le respect des principes de base. Un de ceux-ci peut se rsumer en no scrum no win, comme pour le rugby : une quipe qui ne fait pas tous les jours le scrum aura bien des difficults russir son projet. Lorsquune quipe ne pratique pas les runions quotidiennes, cest souvent le signe quelle nest pas vraiment constitue comme devrait ltre une quipe Scrum. La runion quotidienne permet de rappeler lengagement pour le sprint, dvaluer lavancement, de dfinir ce qui devrait tre fait pour optimiser les chances de succs. Et surtout, sans le scrum quotidien et notamment sa troisime question, lquipe ne gre pas les risques et les obstacles, qui arrivent forcment, jour aprs jour.

Le premier et le dernier jour du sprint sont particuliers : il y a dautres runions du crmonial et le scrum nest pas fait ces jours-l. Dans le cas de projet plusieurs quipes, chaque quipe organise son scrum qui sera suivi du scrum de scrums1 avec le ScrumMaster de chaque quipe.

8.2 TAPES
8.2.1 Se runir
La runion seffectue avec toutes les personnes de lquipe, debout et en cercle, de prfrence un endroit o les tches sont visibles de tout le monde. Il est prfrable que le scrum ait lieu le matin en arrivant, tous les jours au mme endroit et la mme heure. La runion commence lheure prvue, mme si des personnes sont en retard.
Si la runion a lieu dans un endroit o les postes de travail sont accessibles, le ScrumMaster doit veiller ce que les occupants du bureau enlvent les mains de leur clavier et ne gardent pas un il sur lcran pendant la runion. De mme lusage des messageries instantanes, de Facebook ou Twitter est suspendue pendant un quart dheure...

Pour tenir les objectifs du scrum dans un dlai aussi court, il est souhaitable de disposer dune aide visuelle. Un tableau des tches fournit cette assistance (gure 8.2). Si on utilise un outil, on peut souhaiter sen servir lors de ces runions pour mettre jour ltat des tches. Avec un vido-projecteur, on projette la liste des tches sur un cran et il est possible, ventuellement, de mettre jour le reste faire en direct. Cependant, il vaut mieux rserver loutil aux quipes disperses : cette pratique complique la logistique et linconvnient principal est quune seule personne a les

1. Pour en savoir plus sur les scrums de scrums, voir le chapitre 18, La transition Scrum.

8.2 tapes

109

mains sur le clavier. Cela ne contribue pas renforcer lautonomie et la responsabilit de lquipe.

Figure 8.2 Un tableau des tches simple avec des Post-it

8.2.2 Rpondre aux trois questions


Prsenter ce qui a t fait
Chaque participant rpond la premire question : Quas-tu1 fait depuis le dernier scrum ? Il sagit, pour chaque membre de lquipe, de parler des tches sur lesquelles il a travaill. Pour chacune dentre elles, il indique si la tche est en cours ou si elle est nie. Pour les quipes qui utilisent un tableau des tches mural, ralis avec des cartes (ou des Post-it), lorsque cest le tour dune personne de rpondre cette question, elle dplace physiquement la carte correspondant la tche dans la colonne en cours ou ni .

Prvoir ce qui va tre fait


Chaque participant rpond la deuxime question : Que prvois-tu de faire jusquau prochain scrum ? Il sagit de parler des tches sur lesquelles il prvoit de travailler. Pour chacune dentre elles, il indique en quoi elle consiste et sil pense la nir dans la journe.

1. On se tutoie quand on fait partie de la mme quipe.

110

Chapitre 8. Le scrum quotidien

Identifier les obstacles


Chaque participant rpond la troisime question : Quels sont les obstacles qui te freinent dans ton travail ? Un obstacle empche une tche (ou plusieurs) de se drouler normalement.
La troisime question est un peu plus dlicate que les deux autres : dans la pratique, les rponses ne viennent pas aussi facilement quavec les deux premires questions. Le plus souvent les obstacles mentionns ont dj t rencontrs : la personne pense ce qui la gn dans les tches quelle a faites. Cest au ScrumMaster de rechercher les vrais obstacles derrire les formulations vagues comme difficult communiquer avec le Product Owner . Un problme identifi avec cette troisime question sera formul plus prcisment comme jai propos deux faons de procder pour larrangement des boutons sur la fentre de validation de la story 22 et jattends toujours la rponse du Product Owner . Ce qui rend lidentification des obstacles et leur limination plus faciles...

Quand un obstacle est identi en sance, il est possible quun des membres de lquipe connaisse dj la solution pour lliminer. Il est bien vident quil la donne immdiatement. En revanche, si des personnes ont seulement des pistes de solution, une discussion peut sengager, mais ce nest pas le lieu adquat pour la prolonger. Le ScrumMaster arrte la discussion et propose aux personnes intresses de la repousser plus tard, en dehors du scrum.

8.2.3 Statuer sur latteinte des objectifs


Comme la mle au rugby vient aprs une phase de dsordre et permet au jeu de repartir sur de nouvelles bases, le scrum quotidien permet lquipe de se synchroniser par rapport aux objectifs du sprint. Avec les informations collectes sur les tches et les obstacles, lquipe acquiert une connaissance objective de ce quil lui reste faire jusqu la n du sprint. Elle peut prendre une dcision sur lajustement du but du sprint. Lors du scrum, chacun sengage devant ses pairs. Lorsquune personne de lquipe dit ce quelle va faire dici le prochain scrum, elle lannonce devant toute lquipe et cela constitue un engagement fort. Comme tout le monde connat la situation et les obstacles rencontrs, cest plus facile de sengager. Quant lengagement de lquipe fait au dbut du sprint, il doit rester lobjectif de tous. Certains proposent dailleurs une quatrime question dans le scrum : est-ce que, ton avis, compte tenu de lavancement actuel, le but du sprint sera atteint ? Un processus empirique comme Scrum demande de sappuyer sur lexprience du jour pass pour adapter le planning des jours restant dans le sprint. Il faut garder lesprit quun sprint est limit dans le temps (le principe Scrum du timebox) et quil est toujours possible de supprimer du contenu prvu initialement (mais pas de reculer la date de n).

8.3 Rsultats

111

Ladaptation, si elle est juge ncessaire, peut se manifester de plusieurs faons :


si lquipe considre quelle nest pas en mesure de montrer quoi que ce soit la

revue de sprint, le sprint est arrt, de faon exceptionnelle ;


si lquipe est dans une situation o toutes les stories prvues au dbut ne

pourront pas tre ralises, elle ngocie avec le Product Owner pour savoir quelle story peut tre enleve du sprint ; si lquipe estime pouvoir nir toutes les stories avant la n du sprint, elle demande au Product Owner une nouvelle story qui pourrait tre ajoute au sprint.
Dans le cas o lquipe a un peu de temps, mais pas suffisamment pour prendre une nouvelle story, elle se consacre lamlioration de la qualit ; il y a toujours faire, par exemple du remaniement de code.

Cette inspection facilite par la transparence, suivie dadaptation, fait du scrum un maillon de lapproche empirique de Scrum.

8.3 RSULTATS
8.3.1 Le plan de sprint actualis
Le plan volue jour aprs jour : la liste des tches peut changer et surtout ltat de quelques tches est modi. Il arrive que des tches soient dcouvertes pendant le sprint : en travaillant sur une story, on saperoit quun travail important a t oubli lors de la planication du sprint. Il est aussi possible de supprimer des tches devenues inutiles. Les attributs qui retent le changement dune tche sont :
La quantit de travail restant faire pour la nir. Son tat, qui peut prendre trois valeurs : faire (quand la tche nest pas

commence), en cours, nie. Les deux attributs sont corrls : une tche nie a un reste faire de 0 et une tche en cours a un reste faire actualis.

8.3.2 Le burndown chart de sprint actualis


Le burndown chart de sprint est un graphe, actualis tous les jours, montrant la tendance de lavancement dans la ralisation des tches du backlog de sprint. Le burndown chart de sprint a souvent lallure de la gure 8.3 : une descente dabord modre, voire pas de descente du tout ( cause de dcouverte de nouvelles tches ou de travaux commencs et plus compliqus que prvus), suivie dune dcroissance plus rapide. Sil est un bon indicateur de la quantit de travail qui reste faire, il ne

112

Chapitre 8. Le scrum quotidien

montre pas lavancement par rapport aux objectifs : on ne voit pas si les tches sont nies (et encore moins si les stories sont nies).

Figure 8.3 Un burndown chart de sprint lissue du scrum, un nouveau point, calcul en faisant la somme du reste faire des tches, est ajout dans le graphe. Dans ce schma, on vient dajouter le point du lundi de la dernire semaine du sprint : il reste 34 heures.

Le burndown chart de sprint a trois variantes considrer :


Le burndown en tches, bas sur le nombre de tches restant faire. Le burndown en stories, bas sur le nombre de stories restant faire pour ce sprint. Le burndown en points, bas sur le total des points de stories restant faire.

Ceux qui prfrent les courbes qui montent celles qui descendent choisiront la reprsentation avec un burnup chart. Celui qui a ma prdilection est le burnup en points deux courbes : une pour ce qui est ni, lautre pour le total des stories associes au sprint (gure 8.4).

8.3.3 La liste des obstacles


La liste des obstacles ne fait pas partie des artefacts premiers de Scrum, cest chaque quipe de se dnir quant son utilisation. Jeff Sutherland1 voque la liste des obstacles (impediment backlog ) dans un billet sur les trois questions du Scrum meeting. Il dit, propos de la troisime question : Leffet le plus important de cette question est de crer une liste des obstacles dont le travail dlimination est assign lquipe ou aux managers. Une responsabilit majeure du ScrumMaster est de grer cette liste, de la prioriser et de sassurer que sa taille diminue.

1. Un des fondateurs de Scrum : http://www.jeffsutherland.com/

8.3 Rsultats

113

Figure 8.4 Un burnup de sprint en points la fin dun sprint de deux semaines. Dans cet exemple, on voit que le primtre du sprint dabord 26 points a t ramen 22 points.

Comment grer cette liste des obstacles ? Elle peut tre gre de faon trs informelle. Le plus souvent, ce sera fait en listant les obstacles sur le tableau des tches. Parfois il y a de nombreux obstacles, dont certains ne sont pas faciles liminer et si le ScrumMaster nest pas plein temps sur le projet, alors il devient ncessaire de les enregistrer.

Cest la responsabilit du ScrumMaster de les classer par priorit et de faire en sorte quils soient limins au plus vite. Certains peuvent tre du ressort de lquipe, dautres ne peuvent avoir une solution quavec lintervention de personnes extrieures, dans dautres quipes (par exemple, si une quipe support soccupe de lenvironnement de dveloppement) ou au niveau de la direction du projet.
Quel est le lien de cette liste avec les tches ? Un obstacle bloque ou ralentit le bon droulement dune tche ou de plusieurs (et pour liminer lobstacle, il peut tre utile de crer une nouvelle tche).

Un obstacle possde les attributs suivants :


son nom, son tat (identi, en cours de rsolution, rsolu), son impact (dni par les tches qui sont bloques ou freines), la date didentication.

114

Chapitre 8. Le scrum quotidien

Sprint 3 : dbut le 13/9, fin le 27/9 But : blabla


faire
tche tche tche

Equipe

En cours
tche tche

Fini

Fini

story

tche

Obstacles
traiter
obstacle obstacle obstacle

En cours

Figure 8.5 Tableau des tches avec la liste des obstacles Dans la partie droite du tableau, on trouve les obstacles avec les Post-it rangs en deux lignes en fonction de leur tat : les obstacles traiter et les obstacles en cours de rsolution. Les obstacles dj rgls sont limins du tableau. Au-dessus figurent ltat prvisionnel des ressources, la dfinition de fini et le burndown chart de sprint.

8.4 GUIDES POUR LE SCRUM


essayer Faire le suivi des tches avec les tats Organiser des variations dans le droulement du scrum viter Dpasser un quart dheure Sintresser au temps pass Prendre un engagement draisonnable

Finir vite les stories

8.4.1 Sen tenir un quart dheure


Pour que le scrum ne dure pas trop longtemps, il faut appliquer les rgles suivantes :
Il a lieu tous les jours de travail. Les solutions pour liminer les obstacles ne sont pas discutes en runion.

8.4.2 Ne sintresser quau reste faire, pas au temps pass


Lobjectif du sprint est de nir des stories et pour y arriver il faut nir les tches qui permettent la ralisation dune story. Mme si cest utile de bien estimer, ce nest pas le plus important. Cest pourquoi Scrum sintresse uniquement au reste faire sur une tche, pas au temps pass dessus. Pour certains, cest un changement radical.

8.4 Guides pour le scrum

115

Chez un de mes clients, au cours du scrum quotidien, le premier du sprint, chacun prit la parole tour de rle. Quand vint le tour dIbrahima, il prsenta ce quil avait fait depuis la veille, et sur quelles tches il avait travaill. La liste des tches, labore au cours de la runion de planication du sprint tait afche sur le tableau autour duquel nous tions debout, comme il se doit. Comme je lui demandais combien il restait faire sur la tche quil venait dvoquer, il consulta la liste et y lit le nombre dheures inscrit la veille pour cette tche, soit 14 heures. Il rchit brivement et dit : jai travaill deux heures sur cette tche alors il reste 14 moins 2 soit 12 heures faire. Il navait pas t form la gestion de projet agile et donc sa manire de procder est celle de la gestion de projet classique. Elle met en vidence plusieurs aspects venant des habitudes prises : la premire estimation est souvent considre comme la rfrence, quand on a du mal savoir combien il reste faire, on trouve plus facile de prendre le chiffre de lestimation prcdente et de soustraire le temps pass. Le reste faire sur une tche est obtenu en actualisant lestimation, pas par une soustraction entre la premire estimation et le temps pass. La mesure du temps pass sur une tche nest pas utile avec Scrum.

8.4.3 Faire le suivi des tches avec les tats plutt que les heures
La ractualisation en heures du reste faire pendant un sprint est difcile obtenir des quipes. Jai observ, sur certains projets, que :
mme si on pense quil faut plus de temps que prvu pour nir une tche, on

hsite lannoncer (en esprant se rattraper ?) ; mme si on pense quon aura ni avant, on hsite diminuer le reste faire (de peur de se tromper ?). Une premire solution est souvent de dcomposer plus nement les tches. Si on ne sait pas dire combien il reste faire, cest que la tche est trop importante, mal cerne. La dcomposer en tches plus petites permet effectivement dy voir plus clair. De faon gnrale, il est souhaitable que les tches soient sufsamment petites pour tre nies en une journe de travail. Une solution complmentaire est de suivre les tches uniquement par les tats : lors de la runion de planication du sprint, aprs que les tches aient t identies, lestimation des heures nest pas faite. Le dcoupage doit tre sufsamment n pour quune tche puisse tre nie en une journe de travail.

116

Chapitre 8. Le scrum quotidien

Suivi avec deux tats


Lors des scrums quotidiens, plutt que dactualiser le reste faire en heures, on note simplement les tches qui sont nies. Si une tche nest pas nie, cest le signe quil y a un problme. Le burndown chart montre normalement lvolution du reste faire pendant le sprint. Plutt que de le baser sur les heures, on va simplement noter les tches restant faire, cest--dire celles qui ne sont pas nies.
Exemple : il y avait 49 tches identifies au dbut du sprint. Le premier jour 3 sont finies, le deuxime 5... cela donne un burndown chart avec 49, 46, 41.

Cette pratique simplie me parat adapte aux quipes peu exprimentes dans les estimations. De plus la mesure binaire est de nature motiver davantage nir une tche. Le burndown chart de sprint bas sur les heures peut tre remplac par un burndown portant sur le nombre de tches qui restent raliser.

Suivi avec trois tats


Une tche du sprint est dans un de ces trois tats : faire, en cours, nie. Un bon suivi sur le tableau des tches avec ces trois tats permet de se passer de lestimation du reste faire.
Pour un dveloppeur est-il plus facile darriver dire quil reste six heures sur une tche ou bien de dire quelle est en cours et quelle sera finie demain ? Mon exprience avec de nombreuses quipes me pousse privilgier le suivi par les tats plutt que par les valeurs en heures. Jai constat que pour les membres de lquipe cest beaucoup plus facile vivre. Certains sont tourments quand on leur demande avec insistance le reste faire. Ce nest pas le cas quand il sagit simplement de donner ltat de la tche. En se passant du reste faire, on vite de perdre du temps y rflchir. Mais peut-on assurer un bon suivi ? Cela dpend des quipes et de lexprience du ScrumMaster. Un bon ScrumMaster saura dceler un problme quand une tche reste en cours plusieurs jours sans se terminer, par exemple.

8.4.4 Veiller finir les stories


Le scrum permet de grer les priorits et les dpendances entre les tches. Lobjectif primaire est de nir les tches, mais lobjectif essentiel est de nir les stories. Pour quune story soit nie, il faut videmment que toutes les tches associes soient termines. Cela conduit avoir des priorits pour la prise des tches libres.

8.4 Guides pour le scrum

117

8.4.5 Organiser des variations dans le droulement du scrum


Il est fondamental que le scrum reste un moment o lquipe reprend de lnergie pour la journe. Pour viter de tomber dans la routine, le ScrumMaster peut proposer des variations dans le droulement des scrums :
la prise de parole se fait un coup de gauche droite, un coup de droite gauche ; la rponse aux trois questions se fait une fois la suite pour chaque personne,

une autre fois par trois tours avec une question chaque fois. Des accessoires peuvent renforcer la cohsion de lquipe, par exemple :
de la musique pour annoncer le scrum, qui change chaque sprint ; un ballon de rugby pass de main en main pour montrer qui a la parole.

Figure 8.6 Un ballon, pas une boule de ptanque !

En rsum
Le scrum quotidien est une runion qui se passe tous les jours, avec toute lquipe debout qui fait le point sur le travail effectu et celui faire. Cest une pratique qui a prouv son efcacit et qui ne cote pas cher mettre en place.

9
La revue de sprint

Avant celles de Scrum, jai particip de nombreuses revues. Elles portaient sur des documents, qui devaient tre envoys plusieurs jours avant la runion pour que les participants aient eu le temps de les lire. La runion elle-mme pouvait durer longtemps. Certaines revues de n de phase de systmes spatiaux se droulent pendant plusieurs jours, chaque document tant pluch et chaque remarque commente. Lobjectif de ces revues tait de connatre ltat dun projet pour prendre des dcisions sur sa poursuite. La revue de sprint Scrum a la mme raison dtre, mais la faon de les mener est radicalement diffrente. Scrum se situe dans le giron des mthodes agiles et du Manifeste agile qui dit que pour connatre lavancement dun dveloppement, il vaut mieux se baser sur du logiciel fonctionnel plutt que sur de la documentation . Dans un dveloppement de logiciel, on va montrer du code qui marche. Cest ce qui est mis en uvre lors de la revue, avec la dmonstration de lincrment de produit ralis pendant le sprint. Cest un moment essentiel de la mise en uvre de la thorie empirique de Scrum, base sur les notions de visibilit, inspection et adaptation.

9.1 LA REVUE EST BASE SUR UNE DMONSTRATION


Le but de la revue est de montrer ce qui a t ralis pendant le sprint an den tirer des enseignements pour la suite du projet.

120

Chapitre 9. La revue de sprint

9.1.1 La revue accueille de nombreux invits


Toute lquipe Scrum participe la runion. Lquipe considre est lquipe tendue, avec le ScrumMaster et le Product Owner. Toutes les personnes qui sont parties prenantes (stakeholders) du projet y sont invites et leur prsence vivement encourage On peut mme y accueillir des invits qui ne sont pas directement concerns par le projet, mais intresss voir lapplication de Scrum. Cest la runion Scrum laquelle assistent le plus grand nombre de personnes. Cest loccasion de les faire collaborer sur lavenir du produit.

9.1.2 Dure de la runion


La revue de sprint a lieu le dernier jour du sprint, elle sera suivie de la rtrospective. Pour des sprints dun mois, la dure maximum est de 4 heures. Pour des sprints plus courts, la dure de la revue sajuste en fonction de celle du sprint.
Exemple : pour un sprint de deux semaines, cela fait une limite de deux heures.

Cest ce que mentionne le Guide Scrum de la Scrum Alliance, mais je prconise une dure plus courte : une heure pour un sprint de deux semaines. Dans la pratique, cette limite est assez facile tenir si on se tient une dmonstration qui ne porte que sur les nouveauts du sprint.

Revue de sprint

Sprint

Figure 9.1 Place de la revue de sprint

La revue ncessite une prparation, au moins pour accueillir le public et tre en capacit de leur faire la dmonstration. Le temps de prparation global ne devrait pas excder une heure, car il ny a pas de prsentation formelle faire : pas de slides prparer.

9.2 tapes

121

9.1.3 La revue montre le produit


La revue de sprint porte sur le rsultat du travail de lquipe pendant le sprint : le produit partiel potentiellement livrable. Cest cette version oprationnelle qui est prsente. Dans le cas dun dveloppement de logiciel, il a la forme dun build incluant les stories nies, accompagn de ce qui est ncessaire pour le faire fonctionner (tests, documentation, scripts...) et dploy sur un environnement de test.

9.2 TAPES

Prparer la dmonstration

Rappeler les objectifs du sprint

Effectuer la dmonstration

Calculer la vlocit

Ajuster le plan de release

Figure 9.2 Les tapes de la revue de sprint

9.2.1 Prparer la dmonstration


Logistique
Lquipe doit sassurer que le matriel ncessaire pour la revue fonctionne bien. La dmonstration est gnralement faite dans une salle pouvant accueillir du monde et disposant dun vidoprojecteur. Une erreur classique est de ne pas vrier les connexions rseau de la salle si lapplication en a besoin. Jai vu une revue de sprint perdre une heure cause de ce dtail. Si des participants sont distance, la revue ncessite lemploi dun systme de vidoconfrence.

Environnement de dmonstration
La prparation de la runion consiste aussi imaginer un scnario denchanement des diffrentes stories qui seront montres, avec ventuellement des jeux de donnes associs. La dmonstration se fait de prfrence sur un environnement de test, le plus proche possible de lenvironnement de production, et surtout pas sur lenvironnement de dveloppement.

122

Chapitre 9. La revue de sprint

Lquipe se met daccord sur le droulement de la dmonstration et sur quelles personnes vont la prsenter, an quil ny ait pas de temps perdu organiser cela pendant la runion.

9.2.2 Rappeler les objectifs du sprint


Le Product Owner rappelle le but du sprint dni lors de la runion de planication, en dbut de sprint. Il donne la liste des stories qui taient dans le primtre prvu et annonce celles qui vont effectivement tre montres lors de la revue. Sil y a des diffrences, lquipe intervient pour en donner brivement les raisons, sachant que les causes seront examines lors de la rtrospective.

9.2.3 Effectuer la dmonstration


Lquipe prsente le produit partiel, rsultat de ses travaux, en faisant une dmonstration des stories ralises. Seules les stories compltement nies (selon la dnition de ni) sont prsentes. Cela permet davoir une mesure objective de lavancement. La dmonstration est faite en indiquant une une les stories prsentes.

Qui fait la dmonstration ?


La dmonstration peut-tre faite par lquipe, avec chaque personne de lquipe montrant la story sur laquelle elle sest particulirement implique. Le risque est le manque dhomognit. De plus il arrive que certains dveloppeurs aient tendance avoir le clic trop rapide pour un public compos dutilisateurs. Il est prfrable que ce soit le Product Owner qui fasse la dmonstration, cela a lavantage de lobliger simpliquer dans le test du produit avant la revue. Les meilleures dmonstrations que jai vues taient faites par un binme constitu du Product Owner et dun membre de lquipe : le Product Owner parle et lquipier manipule.

Impliquer les participants


Les participants la runion sont invits poser des questions lquipe et donner leur impression sur le produit montr. Leur feedback se concrtise en propositions et demandes de changement. Le backlog de produit est enrichi avec les ventuels dfauts dcouverts et les demandes dvolution suggres. Si cest possible, les personnes prsentes la runion sont invites manipuler le produit la n de la dmonstration.

9.2 tapes

123

9.2.4 Calculer la vlocit


La liste des lments du backlog considrs comme nis est tablie en commun. En principe, si lquipe na prsent que les stories vraiment nies, la liste est connue lavance, mais il est prfrable dimpliquer tout le monde dans la dcision. La vlocit du sprint est obtenue en faisant la somme de tous les points attribus ces lments.
Que faire si une story est presque finie ? Il ny a pas de stories moiti finies ou 90 % finies lorsquil sagit de mesurer la vlocit : seules les stories qui passent les tests dacceptation et respectent la signification de fini comptent. Toutes les autres ne contribuent pas la vlocit.

La vlocit obtenue est compare celles des sprints prcdents.

Figure 9.3 Le graphe de vlocit

La gure 9.3 montre la vlocit avec une classication des stories selon leur type. La vlocit moyenne est calcule en tenant compte de celle ajoute pour le sprint. Cette nouvelle vlocit moyenne sera utilise pour ajuster le plan de release.

9.2.5 Ajuster le plan de release


Les conditions ont chang depuis la dernire planication de la release : des lments du backlog ont pu tre ajouts ou supprims, les estimations modies, lordre dans lesquels les lments sont classs (la priorit) a pu tre modi, la vlocit moyenne a pu voluer. Le Product Owner prsente le plan de release ajust (sil y a eu un feedback important, cet ajustement ne pourra pas se faire en sance et sera communiqu aprs la runion).

124

Chapitre 9. La revue de sprint

Cest loccasion de discuter avec les intervenants sur le contenu de la release et sur sa date de n. Des projections peuvent tre faites en tenant compte dhypothses sur la capacit de lquipe et sur les variations de primtre. Il est possible de prendre une dcision sur la date de la mise en production de la release, ou sur son contenu, si cela na pas t fait avant.

9.3 RSULTATS
9.3.1 Backlog de produit actualis
Le backlog de produit est mis jour :
les stories du sprint dclares termines changent dtat et passent dans la zone

du backlog rserve aux stories nies, le feedback des participants la dmonstration peut entraner la cration de nouvelles stories.

9.3.2 Plan de release et burndown chart de release mis jour


Le plan de release est impact par les modications sur le backlog et par la mesure de la vlocit. Le burndown chart de release est complt avec un nouveau point pour le sprint qui sachve, calcul partir du backlog.

points

53 5

sprints

Burndown de release
Figure 9.4 Mise jour du burndown chart de release

Dans la gure 9.4, il reste 53 points dans le backlog la n du sprint 5.

9.4 Guides pour la revue

125

9.4 GUIDES POUR LA REVUE


essayer Drouler un scnario Inviter largement mais expliquer que cest un produit partiel Parler des stories Solliciter le feedback En faire la runion essentielle sur le produit viter Modifier le produit au dernier moment Parler processus Parler des tches Ne pas finir les stories Faire un compte-rendu

9.4.1 Drouler un scnario


Une dmonstration de n de sprint nest pas une prsentation marketing avec des paillettes, ce nest pas non plus une recette fonctionnelle avec le passage roboratif des tests.

Figure 9.5 Le Product Owner fait sa revue en tutu (et gilet pare-balles au cas o)

Pour que lauditoire comprenne bien, il faut que la dmonstration soit uide. Il peut tre utile de prparer un scnario. Ce nest pas bien difcile, puisquon dispose de la liste des stories ; il suft dimaginer un enchanement de ces stories et de rchir, pour chacune, la faon de les prsenter. Ce scnario peut tre crit, ce nest pas du travail inutile, il pourra tre laiss aux utilisateurs du produit partiel aprs le sprint.

126

Chapitre 9. La revue de sprint

Attention : la revue nest pas lendroit o lon passe les tests dacceptation : ils sont passs avant et ne sont montres que les stories les ayant passs avec succs.

9.4.2 Inviter largement, mais expliquer que cest un produit partiel


La revue de sprint est loccasion de prsenter le produit et il faut rechercher laudience la plus large possible. Des invitations sont envoyes toutes les personnes impliques directement ou indirectement dans le futur produit. Dans certaines organisations, on rechigne inviter des personnes extrieures tant que le produit nest pas sufsamment complet. Il existe la crainte que les personnes soient frustres parce que le produit ne contient pas tout ce quelles attendent. Ce serait une erreur de se priver des bnces dune revue avec des personnes extrieures. Le mieux est de les former Scrum si cest ncessaire et de les inviter la revue. Au dbut de la runion, il est bon de leur rappeler quil sagit dun produit partiel et que les autres fonctions du produit seront ralises ultrieurement. Une bonne faon de procder est de prsenter le plan de release actuel.

9.4.3 viter de modifier le produit partiel au dernier moment


Le logiciel, cest souple, des modications peuvent tre faites rapidement. quelques minutes de la revue, si lquipe dcouvre un dfaut, il est tentant de le corriger. Il faut rsister cette envie, cest trop tard. On pourrait se dire que si a ne marche pas, ce nest pas grave. En fait, cela peut ltre : une modication peut entraner des rgressions. Si le temps ne permet pas de passer des tests qui permettent de sassurer quil ny a pas de rgressions, alors il ne faut pas modier le code. Jai entendu de nombreuses quipes, et pas seulement des quipes dtudiants, qui, voyant leur dmo planter, se sont exclames, de bonne foi : mais a marchait tout lheure . Pour ne pas risquer le fameux effet dmo , il est conseill de ne pas toucher au code le dernier jour.
Montrer uniquement ce qui est fini Quand cest lquipe qui prsente, et en particulier quand cest un dveloppeur qui fait la dmonstration, la tentation est forte de montrer tout le travail ralis, mme si ce nest pas fini. Il faut considrer la dmonstration comme un rsum du travail du sprint o on ne montre que les actions abouties, de la mme faon quun rsum de match de rugby ne porte que sur les essais marqus.

9.4 Guides pour la revue

127

9.4.4 Parler des stories, pas des tches


La revue de sprint est un moment privilgi pour la transparence : lquipe montre au public ce qui fonctionne. Il sagit aussi dinspecter le rsultat, en particulier par rapport aux objectifs de dbut de sprint. Le Product Owner prsente les stories prvues, et ce qui a t effectivement ralis. Certaines quipes donnent trop dimportance au burndown chart de sprint et le prsentent lors de la revue. Cest une erreur : il est usage de lquipe pendant son sprint, seules les stories nies intressent les invits de la revue. Ce quon peut leur montrer, cest le burndown chart de release, mais celui de sprint, non. Ce qui compte pour les invits de la revue, cest le produit partiel avec les stories quil contient. Le droulement du sprint et en particulier les tches qui sont nies ou pas, cela ne concerne que lquipe et ce nest pas lobjet de la revue.

9.4.5 Solliciter le feedback


Un processus itratif fonctionne avec le feedback. La revue de sprint est lendroit idal pour le solliciter. Les personnes prsentes peuvent intervenir pendant la revue et poser des questions lors de la dmonstration. Lquipe y rpond, soit en prcisant un point mal compris, soit en expliquant que cela est dj dans le backlog et sera fait plus tard, soit en ajoutant une entre au backlog. Le feedback pendant la revue reste limit : les personnes ne manipulent pas ellesmmes en gnral. Cest pourquoi il faut pousser utiliser le rsultat du sprint aprs la revue : pour cela, un environnement spcique peut tre mis disposition des personnes qui souhaitent essayer le produit et faire ainsi du feedback plus complet.

9.4.6 En faire la runion essentielle sur le produit


La prsence des personnes impliques dans le produit rend inutiles la tenue dautres runions.
La revue permet dviter des dmonstrations spcifiques pour des personnes importantes qui nont pas daign se dplacer. Cest de la perte de temps alors que la revue est prvue pour a. En revanche, il peut toujours tre ncessaire dorganiser dautres dmonstrations pour des clients.

Si quelquun dimportant ne peut pas assister la revue, ce nest pas dramatique, la prochaine reviendra vite, au rythme des sprints. Les organisations qui fonctionnent dhabitude avec des comits (comit de pilotage, comit de suivi) devraient les supprimer pour ne conserver que les revues de sprint.

128

Chapitre 9. La revue de sprint

Ne pas faire de compte-rendu de runion et ne pas parler processus Les personnes qui assistent nont pas besoin de compte-rendu, elles ont vu le produit dans son tat actuel. Les autres navaient qu venir ! Sinon, elles ont toujours accs au backlog de produit, au plan de release et au burndown chart de release qui sont publis et diffuss largement. Dans la mesure du possible, ces artefacts sont mis jour pendant la runion. Le processus, cest lobjet de la rtrospective, qui a lieu juste aprs. La revue est consacre au produit.

En rsum
La revue de sprint est loccasion de faire partager les ralisations de lquipe avec le reste de lorganisation. La visibilit apporte et le feedback reu permettent daugmenter les chances que le produit soit un succs.

10
La rtrospective de sprint

Dans de grandes entreprises, quand un projet touche sa n, le service mthodes ou son quivalent rappelle au chef de projet quil faudrait faire un bilan avant que lquipe ne se disloque. Le bilan de projet alors men est loccasion de revenir sur la faon dont sest droul le projet et de faire une liste des faits marquants. Malheureusement le bilan de projet arrive trop tard : le projet est ni. On peut toujours se dire que dautres projets bncieront des rsultats du bilan. Encore faudraitil que la capitalisation sopre bien dans lentreprise. Dans la plupart des entreprises, ce genre dinitiative nexiste mme pas. Cest pour permettre une quipe de samliorer rgulirement que la rtrospective de sprint existe. Avec Scrum, on nattend pas la toute n du projet, elle fait partie du crmonial de chaque sprint. En prenant lanalogie dun match de rugby pour le sprint, on peut comparer la rtrospective la discussion sur on refait le match , mais laquelle participeraient uniquement les joueurs. Le Manifeste agile rappelle que les personnes et les interactions entre elles sont plus importantes que les processus et les outils. Pourtant la rtrospective, cest de lamlioration de processus, ne serait-ce pas contradictoire ? Avec Scrum, le processus nest pas impos lquipe cest elle qui le construit rgulirement partir du cadre propos par Scrum, et en particulier lors des rtrospectives. partir des expriences tires du dveloppement sur le sprint courant, lquipe identie ce qui marche bien pour elle, ce qui marche moins bien et trouve collectivement ce quil faut modier au processus quelle utilise.
Un des principes du Manifeste lnonce : intervalles rguliers, lquipe rflchit comment devenir plus efficace, puis adapte et ajuste son comportement en consquence.

130

Chapitre 10. La rtrospective de sprint

En rsum, le but de cette runion est lvaluation par lquipe de sa faon de travailler pour trouver un moyen de lamliorer dans le prochain sprint.
Dfinition Le terme est surtout utilis dans le domaine artistique pour voquer la prsentation de luvre dun crateur de faon chronologique : on entend que France 3 propose une rtrospective Hitchcock pendant lt et on lit dans La Dpche que Les Abattoirs exposent du Saura pour une rtrospective.

Figure 10.1 Un ScrumMaster mgalo pose pour la rtrospective de ses sprints

Cest Norm Kerth1 qui est lorigine de lutilisation de rtrospective pour le dveloppement, il la dnit comme : un rituel la n dune tape pour acqurir de la connaissance et dcider damliorations mettre en uvre lors de la prochaine tape . La rtrospective agile est maintenant passe dans le langage courant.

10.1 UNE PRATIQUE DAMLIORATION CONTINUE


Une quipe a t sensibilise Scrum et essaie de lappliquer. la n dun sprint, la rtrospective est le moment pour se poser des questions sur la faon dont elle a travaill. Il est normal de procder des adaptations du processus, en fonction du vcu sur le sprint qui se termine.
1. Project Retrospectives : A Handbook for Team Reviews- Dorset House, 2001

10.1 Une pratique damlioration continue

131

Ces adaptations se poursuivent pendant toute la vie du produit : en effet, il y a toujours des amliorations faire, il nexiste pas de processus ultime.

10.1.1 Un moment de rflexion collective la fin de chaque sprint


La rtrospective constitue un moment particulier o lquipe sarrte de produire, prend le temps de rchir et parle de ses expriences, avec lobjectif de :
capitaliser sur les pratiques qui ont march, viter de refaire les mmes erreurs, partager diffrents points de vue, permettre au processus de sadapter aux nouvelles avances dans la technologie

utilise pour dvelopper. Ce travail est ralis en groupe au cours dune runion, dont la dure est limite, comme toutes les autres. La rgle est de ne pas dpasser trois heures pour un sprint dun mois. Daprs mon exprience, elle dure en moyenne une heure et a lieu dans la mme demi-journe que la revue de sprint.
Rtrospective

Sprint

Figure 10.2 Place de la rtrospective

10.1.2 Cest lquipe qui refait le match


Toute lquipe Scrum participe la runion. Lquipe considre est lquipe tendue, avec le ScrumMaster et le Product Owner. La rtrospective a gnralement lieu juste aprs la revue de sprint et les intervenants qui sont venus y assister peuvent rester pour la rtrospective, titre dobservateurs. Cependant, la conance est ncessaire pour le succs dune rtrospective et la prsence de certaines personnes peut tre un obstacle son instauration.
La runion est anime par le ScrumMaster. Mais, notamment dans les environnements difficiles, il est prfrable que ce soit une personne extrieure lquipe qui joue le rle de facilitateur de cette runion.

132

Chapitre 10. La rtrospective de sprint

Une rtrospective reprsente pour les participants une possibilit dapprendre comment samliorer. Lide est que ceux qui ralisent sont les mieux placs pour savoir comment progresser. Lobjectif est lapprentissage, et non la recherche de fautes. Lquipe est implique dans la mesure o chacun doit :
comprendre le besoin damlioration, concevoir les amliorations, sapproprier les amliorations, tre motiv pour samliorer.

10.2 TAPES
Crer un environnement propice lexpression

Collecter des informations

Identifier des ides d'amlioration

Adapter Scrum pour le prochain sprint

Dfinir l'amlioration prioritaire

Regrouper les ides

Figure 10.3 Les tapes de la rtrospective

10.2.1 Crer un environnement propice lexpression


Il sagit de sassurer que tout le monde se sent en conance et pourra sexprimer librement pendant la runion. Norm Kerth a dni le principe qui doit guider les participants :
Indpendamment de ce que nous allons dcouvrir aujourdhui, nous comprenons et nous croyons vraiment que chacun a fait de son mieux, en fonction de ses connaissances, de ses comptences et de ses capacits, des ressources disponibles et de la situation courante.

Il sagit de regarder le pass, non pour juger le comportement de certains ni pour faire son autocritique, mais dans le but de samliorer en tant ququipe. Sil y a des doutes sur le climat de conance qui entoure la runion, il est prfrable de demander chacun, bulletin secret, sil se sent en capacit de sexprimer librement. Si lanimateur constate que ce nest pas le cas, la rtrospective ne peut pas avoir lieu, il faudra trouver des conditions diffrentes qui rtablissent la conance.

10.2 tapes

133

10.2.2 Collecter les informations sur le sprint pass


Dans une rtrospective, on commence par regarder en arrire : avant de chercher amliorer les pratiques, il convient de collecter le ressenti des participants sur ce qui sest pass pendant le sprint qui sachve. Lapproche basique consiste poser des questions chaque participant, de faon un peu similaire ce qui est fait dans le scrum quotidien :
Quest-ce qui a bien fonctionn ? Quest-ce qui sest mal pass ? Quest-ce que nous pouvons amliorer ?

Cependant le risque avec cette dmarche un peu brutale est de ne pas collecter beaucoup dinformations, aussi il est prfrable dutiliser une approche plus progressive. Une technique courante qui facilite la collecte est la prsentation chronologique de la vie de lquipe pendant le sprint, appele timeline : la ligne de vie est trace avec les vnements marquants qui ont jalonn la priode. On peut sappuyer sur la liste des obstacles rencontrs pour se remmorer les pripties du sprint. Les vnements sont annots selon leur perception par lquipe : agrables, frustrants, fcheux.

10.2.3 Identifier des ides damlioration


Lobjectif dune rtrospective nest pas seulement de poser des questions sur le pass, mais surtout celui dapporter des rponses concrtes qui seront mises en place dans la prochaine itration. Les informations collectes dans ltape prcdente sont compltes avec les ides damlioration proposes par lquipe.
Il existe de nombreuses techniques, sous forme dateliers, permettant dy arriver. Je conseille de commencer par une rflexion individuelle, pendant laquelle chaque participant note ses ides sur des Post-it (un par ide). Une fois que chacun a identifi au moins quatre ides et que linspiration se tarit, les Post-it sont colls sur un mur.

10.2.4 Regrouper les ides


Les informations sont regroupes en catgories, de faon en obtenir entre cinq et dix. Les catgories correspondent en gnral des pratiques agiles et aux outils qui les supportent. Chacune est nomme pour que tout le monde lidentie clairement.

134

Chapitre 10. La rtrospective de sprint

Figure 10.4 Les catgories identifies aprs regroupement des ides damlioration

Ce travail est fait collectivement, ce qui est facilit par lutilisation de Post-it. Lors des rtrospectives que janime, il marrive de demander un regroupement en silence, ce qui permet de drouler cette tape plus rapidement, les discussions ayant eu lieu lors de ltape prcdente.

10.2.5 Dfinir lamlioration prioritaire


Il sagit de dnir sur quelle pratique va tre port leffort damlioration. Pour un sprint de deux semaines, il est prfrable de nen slectionner quune seule. La technique de slection doit permettre la participation de toute lquipe, avec par exemple un systme de votes. Sur la gure 10.4, on voit le rsultat dun vote, pour lequel chaque participant disposait de cinq points rpartir sur la ou les catgories de son choix. Quelle que soit la technique utilise pour choisir, lobjectif est de renforcer limplication de chacun et de le motiver pour mettre en uvre lamlioration.

10.2.6 Adapter Scrum pour le prochain sprint


Pour la pratique choisie en vue de lamliorer, il sagit de dnir les actions concrtes qui vont tre menes lors du prochain sprint. Les actions sont identies par lquipe, en rchissant toutes les tches ncessaires. la n de la runion, il est conseill que lquipe revoie sa signication de ni1 : elle tudie chaque lment de la liste, dcide de conserver ou pas pour le prochain sprint et en ajoute ventuellement.

1. La signication de ni fait lobjet du chapitre 11.

10.3 Rsultat

135

10.3 RSULTAT
Le rsultat de la rtrospective est la liste des actions qui ont t dcides. On peut classer les actions selon leur orientation :
celles diriges vers les personnes et leur faon dappliquer les pratiques, celles orients outils installer ou adapter, celles axes sur lamlioration de la qualit.

Les actions impactant les personnes sont par exemple : limiter le scrum 15 minutes, faire une heure de travail en binme tous les jours, modier la faon de prendre en compte les bugs...
Exemple : la limitation des scrums quotidiens un quart dheure est lamlioration choisie par lquipe. Les actions identifies sont : apporter un minuteur, annoncer le temps coul, afficher la dure tous les jours. Une personne de lquipe propose dapporter son minuteur. Les autres actions trouveront des responsables au moment du scrum. Lamlioration choisie et les tches faire restent bien visibles pendant le sprint, dans lespace de travail.

Les actions relatives aux outils ncessitent gnralement des tudes dimpact avant gnralisation ventuelle. Par exemple, si lquipe dcide de mettre en place un outil de test automatique, elle ne peut pas le faire ds le prochain sprint. Il faut au pralable tudier plusieurs outils, en choisir un, former lquipe... Ltude devient une story technique, prioritaire pour le sprint venir. Les actions relatives la qualit, comme augmenter le taux de commentaires dans le code ou la couverture de tests vont dans la signication de ni. Les ides damlioration identies et non slectionnes pour le prochain sprint sont places dans le backlog de produit.

10.4 GUIDES
essayer Parler de ce qui va bien Se concentrer sur une seule amlioration Mener des rtrospectives plus pousses en fin de release Utiliser un facilitateur externe viter Rgler ses comptes Vouloir tout amliorer dun coup Ne pas faire aboutir les actions dcides Arrter de faire les rtrospectives

10.4.1 Ne pas en faire une sance de rglement de comptes


La rtrospective permet toute lquipe de sexprimer et chacun est invit participer lidentication des dysfonctionnements constats pendant le sprint. La mise en vidence derreurs ne doit pas conduire accuser une personne den tre responsable.

136

Chapitre 10. La rtrospective de sprint

Figure 10.5 La rtrospective ne doit pas tourner au rglement de comptes

Le ScrumMaster doit veiller ce que la rtrospective ne drive pas vers les attaques personnelles, en faisant de lquipe lobjet central des discussions. Il arrive aussi que lquipe estime que des dysfonctionnements sont provoqus par des entits extrieures. Cest frquent : lquipe nest pas dans sa bulle, elle nest jamais compltement indpendante. Il est difcile de dnir des actions dont les responsables ne participent pas la runion. Le ScrumMaster doit remonter les problmes la hirarchie et tout faire pour quils soient traits. Cependant, lobjectif de la rtrospective est dabord de se concentrer sur son processus et didentier des actions que lquipe peut mettre en uvre elle-mme.

10.4.2 Parler de ce qui va bien


Comme lobjectif est damliorer des faons de faire, la collecte passe essentiellement par la mise en vidence de pratiques qui ne se passent pas bien, en tout cas pas aussi bien quelles le pourraient. Pour quilibrer ce point de vue qui peut tre peru comme ngatif, il convient aussi de mettre en exergue ce qui sest bien pass pendant le sprint, les pratiques qui ont apport de la satisfaction lquipe. Cela permet de construire une communaut partir daspects positifs.

10.4.3 Faire aboutir les actions des rtrospectives prcdentes


Il ny a rien de plus frustrant pour les participants une rtrospective que de constater, sprint aprs sprint, que rien ne bouge vraiment. Cest le rle du ScrumMaster de sassurer que les actions dcides sont vraiment mises en uvre.

10.4 Guides

137

Parfois, les quipes se lassent des rtrospectives, estimant quil ny a plus rien amliorer, ou que nous disons toujours la mme chose . Lerreur la plus grave est darrter de faire des rtrospectives. Ne pas utiliser cette possibilit de feedback sur la faon de travailler, cest passer ct dun des bnces majeurs des mthodes agiles. Il y a toujours des choses amliorer. Par exemple une ide damlioration sortant du cadre traditionnel, ce serait une demi-journe par semaine pour travailler sur des projets personnels.

10.4.4 Se concentrer sur une amlioration


La rtrospective de sprint revient rgulirement : chaque n de sprint. Il ne sert rien dtre trop ambitieux en cherchant adapter la faon de travailler sur des nombreuses pratiques. Vouloir faire un trop grand nombre dactions conduit au risque quaucune qui naboutisse vraiment. Pour des sprints courts, dune semaine ou deux, il vaut mieux nessayer damliorer quune seule chose la fois. On peut se dire que les amliorations qui ne sont pas choisies lors dune rtrospective ont de bonnes chances de ltre dans une prochaine.

10.4.5 Mener des rtrospectives plus pousses en fin de release


La rtrospective de sprint revient sur le proche pass du sprint qui se nit. chaque n de release, il est souhaitable de mener une rtrospective qui porte sur ce qui sest pass pendant les quelques mois de la release. cette occasion, il vaut mieux prvoir une runion plus longue que dhabitude et dutiliser une technique diffrente.

10.4.6 Utiliser un facilitateur externe


Quand le ScrumMaster ny arrive pas, quand il y a des blocages qui ne permettent pas lquipe de sexprimer, lintervention dun consultant extrieur est souhaitable.

138

Chapitre 10. La rtrospective de sprint

En rsum
La rtrospective est la pratique Scrum pour amliorer le processus. Place la n dun sprint, la runion implique toute lquipe dans un brainstorming en vue didentier des faons de mieux travailler. Par rapport aux approches habituelles damlioration de processus souvent imposes den haut, elle donne la parole lquipe pour quelle sapproprie la conduite de son processus.

11
La signification de fini

Est-ce que tu as ni ton travail ? Quand aurez-vous ni de coder ? Ces questions reviennent sans arrt dans le dveloppement dun produit. Avec Scrum aussi : il y a mme une pratique ddie cela. Fini ? Fini ni, cest le credo de Scrum ! Et quand cest ni, a ne recommence pas ! la n dun sprint lquipe a ralis un produit partiel contenant de nouvelles stories et le produit est potentiellement livrable. la n de la release, le produit est vraiment livr. Scrum pousse nir une story la n dun sprint. Mais que signie ni ? La rponse varie selon les organisations et les quipes. Cest chaque quipe de le dnir et de lappliquer. Le constat fait avec les quipes qui dmarrent avec Scrum est que cette pratique est une des plus difciles russir : souvent on pense que cest ni, mais cest seulement presque ni. Cest lobjet de ce chapitre de montrer comment procder pour que ni ait la mme signication pour toute lquipe.

11.1 FINI, UNE PRATIQUE PART ENTIRE


La mcanique de Scrum repose sur la ralisation dune story du backlog en un sprint. la n du sprint, la story slectionne pour ce sprint est nie et, comme toutes les autres stories faites dans le sprint, elle sajoute aux incrments prcdents. Lensemble doit fonctionner, ce qui implique quil passe avec succs quelques contrles. Cest la liste de ces contrles qui constitue la signication de ni.

140

Chapitre 11. La signification de fini

Toute lquipe doit dnir ce que signie ni, puis lassumer. Il est entendu que ni englobe du test, mais cette dnition nest pas sufsante :
dune part, il existe de nombreux types de test diffrents ; dautre part, il ne suft pas toujours de passer des tests avec succs pour sassurer

quune story est nie. Le travail faire par lquipe en rapport avec la signication de ni constitue une pratique Scrum part entire.

Figure 11.1 Jai fini de ranger ma chambre ! La signification de fini nest pas la mme pour tout le monde.

11.1.1 Impact du mal fini


Ne pas bien mettre en uvre cette pratique a des impacts nfastes sur les sprints venir. Les deux impacts les plus reprsentatifs sont la dcouverte de bugs, quil faudra corriger et laccumulation dune dette technique, quil faudra rembourser en payant les intrts.

Bug sur une story


Si la dnition de ni nest pas sufsamment complte ou mal applique, une story quon avait cru nie la n dun sprint peut nalement receler un ou plusieurs bugs qui seront dcouverts dans les sprints suivants. En particulier des lacunes au niveau des tests permettant daccepter la story expliquent la dcouverte ultrieure de bugs. La pratique signication de ni a pour objectif dviter de laisser des bugs sur les stories ralises dans un sprint.

11.1 Fini, une pratique part entire

141

Dette technique
Ward Cunningham est linventeur du terme technical debt1 . Il utilise lanalogie avec la dette nancire pour mettre en vidence que, comme les intrts saccumulent progressivement lorsquon contracte une dette, le cot de dveloppement augmente si le logiciel comporte des imperfections techniques. Chaque minute supplmentaire passe sur du code de mauvaise qualit, cela correspond lintrt de la dette. Les bugs sont visibles des utilisateurs, alors que la dette technique ne lest pas, seuls les dveloppeurs la peroivent. Comme son nom lindique, elle est technique et cela peut avoir de multiples formes : architecture bancale, code mal crit, standard de codage mal suivi, absence de documentation ou manque dautomatisation des tests. La pratique signication de ni a pour objectif de dtecter la prsence dune dette technique et den limiter les effets.

Report la fin de la release


Tout ce qui nest pas ni pendant les sprints, et qui doit cependant tre fait pour que les utilisateurs puissent utiliser le produit, constitue du travail qui devra tre fait dans la priode de temps comprise entre le dernier sprint et la livraison de la release. On comprend bien que la signication de ni a un impact sur ce quil y a faire pendant cette priode : plus il y aura de choses nies pendant les sprints moins il en restera faire. Lidal est de tout faire pendant les sprints et de raccourcir au maximum cette priode. Cela peut ncessiter dajuster la signication de ni au fur et mesure du droulement des sprints.

11.1.2 Intrt davoir une signification de fini partage


Motivation de lquipe Comme cest lquipe qui dcide elle-mme de la

signication de ni, cela contribue la motiver, bien plus que si cela venait du management. Lappropriation collective pousse une application de la pratique. Moins dambigut En labsence de dnition de ni, cest normalement le Product Owner qui dcide, la n du sprint, de ce qui est vraiment ni. Il existe des Product Owners qui, manquant dimplication, ne sont pas assez disponibles pour passer des tests dacceptation et (souvent cause de leur exprience dutilisateurs face des informaticiens) sont mants et ont du mal considrer que quelque chose est vraiment ni. Avoir une dnition labore par toute lquipe vite davoir une trop forte dpendance de la dcision du Product Owner. Plus de qualit, plus de transparence La qualit requise est connue par tous, grce la liste explicite des contrles dnis dans la signication de ni. La transparence fait que le produit partiel est conforme cette dnition.

1. Dans un article publi en 1992 : http://c2.com/doc/oopsla92.html

142

Chapitre 11. La signification de fini

11.2 TAPES
La pratique couvre non seulement la dnition de ce que signie ni mais aussi son application pendant le dveloppement.
Dfinir la signification de fini Utiliser la dfinition de fini

Publier la liste des contrles

Figure 11.2 Les tapes de mise en uvre de la pratique

11.2.1 Dfinir la signification de fini


Toute lquipe est implique : cest normal, cest elle qui appliquera cette dnition. La participation du Product Owner au travail collectif est indispensable et celle des managers est fortement souhaite. La signication de ni est dnie pour la premire fois avant de commencer le premier sprint. Elle est mise jour, si ncessaire, chaque sprint, le plus commode tant de le faire loccasion de la rtrospective.
Release Sprint 1 Sprint 2 Sprint 3 Sprint 4

Premire fois

chaque sprint

Figure 11.3 Moments o lquipe travaille sur la dfinition de la signification de fini

Le premier travail sur la dnition de ni nest pas une runion balise dans Scrum, la faon de procder non plus. Le plus important, cest que ce travail se fasse en quipe : un brainstorming est la formule la plus adapte. Son but est de collecter les ides de chacun pour construire une signication de ni complte et partage. La runion est anime par le ScrumMaster (ou par un consultant externe) qui mne la consolidation partir des ides collectes. En particulier, il doit sassurer que la voix des personnes les plus impliques dans les tests soit entendue : les tests sont au cur de la nition dune story. La dure de la runion varie selon la technique utilise. Daprs mon exprience, la dure moyenne dune sance de travail sur la signication de ni est dune heure et demie.

11.2 tapes

143

Figure 11.4 Collecte des Post-its prparant la consolidation

Lobjectif de la premire runion est dobtenir une liste de contrles qui sappliquent aux user stories. Cette liste sera remise jour chaque sprint.

11.2.2 Publier la liste des contrles


La liste doit tre publie pour tre visible de toute lquipe. Cest un moyen simple de communiquer sur le processus, qui permet tout le monde davoir une comprhension commune de ce que ni signie. Si lquipe dispose dun espace de travail ouvert, la publication prend la forme dune afche colle sur le mur ct du tableau des tches.
Sprint 3 : dbut le 13/9, fin le 27/9 But : blabla
faire
tche tche tche

En cours
tche tche

Fini

Signification de fini
Fini pour une story 1. Lorem ipsum 2. Lorem ipsum 3. Lorem ipsum

story

tche

Fini pour un sprint 1. Lorem ipsum 2. Lorem ipsum

Figure 11.5 La signification de fini sur le tableau mural

144

Chapitre 11. La signification de fini

La liste a galement sa place dans les autres formes de communication utilises par lquipe : site, wiki...

11.2.3 Utiliser la dfinition de fini


La pratique est mise en uvre pendant les travaux du sprint et au cours des runions du crmonial Scrum :
Planication de release La planication de release repose sur le principe

quune story est nie la n dun sprint, cest pourquoi il est prfrable davoir dni au pralable ce que cela signie. En effet, selon la dnition de ni, les estimations peuvent varier. Exemple : il arrive que deux stories qui ncessitent autant de dveloppement soient bien diffrentes sur le travail faire en test. Une estimation faite sans avoir en tte la dnition de ni prcisant le type de tests mettre en uvre peut conduire leur donner la mme taille, tort. Planication de sprint Ce que signie ni a un impact sur les tches du sprint. En effet les travaux induits doivent explicitement gurer dans le plan de sprint. Exemple : si la dnition de ni inclut la rdaction de la documentation utilisateur, il faut une tche pour cela. la n de la runion, quand lquipe sengage pour le primtre dun sprint, elle doit le faire laune de sa dnition de ni, en tant bien consciente des implications de son engagement. Pendant le sprint Pendant le sprint, des contrles sont effectus pour sassurer que la signication de ni est bien applique. En gnral, un contrle est associ une tche et il est effectu la n de la tche. Exemple : si ni inclut la rdaction dun document, la tche pour le rdiger inclut le contrle du document produit. Revue de sprint Lors de la revue de sprint, lquipe ne montre que ce quelle a ni. La dcision de considrer un lment du backlog comme ni dpend videmment de la dnition labore par lquipe. Exemple : si elle inclut la disponibilit dune version en plusieurs langues et qu la n du sprint il nexiste que le franais, llment ne devrait pas tre considr comme ni. Rtrospective La rtrospective est le moment o lquipe sinterroge sur sa faon de travailler. Comme la dnition de ni a un impact sur de nombreuses pratiques, elle constitue la runion idale pour la revoir et si ncessaire lamliorer.

11.3 CONTENU DE FINI


Dans les processus classiques, les livrables attendus pour un jalon sont organiss selon les disciplines du dveloppement. Pour du logiciel, un jalon est associe la liste les

11.3 Contenu de fini

145

documents de conception et de gestion de projet, par exemple, qui doivent tre livrs pour la revue. Avec Scrum, la signication de ni dnit ce qui est attendu pour un sprint. Mais comme un sprint porte sur des stories, le dcoupage nest pas fait sur des disciplines, il est dabord relatif ces stories. Pour quun sprint soit bien ni, il convient que les stories soient nies, cest le premier niveau de la dnition de ni. Le deuxime niveau porte sur ce que doit inclure le sprint en plus des stories qui le composent. Un troisime niveau dcrit ce quon entend par ni la n dune release.
Fini pour une story Les tests passer Les autres contrles relatifs une story Fini pour un sprint Le produit partiel livr dans un environnement de test Les autres contrles la fin du sprint Fini pour une release Ce qui reste faire pour la mise en production

Figure 11.6 Les trois niveaux de la signification de fini

11.3.1 Fini pour une story


Avec une approche simpliste, on pourrait considrer que cest simplement : dmontr avec succs lors de la revue de sprint. Mais ce nest pas sufsant : les tests doivent tre passs, par exemple. Fini pour une story est variable, mais on peut identier des travaux faire absolument et dautres qui sont dpendants du contexte.

Obligatoire
Le minimum, pour une user story, est que ses tests dacceptation1 soient passs avec succs. Sans le passage avec succs de ces tests, une story ne peut pas tre considre comme nie.

Dpendant du contexte
Fini peut aller beaucoup plus loin. Chez un de mes clients, le brainstorming avec lquipe a abouti cette dnition de ni pour une user story :

1. Les tests dacceptation sont prsents dans le chapitre 14 De la story aux tests.

146

Chapitre 11. La signification de fini

code en suivant le standard de codage, les tests unitaires passs, les tests dacceptation passs avec succs dans un environnement de test, la version disponible en franais et en anglais, la documentation marketing rdige, la documentation utilisateur rdige.

Contrle
Les contrles sont effectus pendant le sprint avec lobjectif quils soient tous passs avec succs en n de sprint. Si ce nest pas le cas, la story nest pas nie et sauf drogation dcide par lquipe, elle devra tre reprise dans le prochain sprint.

11.3.2 Fini pour un sprint


la n du sprint, lessentiel est que les stories soient nies. Mais, en plus du contrle sur les stories, la signication de ni pour le sprint porte sur des travaux qui sont transverses, dans la mesure o ils ne sont pas spciques dune story. Ces travaux reviennent chaque sprint, cest pourquoi on peut aussi les qualier de rcurrents.

Obligatoire
Le minimum est quun build contenant le produit partiel soit plac dans un environnement de test.

Dpendant du contexte
Selon le contexte, la signication de ni pour un sprint peut varier normment. Pour certains projets, o la criticit est forte, les besoins en documentation seront importants, pour dautres, comme des projets de recherche, ils seront trs faibles. Pour un dveloppement de logiciel, les rubriques de la signication de ni concourent la qualit. On peut y retrouver des exigences sur le code :
un pourcentage de couverture de tests, un taux de commentaires dans le code, des classes limites en complexit...

Des outils qui mesurent la qualit du code1 permettent de sassurer que ces exigences sont respectes. On peut y retrouver des exigences sur la conception. Cest aussi dans cette rubrique que viennent des exigences, dites non fonctionnelles, en rapport avec le comportement du produit considr comme une bote noire.

1. Comme Sonar, outil Open Source : http://sonar.codehaus.org/

11.4 Guides pour une bonne pratique de fini

147

Exemple : fini pour un sprint peut inclure le passage de tests visant vrifier que les performances spcifies sont bien tenues, par exemple des tests de charge.

Fini pour une story

Tches lies une story

Fini pour un sprint

Tches rcurrentes

Figure 11.7 Impact sur les tches du sprint

Si la signication de ni pour une story permet didentier des tches lies aux stories du sprint, celle de ni pour un sprint facilite lidentication des tches rcurrentes.

Contrle
Mme si les exigences de ni pour un sprint nont pas t respectes, le sprint se termine la date prvue. Mais il faut en tenir compte pour les sprints suivants : cest un point aborder lors de la rtrospective et lquipe devra trouver des solutions concrtes. Ne pas le faire contribuerait alimenter la dette technique, quil faudra rembourser un jour, avec les intrts qui augmentent avec le temps.

11.3.3 Fini pour une release


Cela dpend de ce quon fait du produit la n de la priode de temps que constitue la release. Est-ce quil est mis en production ? Ou est-ce quil va tre mis dans un environnement dintgration ou de pr-production ? Est-ce que des activits de marketing sont raliser ? Quelle que soit la rponse, il est important de dnir ltat du produit pour le jalon que constitue la n de release. Cela permet de savoir, par diffrence avec ni la n dun sprint, ce qui reste faire aprs le dernier sprint.

11.4 GUIDES POUR UNE BONNE PRATIQUE DE FINI


11.4.1 Faire des tranches verticales
Pour que ni pour une story ait un sens, il convient de sassurer que les stories correspondent des tranches verticales, en rfrence aux architectures de logiciel en couches.

148

Chapitre 11. La signification de fini

Une tranche verticale signie que la story part de lutilisateur, traverse toutes les couches pour remonter jusqu lui.
Histoire de couches Un dveloppement commence qui reprend une application existante avec une nouvelle technologie. La premire raction de lquipe, voyant limportance des changements effectuer, est de se consacrer, pour le premier sprint de trois semaines, toute la couche IHM dans sa globalit, cest--dire une tranche horizontale dans une prsentation en couches. Cependant lapproche agile pousse dvelopper les user stories de bout en bout incluant leur IHM, ce qui constitue des tranches verticales. la fin dun sprint, on doit disposer dune version partielle mais fonctionnelle du logiciel. Ne faire que de la conception dIHM au cours du sprint ne rentre pas dans ce schma.

11.4.2 Adapter partir dune dfinition gnrique de fini


Toutes les stories ne sont pas de mme nature : il y en a orientes utilisateur, dautres techniques. La signication de ni nest pas la mme pour ces deux types. Mme pour les user stories, il peut y avoir des variations dans ltat dans lequel on veut la voir la n dun sprint, en fonction du feedback attendu. Cest pourquoi, partir dune dnition gnrique, il peut tre ncessaire de la spcialiser selon les types de stories. Certains proposent mme une spcialisation pour chaque story : la signication de ni devient alors une matrice.
Exemple : lquipe a mis en place une matrice, avec en lignes une liste de contrles possibles sur les stories et en colonnes les stories slectionnes pour le sprint courant. Pour chaque story, une croix dans une ligne signifie que le contrle correspondant est faire. La matrice est dfinie par lquipe en dbut de sprint. Cela va plus loin que la pratique habituelle qui consiste avoir une seule dfinition de fini, valable pour toutes les stories. Cest ce que faisait lquipe avant et cest parce que cela ne marchait pas bien que lquipe a dcid de passer la matrice. Dans lenvironnement, les choses faire pour finir une story sont nombreuses. La matrice comporte une vingtaine de lignes pour des contrles comme : scripts JMeter crits, installation sur le serveur de test, release note rdige, tests de charge, Javadoc crite, modle UML mis jour, pour en citer quelques-uns, en plus des classiques tests unitaires et tests fonctionnels (tests dacceptation associs aux stories) passs avec succs.

Llaboration de cette matrice lors de la runion de planication du sprint facilite lidentication des tches associes aux stories. On pourrait imaginer un outil qui facilite la saisie des contrles appliquer pour chaque story, en propose des tches candidates et permette de cocher les contrles retenus au fur et mesure quils sont vris pour rendre visible ce qui reste contrler sur les stories du sprint. Une autre solution est didentier les contrles spciques faits sur une story comme des conditions de satisfaction de cette story.

11.4 Guides pour une bonne pratique de fini

149

11.4.3 Faire voluer la signification de fini


La signication de ni est susceptible dvoluer pour deux raisons :
Des aspects avaient t oublis et ont t mis en vidence lors de la revue. travers la rtrospective, les pratiques dune quipe voluent rgulirement,

chaque sprint. La signication de ni doit voluer galement pour prendre en compte ces amliorations.

11.4.4 Appliquer la pratique avec beaucoup de volont


Lquipe doit sapproprier cette pratique : pour commencer, cest elle qui dnit ce que signie ni. Mais cest surtout lors des travaux qui se droulent pendant le sprint que son application prend toute son importance. Il ne suft pas de dnir ni, il faut le mettre en uvre, notamment pendant les runions du crmonial.
Planification de release Revue de sprint

S1

Sprint 2

Sprint 3

Sprint 4

Fini Planification de sprint Rtrospective

Figure 11.8 La signification de fini et les moments o lappliquer, montrs sur le sprint 1

Comme lquipe a souvent le nez dans le guidon pendant le sprint, le ScrumMaster joue un rle essentiel dans lapplication de la pratique ni . Cest lui de rappeler rgulirement la dnition labore en commun et de motiver lquipe pour quelle soit respecte.

150

Chapitre 11. La signification de fini

En rsum
La signication de ni est la pratique qui dnit les jalons du processus. Avec Scrum, elle dcrit ltat attendu du produit partiel la n de chaque sprint. Une bonne mise en uvre de cette pratique permet de motiver lquipe, contribue diminuer les mauvaises surprises et amliorer la qualit du produit.

12
Adapter Scrum au contexte

Scrum se prsente comme un cadre pour dvelopper des produits, ce nest pas vraiment une mthode ni un processus complet. Quand on utilise Scrum sur un projet il faut ajouter ce cadre des pratiques complmentaires, variables selon le domaine, et adapter le tout au contexte. Cette adaptation, faite une premire fois au dmarrage avec Scrum, est ritre chaque sprint, lors de chaque rtrospective.

Pratiques dingnierie Cadre Scrum

Contexte projet

Complter

Adapter

Processus du projet
chaque rtrospective

Figure 12.1 Du cadre Scrum au processus dun projet

Comme le rappelle Ken Schwaber dans Flaccid Scrum1 , Scrum ne prtend pas tout prendre en compte et il est naturel de le renforcer avec des pratiques issues dautres domaines, comme la dnition de produit, lingnierie des exigences, la gestion de projet et lingnierie du logiciel.

1. http://www.scrumalliance.org/resources/745

152

Chapitre 12. Adapter Scrum au contexte

Exemple : nous avons vu dans les chapitres prcdents que Scrum ne prconisait pas de faon de faire spcifique pour identifier les lments du backlog, ni pour faire des estimations. Des pratiques complmentaires, habituellement associes Scrum, ont t voques comme celles des user stories pour peupler le backlog et le planning poker pour estimer sa taille.

Cest lobjet de ce chapitre que de prsenter comment Scrum doit tre appliqu en tenant compte des contraintes imposes par le contexte.

12.1 PRATIQUES AGILES


La notion de pratique prend toute son importance avec les mthodes agiles. ct des valeurs et des principes qui sont universels, les pratiques sont le reet de la mise en uvre sur le terrain.
Dfinition Une pratique est une approche concrte et prouve qui permet de rsoudre un ou plusieurs problmes courants ou damliorer la faon de travailler dans un dveloppement. Exemple : la revue de sprint.

Une pratique peut tre adopte ou pas sur un projet. Si elle est adopte, sa mise en uvre peut varier selon un grand nombre de paramtres dpendant du contexte. Les valeurs et les principes sont du niveau de la culture et ne changent pas dun projet lautre, tandis que les pratiques sont leur application dans une situation particulire.

12.1.1 Pratiques Scrum


Dans le cadre offert par Scrum, on peut identier 14 pratiques, qui correspondent grosso modo aux chapitres du livre :
Les rles :

Product Owner ScrumMaster quipe auto-organise


Le crmonial avec les timeboxes :

Sprints et release Planication de release Planication de sprint Scrum quotidien Revue de sprint Rtrospective Signication de ni

12.1 Pratiques agiles

153

Les artefacts :

Backlog de produit Plan de sprint Burndown chart de sprint Burndown chart de release

12.1.2 Pratiques complmentaires


Il existe de nombreuses pratiques utilises dans le cadre de projets se rclamant de lagilit. Leur nombre, la faon de les nommer et leur classication varient selon les auteurs. Il ny a pas de liste ofcielle et certains ont tent de faire une synthse des pratiques. Cest le cas de Jurgen Appelo qui prsente sur son blog1 the big list of Agile practices , labore partir de huit sources diffrentes. La faon dorganiser ces pratiques est trs variable et sujette discussion. La classication peut soprer selon diffrentes caractristiques :
la mthode agile dorigine de la pratique (Scrum, XP, Lean...), le fait quelle soit obligatoire ou optionnelle,

La nature optionnelle dune pratique est un sujet polmique qui divise les experts. propos des pratiques Scrum prsentes, mon opinion est que toutes sont obligatoires, sauf le burndown chart, et que cest la faon de les mettre en uvre qui diffre.
les activits ou disciplines du dveloppement (codage, gestion de projet, test...).

Dans les chapitres suivants nous allons prsenter quelques pratiques qui viennent rgulirement en complment Scrum.

Pour lingnierie des exigences et la dfinition de produit


Quand on utilise Scrum pour dvelopper un nouveau produit, il est ncessaire dy adjoindre des pratiques en amont. Les pratiques de dnition de produit (Product Management) et dingnierie des exigences (Requirements Engineering ) sont importantes, en particulier au dbut dun dveloppement, et facilitent la constitution du backlog. Dans le chapitre De la vision aux stories , nous aborderons les pratiques suivantes :
Construire une vision partage. laborer une liste de features. Identier les rles dutilisateur. Dcomposer en user stories.
1. http://www.noop.nl/2009/04/the-big-list-of-agile-practices.html

154

Chapitre 12. Adapter Scrum au contexte

Pour les tests dacceptation


La signication de ni met en vidence le besoin de passer des tests pendant un sprint pour considrer une story comme nie. Dans le chapitre De la story aux tests , nous verrons comment mettre en uvre la pratique de pilotage par les tests dacceptation.

Pour la gestion de projet


Scrum est une approche trs oriente gestion de projet. La visibilit, linspection et ladaptation constituent une faon nouvelle de contrler et suivre les projets. Cependant, dautres domaines de la gestion de projet ne sont pas abords par Scrum. Quelques pratiques souvent associes Scrum seront prsentes dans le chapitre 15 Estimations, mesures et indicateurs :
Estimer la taille des stories en points. Estimer lutilit des stories. Collecter des mesures. Produire et utiliser des indicateurs agiles.

Ingnierie du logiciel
La plupart du temps Scrum est utilis pour dvelopper du logiciel. Cependant Scrum ne prescrit pas de technique dingnierie particulire, laissant le choix lquipe. Nous verrons dans le chapitre 16 Scrum et lingnierie du logiciel que la plupart sont ncessaires et induites par la signication de ni :
Intgration continue. Pilotage par les tests. Remaniement du code. Programmation en binme. Architecture volutive.

12.2 RISQUES DANS LA MISE EN UVRE DE SCRUM


Une quipe qui passe Scrum doit faire face plusieurs risques.

Risque doublier les pratiques dingnierie


Une quipe qui se contente du cadre Scrum et qui ne met pas en place de pratiques dingnierie pour respecter sa signication de ni (ou qui napplique pas la pratique signication de ni ) va se heurter rapidement des difcults. Scrum permet de les rvler mais cest lquipe de faire les efforts pour trouver des solutions.

12.3 Dfinir le contexte

155

Risque de perdre le contexte sans adaptation


En appliquant une pratique strictement, comme on la compris en lisant des livres ou partir dune exprience qui a t raconte, on risque de se couper de lenvironnement actuel de lorganisation. Ce nest pas parce quune pratique a fonctionn ailleurs quelle marchera lidentique dans un contexte diffrent. Voici un exemple quon ma racont, anecdotique mais caricatural de la copie dune pratique sans adaptation au contexte. Une quipe est distribue sur plusieurs sites en France et aux tats-Unis et les runions se tiennent donc en utilisant un systme de vidoconfrence. Un participant au premier scrum quotidien, probablement marqu par le ct standup du scrum, demande sil faut rester debout...

Risque dadapter sans discernement


Certaines quipes pensent appliquer Scrum, mais nutilisent que des bribes de lensemble des pratiques. Partant du principe que Scrum sadapte, elles nen prennent que ce qui les arrange ou uniquement ce quelles ont compris dun apprentissage trop rapide. Je rencontre souvent des quipes qui ont dmarr Scrum depuis quelques mois, sans formation ni assistance, et qui nont conserv que le scrum quotidien et des sprints dun mois. Elles sont un peu perdues et mappellent pour les aider sy retrouver dans les pratiques mettre en uvre sur leur projet. Ken Schwaber dnit de la faon suivante la possibilit dadaptation de Scrum : Lquipe suit strictement les rgles Scrum, jusqu ce que le ScrumMaster considre que lquipe est sufsamment aguerrie. Dans ce cas il peut proposer des adaptations lquipe. Il faut bien dire que les rgles dont parle Ken Schwaber ne sont pas toutes des rgles quon peut vrier mais plutt des recommandations, ce qui laisse une grande part dinterprtation. Ce qui est sr, cest quune adaptation sans discernement est dangereuse : les quipes qui nont pas le recul sufsant risquent dchouer. La plupart des pratiques sont utiles pour la plupart des projets, mais elles ne sappliquent pas partout de la mme faon et leur application volue dans le temps. Pour en savoir plus sur leur application, il faut commencer par dnir le contexte des organisations et des projets.

12.3 DFINIR LE CONTEXTE


Un projet de dveloppement de logiciel sinscrit dans le contexte dune organisation. Celle-ci possde un environnement qui inue sur les caractristiques des projets qui y sont lancs et dvelopps. Les attributs relatifs la situation dun projet permettent de dnir la faon dont les pratiques agiles peuvent y tre appliques. Cest lagilit

156

Chapitre 12. Adapter Scrum au contexte

en situation1 , titre de la prsentation de Philippe Kruchten et Claude Aubry, lors de lAgile Tour 2008, sur laquelle sappuie la notion de contexte.
Environnement de l'organisation Direction et contraintes Contexte du projet

Figure 12.2 Linfluence de lorganisation sur les projets

12.3.1 Influence de lorganisation


Une organisation possde une culture, un savoir-faire, bref des conditions qui ont une inuence sur les projets qui vont appliquer Scrum et lagilit. Il est bien vident que lapplication sera plus difcile dans une entreprise qui a des valeurs et des principes loigns de ceux dnis par le Manifeste agile. On peut relever quelques attributs qui permettent de situer une organisation par rapport lagilit :
Niveau dinnovation : les entreprises qui dveloppent des produits innovants

seront dans un contexte plus favorable que celles qui font des applications plus classiques. Culture : si la faon de partager un modle mental, de communiquer et de collaborer est base sur la conance entre les gens, cela facilitera une bonne mise en uvre des pratiques agiles. Domaine mtier : il existe de nombreux domaines bien diffrents qui ont une inuence sur les caractristiques des projets. Par exemple, dans le domaine de laronautique embarque, la criticit des applications fera que la mise en uvre de Scrum demandera plus defforts que dans le cas dune application web. Niveau de maturit : lexprience en ingnierie du logiciel est trs diffrente selon les organisations. Une bonne comptence des personnes dans les pratiques dingnierie facilite la transition Scrum. Les projets qui sont mens dans une organisation sont inuencs par sa situation, mais pas forcment tous de la mme faon : les entreprises ont de plus en plus une grande htrognit dans leurs projets, cest pourquoi il convient avant tout de dnir le contexte du projet qui va utiliser Scrum.

1. http://www.sigmat.fr/dotclear/index.php?post/2008/10/17/L-Agilite-en-situation-lapresentation

12.3 Dfinir le contexte

157

12.3.2 Contexte du projet


Les attributs de contexte permettent de caractriser un projet, la gure 12.3 prsente un exemple de dix attributs signicatifs.

Taille Type de gouvernance Capacit en ingnierie

Modle conomique

Dispersion gographique

Stabilit de larchitecture

Taux de changements

ge du systme Dploiement

Criticit

Figure 12.3 Les attributs dfinissant le contexte dun projet

Attributs relatifs lquipe

Taille : le nombre de personnes dans lquipe dveloppant le produit. La taille de lquipe est reprsentative de la taille du projet, comme le sont aussi le budget ou la taille du code. Capacit en ingnierie : le niveau des personnes de lquipe dans les pratiques dingnierie de logiciel, qui est une combinaison de la formation et de lexprience. Dispersion gographique : le nombre de bureaux diffrents accueillant les personnes de lquipe.
Attributs relatifs la nature du produit Ces attributs dpendent essentielle-

ment du domaine mtier dans lequel se situe le produit dvelopp. Taux de changements : la frquence des changements sur le produit, propos de sa technologie ou des besoins des utilisateurs. Criticit : lenjeu humain ou conomique en cas de dfaillance du logiciel. Dploiement : le nombre dinstances du produit nal.

158

Chapitre 12. Adapter Scrum au contexte

Attributs relatifs ltat du logiciel

ge du systme : la quantit de code dj existant quincorpore le logiciel dvelopper. Stabilit de larchitecture : le degr selon lequel on peut ajouter des user stories au logiciel existant sans revoir larchitecture.
Attributs lis lorganisation de dveloppement

Modle conomique : projet open source, projet interne, projet sous-trait au forfait, logiciel commercial... Type de gouvernance : les contraintes imposes par lorganisation sur le cycle de vie et le reporting .

12.4 IMPACT DU CONTEXTE SUR LES PRATIQUES


12.4.1 Impact par attribut
Taux de changement
Un taux de changement lev est souvent le facteur qui va dclencher le passage lagilit. Dans lesprit des personnes, il y a souvent lide : on ne sait pas vraiment ce quon veut et on est srs que a va changer, alors comme lapproche traditionnelle ne marche pas, essayons une mthode agile . Au-del de cet effet dclencheur, un taux de changement lev aura un impact sur quelques pratiques, sans demander defforts supplmentaires pour leur mise en uvre :
Les sprints seront plus courts pour incorporer rapidement les changements. Limplication du Product Owner doit tre trs forte pour dnir les priorits

dans le backlog de produit.


La planication de release doit tre rvise rgulirement pour reter des

changements. Le burndown chart de release ne sera pas sufsant et devra tre complt par un indicateur (comme le burnup1) faisant apparatre lvolution de primtre. Au contraire, si les besoins sont stables et larchitecture matrise, les quipes seront peut-tre moins enclines passer lagilit ou relaxer des rgles. Mais un faible taux de changement nempche pas dutiliser les pratiques.

Criticit
Lorsque le produit dvelopp possde une criticit leve, la conformit des normes doit tre prouve, par lutilisation de mthodes formelles, par des tests intensifs ou par des audits externes.

1. Voir le chapitre 15 Estimations, mesures et indicateurs agiles

12.4 Impact du contexte sur les pratiques

159

Une criticit leve a un impact sur :


Les pratiques de test qui devront tre pousses (pour tre conforme aux normes

du domaine).
Le backlog qui demandera tre complt avec de la documentation, et la mise

en place dune traabilit explicite sur les exigences.


Le rythme des sprints, qui peut tre perturb par les audits qui ont un rythme

diffrent. Le rle de Product Owner : il risque dtre difcile pour une seule personne de bien connatre la fois les normes respecter et les fonctions attendues et de dnir les priorits.

Taille de lquipe
Si le dveloppement du produit implique un grand nombre de personnes, cela affecte :
La constitution des quipes, puisquil faudra organiser lquipe globale en

plusieurs sous-quipes, la taille dune quipe Scrum tant limite une dizaine de personnes. La dure des sprints, qui sera plus longue pour synchroniser les travaux des diffrentes quipes. Le mode de communication qui ncessitera plus de formalisme et de documentation. Le rle de Product Owner pour dnir et mettre en place son interaction avec les diffrentes quipes Scrum. Le droulement du crmonial qui devra tre adapt au fonctionnement multiquipes, pour rendre possible la participation de personnes aux runions de diffrentes quipes.

Dispersion de lquipe
La distribution gographique rend toutes les pratiques plus difciles appliquer et plus susceptibles dchouer. La dispersion dune quipe affecte lourdement le droulement du crmonial Scrum. Toutes les pratiques sont adapter cette situation, en gnral par une utilisation massive doutils permettant la collaboration distance. Cela ninterdit pas ces quipes dutiliser Scrum : il serait dommage de priver de nombreux des projets de ses bienfaits. Dans Succeeding with Agile1 , Mike Cohn prsente, dans un chapitre ddi, les faons dadapter les pratiques Scrum dans le cas dquipes rparties sur plusieurs sites.

1. http://mikecohnsignatureseries.com/books/succeeding-with-agile, chapitre 18.

160

Chapitre 12. Adapter Scrum au contexte

Figure 12.4 Une quipe Scrum coupe en deux aura plus de difficults

Capacit en ingnierie de lquipe


Une quipe Scrum doit couvrir, avec lensemble de ses membres, toutes les activits ncessaires pour obtenir un produit la n dun sprint : elle est dite multifonctionnelle. Une quipe qui ne possde pas assez de comptences techniques en ingnierie de logiciel1 , cela a des impacts ngatifs sur la gestion du projet et la qualit du produit. Si la capacit de lquipe en ingnierie nest pas sufsante, sa mise niveau est la priorit, par des actions de formation ou daccompagnement des membres de lquipe.

ge du systme
Il est plus facile de mettre en uvre Scrum sur un logiciel nouveau. Si le produit incorpore des parties de code existant (legacy), il faut vivre avec ce code qui est de plus ou moins bonne qualit :
Les pratiques de test sont impactes : se pose la question des tests sur le code

ancien (rgression et automatisation). La dcouverte de bugs sur cette partie existante risque de perturber le droulement des sprints. La gestion des priorits dans le backlog demande des arbitrages incessants entre les bugs, la rsorption de la dette technique et les nouveauts fonctionnelles.

1. Les pratiques dingnierie du logiciel sont prsentes au chapitre 16.

12.4 Impact du contexte sur les pratiques

161

Stabilit de larchitecture
Si larchitecture dun logiciel est stable, le backlog comportera essentiellement des user stories qui pourront tre dveloppes sans modication importante de la structure du logiciel. Si ce nest pas le cas, il sera ncessaire dinclure de nombreuses stories techniques pour stabiliser larchitecture et les pratiques suivantes peuvent tre impactes :
Les sprints, dont la dure devra tenir compte de la longueur des travaux

techniques. La gestion des priorits dans le backlog, qui demandera de convaincre le Product Owner de limportance des stories techniques, alors quelles napportent pas de valeur visible.

Modle conomique
La faon dont le budget pour le dveloppement est obtenu (ou les ressources dans le cas dun projet Open Source) inue sur les pratiques. Par exemple, un dveloppement ralis par un contrat au forfait entre un donneur dordre et une SSII complique la mise en uvre de plusieurs pratiques :
La personne qui tient le rle de Product Owner devrait tre ct donneur dordre

et intgre lquipe, ce qui est souvent difcile.


La planication de release, avec les estimations faites par lquipe qui ncessitent

davoir acquis la conance entre le donneur dordre et le prestataire. Le suivi du projet du point de vue conomique, qui demande tous les partenaires de se mettre daccord sur les nouveaux indicateurs agiles utiliser.

Type de dploiement
Le nombre dinstances dployes varie entre un et des millions selon les applications. Dans le cas de lhbergement en ligne, appel SaaS (Software as a Service), le dploiement est matris par lorganisation, qui peut le faire trs frquemment. Un dploiement frquent a un impact sur :
Les sprints, qui peuvent tre trs courts. La signication de ni. Lautomatisation des tests.

linverse, un dploiement du logiciel sur des dispositifs diffuss des milliers dexemplaires (comme dans le domaine de la tlphonie ou celui des jeux vido), rend les mises jour difciles, et trs coteuses dans certains cas, ce qui oblige avoir des tests trs pousss en interne.

Type de gouvernance
En France, les administrations et les grandes entreprises ont une faon de gouverner les projets qui est souvent hrite de Merise dans le domaine tertiaire et du GAM T17

162

Chapitre 12. Adapter Scrum au contexte

dans le domaine industriel. Bien sr, chacune a ensuite fait ses adaptations ces cadres, mais le rsultat en matire de gouvernance ne donne pas, en gnral, dans la lgret. Ces structures se lancent maintenant dans lagilit, mais leur type de gouvernance a un impact sur les pratiques agiles, notamment :
Lautonomie de lquipe nest pas facile obtenir dans un environnement trs

hirarchique. La faon de faire le planning et du reporting avec Scrum, quil faut faire cohabiter avec les pratiques traditionnelles (comme les comits de pilotage), au moins un certain temps. Les relations du projet agile avec les autres services, en particulier celui qui soccupe dinfrastructure, ncessitent de faire de la planication prvoyant les points de synchronisation lavance.

12.4.2 Situation dun projet par rapport lagilit


Lexamen des attributs du projet permet de dnir les pratiques adapter. Une reprsentation synthtique donne une ide de leffort ncessaire pour ladaptation.
Taille
10 9

Age systme

8 7 6 5 4 3

Criticit

Dploiement

2 1 0

Modle conomique

Capacit quipe

Stabilit architecture

Gouvernance

Dispersion quipe

Peu d'efforts

Plus d'efforts

Figure 12.5 Profil pour ladaptation lagilit Les projets qui demandent le moins defforts sont au centre.

Attention : cest relatif ! Un changement de processus, comme lest un passage lagilit, demande toujours de nombreux efforts.

Un projet typique pour un passage Scrum sans beaucoup dadaptations a les attributs suivants :
Une quipe de sept personnes, toutes dans le mme bureau. Un logiciel nouveau avec une architecture connue.

12.4 Impact du contexte sur les pratiques

163

Un produit qui nest pas critique. Un dveloppement fait en interne avec dans lquipe de bonnes comptences

techniques. Une gouvernance accommodante. De nombreux projets se situent dans ce cur de cible de lagilit. Mais il en existe beaucoup dautres qui sont dans une situation demandant plus defforts lors de lintroduction de Scrum.

Figure 12.6 Le projet B demande plus defforts pour appliquer Scrum

Les attributs dnissant le contexte voluent dans le temps. Aprs quelques mois, certains devraient se rapprocher du centre, comme la gouvernance, mais dautres peuvent sen loigner, comme la taille de lquipe si le projet grandit. Cest pourquoi lanalyse du contexte devrait tre mise jour chaque nouvelle release.

En rsum
Scrum ne se vend pas en pack de 6. Slection et adaptation des pratiques sont les deux mamelles de son application sur un projet.

13
De la vision aux stories

Quand on est dans les starting-blocks, il est tentant de partir vite et fond, mais il y a des risques de faire un faux dpart. Les sprints avec Scrum, a se prpare et nous avons vu quil y avait une priode particulire avant de commencer le premier. Cest de cette priode pour le dveloppement dun nouveau produit dont il est question dans ce chapitre. Les pratiques prsentes sont mises en uvre au dbut dun projet, mais gardent de limportance pendant tout le dveloppement.

13.1 LE PRODUIT A UNE VIE AVANT LES SPRINTS


Jai dj voqu quelques-unes des activits mener, juste avant le premier sprint, avec la planication de release. Elles ncessitent de disposer dun backlog de produit, mais comment, partir de lide initiale, arriver au backlog nest pas dans la vise de Scrum. Mme si Ken Schwaber voque la notion de vision, il ne la dveloppe pas et dit clairement que Scrum naborde pas les pratiques de gestion de produit et aborde peu celles dingnierie des exigences. Donc, la voix ofcielle de Scrum considre que la faon de drouler la phase amont est en dehors du cadre et suggre dassocier Scrum des pratiques complmentaires. Dans la suite de ce chapitre, nous allons aborder les pratiques prsentes gure 13.1.

Construire une bonne vision

Lister les features du produit

Identifier les rles dutilisateur

Dcomposer en user stories

Figure 13.1 Les pratiques permettant la constitution du backlog initial

166

Chapitre 13. De la vision aux stories

Ces pratiques visent dmarrer le premier sprint dans de bonnes conditions. Nous avons vu quil fallait un backlog estim et prioris1 . Pour obtenir ce backlog, il est ncessaire davoir une bonne vision sur le produit, didentier les features et les rles et de dcomposer les features en stories.

13.2 CONSTRUIRE UNE BONNE VISION


Dans Scrum la notion de produit est essentielle : on parle de backlog de produit et de produit partiel la n dun sprint, par exemple. La vision du produit futur permet de prparer son dveloppement. Tous les produits ont besoin dune vision : cela guide les personnes qui participent au dveloppement vers un objectif partag. Une vision est lexpression dune volont collective de dvelopper un excellent produit. Labsence de vision limite la capacit sinvestir dans un projet.

13.2.1 Techniques pour la vision


La meilleure faon dobtenir une bonne vision est de procder par des sances de travail en groupe. Un brainstorming collectif permet lquipe dobtenir rapidement des parties de la vision, comme la formulation du problme et la position du produit2 .

nonc du problme
Le vrai problme lorigine du produit, doit tre clairement identi. On peut utiliser la technique cause-effet, connue par son rsultat montr avec un diagramme en arte de poisson3 . Une technique plus simple consiste noncer le problme dans un tableau (tableau 13.1).
Tableau 13.1 Le problme de affecte Il en rsulte Une solution russie permettrait de [dcrire le problme] [les intervenants affects par le problme] [quel est limpact du problme] [donner quelques bnfices]

Le but de ce tableau synthtique est de forcer lquipe laborer une formulation concrte du problme.

1. Voir les chapitres 5 Le backlog de produit et 6 La planication de la release. 2. Un exemple utilisant les diffrentes pratiques prsentes est fourni dans le chapitre 17 Scrum avec un outil. 3. http://fr.wikipedia.org/wiki/Diagramme_d%27Ishikawa

13.2 Construire une bonne vision

167

Position du produit
La position choisie pour le produit est dcrite au plus haut niveau possible. Une technique possible, venant du marketing, est le test de lascenseur ou lElevator Statement (Moore 1991) rsume par le tableau 13.2.
Tableau 13.2 Pour Qui <nom du produit> Qui permet la diffrence de Notre produit [Public concern par loutil] [Leur rle gnral] [Ce que cest (outil, systme, application...)] [Utilit] [Pratique actuelle, concurrence] [Ce quil permet de faire]

La position du produit est prsente en six points et constitue un rsum permettant de comprendre rapidement quelle est la solution propose. Le nom vient de lide quune position, destine convaincre son chef, doit tre exprime pendant le temps que prend un voyage en ascenseur avec lui.

13.2.2 Qualits dune bonne vision


La vision permet de mobiliser lquipe vers lobjectif en sappuyant sur lintrt du produit mais aussi sur des dimensions culturelles, psychologiques, voire thiques. Le choix dpend de la culture de lorganisation et de limpact quaura le produit attendu. La vision doit tre ambitieuse pour entraner les nergies et donner un lan, tout en restant raliste : ce nest pas une hallucination. Une bonne vision reprend ladage de Scrum, lart du possible. La vision est partage avec toutes les personnes intresses dans le produit. Elle fait la synthse entre les diffrents points de vue et fournit le contexte pour tout le monde. Elle prsente la stratgie moyen terme, pour quelques mois. Si le plan de release change rgulirement, la vision, elle, devrait rester stable. La vision snonce avec un langage simple et elle est courte : pour que la vision soit lue et partage il faut quelle soit bien rsume et bien crite. Elle se concrtise par un document court de quelques pages, certains la font mme tenir en une seule page. La vision peut aussi prendre la forme de tableaux ou de rubriques dun wiki. Une personne qui arrive dans le projet se doit de commencer par la dcouverte de la vision, cest aussi le premier document lu par quelquun qui sintresse au produit.

13.2.3 Une vision par release


Au dbut du dveloppement dun nouveau produit, on ne se pose pas de question : la vision dcrit le produit. Le dveloppement se faisant par des releases successives, doit-on remettre jour la vision pour chaque release ? Cest ce que jai longtemps fait en ayant une vision unique pour le produit, en ladaptant chaque nouvelle release. Le problme est quon sy perd entre la vision

168

Chapitre 13. De la vision aux stories

de tout le produit et le delta entre deux versions. Un autre problme est de savoir jusquo porte la vision, quel horizon. Un horizon trop lointain risque de donner la vision trop dinstabilit. Cest pourquoi maintenant, je prconise dassocier une vision une release. Pour chaque nouvelle release, une nouvelle vision : celle du produit moyen terme, dni par lhorizon de quelques mois correspondant la release.

13.3 FEATURES
On peut essayer didentier les lments dtaills du backlog. En trouver plusieurs centaines, puis essayer de les ordonner par priorit. Une approche plus efcace consiste dnir une vision du produit, puis sintresser aux features : entre la vision, gnrale, et le backlog avec ses stories, dtailles pour les sprints, un niveau intermdiaire est ncessaire.

13.3.1 Justification du terme feature


Dans la littrature relative lingnierie des exigences (agile ou pas), on trouve, en anglais, de nombreux termes pour qualier des lments plus gros que des stories : themes, epics, features, minimal marketable features (MMF). Aprs la lecture de User stories applied de Mike Cohn, jai utilis un temps theme et epic. Un theme est une collection de stories. Une epic est une grosse story. Je me base maintenant sur le modle qui me parat le plus abouti, celui de Dean Lefngwell, rsum dans the Big picture for the agile entreprise 1 . Il utilise quatre niveaux : strategic theme, epic, feature et story. Les deux premiers concernent la vision dentreprise et sont hors du primtre de mon propos qui porte sur la vision dun produit. Le terme features est abondamment utilis dans le domaine de lingnierie des exigences. Il y a mme une ancienne mthode qui lutilise dans son nom : Feature driven development ou FDD et on retrouve le terme feature dans les visions du RUP (Rational Unied Process). Je lai traduit pendant plusieurs annes par fonctionnalit essentielle. Mais cest un peu long et dsormais je conserve langlais feature (on prononce tcheur ). En fait peu importe les noms, ce qui compte cest de sy retrouver.
Dfinition Une feature est un service fourni par le systme, observable de lextrieur, qui rpond un besoin, et dont la description se situe un niveau tel que toutes les parties prenantes comprennent facilement ce dont il sagit.

1. http://scalingsoftwareagility.wordpress.com/2009/08/17/new-whitepaper-the-big-picture-ofenterprise-agility/

13.3 Features

169

13.3.2 Identification des features


Lidentication des features est faite, de prfrence, par des ateliers de travail en groupe, auxquels participent les membres de lquipe Scrum (si elle est constitue), et les personnes impliques dans le produit. Latelier a un ct ludique. Il favorise les changes, les arbitrages, la leve de certaines incomprhensions. Le format oblige les participants aller lessentiel, prioriser1 .. Les ateliers que jutilise pendant mes formations et sur les projets de mes clients, comme bote du produit, souvenir du futur2 , bote du produit, arbre des features, permettent lquipe didentier une liste de features initiale de bonne qualit et partage par tous.

Figure 13.2 Le Product Owner lors de latelier bote du produit .

Les ateliers sous forme de jeu permettent de canaliser la crativit pour une meilleure dnition dun produit. On trouvera de nombreux projets sur le site Innovation Games3.
1. http://www.qualitystreet.fr/2009/07/29/la-vision-du-produit/ 2. http://www.aubryconseil.com/post/2007/10/29/320-souvenir-du-futur 3. http://innovationgames.com/

170

Chapitre 13. De la vision aux stories

13.3.3 Attributs dune feature


Une feature peut possder les attributs suivants :
Nom. Description. Valeur ajoute (ou utilit) de la feature. Stories lies (ajoutes quand la feature est dcompose en stories). Taille (gnralement obtenue en faisant la somme des estimations de taille des

stories lies).

13.3.4 Features et backlog


Les features servent notamment amorcer le backlog. La dmarche pour obtenir le backlog initial dun nouveau produit consiste en :
identier les features pour en obtenir de 5 20, les consolider de faon constituer des domaines fonctionnels indpendants, dcider des priorits entre les features, par exemple par une session de priority

poker, prsent ci-dessous,


pour les deux ou trois features les plus prioritaires, dcomposer en stories, qui

sont places dans le backlog initial.

13.3.5 Features et priorit


La valeur dune feature, cest ce quelle rapporte lorganisation, son utilit. Cest un des facteurs utiliss pour dterminer la priorit dans le backlog. Il est extrmement difcile dvaluer la valeur nancire (en euros) dune feature. En particulier sil ne sagit pas dun produit commercial, il vaut mieux parler dutilit. Cest aussi une responsabilit quil est difcile dexercer en solitaire si on la laisse au Product Owner. Cest pourquoi il est plus efcace dorganiser une runion sous forme datelier et estimer lutilit des features de faon relative, sans unit. Latelier peut se drouler de diffrentes faons en utilisant diffrentes techniques. Voici un exemple de ce qui se pratique le plus souvent et qui est appel priority poker :
chaque participant reoit un lot de neuf cartes numrotes de 1 9 (on peut

aussi utiliser les cartes du Planning Poker), chaque feature est tudie successivement, le premier vote porte sur lintrt davoir la feature, chaque participant vote avec une carte, on fait le total des points, le deuxime vote porte sur la pnalit relative de ne pas avoir la feature dans le produit, chaque participant vote galement de 1 9, on dnit limportance des deux votes, par exemple on peut donner un poids de 3 au premier et le poids 1 au second, en faisant la somme des deux votes pondrs, on obtient lutilit de llment.

13.4 Rles dutilisateurs

171

Pour obtenir lutilit relative, il faut rapporter cette utilit au total de lensemble des lments, et la priorit dun lment sobtient en divisant lutilit relative par le cot relatif. Ce genre datelier de travail en groupe permet dtablir une premire liste de priorits au dmarrage dun projet. Et comme souvent dans les runions, le bnce qui en est tir vient aussi de la richesse des discussions entre les participants. Le premier backlog de produit est constitu par les features, ordonnes par priorit.

13.4 RLES DUTILISATEURS


Un produit est destin des utilisateurs. La dnition des rles dutilisateurs permet davoir une meilleure connaissance des usages quils pourront faire du produit et den tenir compte pour identier les features et les stories.

13.4.1 Intrt des rles


La dcouverte des user stories, comme dailleurs celle des cas dutilisation ou de toute autre technique, se fait en rchissant ce quattendent les utilisateurs du logiciel. Il faut donc commencer par identier ces utilisateurs, au sens large, du logiciel. Les cas dutilisation utilisent le terme acteur, pour les stories on parle de rle ou de type de rle ou encore de rle dutilisateur. Il faut tre vigilant pour ne pas passer ct de certains rles, ce qui induirait probablement loubli de stories importantes. Jai fait lexprience avec deux quipes dtudiants qui jai demand didentier des stories pour une application web. Pour une quipe je ne leur avais pas demand de rchir dabord cette notion de rle et pour lautre quipe, javais exig une liste de rles en premier. Dans la premire quipe, je nai retrouv que des stories lies lutilisateur principal, tandis que lautre, partir dune liste de cinq rles, a identi bien dautres stories. Il ne faut pas en rester un seul rle quon appelle utilisateur, ce nest pas assez prcis, cela va conner la rexion un seul point de vue. Le risque est doublier des stories et de faire que celles quon propose ne seront pas assez spciques du problme. Les spcialistes des IHM, les ergonomes, les marketeurs du web le savent bien, il faut aller plus loin et penser aux usages.

172

Chapitre 13. De la vision aux stories

13.4.2 Identification des rles


Pour identier les rles, on peut sinspirer des questions suivantes :
qui fournira, utilisera ou supprimera les informations de lapplication ? qui utilisera le logiciel ? qui est intress par une fonction ou un service propos ? qui assurera le support et la maintenance du systme ? avec quels autres systmes doit interagir le logiciel dvelopper ?

Ces questions axes sur le logiciel en dveloppement peuvent aider dmarrer la collecte des rles. Dans un esprit de travail collectif, recommand par les mthodes agiles, il est souhaitable de faire un atelier pour identier tous les rles potentiels, puis de les regrouper. Pratiqu juste aprs latelier features, un atelier rles permet dy procder en une heure environ. Pour certains types de logiciel, comme le logiciel embarqu, la collecte des rles est difcile, puisquil ny a pas vraiment dutilisateurs en relation directe. Latelier nen est pas moins utile pour identier les utilisateurs plus loigns et les interfaces du logiciel. Pour complter la liste, on peut rchir aux personnes mal intentionnes qui chercheront proter abusivement du logiciel, par exemple les trolls et les spammeurs, car il faudra probablement ajouter des stories spcialement pour les empcher.

13.4.3 Attributs dun rle


Un rle peut possder les attributs suivants :
Nom. Description du rle. Sa frquence dutilisation du produit. Son niveau en utilisation des applications informatiques. Le nombre de personnes ayant ce rle pour le produit nal. Ses critres de satisfaction dans lutilisation du produit.

13.4.4 Personas
Pour afner cette notion de rle utilisateur et bncier de la valeur ajoute dune conception centre usage, la mthode des personas est particulirement efcace.

13.5 User Stories

173

Voil ce quen dit Jean-Claude Grosjean1 , ergonome agile : Un persona, cest un utilisateur-type, une reprsentation ctive des utilisateurs cibles, quon peut utiliser pour xer des priorits et guider nos dcisions de conception dinterface. Cette mthode, invente par Alan Cooper en 1999 dans son best-seller "The Inmates Are Running the Asylum", permet doffrir une vision commune et partage par lquipe des utilisateurs dun produit, en insistant sur leurs buts, leurs attentes et leurs freins potentiels, et en proposant un format des plus engageants. Les Personas suscitent en effet de lempathie, un vritable investissement motionnel : ils prennent trs vite une place de choix sur le panneau dafchage de lquipe. Les rles utilisateurs adoptent volontairement un format trs synthtique, et restent avant tout sur la relation utilisateur/systme : ni lments ctifs, ni scnario, ni travail denqute. La technique des Personas va donc plus loin...elle est aussi plus contraignante. Cest une dmarche avant tout collaborative : les Personas se construisent collectivement au cours de plusieurs ateliers de travail. Cette construction doit imprativement sappuyer sur des donnes issues dentretiens (partie prenantes et futurs utilisateurs), voire de lobservation des cibles et sur lpluchage de diverses sources (support, presse, tudes externes, concurrence...) : cest la spcicit et la force de la mthode ! Quelques conseils :
Mobiliser lquipe autour de la dmarche. Limiter le nombre de Personas. Dnir idalement un (deux au maximum) Persona primaire : la cible principale du

futur produit. Donner vie vos Personas en crant des ches contenant au minimum les lments suivants sans pour autant tomber dans les strotypes: prnom, titre/rle, scnario (le storytelling qui permet de bien rentrer dans la vie du personnage), photo, buts, dclencheurs, freins, features attendues. tre vigilant sur le choix de la photo : viter les clbrits, les proches ou les visages trop parfaits. Votre Persona doit tre crdible. Communiquer sur vos Personas. La technique des personas peut tre employe en complment avec Scrum, couple des enqutes sur les comportements, notamment pour les applications web.

13.5 USER STORIES


13.5.1 Dfinition
La notion provient dExtreme Programming : une user story y est dnie comme un rappel pour tenir une conversation qui existe dans le but de faciliter la planication.

1. http://www.qualitystreet.fr/

174

Chapitre 13. De la vision aux stories

Cela montre bien quune story doit raconter quelque chose. Ron Jeffries1 dnit trois composants pour une story :
Une carte pour enregistrer son titre. Une conversation pour la raconter. Une conrmation pour sassurer quelle est nie, ce qui nest pas le plus facile.

Pas du tout les mmes objectifs que le storytelling utilis en marketing et en politique ! Plus simplement on peut dire quune user story est un morceau fonctionnel qui apporte de la valeur et qui pourra tre dvelopp en un sprint.

13.5.2 Identifier les stories


Le travail de dcomposition des features en stories se fait, de prfrence, dans un atelier auquel participe toute lquipe. Cet atelier utilise la liste des features et la liste des rles. On part de la feature la plus prioritaire pour la dcomposer en stories dont chacune est enregistre sur un Post-it, ainsi que le rle dutilisateur. Un atelier permet didentier quelques dizaines de stories en une session de travail collective de deux trois heures. la n de la runion, les stories pourront tre introduites dans le backlog de produit.

13.5.3 Attributs dune story


Utilisation du plan type
Mike Cohn, auteur de livre User Stories Applied, prconise lemploi de la formulation suivante : As a <type of user>, I want <some goal> so that <some reason> (En tant que <rle dutilisateur>, je veux <un but> an de <une justication>) La partie justication est optionnelle, parce quelle est parfois vidente.
Exemples
En tant qutudiant, je veux minscrire une formation afin dobtenir le diplme. En tant que voyageur je veux rserver un billet de train. En tant quoprateur je veux crer un compte pour un client afin de recevoir son argent. En tant quorganisateur, je veux connatre le nombre de personnes inscrites la confrence afin de choisir la salle adquate.

1. Larticle 3C de Ron Jeffries a t traduit en franais par Fabrice Aimetti ; il est disponible sur son blog www.fabrice-aimetti.fr.

13.5 User Stories

175

Un outil aide la formulation, par exemple avec trois attributs identis pour le rle, lexigence et la justication :
Rle : organisateur But fonctionnel : connatre le nombre dinscrits Justication : savoir si la salle aura la bonne capacit.

Ce plan type permet de se concentrer sur lutilit apporte par une story un utilisateur.

Autres attributs dune story La frquence dutilisation de la story par le rle. Une story utilise plusieurs fois par jour devra probablement subir plus de tests quune autre utilise une fois par an. Des informations complmentaires sur la story. Cela peut-tre du texte ou un schma utile lquipe pour le dveloppement, comme un diagramme de squence UML. Les tests1 associs la story.

13.5.4 Techniques de dcomposition des stories


Pour tre sufsamment petites et nies en un sprint, les stories doivent tre dcomposes. Il existe plusieurs techniques pour cela :

Dcomposition par les donnes


Exemple avec la story En tant quoprateur je cre un compte Sil existe plusieurs types de compte et que la faon de crer les comptes nest pas la mme pour tous, il faudra crer autant de stories quil y a de types de compte :
-- En tant que oprateur je cre un compte espces -- En tant que oprateur je cre un compte titres

Dcomposition selon les actions


Exemple : sil existe plusieurs oprations sur un compte, il faudra crer autant de stories quil y a doprations ayant un comportement diffrent :
-- En tant que oprateur je cre un compte espces -- En tant que oprateur je bloque un compte espces...

Une story prte tre dveloppe dans un sprint est petite : en moyenne, elle est ralise en trois jours, tout compris (selon la signication de ni).

1. Voir le chapitre 14 De la story aux tests dacceptation

176

Chapitre 13. De la vision aux stories

Lintrt des petites stories est double :


les tests sont plus faciles identier, cela apporte plus de exibilit dans la planication car les stories dcomposes

peuvent tre planies dans des sprints diffrents.

13.5.5 Diffrence avec les use-cases


la diffrence des use-cases, la technique des user stories nest pas une technique de spcication. Elle repose sur lide quil nest pas efcace de rdiger des spcications dtailles, mais quil est prfrable :
de dialoguer pour arriver au dtail, de rdiger (ou dcrire) des tests fonctionnels et de les passer pour valider la

story. Ces tests remplacent la spcication dtaille. Une autre facette, que nont pas les cas dutilisation, cest la gestion de projet par lintermdiaire du backlog de produit. Cest pourquoi la question du choix entre cas dutilisation et user story ne se pose pas dans un dveloppement agile : un cas dutilisation ne remplit pas les conditions pour devenir un lment du backlog slectionn pour un sprint.

13.6 AMLIORER LINGNIERIE DES EXIGENCES


Mais que deviennent les spcications, les exigences, lingnierie des exigences, la traabilit ?

13.6.1 Exigences et spcifications


Pratiquer lingnierie des exigences la mode agile reprsente un changement dans la faon de procder comme dans le vocabulaire. Avec lavnement des mthodes agiles, on ne parle plus dexigence, llment central devient la story. La nouvelle orientation fait que, plutt dexiger une capacit laquelle le systme doit se conformer, on se proccupe essentiellement doptimiser la valeur apporte aux utilisateurs. Le gros document de spcication fait au dbut nexiste plus. Il est remplac par un backlog de produit voluant rgulirement, dans lequel le comportement attendu est dcrit par les stories, chacune accompagne de ses tests dacceptation.

13.6.2 Traabilit
La traabilit est la capacit de lier des lments dun projet an dvaluer limpact dune modication dun lment.

13.6 Amliorer lingnierie des exigences

177

Le fait davoir un backlog unique dans lequel on trouve toutes les stories diminue le besoin de tracer des exigences dcrites dans diffrents documents. Dans le backlog, on peut garder la trace entre une feature et les stories qui sont le rsultat de sa dcomposition. Scrum apporte aussi la trace entre une story et les tches ncessaires pour la raliser. La trace entre les stories et les tests fonctionnels est assure : chaque story, on associe plusieurs tests dacceptation.

Feature

Dcompose en

Story
Ralise par
Tche

Dtaille avec

Test

Figure 13.3 Traabilit entre feature, story, tches et test

13.6.3 Exigences non fonctionnelles


La technique des user stories permet didentier les exigences fonctionnelles, mais pour un produit logiciel, il y a dautres exigences, qualies de non fonctionnelles, parfois dexigences techniques. Cela concerne :
les qualits dexcution comme lusabilit, la abilit, la performance ; les qualits de dveloppement comme la maintenabilit, la portabilit... les contraintes de conception, de dploiement, de conformit des standards...

Il y a plusieurs faons de traiter les exigences non fonctionnelles comme le prsentent les paragraphes suivants.

Citer les plus importantes dans la vision


Quand une exigence non fonctionnelle a un impact fort sur le produit, elle peut dj tre mentionne dans la vision.
Exemples : on peut trouver dans la vision des contraintes comme la conformit des standards dun domaine (comme le DO178B pour laronautique), ou le choix dun progiciel, ou un type de licence.

178

Chapitre 13. De la vision aux stories

Les mettre dans le backlog


Le backlog de produit a vocation contenir tout ce qui ncessite du travail pour lquipe, le fonctionnel, comme ce qui est non fonctionnel. Lavantage de tout mettre dans le backlog permet davoir une source unique, avec des priorits, pour tout ce quil y a faire. La difcult, pour une exigence non fonctionnelle, est de faire en sorte quelle soit :
faisable en une itration, selon la signication de ni, testable.

Cela demande souvent dcouper une exigence gnrale en petits morceaux. Ce nest pas toujours facile mais on y arrive pour certaines : la technique consiste se concentrer sur les tests ncessaires pour la vrier plus que de sa description.
Exemple Plutt que de dire le logiciel doit tre ergonomique (ce quon trouve dans des cahiers des charges), on dira : en tant que membre de lquipe, jaccde mes tches en deux clics maximum. Pour une exigence gnrale comme lergonomie, il y aura souvent plusieurs stories non fonctionnelles. Pour mentionner les exigences de performance on sefforcera dexprimer ce qui est vrifiable, comme : en tant quutilisateur lorsque je me connecte, jai un temps de rponse infrieur deux secondes dans 99 % des cas, mme sil y a dj 50 utilisateurs connects, en prcisant la configuration du serveur sur lequel faire les tests.

Le Product Owner doit tre impliqu dans lidentication de ces stories non fonctionnelles : cest lui le responsable de ce quil y a dans le backlog et il aura dnir les priorits de ces lments par rapport aux autres.

Les dfinir comme associes une story


Certaines contraintes peuvent tre simplement associes une story, o elles apparaissent comme des cas de test.
Exemple : pour une story de recherche dune occurrence dun mot dans un texte, un cas de test pourrait porter sur la vrification du temps de rponse souhait en utilisant un gros document.

Les mettre dans la signification de fini


Les exigences de qualit de dveloppement se dclinent dans la signication de ni. On y trouve aussi des exigences de localisation ou dutilisabilit qui reprsentent des contraintes portant sur plusieurs user stories.

13.6 Amliorer lingnierie des exigences

179

Exemple IceScrum est un produit utilis dans le monde entier, il parle anglais (en plus du franais). Cest une exigence de localisation. Est-ce quelle va dans le backlog de produit ? Non ! En tant quutilisateur, je veux un produit qui parle ma langue serait une story possible, mais elle ne pourrait tre faite qu la fin quand tout le franais serait fait. Or nous voulons que langlais, soit fait au fur et mesure. Chaque fois quon ajoute du texte pour une nouvelle user story, il doit tre accessible en franais et en anglais.

Chaque user story avec du texte est donc contrainte par cette exigence de localisation. Lexigence texte en franais et en anglais doit tre connue de tous les membres de lquipe : dveloppeurs et testeurs. Une faon de la rappeler tous est de linclure dans la dnition de ni. Il existe dautres exigences non fonctionnelles du mme genre :
compatibilit avec Firefox, IE7, Chrome et Safari, aide en ligne disponible sous forme dinfo-bulle, compatibilit Java6 et Java5.

Ces exigences non fonctionnelles ncessitent des tests particuliers, avec ventuellement des environnements spciques. Cela peut reprsenter beaucoup de travail. Porter la connaissance de toute lquipe les exigences non fonctionnelles permet dviter les surprises. Pour rester avec IceScrum, jai appris fortuitement, lors dune dmonstration chez un client, quil ntait pas compatible avec IE6. Si nous avions mis en vidence dans la dnition de ni ce genre de contraintes, il ny aurait pas eu de surprise.

13.6.4 Avec quelle quipe ?


Le mieux est de faire participer toute lquipe ces travaux et aux diffrents ateliers organiss avant le lancement du premier sprint. Elle nest pas toujours constitue ce moment, cependant il est important que le Product Owner, le ScrumMaster et un architecte soient dj identis et constituent le socle de lquipe pour les sprints suivants.

180

Chapitre 13. De la vision aux stories

En rsum
Pour bien dmarrer les sprints, il faut disposer dune vision partage sur le produit. Une bonne vision prsente la position du produit, les rles dutilisateurs et une liste de features. Cela permet de diffuser lquipe la connaissance ncessaire pour dvelopper le produit. Le backlog initial est constitu, en sappuyant sur la vision, par la dcomposition des features les plus prioritaires en stories.

14
De la story aux tests dacceptation

loccasion dun audit sur le processus de dveloppement dune entreprise, javais constat que la documentation relative aux spcications et aux tests tait abondante et, qu mon avis, ctait du gaspillage. Lentreprise en question tait organise avec une sparation entre le service des reprsentants des utilisateurs (matrise douvrage) et celui des informaticiens (appel matrise duvre) :
Le premier rdigeait un document de spcication fonctionnelle du besoin. Le second rpondait par un document de spcication du logiciel pour montrer

ce quil avait compris des demandes des utilisateurs. Il dveloppait le logiciel et passait des tests unitaires, des tests dintgration mais aussi des tests fonctionnels crits en interne. Lquipe de test de la matrise douvrage rdigeait un cahier de recette, pas fourni au pralable, quelle passait sur le logiciel reu des informaticiens. Cela faisait quatre documents, tous dcrivant le comportement du produit ! Cest pour viter ce genre de gaspillage que les mthodes agiles prconisent davoir un seul rfrentiel pour les spcications et les tests. Un article publi dans le trs srieux magazine IEEE Software1 fait lhypothse de cette quivalence entre les tests et les exigences. La rfrence au ruban de Mbius illustre comment les deux (exigences et tests) se confondent lorsque le formalisme augmente.
1. Larticle Tests and Requirements, Requirements and Tests : A Mbius strip est sign de Grigori Melnik et de Robert C. Martin, le clbre Uncle Bob.

182

Chapitre 14. De la story aux tests dacceptation

Cest lobjectif de ce chapitre de montrer comment les stories, accompagnes de leurs tests dacceptation, constituent une spcication par lexemple.
Le test nest pas une phase Tester cest un processus qui consiste collecter des informations en faisant des observations et en les comparant aux attentes. Avec lapproche itrative de Scrum, le test nest plus une phase qui se droule aprs le dveloppement. Il est intgr dans chaque sprint. Ds le premier sprint, une quipe commence tester des stories.

Cette faon de procder permet de rduire le dlai entre le moment o une erreur est introduite dans le logiciel et celui o elle est corrige. On sait depuis longtemps que plus ce dlai sallonge plus le cot de la correction est lev.

14.1 TEST DACCEPTATION


Quelle que soit la mthode de dveloppement utilise, il existe des tests de nature diffrente. Les mthodes agiles apportent une nouveaut dans la faon de percevoir certains types de tests. En effet, la vue classique du test est la dtection derreurs a posteriori, aprs le travail de dveloppement : le testeur, en cherchant des erreurs, vise critiquer. Or, le test agile a un objectif diffrent, celui de guider le dveloppeur dans son travail. Brian Marick met en vidence cette nouvelle vision des tests dans la matrice quatre quadrants1 (gure 14.1).
Orientation dveloppeur Guide pour le dveloppement Critique du dveloppement Pilotage par les tests unitaires (TDD) Autres tests Bote blanche

Pilotage par les tests dacceptation (ATDD)

Autres tests Bote noire

Orientation client

Figure 14.1 Quadrants des tests

Cette ide de guide pour le dveloppement transparat dans le pilotage par les tests (TDD pour Test Driven Development), centr sur les tests unitaires2 . Cest aussi le but

1. http://www.exampler.com/old-blog/2003/08/21/ 2. Le TDD est abord dans le chapitre 15 Scrum et lingnierie du logiciel

14.2 tapes

183

pour les tests dacceptation qui sont des tests orients client (ATDD, Acceptance Test Driven Development). Le test dacceptation est le processus qui permet daccepter une story la n dun sprint. Il consiste en plusieurs tapes, appliques une story :
Dcrire le comportement attendu avec les conditions de satisfaction. Transformer ces conditions en cas de test, appels storytests. crire le code applicatif qui rpond au comportement attendu Passer les storytests sur le code applicatif. En cas dchec, corriger les tests ou le

code. Ce processus est appel pilotage par les tests dacceptation.


Story Storytest

Figure 14.2 Une story possde des storytests

Une user story devrait possder au moins deux storytests associes : un cas de succs et un cas dchec. Il peut y avoir dautres cas de tests pour une story, mais un nombre trop important (disons au-del de huit) est le signe dune trop grande complexit de la story, quil conviendrait de dcomposer. Pour les stories techniques, la notion de test nest pas pertinente, on en restera au niveau des conditions de satisfaction. De mme pour une user story, toutes les conditions de satisfaction ne deviennent pas des tests : cest le cas de celles qui portent sur dautres artefacts que le produit, par exemple sur de la documentation requise.

14.2 TAPES
Dfinir les conditions de satisfaction crire les storytests Dvelopper la story Passer les storytests

Figure 14.3 Les tapes du processus

14.2.1 Dfinir les conditions de satisfaction


Le principe, pour toutes les mthodes agiles, est quune story soit ralise en une itration. Mais comment savoir si elle est vraiment nie la n de litration ? Cest la responsabilit du Product Owner daccepter (ou non) une story. Pour cela, le moins quil puisse faire est de dnir ses conditions de satisfaction. Si toutes les

184

Chapitre 14. De la story aux tests dacceptation

conditions sont satisfaites, la story est accepte, sinon elle nest pas considre comme nie. Exemple avec la story Inscription une confrence . On peut identier trois comportements :
Inscription accepte Cest le cas de succs, linscription dune personne une

confrence est conrme. Inscription diffre Linscription nest pas conrme faute de place et place en liste dattente. Inscription refuse Linscription est refuse, la liste dattente ayant atteint sa limite. Pour une user story, une condition de satisfaction peut tre formalise par un test.

14.2.2 crire les storytests


Formalisme utilis pour les storytests
Les diffrents tests associs une story correspondent des comportements diffrents du logiciel. Les comportements diffrent parce que, en fonction de ltat du logiciel au moment o la story est excute, les rsultats obtenus seront diffrents. La technique du BDD (Behaviour Driven Development1 ) permet de dcrire ces comportements. Chaque test est formalis avec trois rubriques :
ltat du logiciel avant lexcution du test (on parle aussi de prcondition ou de

contexte du test) ;
lvnement qui dclenche lexcution ; ltat du logiciel aprs lexcution (on parle aussi de postcondition ou de rsultat

attendu).
tat avant lexcution (tant donn) vnement (quand)

tat aprs lexcution (alors)


Figure 14.4 Un test BDD

1. http://dannorth.net/introducing-bdd

14.2 tapes

185

Le formalisme textuel du BDD est le suivant :


tant donn le contexte et la suite du contexte Quand lvnement Alors rsultat et autre rsultat

Cette faon de faire est particulirement adapte des applications interactives. Elle pousse avoir des tests courts, puisquon y dcrit la rponse un seul vnement.

Exemple avec la story Inscription une confrence


Chaque condition de satisfaction est transforme en test.
Exemple pour inscription accepte
tant donn lutilisateur Benji connect et la confrence AgileToulouse avec le nombre dinscrits 134 et la salle A4 dune capacit de 200 associe AgileToulouse. Quand Benji sinscrit AgileToulouse Alors linscription de Benji est accepte et le message Vous tes bien inscrit AgileToulouse est envoy Benji et le nombre des inscrits passe 135.

Exemple pour inscription diffre


tant donn lutilisateur Pred connect et la confrence AgileToulouse avec le nombre dinscrits 200 et la salle A4 dune capacit de 200 associe AgileToulouse et 3 personnes dans la liste dattente. Quand Pred sinscrit AgileToulouse Alors linscription de Pred est refuse et le message Vous tes en liste dattente est envoy Pred et le nombre des inscrits reste 200 et le nombre de personnes en liste dattente passe 4.

Exemple pour inscription refuse


tant donn lutilisateur Chipeau connect et la confrence AgileToulouse avec le nombre dinscrits 200 et la salle A4 dune capacit de 200 associe AgileToulouse et 20 personnes dans la liste dattente. Quand Chipeau sinscrit AgileToulouse Alors linscription de Chipeau est refuse et le message Il ny a plus de places disponibles est envoy Chipeau et le nombre des inscrits reste 200 et le nombre de personnes en liste dattente reste 20.

O stocker les tests ?


Chaque test tant associ une story, il est considr comme un attribut de la story et plac avec elle dans le backlog de produit (si loutil employ le permet ; sinon les tests peuvent tre mis dans un document annexe mais en gardant la rfrence aux stories).

186

Chapitre 14. De la story aux tests dacceptation

Quand crire les tests ?


Si la story est ralise dans litration n, cela implique que les tapes du processus de test dacceptation sy droulent (pour quelques stories, il faut mme faire ltape dcriture des tests dans litration n 1).
Une recommandation est, au moins pour une story du sprint, que ses tests soient prts avant le dbut du sprint et que tous les tests soient prts la moiti du sprint.

Les tapes ne sont pas ncessairement squentielles, lajout de nouveaux tests peut se faire en parallle avec le dveloppement de la story.

Qui crit les tests?


Scrum met laccent sur lquipe sans spcialiser les rles. Il ny a pas de rle de testeur, mais cela ne veut pas dire que lquipe ne teste pas ! Il existe parfois lide que cest le client qui teste, le client tant reprsent par le Product Owner, ce qui peut conduire les dveloppeurs dlguer au Product Owner tout leffort de test. Ce nest pas une bonne ide : pour des raisons de quantit de travail et de comptences, le Product Owner nest gnralement pas en situation pour soccuper seul du test dacceptation et surtout cela doit tre un travail collectif. En fait, peu importe qui rdige les tests, ce qui compte cest que cela soit fait au bon moment.

14.2.3 Dvelopper la story


Le dveloppement de la story est men rapidement pendant le sprint ; il dure, en moyenne, trois jours, plusieurs personnes. Le pilotage par les tests signie que lquipe part des tests dacceptation pour concevoir et coder la story. Pendant le dveloppement, il est frquent que des storytests soient complts, voire que de nouveaux soient ajouts.

14.2.4 Passer les storytests


Pour vrier que la story est bien nie, il faut excuter ses tests sur la dernire version du logiciel, le build courant. Si des tests ne passent pas, la correction est faite aussitt, lobjectif tant que tous passent avant la n du sprint. chaque nouveau build, pour viter les rgressions, il conviendrait de repasser tous les tests. Cest une raison pour laquelle il est vite ncessaire de sintresser leur automatisation.

Intrt de lautomatisation
la premire itration, on passe T1 tests. la deuxime, on passe les T2 nouveaux tests identis et on repasse les T1 pour dtecter les rgressions ventuelles. Cela donne :

14.2 tapes

187

Itration Itration Itration Itration

1 2 3 n

: : : :

T1 T2 + T1 T3 + T2 + T1 Tn + .... + T3 + T2 + T1

Avec lhypothse dun nombre moyen Ti des tests par itration, cela donne pour le nombre de tests passer :
Total = Ti *n*(n+1)/2

Pour dix itrations avec chacune dix nouveaux tests, le total est de :
Ti=10, n=10, Total = 550

Avec 50 tests par itrations, il devient :


Ti=50, n=10, Total = 2750

On imagine que si les tests ne sont pas automatiss, ils ne seront pas tous passs manuellement chaque sprint et que des rgressions peuvent ne pas tre dtectes.

Mesures et indicateurs de suivi de test


Il nest pas ncessaire de produire une documentation de rapport des tests comme on en fait dans le dveloppement traditionnel. Il peut tre intressant, lorsque la pratique est mise en place, de faire quelques mesures. Les mesures sur le nombre de stories tests existants et sur leur excution sont importantes pour valuer la qualit du test. La collecte1 se fait chaque build et chaque n de sprint.

Figure 14.5 volution des tests chaque sprint Dans cet exemple, on voit que le nombre de tests passs avec succs a diminu entre le sprint 3 et le sprint 4, ce qui est le signe dun problme. Lquipe doit analyser ce qui a caus cette rgression et en tirer les consquences. Cet indicateur met galement en vidence quil reste des tests en chec la fin dun sprint.

1. Voir le chapitre 15 Estimations, mesures et indicateurs.

188

Chapitre 14. De la story aux tests dacceptation

14.3 GUIDES POUR LE TEST DACCEPTATION


essayer Se servir des tests pour communiquer Connecter les tests Planifier le travail de test viter Tester une story dans le sprint suivant son dveloppement Stocker les bugs

14.3.1 Se servir des tests pour communiquer


Lensemble des stories avec leurs tests remplacent une spcication fonctionnelle dtaille, avec un bnce essentiel : la communication est facilite entre le mtier et le dveloppement. Les membres de lquipe sont demandeurs de ces tests. Ils sen servent dans les discussions avec le Product Owner et les testeurs. Ils les compltent si cest ncessaire. Le rfrentiel des tests est complt progressivement et toujours jour. Cela montre que cette faon de faire dans faon de faire jinclus bien plus que du test ; en fait je pense que le mot test est trompeur : au lieu de test dacceptation, spcication par lexemple serait probablement plus appropri est un moyen dobtenir une meilleure comprhension entre le mtier et le dveloppement, et procure un apport absolument fondamental.

14.3.2 Tester une story dans le sprint o elle est dveloppe


Un des constats fait en suivant des quipes Scrum qui dbutent est que de nombreuses stories ne sont pas nies en un sprint. Quelques-unes durent mme plusieurs sprints ! Ce problme est souvent d laccostage dveloppeurs-testeurs. Si un testeur reoit le logiciel tester en toute n de sprint, au mieux il dcouvre des erreurs qui ne pourront pas tre corriges avant la n du sprint, au pire il diffre ses tests au sprint suivant. Ne pas dvelopper, tester et corriger une story dans le mme sprint est un dysfonctionnement srieux auquel il faut sattaquer. Pourquoi est-ce un problme ?
Cela diminue la productivit des dveloppeurs qui doivent se replonger dans

le code qui implmente une story quils ont dveloppe dans une itration prcdente. Ce nest pas satisfaisant pour lquipe. Elle sest engage au dbut de litration nir une story et le rsultat montre que ce nest pas ni. Cela rend la planication plus difcile. Une user story pas nie est compte zro point pour la vlocit alors que du travail a t effectu dessus. Cette dcorrlation entre rsultat et travail tend produire un burndown chart de release en dents de scie, ce qui peut tre perturbant.

14.3 Guides pour le test dacceptation

189

Le testeur doit tre impliqu dans la planication du sprint, sengager avec le reste de lquipe et tre trs ractif. Lquipe doit aussi tre capable de refuser dinclure une story dans un sprint si elle estime quelle nest pas sufsamment dnie.

14.3.3 Ne pas stocker les bugs


Un story dveloppe dans un sprint est teste dans ce sprint. Si un test ne passe pas avec succs, lquipe doit effectuer la correction au plus vite et au plus tard avant la n du sprint. Si la n du sprint tous les tests ne passent pas avec succs, la story nest pas montre lors de la revue et nest pas considre comme nie. On ne stocke pas les bugs, on stocke les tests.

14.3.4 Connecter les tests dacceptation


La technique des user stories est trs efcace couple un dveloppement par itrations. Les stories alimentent le backlog de produit et sont dveloppes pendant litration. La tendance est avoir des stories trs petites, ce qui prsente des avantages en termes de gestion et de suivi. Mais cela a linconvnient de rendre les choses plus difciles comprendre. Une story est replacer dans un contexte plus large pour que lon identie son usage. En fait une story ne suft pas pour raconter une histoire qui parle aux utilisateurs. Par exemple lors de la revue, laquelle participent de nombreuses personnes, il convient de prparer une dmonstration qui enchane des user stories. Cest ce quon appelle un scnario. Sur un projet de gestion documentaire auquel jai particip, deux scnarios ont t prsents lors de la revue de sprint. Nous avions identi et slectionn pour ce sprint des stories comme :
crer un document, tlcharger un document existant, commenter un document, dsigner les approbateurs, dlguer lapprobation, approuver un document.

La dmonstration a montr dabord le cas dun nouveau document cr et approuv (scnario 1), puis celui dun document tlcharg puis dlgu dans un mcanisme dapprobation en srie (scnario 2). Souvent les scnarios font rfrence des utilisateurs ctifs, appels user1 ou toto. Il est prfrable de choisir de vrais utilisateurs. De la mme faon, plutt que de prendre des documents appels doc1, il vaut mieux sappuyer sur un exemple rel qui rend les choses plus concrtes et facilite leur comprhension.

190

Chapitre 14. De la story aux tests dacceptation

Les scnarios sont utiles pour la dmonstration en n de sprint, mais cest mieux de les laborer bien avant. En dbut de sprint, ils donneront toute lquipe le contexte pour le travail de dveloppement.

14.3.5 Planifier le travail de test


Pour chaque story, on peut identier deux tches pour mener bien le test dacceptation :
La spcication des tests de cette story, quon peut sparer en identication du

test et formalisation du test. Le passage de ces tests. Cest du travail qui prend du temps, cest pourquoi les tches de test doivent gurer dans le plan du sprint.

Rsum
Le test nest pas une activit rserve la n des dveloppements. Avec les mthodes agiles, les tests dacceptation sont passs chaque sprint. Le pilotage par les tests dacceptation pousse mme dnir le test dune story avant son dveloppement, pour quil serve de spcication par lexemple lquipe.

15
Estimations, mesures et indicateurs

La thorie sur laquelle est bas Scrum (visibilit, inspection, adaptation) ncessite de produire des indicateurs (visibles) pour inspecter et adapter le processus. Dans les chapitres prcdents, nous avons vu que lindicateur emblmatique de Scrum tait le burndown :
Le burndown chart de sprint montre lvolution du cumul des estimations de reste

faire sur les tches, sur une base quotidienne. Le burndown chart de release montre lvolution du cumul des estimations sur les stories qui restent faire, chaque sprint. Nous verrons que le burndown chart, malgr son intrt, prsente des limitations rdhibitoires dans certains contextes pour lesquels dautres indicateurs sont plus pertinents. Pour produire des indicateurs, il faut collecter des mesures brutes. Avec Scrum, les mesures les plus importantes portent sur des rsultats visibles un suivi de projet traditionnel porte sur lavancement de tches qui ne produisent pas de rsultat visible, tandis que le suivi agile sappuie sur les stories nies, qui sont visibles. Les mesures les plus importantes portent sur des grandeurs qui ne sont pas connues au moment o on en a besoin et quil faut donc estimer. Ce chapitre prsente les indicateurs dun dveloppement avec une mthode agile et montre comment les obtenir, avec quelles mesures et partir de quelles estimations.

192

Chapitre 15. Estimations, mesures et indicateurs

Estimer Estimation en points dune story

Mesurer Mesure de la vlocit chaque sprint

Publier les indicateurs Graphe de vlocit par type de story

Figure 15.1 Exemple destimation, mesure et indicateur

15.1 ESTIMER LA TAILLE ET LUTILIT


Lestimation est, depuis toujours, un domaine extrmement difcile dans le dveloppement de logiciel. On sait que le meilleur outil pour estimer se trouve dans lhistorique des donnes collectes (les mesures). Mais il faut bien constater que, dans les projets traditionnels, les mesures sont rarement utilises par ceux qui estiment. Il faut dire aussi que des mesures ne sont pas souvent collectes et, quand elles le sont, elles ne sont pas toujours utilisables. Avec Scrum et les mthodes agiles, lestimation reste un art difcile, mais il y a des diffrences fondamentales dans la faon de laborder :
Lestimation est collective En particulier, les estimations de taille ou de dure

sont faites par ceux qui ralisent. Lestimation se base sur des mesures Par exemple, la capacit de lquipe est estime partir de la mesure de la vlocit sur les sprints passs. Nous avons dj abord trois situations o lestimation tait pratique avec Scrum :
Lestimation en points des stories pour la planication de release. Lestimation en valeur des features pour aider dnir les priorits. Lestimation en heures des tches pour la planication du sprint.

Nous allons revenir sur les deux premires, qui sont les plus importantes et aussi les plus nouvelles.

15.1.1 Estimation de la taille des stories en points


La taille du backlog dpend de la taille des stories
Pour mesurer la taille dun backlog, utile pour planier, on pourrait se baser sur le nombre dlments quil contient. Seulement nous avons vu que la dcomposition du backlog tait progressive et qu un moment donn, les lments taient de taille disparate : le nombre total dlments est une mesure, certes intressante, mais pas assez prcise pour avoir une ide du travail qui reste faire. Cest pourquoi la taille du backlog est obtenue par la mesure de la taille de chaque lment. videmment pour planier, on a besoin de cette mesure avant que la story

15.1 Estimer la taille et lutilit

193

ne soit ralise. La valeur de la taille ntant pas disponible, il faut lestimer, et cest difcile.
Pourquoi cest difficile destimer la taille dune story ? La taille dpend de la comprhension de cette story et de la complexit pour la concevoir et la dvelopper qui est aussi influence par la qualit de larchitecture et du code. Et toutes ces notions ne sont pas connues avec prcision au moment o est gnralement faite la premire estimation, lors de la planification de release.

Lapproche prconise face des difcults est de pratiquer lestimation en quipe par une sance de planning poker1 . Lunit destimation prconise est le point, sans unit (alors que la pratique courante est de chiffrer en jours). Cela prsente lavantage de diffrencier les notions de taille et de dure et contraint pratiquer lestimation relative, par comparaison. Une fois chaque story estime, la taille du backlog sobtient en faisant la somme des tailles des stories qui le composent.

De la taille la dure
Le concept de timebox permet de connatre les ressources dun sprint, qui sont xes si lquipe est stable et la dure uniforme. Cest l que la vlocit intervient : cest une mesure sur les sprints passs qui sert pour estimer la capacit de lquipe pour les sprints futurs. Cette notion permet de faire la relation entre la taille et la dure : il suft de diviser le total des points faire pour une release par la capacit de lquipe pour obtenir la date de n (dans le cas dun primtre stable).
Exemple : un backlog a une taille de 124 points et la capacit de lquipe est de 26 points. Le nombre de sprints ncessaires est 5 (124/26 arrondi). Connaissant la dure du sprint, 3 semaines, on peut en estimer la dure de leffort ncessaire, 15 semaines.

La vlocit est videmment une mesure importante pour les quipes agiles : combine la notion de timebox, elle rend totalement inutile de collecter des mesures de la dure et du cot de chaque story pour planier moyen terme.

15.1.2 Estimation de la valeur ou de lutilit


Cest un prcepte de Scrum et des mthodes agiles : on cherche maximiser la valeur ajoute. Plus la valeur dun lment est importante, plus sa priorit est leve et, comme la priorit dnit lordre dans lequel les lments du backlog sont raliss, les lments avec le plus de valeur sont dvelopps en premier.

1. Le planning poker est prsent dans le chapitre 6 La planication de la release.

194

Chapitre 15. Estimations, mesures et indicateurs

De la valeur lutilit
Mais ce nest pas facile destimer la valeur ajoute par une story... Il faut dj dnir ce quon entend par la valeur mtier : le retour sur investissement, la valeur actuelle nette ? Ensuite, un gros travail dtude est ncessaire pour estimer la valeur nancire que va rapporter un lment du backlog. Personnellement je nai pas rencontr dentreprises qui avaient dni la valeur en euros des fonctions dun logiciel. De plus, la valeur est une notion mal comprise : on saperoit que beaucoup la confondent avec le cot. Pour viter les confusions, il est prfrable de changer de vocabulaire et de parler dutilit. Cest une notion utilise en conomie1 : lutilit est une mesure du bien-tre ou de la satisfaction obtenue par la consommation, ou du moins lobtention, dun bien ou dun service. Elle a aussi lavantage dtre plus gnrale : si tous les produits ne visent pas apporter de la valeur nancire, ils ont tous vocation tre utiles. Cest le cas des logiciels Open Source.

Utilit relative
Comme lestimation de la taille, celle de lutilit se fait en points sans unit, et de faon relative. Le Product Owner fait, implicitement, un tri selon lutilit des stories quand il ordonne son backlog par priorit (cest ce quon appelle lutilit ordinale). Pour aller plus loin que lordre et obtenir une mesure, il faut valuer lutilit de chaque lment (faire de lutilit cardinale). Il y a plusieurs techniques possibles, comme le Priority Poker2 .

Sur quels lments estimer lutilit


Des user stories peuvent tre trop petites pour apporter de la valeur par elles-mmes. Cest pour cette raison que la pratique la plus simple est de dnir lutilit sur des features plutt que sur des user stories, ce qui limite le nombre dlments estimer. la diffrence des user stories, les stories techniques et les dfauts, nont pas une utilit directe, perceptible par des utilisateurs. Cependant, comme des user stories en dpendent, il est possible de leur allouer une utilit indirecte3 . Les dfauts, eux, ont une utilit ngative dans la mesure o ils retirent de la valeur la story sur laquelle ils portent.

1. http://fr.wikipedia.org/wiki/Utilit%C3%A9. 2. Vu dans le chapitre 13 De la vision aux stories. 3. Voir ce sujet les travaux de Philippe Kruchten prsents au Scrum Gathering dOrlando : philippe.kruchten.com/kruchten_backlog_colours.pdf.

15.1 Estimer la taille et lutilit

195

Utilit et taille
La taille et lutilit sont statistiquement corrles : en moyenne, plus la taille est grande plus lutilit est importante.

Story C

Utilit Story B

Story A

3 points

Taille

Figure 15.2 En moyenne, lutilit augmente avec la taille.

Mais ce nest videmment pas vrai pour toutes les stories : on connat tous lexemple de fonctions faciles dvelopper qui peuvent tre trs utiles (ou inversement des usines gaz inutilisables).

Story C

Utilit

Story B

Story A

3 points

Taille

Figure 15.3 Trois stories de taille identique peuvent avoir des utilits diffrentes.

Il est donc intressant quun lment du backlog possde deux attributs distincts : sa taille et son utilit. Le ratio utilit sur taille (R = U/T) donne une ide du meilleur retour sur investissement et, plus concrtement, aide dnir les priorits dans le backlog. La taille et lutilit servent donc pour dnir la priorit dans le backlog et sont collectes pour produire des indicateurs.

196

Chapitre 15. Estimations, mesures et indicateurs

15.2 COLLECTER LES MESURES


Avec Scrum, les mesures sont collectes au rythme des cycles de rgulation : chaque jour, chaque sprint, chaque release.
Release Sprint 1 Sprint 2 Sprint 3 Sprint 4

Tous les sprints

Toutes les releases

Figure 15.4 Quand collecter les mesures.

Toutes les mesures prsentes ci-aprs ne sont pas faire dans tous les projets, cest lquipe de dnir celles qui doivent ltre en fonction de ses objectifs et de ses possibilits. Les deux mesures les plus importantes sont celles en relation avec les notions de vlocit et dutilit.

15.2.1 Mesures quotidiennes


Pendant un sprint, la collecte suivante peut tre faite tous les jours :
Le nombre dheures restant faire pour les tches du sprint non nies (Q1). Le nombre de tches restant nir (Q2). Le nombre de stories restant nir pour ce sprint (Q3). Le nombre de points de stories restant nir pour ce sprint (Q4).

15.2.2 Mesures chaque sprint


chaque sprint, les mesures suivantes peuvent tre collectes :
La capacit estime au dbut du sprint (S1). La vlocit relle du sprint (S2). Lutilit ajoute pendant le sprint (S3). Le nombre de stories restant faire dans le backlog dans chaque tat de son

workow (S4).
La taille (en points) du reste faire dans la partie du backlog de produit rduite

la release courante (S5).

15.3 Utiliser les indicateurs

197

Le nombre de points total dans le backlog, y compris ce qui est ni (S6). Le nombre de cas de test dacceptation crits et parmi eux, ceux passs avec

succs et en chec (S7).

15.2.3 Mesures chaque release


Les mesures de n de release sont les mmes que celles dcrites pour les sprints et peuvent tre obtenues par le cumul des sprints qui composent la release.

15.2.4 Autres mesures possibles


Dans certains cas, dautres mesures, faites chaque sprint, peuvent aussi tre utiles, de faon ponctuelle (la dcision de les commencer et de les arrter se prend lors de la rtrospective) :
Le nombre de builds produits pendant le sprint, pour une quipe qui nest pas

encore passe lintgration continue.


Le nombre dobstacles restant liminer la n du sprint, pour une quipe qui

narrive pas bien les liminer. Les ressources consommes pour le sprint, dans le cas o toute lquipe nest pas plein temps sur le projet. Lexposition au risque, pour les projets critiques. ct de ces mesures orientes gestion de projet, des mesures sur la qualit du code (complexit, taux de commentaires...) sont elles toujours ncessaires.

15.3 UTILISER LES INDICATEURS


15.3.1 Indicateurs pour le suivi du sprint
Lindicateur reprsentatif de Scrum est le burndown chart. Dans sa forme usuelle, il est ralis avec les heures restant faire (Q1). Pour des quipes aguerries, lestimation des tches en heures constitue du gaspillage et des variantes possibles sont dutiliser les mesures Q2, Q3 ou Q4 qui sont obtenues plus facilement. Une autre possibilit avec ces variantes est de reprsenter lavancement plutt que le reste faire. Un indicateur intressant, obtenu avec la mesure sur les stories (Q4), est le burnup de sprint en points. Ces graphiques1 sont uniquement destins lquipe dans le suivi de son sprint, ils nont pas dintrt pour des intervenants extrieurs.

1. Voir le chapitre 8 Le Scrum quotidien

198

Chapitre 15. Estimations, mesures et indicateurs

30 25

Points

20
15 10 5 Fini En tout

0
Ma Me J V S D L Ma Me J V S D L

Figure 15.5 Un burnup de sprint en points

15.3.2 Indicateurs pour le suivi du produit


Vlocit des sprints
Le graphe de la gure 15.6 prsente lhistorique de la vlocit (S2) de chaque sprint.
25 22 20 17 19 23 23

15
10 5

0
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5

Figure 15.6 La vlocit des sprints

Usage : pour estimer la capacit de lquipe et faire la planication de la release. Quand lutiliser : ds que possible et tout au long du dveloppement. Tendance souhaite : croissance aprs la constitution dune nouvelle quipe, puis stabilisation. Une diminution de la vlocit aprs est souvent le signe dune dette technique. Risques : changements dans les ressources disponibles par sprint, tendance vouloir une croissance continue de la vlocit (ce qui peut nuire la qualit et provoquer de la dette technique).

15.3 Utiliser les indicateurs

199

Une variante est de montrer la vlocit par type de story. La visualisation des types de story permet de constater limportance prise par les stories techniques (plus importante au dbut dun nouveau dveloppement) et les dfauts (qui peuvent arriver aprs plusieurs sprints, mais dont la proportion doit rester rduite).
25 20 15 Dfaut 10 5 0 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Story technique User story

Figure 15.7 Historique de vlocit par type de story

Vlocit vs capacit
Le graphe prsente, pour chaque sprint deux points : le premier est la capacit qui avait t prvue au dbut du sprint (S1), lors de la runion de planication, le deuxime est la vlocit mesure la n du sprint (S2).
30 25 20 15 10 5 0 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Capacit Vlocit

Figure 15.8 La vlocit compare la capacit

Usage : destin lquipe.

200

Chapitre 15. Estimations, mesures et indicateurs

Quand lutiliser : quand lquipe obtient une vlocit toujours diffrente de la capacit estime lors de la runion de planication du sprint. En gnral, les quipes sont optimistes et la vlocit relle est infrieure la capacit prvue. Tendance souhaite : les deux courbes doivent converger aprs quelques sprints : la vlocit nest pas systmatiquement en dessous (ou au-dessus) de la capacit. On arrte de lutiliser quand lquipe a progress dans ce sens.

Utilit par sprint


Le diagramme montre lutilit, cumule sprint aprs sprint ( partir de la mesure S3).
35 30 25 Utilit 20

15
10 5 0 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5

Figure 15.9 Lutilit cumule.

Usage : permet de visualiser lutilit du produit sprint aprs sprint et de prendre des dcisions sur la n de la release (si le produit prsente sufsamment dutilit, on peut dcider de le mettre en production). Quand lutiliser : ds que possible, mais cela demande beaucoup defforts pour estimer lutilit et la mesurer. Tendance souhaite : croissance rgulire. En principe une bonne gestion des priorits faits que les stories ayant le plus dutilit sont faites en premier, ce qui donne la forme en escalier avec de plus grandes marches au dbut.

Utilit par release


Cest une variante plus simple qui ne porte que sur lutilit vraiment fournie aux utilisateurs, la n dune release. Il faut donc plusieurs releases pour que lindicateur soit signicatif.

15.3 Utiliser les indicateurs

201

400 350 300 250 Utilit 200 150 100 50 0 Release 1 Release 2 Release 3 Release 4 2009 2008

Figure 15.10 Utilit mesure chaque release prsente pour deux annes (lanne 2008 na produit que trois releases).

Burndown de produit
Le burndown chart montre la taille ce qui reste faire dans le backlog, sprint aprs sprint.
90 80 70 60 Points 50 40 30 20 10 0 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6

Figure 15.11 Un burndown de produit

Usage : permet au Product Owner et aux intervenants de dterminer ce qui reste faire dans le dveloppement. Quand lutiliser : ds que possible. Tendance souhaite : dcroissance rgulire (si le primtre est stable)

202

Chapitre 15. Estimations, mesures et indicateurs

Risques : on ne voit pas linuence des changements de primtre, ce qui rend le graphe difcile comprendre ; en cas de variation de primtre importante, la courbe peut remonter. Dans ce cas, le burnup permet un meilleur suivi.

Burnup de produit
Jai remarqu que la plupart des gens prfrent les courbes qui montent celles qui descendent.

Figure 15.12 Un burnup montre plus leffort quun burndown !

Le burnup de produit possde deux courbes : une qui montre ce qui est ni (elle ne descend jamais, il ny a pas de vlocit ngative !) et lautre tout le travail contenu dans le backlog, y compris ce qui est ni (elle peut monter mais aussi descendre : si on supprime des stories qui avaient t dj estimes, si on r-estime la baisse). Le burnup est bas sur les mesures S2 (cumule) et S6. Usage : permet de visualiser lavancement et le reste faire. Quand lutiliser : quand le primtre volue (ce qui est frquent), il est prfrable au burndown. Tendance souhaite : il est possible que les deux courbes montent en parallle, cela veut simplement dire quon ajoute des lments dans le backlog au mme rythme que leur ralisation dans les sprints. En fait la tendance souhaite dpend du contexte.

15.3 Utiliser les indicateurs

203

100 90 80 70

60
50 40 30 20 10 0 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Total

Fini

Figure 15.13 Le burnup chart

Tests dacceptation
Le diagramme montre le cumul des tests dacceptation existants et ceux passs avec succs (S7), sprint aprs sprint.
60 50 40 30 20 10 0 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Dfinis Passs Succs

Figure 15.14 Le diagramme de tests (running tested features)

Usage : il permet de sassurer que les story sont testes. Quand lutiliser : il pousse faire plus de test dacceptation et on peut arrter de le produire quand la pratique est acquise. Tendance souhaite : croissance rgulire ds les premiers sprints.

204

Chapitre 15. Estimations, mesures et indicateurs

Diagramme de flot cumul


Le diagramme montre le cumul de stories dans chaque tat, sprint aprs sprint. Le diagramme de ot cumul nest pas bas sur les points mais sur le nombre de stories dans chaque tat. La mesure est faite lactivation du sprint, avec six valeurs :
le nombre de stories en tout dans le backlog, parmi celles-ci, celles qui sont acceptes ou estimes ou planies ou en cours

ou nies, parmi celles-ci, celles qui sont estimes ou planies ou en cours ou nies, parmi celles-ci, celles qui sont planies ou en cours ou nies, parmi celles-ci, celles qui sont en cours ou nies, parmi celles-ci, celles qui sont nies.
60 50 40 30 20 10
W I P

0
Sprint 1 Fini Sprint 2 En cours Sprint 3 Planifi Estim Sprint 4 Accept Sprint 5 Identifi

Figure 15.15 Le diagramme de flot cumul

Pour les adeptes du Lean, ce diagramme permet de dceler des goulots dtranglement et de mesurer le dbit et le travail en cours (WIP, Work In Process1 ).

Parking lot
Le diagramme montre le pourcentage de nition des stories associes un domaine fonctionnel (feature). Il intressera en particulier les intervenants, spcialiss dans un domaine fonctionnel, participant la revue de sprint.

1. http://leansoftwareengineering.com/2008/06/12/queue-utilization-is-a-leading-indicator/

15.3 Utiliser les indicateurs

205

Feature 8
Feature 7 Feature 6 Feature 5 fini Feature 4 faire Feature 3 Feature 2

Feature 1
0% 20% 40% 60% 80% 100%

Figure 15.16 Le diagramme de parking lot

15.3.3 Indicateurs pour le suivi de la release


Les indicateurs pour le suivi dune release montrent, en plus de lavancement, la comparaison par rapport la cible. Leur objectif est de mettre en vidence des dviations par rapport aux objectifs et de permettre la prise de dcision pour des ajustements. Les indicateurs suivants sont utilisables pour le suivi de la release : burndown chart, burnup, parking lot, en les adaptant en fonction du type de release. Release date xe : la cible se dnit par une date. On ajoute aux indicateurs prsents pour le produit une barre verticale montrant la date cible.
Total 100 90 80 70 60 50 40 30 20 10 0 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Fini

Sprint 6

Figure 15.17 La release se termine au sprint 6 : en prolongeant les courbes sur la barre verticale, on identifie la part du backlog qui restera faire.

206

Chapitre 15. Estimations, mesures et indicateurs

Release primtre x : chaque story dans le backlog doit disposer dun attribut supplmentaire indiquant la release cible. Les mmes indicateurs sont produits, en restreignant la release.
100 90 80 70 60 50 40 30 20 10 0 Sprint 1 Sprint 2 Sprint 3 Sprint 4

Produit
Release

Date de fin

Figure 15.18 Le burndown de release porte sur le sous-ensemble du backlog finir pour la release.

15.4 GUIDES POUR ESTIMER, MESURER ET PUBLIER LES INDICATEURS


essayer Collecter les mesures ds le dbut dun dveloppement Utiliser un outil pour la collecte Expliquer les indicateurs viter Considrer une estimation comme un engagement Mesurer le temps consomm

15.4.1 Une estimation nest pas un engagement


Avec les mthodes agiles, une diffrence fondamentale par rapport la gestion de projet classique est que les estimations sont ajustes rgulirement. Il convient alors de considrer les estimations faites au dbut dun projet comme un budget pour une solution possible, pas comme un engagement sur une solution spcique. Cette pratique permet de :
Faciliter la premire estimation, car on sait quon pourra r-estimer si ncessaire. Se passer de la marge de protection parfois ajoute arbitrairement une

estimation par ceux qui craignent davoir des reproches en cas de dpassement du chiffre annonc.

15.4 Guides pour estimer, mesurer et publier les indicateurs

207

viter quune personne qui a ni un travail en avance ne le fasse durer de

peur dtre accuse de sur-estimation.


Diminuer le doute. Une estimation est toujours fausse, mais de moins en moins

au fur et mesure des r-estimations. viter de perdre du temps mesurer le rel consomm, le comparer la premire estimation et proposer une justication (gnralement sans intrt) de lcart constat.
Si les membres de lquipe ne sengagent pas sur leurs estimations, quoi sengagent-ils ? Une estimation possde une part dincertitude, cela na pas vraiment de sens de sengager quand lincertitude est trop grande. Plutt que de contraindre une personne sengager sur quelque chose quelle ne partage pas forcment, lagilit sappuie sur la responsabilit individuelle dans un collectif qui partage des valeurs communes : courage, communication, simplicit, feedback, respect. Lengagement est possible quand lincertitude diminue : lors de la runion de planification du sprint, lquipe sengage raliser les stories slectionnes parce quen identifiant les tches elle a rduit le degr dincertitude. On peut considrer aussi que lors du scrum quotidien chacun sengage devant ses pairs : lorsquune personne de lquipe dit ce quelle va faire dici le prochain scrum, elle lannonce devant toute lquipe et cela constitue un engagement fort.

15.4.2 Pas de mesure du temps consomm


Lestimation du temps quil reste passer sur une tche est plus importante que la mesure du temps quon y a pass. La pratique habituelle de gestion de projet consiste estimer la dure de la tche avant de la commencer, de relever les heures passes effectivement et danalyser les carts constats. Avec Scrum, on estime aussi la tche, et on la r-estime rgulirement (tous les jours si ncessaire !) pendant son droulement. Le rsultat sappelle le reste faire (RAF). On ne se proccupe pas des heures consommes. Une erreur serait de croire que le RAF est lestim au dpart moins le consomm. En effet on peut avoir estim une tche vingt heures, avoir travaill deux heures dessus et se rendre compte que cest plus facile que prvu et que dix heures sufront pour nir la tche. Lorsque je prsente la position de Scrum sur ce sujet, jentends : quoi servirait de faire des estimations si on ne mesure pas le temps effectivement pass ? Les estimations servent dabord planier. On peut trs bien avoir des estimations sans mesure du temps rellement pass. Cest exactement ce quon fait avec Scrum. Ce qui nous intresse, cest le reste faire, pas le relev des heures. Cest avec

208

Chapitre 15. Estimations, mesures et indicateurs

lvolution du reste faire que des dcisions de planication peuvent tre prises, par exemple ajuster lobjectif dun sprint en ajoutant ou supprimant des tches. La mesure individuelle du temps pass prsente de nombreux inconvnients : elle prend du temps, elle nest pas able, elle pousse considrer que lobjectif dun projet est de tenir une estimation plutt que de produire quelque chose, De plus, elle ne contribue pas dvelopper lesprit dquipe, chacun essayant de se justier en invoquant le temps quil annonce avoir pass ; lafchage des diffrences dheures entre membres de lquipe peut dgrader lambiance. Enn, cela ne sert pas grand-chose. En effet, si on observe un dcalage entre une estimation et les heures effectivement passes, on ne peut pas dire si cest un problme destimation ou de comptence ou de dnition de la tche. Quand une quipe applique Scrum pour la premire fois, on constate que certains membres de lquipe ont beaucoup de rticences donner une estimation de leurs tches. Une des raisons est la peur dtre jug sur la qualit de leur estimation et sur leur productivit individuelle. Cette tendance naturelle considrer une estimation comme un engagement diminue quand le relev des heures consommes nest pas mis en exergue et quil est substitu par le reste faire.

15.4.3 Collecter les mesures ds le dbut dun dveloppement


La publication dindicateurs pertinents contribue lamlioration des pratiques en permettant lquipe dvaluer les progrs quelle accomplit. Elle permet aussi de promouvoir lusage de Scrum dans lorganisation. Cest pourquoi il est prfrable de rendre possible la production dindicateurs ds le dbut dun dveloppement en mettant en place la collecte des mesures les plus importantes, comme la vlocit. Lutilit est une mesure encore plus importante, cependant il faut tre conscient quelle demande beaucoup plus defforts et une grande maturit de lorganisation dans la dnition du produit.

15.4.4 Considrer un outil pour la collecte


La collecte des donnes prend du temps si elle est faite manuellement. Avec un outil, la collecte est automatique. Les mesures et indicateurs proposs, cest un critre prendre en compte dans le choix de loutil.

15.4.5 Expliquer les indicateurs


Il ne suft pas de produire des graphiques, il convient de slectionner les plus pertinents pour les personnes auxquelles ils sont destins. Les plus simples sont les meilleurs. Il est aussi ncessaire, en particulier les premires fois, dexpliquer la signication de ces indicateurs.

15.4 Guides pour estimer, mesurer et publier les indicateurs

209

Figure 15.19 Un indicateur simple

En rsum
Les mesures agiles sont diffrentes. Elles diffrent dans leur nature avec limportance donne la valeur ajoute (ou utilit) et aux rsultats visibles (vlocit calcule avec les stories nies). Lutilit et la vlocit reposent sur des estimations, faites de faon relative, sans units. Les indicateurs, labors partir des mesures, sont utiles pour le suivi des plans ; ils servent aussi lquipe pour quelle value ses progrs et amliore ses pratiques.

16
Scrum et lingnierie du logiciel

Scrum sest largement diffus pour les dveloppements de logiciel et, aprs lenthousiasme des premiers utilisateurs, on constate que certaines quipes ont des difcults obtenir des produits de qualit. Dbut 2009, Martin Fowler, James Shore et Robert Martin, des gourous de lagilit, y sont alls de leur publication sur le thme Scrum sans pratiques dingnierie, cest risqu . Ils ont raison : Scrum est un cadre et, selon le domaine, il est impratif dy ajouter des pratiques complmentaires. En fait, mme si Scrum ne prsente pas explicitement ces pratiques, leur usage est induit par la dnition de ni : pour respecter ce que signie ni, une quipe est pousse appliquer ces pratiques dingnierie. Une erreur serait de considrer que ces pratiques sont optionnelles et que la qualit du produit nest pas un objectif de Scrum. Le code doit tre de meilleure qualit possible : certains seront peut-tre dus, mais Scrum ne rend pas possible le dveloppement larrache . Cest le sujet de ce chapitre de prsenter comment Scrum doit tre complt avec des pratiques dingnierie technique du logiciel. Nous aborderons rapidement les pratiques les plus courantes et surtout, nous montrerons comme elles sintgrent au cadre Scrum.

212

Chapitre 16. Scrum et lingnierie du logiciel

16.1 PRATIQUES AUTOUR DU CODE


16.1.1 Intgration continue
Lintgration continue est une pratique de dveloppement logiciel qui conduit les membres dune quipe intgrer leur travail frquemment ; habituellement chaque personne le fait au moins quotidiennement, ce qui conduit avoir plusieurs intgrations par jour.

Une pratique indispensable


Lintgration rgulire du code de chaque dveloppeur est une pratique essentielle pour le dveloppement itratif. Comme le dit Martin Fowler : Je crois que toutes les quipes devraient pratiquer lintgration continue. Les outils sont gratuits. Le seul prix payer cest dapprendre . Une intgration produit un build, qui peut tre utilis pour passer des tests et permettre le feedback du Product Owner. Pendant un sprint, une quipe produit de nombreux builds. Lintgration continue garantit des progrs dans lapplication en assurant que le code rcemment ajout fonctionne bien avec le build prcdent dj valid. chaque commit1 dun dveloppeur, un outil plac sur le serveur dintgration lance un build, suivi de contrles. Lenchanement est gnralement le suivant :
Compiler et vrier le build. Lancer les tests unitaires. Lancer les tests dintgration et les tests dacceptation. Produire le rapport, avec les erreurs ventuelles.

Si le build ne passe pas, lquipe sarrte pour rsoudre rapidement le problme et relancer la fabrication dun build stable : il ne faut jamais laisser un build cass pour viter de propager des erreurs.

Quand la mettre en place ?


Il est prfrable que lintgration continue soit en place avant le premier sprint. Si lquipe nen dispose pas et dcide de la mettre en place pendant une release, linstallation du serveur et du logiciel constitue une story technique qui va dans le backlog de produit. Ce sera lquipe de ngocier sa priorit avec le Product Owner, en lui expliquant tout lintrt quil va en tirer : avec lintgration continue, un Product Owner peut tester les stories ds quelles sont dveloppes. Lintgration continue permet davoir tout moment un logiciel qui marche, ce qui motive lquipe et aussi les utilisateurs. Elle augmente la transparence en vitant que des travaux dune personne restent ignors du reste de lquipe pendant un certain temps.
1. Le commit est le fait, pour un dveloppeur, de mettre le rsultat de son travail dans lespace commun toute lquipe.

16.1 Pratiques autour du code

213

16.1.2 Pilotage par les tests


Un dveloppeur qui crit du code a pour responsabilit de tester son code morceau par morceau : cest ce quon appelle le test unitaire1 . La pratique du pilotage par les tests (Test Driven Development, TDD) va plus loin : il sagit dcrire les tests avant dcrire le code et de proter de la prsence de tests automatiques pour amliorer le code.

Test en premier
Le programmeur crit dabord les tests unitaires dun composant : cela lui permet de rchir au comportement attendu de ce composant. Ensuite, il crit le code pour que les tests passent avec succs ; avoir crit le test avant permet de rester simple au niveau du code. Il continue ainsi en ajoutant de nouveaux tests, puis le code minimal pour quils passent. Cette pratique est en fait plus une mthode de conception que de codage, dans la mesure o la rexion sur le test guide le dveloppeur vers une solution. Le pilotage par les tests est accompagn du remaniement de code (refactoring ).

Remaniement du code
Le remaniement de code consiste amliorer le code sans changer son comportement. Lobjectif est damliorer sa qualit en simpliant et optimisant la solution actuelle. lissue de chaque modication, il convient de lancer les tests nouveau pour sassurer que le comportement reste celui attendu. Le remaniement de code peut se pratiquer sans laborer les tests en premier, mais cest lintgration des deux qui constitue le pilotage par les tests.
Pilotage par les tests = Tests crits en premier et remaniement du code

succs chec crire le code

Remanier le code

Figure 16.1 La pratique du pilotage par les tests

1. Les autres types de test, et notamment le test dacception, ont t prsents dans le chapitre 15.

214

Chapitre 16. Scrum et lingnierie du logiciel

Quand commencer ?
Le mieux est de mettre en place les conditions permettant de faire du pilotage par les tests ds le dbut dun dveloppement, avant le premier sprint dune release. Le niveau de pratique souhait est renseign dans la signication de ni : par exemple, si lquipe considre quil nest pas ncessaire davoir des tests unitaires pour certaines parties du code, cest lendroit o elle le rend explicite. Dans le plan de sprint, des tches de test unitaire peuvent tre identies ou incluses dans celles de codage, selon lexprience de lquipe : si elle est novice, il est prfrable de les rendre explicites. Si lquipe dcide de mettre en uvre ces pratiques au milieu dune release, sur un logiciel dj existant, il va exister un passif, cest--dire que des parties du logiciel nauront pas de tests unitaires et auront besoin dtre remanies. La question qui se pose est la rsorption de ce passif, appel aussi dette technique. Comme il est difcile, et pas forcment utile, darrter le dveloppement de toutes les nouvelles stories pour se consacrer au remaniement du code, il convient de dnir les composants qui doivent tre remanis et de les ordonner par priorit. Le travail faire pour remanier et crire des tests sur des parties existantes prend du temps, cest pourquoi les travaux doivent tre identis comme des stories techniques et ont leur place dans le backlog de produit. Le Product Owner, qui dnit les priorits, doit tre impliqu pour que ces stories, qui visent amliorer la qualit du produit, soient prises en compte au bon moment.
Exemple : une quipe se rend compte pendant le sprint n que la qualit du code nest pas satisfaisante. Lors de la rtrospective du sprint n, elle dcide que le remaniement est laction prioritaire. Pendant le sprint n + 1, une tche dtude est cre pour dfinir les composants ncessitant du remaniement, puis une runion a lieu pour fixer les priorits. Lors de la planification de release du sprint n + 2, en prsence du Product Owner, ces stories techniques portant sur le remaniement de composants sont ajoutes au backlog de produit. Selon leur priorit, certaines seront faites dans le sprint n + 2, dautres plus tard.

16.1.3 Programmation en binme


La programmation en binme est une pratique qui consiste mettre deux dveloppeurs devant un seul poste de travail, de faon ce que leur collaboration amliore la qualit du code. Un dveloppeur tient le clavier et programme pendant que lautre observe lcran, de faon active. La collaboration nat de la diffrence des points de vue : le premier est orient vers les dtails du code tandis que le second a le recul sur la structure de lensemble du programme. Cette pratique peut tre tendue au-del des dveloppeurs : la constitution de binmes dveloppeur-testeur savre galement efcace. Cest pourquoi le binmage

16.2 Pratiques de conception

215

(travail en binme) est plus une pratique de collaboration quune pratique rduite la programmation.

Figure 16.2 Pour viter les dissonances, il vaut mieux une seule personne au clavier

Quand en faire ?
Cest lquipe de dcider de quelle faon elle met en uvre la pratique de binmage. Il nest pas ncessaire den faire toute la journe et il est important de permuter rgulirement entre les rles dans un binme et entre les personnes pour les binmes de lquipe. Utilis avec discernement, le travail en binme contribue amliorer la qualit du produit : le besoin en remaniement sera moindre sur les parties faites en paire.

16.2 PRATIQUES DE CONCEPTION


Autrefois, on distinguait la conception prliminaire de la conception dtaille. Maintenant le terme architecture du logiciel est largement employ. Larchitecture est relative lorganisation des composants et leurs interactions. Pour faire simple, larchitecture est globale et permet de guider des choix de conception fait sur un composant ou pour dvelopper une story.

216

Chapitre 16. Scrum et lingnierie du logiciel

16.2.1 Architecture volutive


En caricaturant les points de vue, on dirait quavec une mthode traditionnelle on est cens laborer toute larchitecture au dbut et quavec une mthode agile, larchitecture commence avec la premire itration et se poursuit rgulirement. Dans un cadre Scrum, sil nest pas recommand dtre dans le premier cas en geant trs tt larchitecture, il nest pas interdit de faire de larchitecture avant le premier sprint (heureusement) : la quantit darchitecture ncessaire dpend de chaque produit. Quelle que soit la quantit darchitecture faite avant le premier sprint, il faut partir sur lide quil y aura encore des travaux mener pendant les sprints : larchitecture est volutive. Les gros travaux constituent des stories techniques et vont dans le backlog de produit. Des travaux darchitecture peuvent demander lassistance ponctuelle dun expert, il convient danticiper leur planication pour sassurer de sa disponibilit. Comme pour toutes les stories qui napportent pas directement de la valeur, une ngociation avec le Product Owner est ncessaire pour le convaincre de limportance de ces travaux pour lordonnancement par priorit. Sil existe un document darchitecture, sa mise jour se fait chaque sprint et cela fait lobjet dune entre dans la dnition de ni et se concrtisera comme une tche dans le plan de sprint. Larchitecture volutive pousse un changement dans les rles. Typiquement, on peut identier deux postures :
Larchitecte qui prend les grandes dcisions en suivant les tendances techno-

logique, mais ne participe pas aux travaux de lquipe (il reste dans sa tour divoire). Larchitecte qui montre lexemple en mettant les mains dans le cambouis et collabore intensivement avec les autres membres de lquipe. Avec Scrum et les mthodes agiles, cest la seconde posture qui est privilgie.

16.2.2 Conception mergente


La pratique de conception mergente se concrtise par des travaux de conception faits rgulirement, chaque sprint. Nous avons voqu deux moments o de la conception tait faite pendant les sprints :
Pendant la runion de planication de sprint, la conception dune story est faite

de faon collective, lors de lidentication des tches. Elle peut tre reprsente par un diagramme de squence montrant les interactions entre les composants collaborant la ralisation de la story. Lcriture des tests en premier (pour le pilotage par les tests) participe la conception ; cette activit est mene pour dvelopper une story, par un dveloppeur ou en paire.

16.3 Maintenance

217

Il peut aussi tre ncessaire de mener des travaux dtude ou dexploration technique pendant un sprint. Cest ce quon appelle un spike.
Le spike est utilis quand lquipe ne sait pas estimer correctement une story. En gnral, si elle ne sait pas lestimer, cest quelle ne connat pas de solution technique pour cette story et cest lobjectif du spike den identifier une.

Le besoin est identi lors dune runion de planication de release (au moment de lestimation). Le spike est alors ajout au backlog, comme story technique, estim et prioris. la n du sprint incluant le spike, on devrait :
avoir dni une solution, tre capable destimer le cot de dveloppement (sa taille en points, en fait) de

la story objet de ltude, pour aider le Product Owner dcider quoi en faire. Il arrive aussi que le spike amne dcomposer la story initiale en plusieurs autres, plus petites.

16.3 MAINTENANCE
16.3.1 Il ny a pas de phase de maintenance
Dans les organisations, on spare souvent le premier dveloppement dun produit des mises jour venant aprs sa mise en production. On parle de phase de maintenance pour les travaux postrieurs au premier dveloppement et bien souvent les quipes, les procdures et les outils sont diffrents. Avec Scrum, cette distinction nexiste pas : les mises jour sont produites par les releases successives. Au cours de ces releases, cest toujours le cadre Scrum et les pratiques agiles qui sont appliqus, le mme backlog qui continue de vivre et de prfrence les mmes quipes qui dveloppent. Un point-cl des phases de maintenance est la gestion des bugs et demandes dvolution.

16.3.2 Gestion des bugs


La gestion des bugs, ou plus exactement des dfauts, varie selon les projets. Mme si lobjectif ultime avec une mthode agile est de ne pas laisser de dfauts dans le code, dans la vraie vie des projets il y a toujours des dfauts. Et il faut sen occuper, en gardant lide que cest moins cher de les corriger tt que tard.

218

Chapitre 16. Scrum et lingnierie du logiciel

Dfaut sur une story en cours


Un dfaut trouv sur une story en cours de dveloppement dans le sprint est une condition de satisfaction en chec : la story nest pas nie. Lquipe ajoute les tches quil faut pour corriger le dfaut (code, test) et les ralise pour nir la story avant la n du sprint. Le dfaut ne va pas dans le backlog de produit et encore moins dans un outil de bugtracking , ce serait de la perte de temps et dnergie.

Dfaut sur une story considre comme finie


On peut trouver un dfaut sur une story dveloppe dans un sprint prcdent et qui a t considre comme nie. tort, mais cest la vie. Rentrent aussi dans cette rubrique les dfauts qui portent sur des parties dveloppes avant que le projet mette en place un processus agile. Un dfaut enlve de lutilit une story, plus ou moins selon sa gravit : Un dfaut critique empche le fonctionnement dune ou plusieurs stories, dont lutilit devient nulle. Un dfaut majeur ne permet pas un fonctionnement normal et fait perdre une grande partie de lutilit la story. Un dfaut mineur fait perdre un peu de valeur une story en rendant son utilisation plus difcile. Le traitement des dfauts varie selon les projets, voici un exemple de ce qui est fait pour le dveloppement du logiciel Open Source IceScrum : Traitement des dfauts critiques Un dfaut critique est trait de faon prioritaire. Ds quun membre de lquipe inform dun dfaut lestime critique, il cre une tche dans le plan de sprint. Il lui associe un reste faire dune heure. Aussitt, dans lquipe de dveloppement, une personne (ou un binme) arrte son travail en cours pour tudier le dfaut, identier sa cause et corriger le dfaut. Si cela est fait en une heure, il suft alors de dclarer la tche nie. Si le travail demande plus dune heure, il faudra alors identier les tches ncessaires pour la rsolution et les ajouter dans le backlog de sprint. Il est probable que cela aura un impact ngatif sur la vlocit du sprint. Cest pourquoi il convient de ne dclarer comme critique ce qui est vraiment catastrophique pour lusage du produit, sans solution de contournement. Traitement des dfauts majeurs Un dfaut majeur suit le mme processus au dbut. La diffrence cest que si la correction nest pas nie en une heure, on cre une entre dans le backlog de produit, avec comme type dfaut. Le dfaut sera alors estim et corrig dans un prochain sprint. Traitement des dfauts mineurs Un dfaut mineur va directement dans le backlog de produit. Les dfauts sont donc collects dans le backlog et suivent la mme vie que les autres stories : ils sont estims et prioriss. Cest au Product Owner de dcider si la correction dun bug (non critique) est plus importante que le dveloppement dune nouvelle user story.

16.3 Maintenance

219

En rsum
Lusage de pratiques dingnierie du logiciel est obligatoire pour une quipe Scrum qui dveloppe un produit logiciel. Les pratiques de dveloppement venant dExtreme Programming comme lintgration continue, le pilotage par les tests et la programmation en binme sintgrent bien dans le cadre Scrum. Avec Scrum, lquipe fait de larchitecture volutive et de la conception mergente. Il ny a pas de distinction entre le premier dveloppement et les suivants : il ny a pas de phase de maintenance.

17
Scrum avec un outil

En France on a srement trop tendance mettre loutil au centre du dveloppement. Je me souviens dune grande socit dans le domaine aronautique o des armes de dveloppeurs passaient leur temps outiller la mthode. Sur cet aspect, les mthodes agiles vont dans le sens dun rquilibrage, en faisant passer loutil aprs la matrise des pratiques. Mais certains vont trop loin en interprtant le premier nonc du Manifeste agile les personnes et leurs interactions sont plus importantes que les outils et les processus comme une recommandation de ne pas utiliser doutils pour le dveloppement agile. Il faut videmment des outils pour dvelopper ; par exemple les pratiques dintgration continue et de pilotage par les tests ne peuvent tre mises en uvre quavec les outils qui vont bien. En ce qui concerne les pratiques Scrum, le besoin doutil dpend du contexte. videmment, dans le cas dquipes regroupes dans le mme espace, le besoin doutil est moins fort que dans le cas dquipes distribues. Lobjectif de ce chapitre est de montrer comment un outil peut assister la mise en application de Scrum et de lagilit.

17.1 LES OUTILS SCRUM


17.1.1 Les outils non informatiques
Cartes
Les cartes sont en fait des ches bristol sur lesquelles on crit les stories, une story par carte. Cet usage est courant dans les premires expriences que font les quipes avec les user stories. Jai utilis des cartes pour mes premiers backlogs avec Scrum. Cest pratique pour classer les stories par priorit quand on est Product Owner, ainsi que pour crire des

222

Chapitre 17. Scrum avec un outil

dtails sur le dos de la carte au l des runions. En revanche, cest difcile faire partager sauf les accrocher ou coller au mur.

Notes collantes
Quitte coller autant choisir des notes qui se collent facilement : les Post-it.
Dans une entreprise, on reconnat lutilisation de Scrum la prsence de notes collantes de couleur sur les murs des bureaux. Quand une quipe dispose dune espace de travail ouvert, cest loutil le plus efficace pour communiquer entre tous les membres, surtout en ce qui concerne les tches du sprint.

Lutilisation de notes collantes est particulirement recommande pour la gestion des tches dun sprint. Le tableau des tches est lendroit privilgi pour la tenue des scrums quotidiens. Le Post-it se colle plus facilement que la carte et permet de jouer avec les couleurs. En revanche, linconvnient, par rapport la carte, est quil na quune face utilisable. Et surtout le Post-it peut senvoler, ce qui est fcheux pour la prennit des informations quil contient. Toulouse, le vent dAutan qui soufe par rafales est lennemi des tableaux des tches avec des Post-it. Je me souviens dune ouverture de fentre aprs une runion de planication du sprint qui a entran une chasse au Post-it, avec lquipe quatre pattes pour les rcuprer. Les notes collantes sont aussi trs utiles pour le travail collectif et cratif fait lors des diffrents ateliers permettant de constituer le backlog ; dans ce cas la prennit nest pas ncessaire au-del de la runion. Mon conseil est dutiliser les Post-it pour les ateliers de travail et, quand cest possible, pour la liste des tches du sprint. Pour bichonner un backlog de produit, les Post-it ne sont pas sufsants.

17.1.2 Les tableurs ou assimils


Le premier outil informatique utilis pour Scrum est le tableur, pour grer le backlog de produit. Les attributs sont des colonnes et les stories les lignes. Je trouve beaucoup dinconvnients lutilisation dun tableur. Le plus important est que cest un outil qui ne favorise pas le partage entre les personnes de lquipe. Le tableur en ligne de GoogleDocs permet de pallier cet inconvnient. Je lai utilis sur plusieurs projets, avec une certaine russite. Dans certaines entreprises, laccs ce type dapplications nest pas autoris. Le backlog peut alors tre un tableur mis sur un Intranet, mais gnralement lutilisation nest pas partage.

17.1 Les outils Scrum

223

Figure 17.1 Product Owner essayant de capitaliser aprs un atelier avec Post-it

Un outil permettant le partage sur un Intranet que jai utilis sur plusieurs projets, parce que ctait le choix de mes clients, est SharePoint. Cet outil permet de grer des listes, ce qui est plus adapt quun tableur pour un backlog : lavantage par rapport une feuille de calcul est que la liste est visible sur le portail sans quil soit ncessaire douvrir un chier. Cependant cest trs pnible utiliser dans une optique Scrum, notamment pour la gestion des priorits, pour la production des burndown charts... On arrive vite des limites rdhibitoires pour tous ces outils, qui sont dtourns de leur usage dorigine pour faire du Scrum : ils napportent aucune aide mthodologique.

17.1.3 Les outils spcifiques


Il existe de nombreux outils ddis Scrum et notamment la gestion du backlog de produit. En cherchant un peu, on en trouve plusieurs dizaines, cest un sujet qui semble inspirer les innovateurs. Le ticket dentre, comme on dit, nest pas trs lev pour raliser un outil qui gre simplement un backlog. Il existe des outils commerciaux et des outils libres, des outils fonctionnant selon diffrents modes, avec diffrentes technologies. Je ne vais pas prsenter les outils commerciaux, je vais prendre un outil Open Source que je connais bien jen suis le Product Owner pour donner un aperu de laide que peut apporter un outil.

224

Chapitre 17. Scrum avec un outil

17.2 UN EXEMPLE AVEC ICESCRUM


La version R2# 14 dIceScrum1 , sortie en juillet 2009, a t utilise pour lexemple. Lexemple va permettre de simuler le dveloppement dun site communautaire pour une association qui organise des vnements. Il sagit de lassociation Omega qui organise tous les trimestres des sminaires dinformation. Ces sminaires accueillent des professionnels, des tudiants et enseignants.

17.2.1 Les rles Scrum


Pour raliser le site Omega, imaginons des membres de lassociation qui travaillent mi-temps sur ce dveloppement. Ils se retrouvent pour des runions mais travaillent chez eux la plupart du temps. Clodio va jouer le rle de Product Owner, au moins au dbut. Il se connecte sur IceScrum et cest lui qui cre le produit (dans loutil un projet et un produit se confondent).

Figure 17.2 Lassistant de cration

Une gestion dynamique des rles


La personne qui cre le produit devient automatiquement Product Owner et ScrumMaster : elle possde ces deux rles en mme temps, pour lui faciliter lusage du logiciel, en attendant que dautres membres le rejoignent pour constituer lquipe. Le principe, dans IceScrum, est de laisser une grande libert lquipe et aux personnes qui la composent. Les membres de lquipe sinscrivent eux-mmes et chacun choisit son rle.

1. Disponible en ligne sur le site IceScrum : www.icescrum.org.

17.2 Un exemple avec IceScrum

225

Les rles de ScrumMaster et Product Owner restent dynamiques, cest--dire quils peuvent changer si cela est ncessaire : par exemple, lors dune absence, un membre de lquipe peut prendre le rle de ScrumMaster ou de Product Owner.

Les personnes qui sont intresses par le produit sans participer son dveloppement prennent le rle de StakeHolder.

Des responsabilits selon les rles Scrum


Dans IceScrum comme dans Scrum, la notion dquipe est primordiale : lusage de loutil nest pas rserv une seule personne qui en devient le spcialiste. Dans cette optique, la spcicit des rles est limite lessentiel :
Un quipier peut crer des stories dans le backlog de produit, crer des tches

dans le plan de sprint, crer des tests dacceptation, noter le rsultat des tests et enregistrer un obstacle. Le ScrumMaster a la responsabilit supplmentaire de grer llimination des obstacles et dindiquer quun nouveau build est utilisable. Le Product Owner est le seul habilit crer une release, dnir les features, changer les priorits dans le backlog et dclarer une story nie. Les stakeholders peuvent ajouter une story et ont laccs en lecture tout le reste, en particulier les rapports graphiques.

17.2.2 Dmarrage dune release


Avant dactiver le premier sprint, il faut dnir ce que va faire le produit. Lquipe se rencontre physiquement pour dnir la roadmap, le plan de release et le backlog initial ; les informations sont collectes dans IceScrum au fur et mesure.

Cration de releases dans la vue roadmap


Une roadmap montre la vie du produit long terme. Elle est prsente sur une ligne de temps, avec les releases successives et les sprints contenus dans ces releases. Pour Omega, lquipe dcide de lancer le dveloppement en juillet avec une premire release qui est espre en octobre, pour la grande fte de lassociation. La roadmap est alimente par la cration de la premire release. Aprs discussion, lquipe envisage de sortir une deuxime version R2 en dcembre. Ces deux releases sont cres avec la date de n xe, qui pourra tre modie ultrieurement.

226

Chapitre 17. Scrum avec un outil

Figure 17.3 Cration de la release R1 qui se termine le 10 octobre

Figure 17.4 La release R1 apparat dans la vue Roadmap

Figure 17.5 La roadmap avec les deux releases

17.2 Un exemple avec IceScrum

227

Vision
Lors dune runion, lquipe Omega dnit :
lnonc du problme, la position du produit.

Le Product Owner entre ces informations dans la vision associe la premire release, avec deux tableaux.
Tableau 17.1 Dfinir le problme Le problme de Affecte Limpact du problme est Une solution russie permettrait de lorganisation artisanale de lassociation. les organisateurs et les membres de la communaut. un manque de visibilit sur les vnements. prsenter une vitrine de lassociation plus attractive, ce qui permettrait davoir plus de participants aux vnements. Tableau 17.2 Donner la position du produit Pour Qui OMEGA Qui permet la diffrence de Notre produit la communaut. est intresse par les activits de lassociation. est une application web. dlargir lcho de lassociation. la pratique actuelle : un site statique simple. offre une vitrine en ligne o lon peut connatre les manifestations organises et sy inscrire.

Rles dutilisateurs
IceScrum permet de collecter des informations sur les rles et sur la faon dont ils sont susceptibles dutiliser le produit.

Figure 17.6 Les rles dutilisateurs et leurs caractristiques pour Omega

228

Chapitre 17. Scrum avec un outil

Features
Dans IceScrum, une feature est gre dans une liste indpendante, la liste des features. En cas de nouveau produit, lapproche est descendante et les features sont identies en premier.

Figure 17.7 Cration dune feature

Pour Omega, les features sont identies en groupe et le Product Owner les ajoute dans la vue Features.

Figure 17.8 La liste des features pour Omega

Chaque feature peut tre repre par une couleur, pour faciliter lidentication des stories qui y seront associes. Lattribut valeur permet dexprimer la valeur ajoute par une feature. Aprs avoir identi les features, entre une dizaine et une vingtaine en gnral, on peut les copier dans le backlog pour linitialiser. Il est possible de les copier toutes ou seulement quelques-unes (gure 17.9).

Backlog de produit initial


Le backlog de produit IceScrum montre louverture les stories qui sont prioriser. Loutil permet de ltrer les lments du backlog selon leur tat. La vue prioriser regroupe les stories qui ne sont pas encore planies, cest--dire celles qui ne sont pas associes des sprints.

17.2 Un exemple avec IceScrum

229

Figure 17.9 Menu pour copier les features dans le backlog

Priorits Comme les features ont t copies dans le backlog, une premire passe sur les priorits seffectue ce niveau-l, sur environ une vingtaine dlments. Pour Omega, le Product Owner fait une premire passe sur les priorits.
Dans cette vue, le Product Owner dnit les priorits en dplaant les notes dcrivant les stories, la priorit la plus leve tant en haut gauche de la vue.

Figure 17.10 Le changement de priorit seffectue par glisser-dplacer dune story

Dans lexemple prcdent la note News est dplace de sa position et lche sur une note sa gauche : elle va passer plus prioritaire que la note sur laquelle elle est dpose.

Ajout de stories
Lors de lajout dune nouvelle story, on peut dnir son type (feature, user, technical, dfaut), donner une estimation (mais cest gnralement fait lors du planning poker) et dcrire la story. Dans le cas dune user story, la description est facilite par la mise disposition du template en tant que rle, je peux... . Loutil propose, pour le rle, un de ceux rentrs dans la liste des rles utilisateurs.

230

Chapitre 17. Scrum avec un outil

Figure 17.11 Cration de la story Nouvelle confrence

Lors du dmarrage, le backlog initial peut comporter jusqu une cinquantaine dlments, les plus prioritaires tant ceux dont la granularit est la plus ne. Pour Omega, le travail de dcomposition en stories seffectue sur les trois features les plus prioritaires : Annonces, Inscriptions et Compte-rendus. Toute lquipe participe lidentication des stories et peut les entrer dans loutil. Il est aussi possible de dcomposer une story en plusieurs (gure 17.12).

Figure 17.12 Dcomposition dune story

Pour la story Programme, un schma a t fait en runion, il est pris en photo et limage est associe la story (gure17.13). Le dveloppement Omega tant nouveau, il ny a pas de story de type dfaut dans le backlog. Lquipe identie une story technique qui porte sur un framework suggr par le spcialiste des architectures web (gure 17.14).

Estimation
Lestimation des stories se fait avec un planning poker. Comme lquipe Omega ne pouvait pas se regrouper facilement, le planning poker a t fait distance, avec toute lquipe connecte IceScrum.

17.2 Un exemple avec IceScrum

231

Figure 17.13 Association dun fichier une story

Figure 17.14 Une story technique dans le backlog de produit

Figure 17.15 Dbut dune sance de planning poker sur IceScrum

232

Chapitre 17. Scrum avec un outil

lissue de la sance destimation, le backlog est prt pour la planication de la release.

Figure 17.16 Le backlog de produit initial pour Omega

Cration de sprints dans le plan de release


Le plan de release montre la vie du produit moyen terme. On y trouve les sprints qui composent la release. Le plan repose sur lassociation des stories du backlog aux diffrents sprints. Maintenant quelle connat mieux ce quil y a faire et comment le faire, lquipe Omega dcide dune dure des sprints. Ce sera trois semaines. Le Product Owner enregistre cette dure de 21 jours dans les caractristiques de la release. Les sprints sont gnrs automatiquement, dans le bloc de temps que constitue la release. Ils sont visibles dans la vue Roadmap (gure 17.17).

Figure 17.17 Trois sprints crs dans la release R1

Lquipe dnit collectivement le but des deux premiers sprints : ils vont porter sur les annonces et les inscriptions.

17.2 Un exemple avec IceScrum

233

Figure 17.18 Le but des sprints dfini dans le plan de release

Planification de release
Les sprints de la release tant crs et le backlog estim et prioris, la planication peut seffectuer, en tenant compte de la vlocit. Avec IceScrum la planication de release peut se faire de faon manuelle ou automatique. Au dmarrage, lorsque la vlocit na pas encore t mesure, il est prfrable de procder la planication manuelle. La planication de release consiste associer des stories du backlog des sprints de la release. Pour cela, il faut donc que le backlog contienne des stories estimes : en effet pour planier, il faut avoir estim et seules les stories estimes seront candidates tre planies. Il faut aussi avoir cr des sprints. Il sera possible plus tard de changer davis (gure 17.19), en dissociant toutes les stories, ou uniquement celles dun sprint ou des stories individuelles ou en dplaant une story dun sprint un autre. Pour Omega la premire planication de release est faite de faon manuelle. Lassociation se fait avec le plan de release ouvert et le backlog en vue rduite (widget). Les stories sont dplaces sur le sprint dans lequel on envisage de les raliser.

Lancement de la release
IceScrum fournit une assistance facilitant le lancement de la release, en montrant avec diffrentes vues les diffrents aspects du projet (gure 17.20). Lquipe Omega passe en revue les lments dont elle dispose avant de lancer les sprints :
la composition de lquipe, avec les rles de ScrumMaster et Product Owner

dnis, et les Stakeholders (partie prenantes),


la roadmap montrant les deux releases prvues, le plan de la premire release avec les sprints et les stories associes, les features, le backlog de produit.

Avant de sprinter , lquipe Omega se met daccord, collectivement, sur ces lments. Dans IceScrum, les releases, comme les sprints, peuvent tre cres lavance, ensuite pour lancer la release il faut lactiver, puis une fois nie la clore. Pour faciliter lusage au dmarrage, la premire release est automatiquement active.

234

Chapitre 17. Scrum avec un outil

Figure 17.19 Association de la story Lecture compte-rendu au sprint 3 par glisser-dposer

Figure 17.20 Vue sur Omega avec le plan de release en fentre principale et les vues rduites

17.2 Un exemple avec IceScrum

235

17.2.3 Droulement des sprints


Planification de sprint
partir de la vue Roadmap ou du plan de release, on accde au premier sprint. Les stories planies (planication de release) apparaissent dans la colonne de gauche (gure 17.21).

Figure 17.21 Plan de sprint avec les stories associes sur la gauche

La vue sprint reprend le principe du tableau des tches avec des Post-it. Lquipe Omega organise la runion de planication du sprint, au cours de laquelle tout le monde identie des tches. Il est possible de crer des tches storyless , associes la pseudo story du sprint.

Figure 17.22 La tche doc darchitecture nest pas associe une story mais au sprint

Une fois que les tches ont t cres, leur reste faire et leur ralisateur ventuellement dnis, il reste activer le sprint, ce qui enregistre lengagement de lquipe en n de runion.

236

Chapitre 17. Scrum avec un outil

Tableau des tches virtuel


Au cours du sprint, les tches sont actualises avec le reste faire mis jour et dautres tches peuvent tre cres. Les membres de lquipe Omega mettent jour le tableau des tches virtuel distance, en dplaant les tches dans les colonnes En cours ou ni (gure 17.23).

Figure 17.23 Le tableau des tches virtuel du sprint 1

Un dveloppeur accde aux tches quil a prises et peut voir les tches libres pour en choisir une quil va prendre. Sil travaille sous Eclipse, il peut accder ses tches avec le connecteur Mylyn, partir de son environnement de dveloppement. Le burndown chart de sprint, actualis tous les jours, est accessible tous.

Obstacles (impondrables)
Un obstacle qui ralentit le travail peut tre consign dans la vue Impondrable. Chacun peut en ajouter et le ScrumMaster a pour mission de les liminer.

Revue de sprint
Le Product Owner a pour responsabilit de vrier quune story est nie. Si cest le cas, il la dclare nie (gure 17.24), sinon il peut la dissocier ou la glisser dans un autre sprint. Une fois toutes les stories contrles, la n de la revue de sprint, le sprint est clos et IceScrum calcule la vlocit.

17.2 Un exemple avec IceScrum

237

Figure 17.24 La story Relance est dclare finie

Sprints suivants
Une fois le premier sprint clos, le deuxime est plani, comme le premier, lors de la runion de planication et activ en n de runion, avec lengagement de lquipe. De retour sur le plan de release, on a un aperu de ce qui a t ni dans le sprint 1 et de ce qui est faire dans le sprint 2 (gure 17.25).

Figure 17.25 Le sprint 1 est fini, le sprint 2 en cours

17.2.4 Les tests dacceptation


Description des tests
La vue Test permet de dnir les tests dacceptation des stories. Un cas de test est associ une story, qui en possde en gnral plusieurs. Un cas de test peut tre dcrit de faon informelle, comme une condition de satisfaction, ou de manire plus prcise.

238

Chapitre 17. Scrum avec un outil

En plus de permettre lexpression dune condition informelle, IceScrum propose une formalisation (gure 17.26) de type BDD (Behavior Driven Development).

Figure 17.26 Un story test la faon BDD

Passage des tests


Pour quune story soit considre comme nie, il faut au minimum que ses tests passent avec succs. IceScrum permet de noter le rsultat des tests dacceptation (passs en dehors de loutil). Les cas de test sont glisss dans la colonne correspondant au rsultat du test.

Figure 17.27 Pour la story 98, le test Inscription accepte est un succs et celui Refus salle complte est un chec

17.2.5 Mesures et indicateurs


Loutil fait automatiquement la collecte des mesures et permet de visualiser les indicateurs prsents dans le chapitre 15 Estimations, mesures et indicateurs (burndown, burnup, vlocit, capacit, ot cumul, test, parking lot).

17.2 Un exemple avec IceScrum

239

Figure 17.28 IceScrum, vous en prendrez bien un cornet ?

En rsum
Une quipe Scrum utilise des outils simples, adapts son contexte. Obligatoire pour les quipes distribues, un outil devient vite ncessaire pour grer le backlog de produit. Un outil ddi Scrum, comme IceScrum, prsente lavantage dapporter une aide mthodologique et de faciliter la production des rapports.

18
La transition Scrum

La premire fois que jai accompagn une grande entreprise dans la transition Scrum, on mavait bien recommand de ne pas citer Scrum ni dutiliser son vocabulaire. Le backlog sappelait le rfrentiel des exigences et les sprints taient des itrations. Ctait avant que Scrum ne soit la mode et il ne fallait pas heurter les thurifraires de la mthodologie ofcielle. Maintenant, avec la ScrumMania, les transitions se font avec plus de publicit. Jai rencontr dautres situations pour le passage Scrum : avec un projet pilote, sur un projet en pleine crise, linitiative de la direction pour tous les projets... Dans tous les cas, adopter Scrum implique pour une organisation un changement dans la faon de travailler. Nous avons vu comment mettre Scrum en uvre pour le dveloppement dun produit avec une quipe. Mais une quipe nest jamais indpendante du reste de lorganisation et, pour largir lusage de Scrum plusieurs quipes et plusieurs produits, il faut organiser la conduite du changement vers plus dagilit. Cest sur cette transition dune organisation Scrum que porte ce chapitre. Parfois elle est relativement facile, souvent elle trs difcile. Pour certaines organisations, on pourrait parler de mutation, comme on parle de mutation industrielle : un changement conomique et social brusque et spectaculaire, qui entrane une modication profonde des structures.

18.1 LE PROCESSUS DE TRANSITION


Il existe de nombreuses variations sur la faon de faire la transition :
Selon la rapidit de mise en uvre : trs vite pour toute lorganisation (big

bang ) ou progressivement en commenant avec un projet pilote.

242

Chapitre 18. La transition Scrum

Selon le contenu : toutes les pratiques ds le dbut, ou des pratiques introduites

graduellement.
Selon linitiateur : Scrum lanc par la hirarchie (top down), ou linitiative

venant de lquipe (bottom up).

18.1.1 Avec qui faire la transition ?


Si une quipe peut tre linitiative du passage Scrum, une transition plus massive passe par limplication de la direction ; dans le cas dorganisation de taille importante, elle doit tre gre comme un vritable projet. Quand la transition est un projet, il convient de constituer une quipe pour la mettre en uvre. Il ne sagit pas davoir un groupe de personnes plein temps comme sur les projets de dveloppement, mais il leur faut nanmoins du temps clairement allou la transition. La constitution de lquipe dpend de la structure et de la taille de lorganisation. On peut y retrouver, par exemple :
Le PDG (ou un dirigeant), qui est potentiellement bien plac pour tenir

lquivalent du rle de ScrumMaster dans lquipe de transition (un Product Owner nest pas ncessaire). Des experts mthodes ou processus. Le ScrumMaster du projet pilote sur lequel Scrum sera appliqu en premier. Un ou plusieurs consultants extrieurs, experts dans la transition Scrum.

18.1.2 Cycle de transition


Le cycle typique dune transition dans une grande organisation passe par les tapes suivantes prsentes gure 18.1.

valuer le contexte

Prparer lapplication de Scrum

Excuter Scrum sur un projet pilote

Diffuser dans lorganisation

valuer le niveau atteint

Figure 18.1 Les tapes de la transition

Une approche cohrente est que le projet de transition Scrum se fasse aussi en appliquant Scrum. Cest pourquoi le processus de transition est itratif, pendant ltape dexcution sur un projet, et bas sur le feedback. Dans le mme esprit, lquipe implique dans ce projet de transition utilise les artefacts Scrum : elle dispose dun backlog, fait un plan moyen terme et gre une liste dobstacles.

18.2 tapes du processus de transition

243

18.1.3 Backlog damlioration des pratiques


Le backlog damlioration des pratiques (ou backlog de transition) est la liste des travaux faire pour la transition. Il est gr comme le backlog de produit, avec des priorits qui dnissent lordre dans lequel seront appliques les pratiques. On y trouve des pratiques ou des faons damliorer certaines pratiques, portant sur des outils par exemple. Le plan dadoption du projet de transition est quivalent au plan de release Scrum, on y trouve le contenu du backlog projet sur les sprints du projet de transition.

18.1.4 Obstacles dorganisation


La force de Scrum est dexposer les obstacles qui ne manqueront pas darriver lors de la transition et qui vont freiner ou arrter le dploiement de Scrum. Les obstacles identis peuvent tre de nature diffrente :
Sur les pratiques de Scrum. Venant de personnes. Venant de lorganisation et de son type de gouvernance. Sur les pratiques complmentaires de Scrum, notamment les pratiques ding-

nierie. Lquipe de transition est charge dliminer ces obstacles par des actions au niveau de lorganisation.

18.2 TAPES DU PROCESSUS DE TRANSITION


18.2.1 valuer le contexte
Le but de cette tape est de connatre la situation de lorganisation au moment o seffectue la transition. Quest-ce qui la pousse passer Scrum ? Quel est lenvironnement de lorganisation, de diffrents points de vue ? Quel est le contexte des projets dvelopps ? Cest lquipe de transition qui value le contexte, il faut donc la constituer en premier.

Dfinir la raison du passage Scrum


Il faut avoir une ide claire de la raison du changement : passer Scrum parce que cest la mode nest pas une justication sufsante. Pour commencer, il est utile dtablir une liste des problmes auxquels est confronte lorganisation. Cela peut tre fait par une sorte de rtrospective sur les derniers projets raliss. Les participants ces projets peuvent tre convis pour une sance de rexion collective dont le but est didentier cette liste de points amliorer. Une

244

Chapitre 18. La transition Scrum

autre possibilit est de demander un expert externe deffectuer des interviews des intervenants majeurs dans les dveloppements.
Exemples de problmes remonts : on ne tient jamais les dlais, il y a une pression terrible en fin de projet, la qualit est dplorable parce que les tests sont ngligs...

La mise en vidence des problmes aidera motiver les personnes impliques dans le changement, puisquelles comprendront ce que la transition Scrum cherche rsoudre.

valuer le contexte de lorganisation et des projets


Lorganisation est value selon ses conditions denvironnement : culture, niveau dinnovation, domaine mtier et ses caractristiques, niveau de maturit dans ses pratiques dingnierie. Le contexte de quelques projets typiques est valu en utilisant les dix attributs signicatifs1 (ou dautres que lquipe de transition aura slectionns) : taille, criticit, modle conomique, stabilit de larchitecture, dispersion de lquipe, mode de gouvernance, capacit de lquipe, ge du logiciel, taux de changements et mode de dploiement.

18.2.2 Prparer lapplication de Scrum


Choisir le projet pilote
Ltude du contexte de quelques projets facilite le choix de celui qui va tre le premier mettre Scrum en application. Cest lquipe de transition de dcider, avec les rsultats de ltape valuer le contexte , et en sappuyant sur des critres complmentaires :
Il est plus facile de mettre en uvre Scrum au dbut du dveloppement dun

nouveau produit quen plein milieu dun projet, cela vite la complexit due la prise en compte de lexistant, en termes doutils et dartefacts notamment. Le projet pilote doit tre signicatif, ce nest pas un projet jouet, mais il ne doit pas tre trop critique non plus avec les risques lis au changement.
Il est possible de lancer simultanment plusieurs projets pilote, mais videmment cela demandera plus de disponibilit de la part de lquipe de transition. Cest la distinction, faite par le Lean, entre le Kaizen et le Kaikaku. Le Kaizen correspond lamlioration continue et progressive et le Kaikaku la transition radicale et rapide. Pour certaines organisations, le Kaikaku est la meilleure solution, mais il demande une implication considrable de la direction et lappel massif des consultants externes.

1. Voir le chapitre 12, Adapter Scrum au contexte, pour le dtail de ces attributs.

18.2 tapes du processus de transition

245

Adapter les pratiques au contexte


partir de lvaluation du contexte, il sagit de dnir prcisment la faon dont les pratiques vont tre mises en uvre en tenant compte des contraintes du projet pilote.
Contexte de lorganisation

Contexte du projet pilote

Pratiques tenant compte du contexte


Figure 18.2 Du contexte aux pratiques

Une faon systmatique de procder est de prendre les pratiques Scrum une une et de dterminer, en quipe, la faon concrte de la mettre en uvre. Il convient aussi dy ajouter les pratiques complmentaires ncessaires1 . En procdant de la sorte, lquipe labore la liste de tous les travaux faire pour que les pratiques soient mises en uvre sur le projet pilote : formation, logistique, outils, appel des experts extrieurs... Le rsultat est la constitution du premier backlog damlioration des pratiques, qui, comme le backlog de produit, est prioris.

Formation initiale
Le premier besoin en formation concerne lorganisation : il est important quelle connaisse sufsamment Scrum et les mthodes agiles pour tre convaincue quils peuvent sappliquer dans son contexte et avoir des pistes sur la faon de faire la transition. Une formation dune journe, allant lessentiel, permet dapporter ces rponses. Elle sadresse toutes les personnes qui pourront tre en contact avec celles pratiquant Scrum. Une fois que la dcision est prise de dmarrer un projet avec Scrum, lquipe du projet pilote doit tre forme lapplication concrte de Scrum. Le ScrumMaster et le Product Owner, qui font partie de lquipe, y participent. Des travaux pratiques de mise en situation sont ncessaires, portant sur le projet. Ce ne serait pas une bonne ide que de former uniquement le ScrumMaster : toute lquipe a besoin de la formation.

1. Voir le chapitre 13 Adapter Scrum au contexte

246

Chapitre 18. La transition Scrum

Selon le niveau de lquipe en pratiques techniques (intgration continue, pilotage par les tests...), des formations ces technologies peuvent tre ncessaires avant de commencer le projet pilote. En rsum :
pour les intervenants qui ne participent pas directement un projet, une

formation dune journe de sensibilisation qui va lessentiel ; pour tous les membres dune quipe qui commencent un projet, une formation pratique de mise en application de Scrum en trois jours, complter par lapprentissage de pratiques techniques si cest ncessaire ; pour le ScrumMaster ou le Product Owner, participation la formation de trois jours, complte ventuellement par lassistance dun expert Scrum, au moins sur les premiers sprints du projet pilote.

Constitution de lquipe pilote


Pour le choix du ScrumMaster et du Product Owner, des critres ont t prsents dans des chapitres prcdents ; pour les membres de lquipe pilote voici des pistes :
Inclure des personnes qui adhrent la culture agile et sont ouverts au

changement.
Inclure des volontaires qui ont envie de faire partie de lquipe. Construire lquipe avec des spcialistes gnralistes (quelquun avec des spcia-

lits techniques qui cherche activement acqurir de nouvelles comptentes dans sa spcialit aussi bien que dans de nouveaux domaines). Inclure des experts pour le travail spcialis ncessaire court terme, notamment pour larchitecture et lergonomie.

18.2.3 Excuter Scrum sur un projet pilote


Une fois le projet pilote dmarr, la transition se droule avec les deux projets actifs simultanment :
Le projet de transition. Le projet pilote.

Les deux se synchronisent rgulirement : un projet pilote dure environ trois mois avec quatre six sprints et le projet de transition suit le mme rythme. Le feedback venant du projet pilote alimente les rexions de lquipe de transition. Lquipe du projet pilote dispose du support de lquipe de transition pendant le sprint. Lassistance peut se concrtiser par une prsence quelques runions, des rponses aux questions sur Scrum, du coaching pour le Product Owner, des formations courtes des techniques qui vont tre utiles pour lquipe... La rtrospective, la n de chaque sprint du projet pilote, est faite en prsence de lquipe de transition. Elle se poursuit ensuite par une runion de lquipe de transition qui fait le point sur la transition Scrum. Le backlog damlioration est mis jour, en

18.2 tapes du processus de transition

247

fonction des remontes de la rtrospective. Les actions pour le prochain sprint sont dcides.
Release Projet pilote Sprint 1 Sprint 2 Sprint 3 Sprint 4

Projet de transition

valuer Prparer contexte

Sprint 1

Sprint 2

Sprint 3

Sprint 4

Diffuser

Figure 18.3 Synchronisation entre projet pilote et projet de transition

18.2.4 Diffuser dans lorganisation


la n de la premire release du projet pilote, si cest un succs, lobjectif est dtendre lusage de Scrum et ses bnces un sous-ensemble signicatif de lorganisation cible.

Capitalisation
La liste des pratiques qui ont t appliques et celles des obstacles rencontrs permet davoir un tat des lieux avant une diffusion plus grande. Lquipe de transition a collect ces informations au fur et mesure du droulement et peut organiser une rtrospective plus pousse la n du projet pilote pour complter la capitalisation sur lexprience.

Diffusion de la connaissance
Les rsultats du projet pilote sont communiqus largement dans lentreprise, pour commencer crer une communaut et dclencher de nouvelles vocations dans les quipes. Les participants au projet pilote sont un vecteur idal pour diffuser la connaissance dans lorganisation (gure 18.4). Ils peuvent tre dispatchs dans les nouveaux projets qui vont utiliser Scrum.

Scrum de scrums
La gnralisation de Scrum va probablement entraner son utilisation des projets de plus grande taille, ncessitant des ressources importantes, allant au-del dune quipe Scrum (limite une dizaine de personnes). Lusage de Scrum reste possible, en constituant plusieurs (sous-)quipes. La pratique Scrum permettant la collaboration dquipes participant au dveloppement dun produit est connue sous le nom de scrum de scrums .

248

Chapitre 18. La transition Scrum

Figure 18.4 Le ScrumMaster dun projet pilote heureux de montrer sa vlocit et son burndown chart

Les runions du crmonial sont appliques de manire rcursive. En ce qui concerne le scrum quotidien, un reprsentant de chaque quipe participe, aprs la runion locale son quipe, au scrum de scrums. La runion permet dexposer et rsoudre les problmes de synchronisation entre les quipes. Le dveloppement grande chelle engendre, bien entendu, et pas seulement avec Scrum, de multiples questions dorganisation :
Comment constituer les quipes ? Comment partager le travail entre les quipes ? Combien de Product Owners ? Les sprints de chaque quipe sont-ils synchroniss ?

Une rponse rapide est quil vaut mieux constituer des quipes selon un dcoupage fonctionnel (par feature), garder un seul backlog et un seul Product Owner et avoir des sprints de mme dure et synchroniss. Mais chaque situation est diffrente et il y a bien dautres questions qui se posent.
Le lecteur pourra trouver des complments sur le sujet dans les crits de Dean Leffingwell (Scaling Agility ) ou dans le chapitre Scaling Agile de Succeeding with Agile de Mike Cohn.

18.2 tapes du processus de transition

249

Formations complmentaires
Le dmarrage de nouveaux projets est loccasion dorganiser de nouvelles formations, tenant compte des rsultats du pilote.
Les quipes des nouveaux projets Scrum qui vont dmarrer suivent la formation

pratique de trois jours.


Cest aussi le bon moment pour une formation spcique, destine aux futurs

Product Owners et ScrumMasters, dune dure de deux jours. La diffusion est complte par une nouvelle formation de sensibilisation (un jour) pour les nouveaux membres de lorganisation qui seront en relation avec les nouvelles quipes Scrum.

18.2.5 valuer le niveau atteint


Il sagit de prparer une diffusion gnrale, une fois que lutilisation est rpandue. Une entreprise qui effectue une transition a une ide des progrs effectus en effectuant la collecte de mesures pertinentes1 et en valuant le niveau (dagilit) atteint ; cela sert de base pour une diffusion plus large. Il convient de choisir un sous-ensemble signicatif de mesures faire pour chaque nouveau projet. Il est souhaitable dajouter aux mesures quantitatives des mesures qualitatives, comme la satisfaction des utilisateurs (et aussi celle des dveloppeurs).
Attention : la plupart des mesures ne permettent pas de comparer plusieurs projets. Par exemple, la vlocit est intrinsque dune quipe et ne peut pas servir valuer son efficacit.

En plus des mesures sur le produit, la diffusion de Scrum doit saccompagner de mesures sur le processus, cest--dire sur la faon dont les quipes mettent en uvre les pratiques. Pour collecter ces mesures sur le processus, lquipe de transition peut laborer un questionnaire permettant dvaluer le niveau dapplication de la pratique. Pour chaque pratique, lquipe se situe en rpondant quelques questions. Les gures 18.5 et 18.6 prsentent un exemple dvaluation des pratiques Scrum, sous forme de carte heuristique.

1. La liste des mesures possibles est prsente dans le chapitre 15.

250

Chapitre 18. La transition Scrum

Figure 18.5 Premire partie de la carte heuristique avec lvaluation des pratiques sur les rles et le crmonial

18.2 tapes du processus de transition

251

Figure 18.6 Deuxime partie de la carte heuristique avec lvaluation des pratiques sur les artefacts, les obstacles, la signification de fini, le sprint et la vlocit.

252

Chapitre 18. La transition Scrum

18.3 IMPACTS SUR LORGANISATION


La diffusion dans une organisation de grande taille a des impacts importants, parce que Scrum vhicule une vision qui est, la plupart du temps, radicalement diffrente sur la faon de sorganiser et de grer les ressources humaines. En voici trois exemples.

18.3.1 Lvaluation individuelle est contre-productive


Esther Derby (dans larticle Performance without Appraisal1 ) pourfend lvaluation individuelle au mrite. Elle cite notamment Deming, bien connu pour ses travaux sur la qualit (et pour sa roue2 ) : The idea of merit rating is alluring. The sound of the words captivates the imagination: pay for what you get ; get what you pay for ; motivate people to do their best, for their own good. The effect is exactly the opposite of what the words promise. Everyone propels himself forward, or tries to, for his own good, on his own life preserver. The organization is the loser. Merit rating rewards people who do well within the system. It does not reward attempts to improve the system W. Edwards Deming, Out of the Crisis. Esther Derby propose de supprimer les entretiens annuels dvaluation couramment pratiqus dans les entreprises et fournit des rponses intressantes aux questions qui en dcoulent :
comment dterminer le salaire de chacun, comment donner une promotion quelquun ou au contraire virer une

personne,
comment les gens sauront quils doivent samliorer.

Scrum, par ses mcanismes de rgulation et la transparence apporte, contribue privilgier une approche collective et se passer des valuations individuelles.

18.3.2 Pas de multitches


Le multitche pour une personne, cest le fait de suspendre une tche en cours alors quelle nest pas encore nie pour passer une autre, qualie de plus prioritaire. Dans nos organisations, le multitche est un fait courant, parce que cest souvent lusage que :
une personne travaille sur plusieurs projets en mme temps (lors dune formation,

jai rencontr une personne qui travaillait sur six projets en parallle). une personne travaille sur un nouveau dveloppement mais aussi sur la maintenance du logiciel. Le bug urgent corriger immdiatement qui ne va pas manquer darriver est le dclencheur du changement de contexte et cela va provoquer inluctablement des soucis au projet de nouveau dveloppement.

1. http://www.scrumalliance.org/articles/50-performance-without-appraisal 2. http://fr.wikipedia.org/wiki/Roue_de_Deming

18.3 Impacts sur lorganisation

253

un responsable surgisse en proclamant quune nouvelle tche est devenue la

priorit absolue. Il faut tout prix viter le gaspillage dnergie et de temps d au multitche. Les mthodes agiles donnent quelques bons conseils pour y arriver :
ne pas affecter une personne plusieurs projets, dnir des priorits et les rendre visibles travers le backlog, viter de perturber une quipe pendant un sprint.

18.3.3 Spcialistes vs gnralistes


Les quipes agiles sont plus efcaces avec des gnralistes ou des spcialistes qui se gnralisent. Thierry Crouzet (qui a crit un billet sur Gnralistes contre spcialistes1 ) dfend avec brio lide que les gnralistes sont plus utiles que les spcialistes dans les priodes de changement. Cette ide est dfendue par le mouvement agile chaque fois que la constitution dune quipe est voque. Par exemple, le tout petit nombre de rles dans Scrum y pousse : pas darchitecte par exemple mais seulement des membres de lquipe. On pourrait comprendre quune quipe Scrum ne doit pas inclure de spcialistes. Il ne sagit pas de cela. Dans mes quipes je me suis souvent appuy sur des spcialistes pour avancer et il serait dommage de se priver de comptences pointues. Lide est plutt dviter lhyper-spcialisation. Comme le fait remarquer Crouzet, il y a un risque denfermement du spcialiste dans une seule voie. Il y a aussi quune quipe de dveloppement qui serait compose de spcialistes ne pourrait pas rester de taille rduite pour couvrir tous les domaines et que la communication y serait bien difcile.

18.3.4 Cohabitation avec dautres processus


La transition Scrum est gnralement progressive, ce qui signie quil y aura une priode de cohabitation avec les processus en place. Des projets qui dmarrent auront le choix entre plusieurs options, dont Scrum. quel moment se fait ce choix ? Pour quil soit pertinent, il convient de le faire aprs une phase dtude (ou tude dopportunit), pour dterminer, par exemple, son contexte avec les attributs prsents prcdemment. Cela signie que la phase dtude est commune tous les projets et qu la n de cette phase, le choix du processus, Scrum ou pas, est effectu. lautre bout du cycle de dveloppement, les grandes organisations qui possdent une infrastructure pour leur systme dinformation ont gnralement des phases balises avant la mise en production. Dans un premier temps, il est peu probable

1. http://blog.tcrouzet.com/2008/05/26/generalistes-contre-specialistes/

254

Chapitre 18. La transition Scrum

que les travaux effectus dans ces phases puissent tre inclus dans les sprints. Cest pourquoi, aprs une release et ses sprints, le produit peut tre amen passer par ces phases traditionnelles.
Pas Scrum tude Release Scrum Sprint 1 Sprint 2 Sprint 3 Sprint 4

Phases du processus traditionnel Phases avant Mise en production

Figure 18.7 Scrum, comme alternative dans le processus global dune entreprise

Rsum
Si lancer un projet avec Scrum est relativement facile, la transition dune organisation est autrement dlicate. Lintroduction de Scrum se prpare en considrant le changement de processus comme un vritable projet.

19
Scrum en France

Bien que le mot Scrum ait dans ses nombreuses racines le franais escarmouche, il est indniablement dorigine trangre. La mthode Scrum vient des tats-Unis, mme si on peut y trouver des racines japonaises1 , et en remontant plus loin des origines europennes avec lautogestion. Le but de ce chapitre est de faire ltat de la diffusion de Scrum en France, en se demandant sil y a des spcicits franaises.

19.1 SCRUM LA FRANAISE


19.1.1 Utilisateurs de Scrum
Lusage de Scrum en France est tardif, par rapport sa diffusion dans le reste du monde. Les premires expriences datent de 2005 et lessor na vritablement commenc que n 2007. Depuis la croissance est fulgurante. Comme on ne dispose pas dune mesure des utilisateurs, il faut lestimer, exercice auquel je mtais prt en mars 2009, pour les quipes pratiquant Scrum en France :
2005 : moins de dix quipes. 2006 : moins de 50 quipes. 2007 : moins de 200 quipes. 2008 : moins de 800 quipes. 2009 : plus de 1 000 quipes.

Jai prsent cette estimation lors du lancement du groupe des utilisateurs franais de Scrum. En effet, ce groupe dchanges sur Scrum a t lanc dbut 2009 ; il comptait

1. Lallusion au rugby vient dun article japonais et Scrum sappuie sur le Lean utilis en production.

256

Chapitre 19. Scrum en France

en septembre 2009 plus de 350 membres. Le Scrum User Group (SUG) franais1 est une association but non lucratif qui a pour objet la promotion des pratiques de Scrum sur le territoire franais en tant que composante fondamentale des mthodes agiles.

19.1.2 Retours dexprience


On dispose maintenant de nombreux retours dexprience sur des projets mens avec Scrum en France. Certains sont publis dans la presse ou prsents loccasion de confrences. Par exemple, Toulouse, lassociation SigmaT2 a organis douze confrences entre 2006 et 2009, avec chaque fois au moins un retour dexprience sur Scrum. Parmi ces socits, des petites et des grandes qui exercent dans diffrents domaines dactivit. Le bilan de ces utilisations a toujours t prsent comme trs positif. Il existe maintenant dautres associations dans les rgions, comme le CARA3 pour Rhne-Alpes, ou au niveau national, par exemple le XP Day4 et lAgile Tour5 , qui organisent rgulirement des manifestations sur lagilit, dont le contenu des sessions porte rgulirement sur Scrum. Pour voquer les retours dexprience, je peux mappuyer aussi sur la cinquantaine de projets Scrum dans lesquels jai t impliqu, et sur lenqute du SUG franais publie en juin 20096. Le SUG franais a lanc une enqute au printemps 2009 sur les usages de Scrum (et des mthodes agiles) en France. Les rsultats font apparatre un taux de satisfaction lev, que ce soit de la part des utilisateurs ou des dveloppeurs (gure 19.1).

19.1.3 Domaines
Scrum est utilis dans tous les domaines du dveloppement logiciel. Lenqute du SUG fait apparatre une grande diversit : les mthodes agiles ne sont pas utilises que pour faire des sites web ! Des domaines a priori moins adapts sont aussi touchs par la vague Scrum. Pour en citer quelques-uns dans lesquels je suis intervenu : administrations du secteur public, banques, studios de jeu vido, diteurs, nergie, automobile, applications M to M (Machine to Machine), oprateurs tlphoniques, commande numrique, web, socits de service.

1. 2. 3. 4. 5. 6.

www.frenchsug.org http://www.sigmat.fr http://clubagile.org/ http://xpday.fr/ http://www.agiletour.org/ Elle est disponible sur le site de lassociation du SUG France

19.1 Scrum la franaise

257

Satisfaction des utilisateurs

Satisfaction des dveloppeurs

Figure 19.1 Extraits de lenqute du SUG en France

Scrum est aussi utilis dans le domaine de lindustrie. Par exemple, Scrum est utilis pour un projet de systme industriel de contrle commande de stations lectriques chez Areva T&D. Camille Bloch, linitiative de lintroduction de Scrum, met en avant lamlioration de la communication dans lquipe : ...Nous nous sommes rendu compte que notre faon de travailler ntait pas optimale. Dans une dmarche damlioration, nous avons donc explor avec une petite quipe lutilisation de Scrum, coupl des bonnes pratiques dingnierie dXP. Aprs quelques mois dexprimentation, nous avons fait appel Claude pour recadrer notre exprience. Depuis lors, nous voluons sans cesse pour nous amliorer. Nous avons rencontr de nombreux problmes, que nous avons rsolus ensemble. Le plus grand apport de Scrum a t de nous permettre de dvelopper un rel esprit dquipe, et de travailler plus sereinement. Notre travail devient plus efcace et le logiciel produit en est de meilleure qualit. Il rpond mieux aux besoins du client... Scrum est indiffrent aux pratiques dingnierie, ce qui le rend potentiellement utilisable en dehors du dveloppement de logiciel. Mme si cela reste marginal, ces utilisations se multiplient. En lisire du dveloppement, Scrum est utilis pour grer des quipes qui font des projets dinfrastructure. Jai particip des projets Scrum portant sur le paramtrage de progiciels, dautres pour modliser et documenter des processus ou pour faire de la validation. En dehors du logiciel, on ma signal des usages de Scrum pour de lco-facilitation et il semble mme que le BTP sy intresse. Les usages personnels de Scrum sont nombreux : les personnes ayant vu lintrt de lapproche sur des projets essaient de lappliquer pour amliorer leur efcacit personnelle. Jai, bien videmment, utilis Scrum pour le gros projet personnel qua constitu lcriture de ce livre.

258

Chapitre 19. Scrum en France

19.1.4 Des particularits locales ?


Existe-t-il une spcicit franaise rendant Scrum adapt ou non notre culture ? En France comme ailleurs, on trouve une grande varit dorganisations et donc de contextes. Par rapport lutilisation de Scrum, nous avons vu quon pouvait dnir des attributs permettant de situer une organisation ou dun projet. Sont-ils diffrents en France ? Les caractristiques des projets nont pas de raison dtre diffrentes. En France comme ailleurs, il y a de grands et de petits projets, des dveloppements nouveaux et des reprises de logiciel existant. Sans prtendre gnraliser, les attributs suivants peuvent mettre en vidence dventuelles spcicits franaises :
Le type de gouvernance, pour les organisations de type MOA/MOE. Le modle conomique, avec les contrats au forfait. La culture des quipes de dveloppement.

Les deux premiers, typiques de quelques grandes entreprises ou administrations, peuvent freiner la diffusion de Scrum, le dernier la renforcer.

19.2 DES FREINS LA DIFFUSION ?


19.2.1 MOA et MOE ne sont pas agiles
Dans la plupart des grandes organisations franaises, il existe une division entre la Matrise douvrage (MOA), qui reprsente des utilisateurs internes lentreprise, et la Matrise duvre (MOE), dans laquelle on trouve la Direction des systmes dinformation (DSI). La plupart des socits du CAC40 et les administrations sont dans ce schma. Aprs une runion du Cigref laquelle il vient dassister, Louis Naugs1 note, propos du rapport nomm Dynamique de cration de valeur par les Systmes dInformation : Il signe en tout cas la mort dnitive dune invention franco-franaise qui a fait beaucoup de dgts : la sparation matrise douvrage, matrise duvre. Comment imaginer une seconde une collaboration efcace entre informaticiens et mtiers sils ne travaillent pas ensemble, en permanence ? Effectivement, cette organisation de type MOA/MOE tend crer une sparation trs nette entre deux groupes. Cela contribue aux problmes suivants :
de la communication base sur des documents au dtriment de la communica-

tion orale, des spcications trop dtailles ds le dbut du projet, des documents redondants entre les deux entits,
1. Linventeur du mot bureautique : http://nauges.typepad.com

19.2 Des freins la diffusion ?

259

des documents qui mlangent le quoi et le comment, du temps perdu dans un processus de validation de documentation, des tests dacceptation passs tardivement.

Aussi quand on me demande aprs une prsentation Scrum si cest la MOA ou la MOE qui doit jouer le rle de Product Owner, je rponds quil faut dabord se dbarrasser de ces notions et de ce quelles impliquent avant de passer Scrum. Il convient de faire tomber les murs et de crer une seule quipe qui contribue au mme objectif (qui nest pas dcrire de la documentation). Le Product Owner fait partie de cette quipe avec ceux qui analysent, conoivent, dveloppent, testent, rdigent...

Choix du Product Owner


La MOA regroupant les personnes qui sont du ct mtier , il parat logique quun Product Owner soit choisi en son sein. Quelquun qui a t analyste mtier (Business Analyst), en assistance MOA, est un bon candidat pour ce rle. Mais cest gnralement le CPU (chef de projet utilisateurs) qui est choisi. Il est impratif davoir un Product Owner qui joue vraiment son rle, cest une condition sine qua non pour la russite des projets, cela ne se ngocie pas. Il ny a pas vraiment dalternative : la russite des projets, quon soit agile ou pas dailleurs, passe par une disponibilit importante du Product Owner. Certains en sont conscients et disent : On ne peut pas appliquer les mthodes agiles chez nous, parce que nous ne pourrions pas impliquer sufsamment nos MOA. Renoncer aux bienfaits de lagilit plutt que dessayer dimpliquer plus la MOA, cest prendre le problme lenvers. Au-del de lagilit, la pratique qui consiste impliquer les utilisateurs ( travers leur reprsentant) est considre comme cruciale pour le succs des projets, depuis des annes. Les tudes le disaient dj dans les annes quatre-vingt-dix. Alors, une meilleure solution serait de supprimer la MOA et la MOE... en commenant par supprimer les murs qui les sparent.

Supprimer les barrires entre MOA et MOE


Nous avons vu quune bonne faon de renforcer lesprit dquipe est davoir, au niveau logistique, un espace de travail ouvert. Le Product Owner, mme sil ny reste pas plein-temps, sera encourag y venir rgulirement. Une responsabilit habituelle de la MOA est le droulement des tests de recette. Avec Scrum, il ny a pas deux quipes, une de dveloppement et lautre de test, mais une seule quipe accueillant tous les participants au projet, y compris les testeurs, prsents dans lespace de travail.

Scrum sur le terrain, le retour de la communication


Les retours dexprience dans ce type dorganisation indiquent tous comme premier rsultat du passage Scrum le retour de la communication entre utilisateurs (MOA) et dveloppeurs (MOE). Pascal Renaut, linitiative de lintroduction de Scrum

260

Chapitre 19. Scrum en France

llectricit de Strasbourg, fait lanalogie avec un couple au bord du divorce qui se reforme : (avant Scrum) ...jen ai entendu de la part de la matrise douvrage : Pas assez vite, pas assez bien . La faute est bien entendu partager entre MOA/MOE, comme dans tous les couples, et il est vrai que le traditionnel cycle en V ne peut pas rpondre toutes les attentes. ... Jai trouv en Scrum le moyen de rconcilier ce couple en perdition. Rdaction de lexpression des besoins limite au plus strict ncessaire (user stories), petits moments de convivialits en quipe pour les estimations et les priorisations, dveloppements dans la foule, livraisons rgulires et on enchane comme cela de sprint en sprint. Il est nalement moins risqu et moins coteux de travailler MOA/MOE sur un projet commun (et non plus sparment projet MOA puis projet MOE) autour duquel on retrouve une quipe mobilise, soude et motive comme jamais.

19.2.2 Contrats au forfait, le mythe du primtre fix


Le malentendu entre contrat dit au forfait et agilit vient de lide que le primtre fonctionnel semble tre x lavance par le client. Mais cest un leurre : sauf pour de petits projets o on peut se passer de feedback ou dans les cas particuliers de spcication formelle, lexprience montre que cest impossible. Dans la ralit, le primtre, dune part nest pas strictement dni au dbut du projet, dautre part volue toujours. Partant de ce constat et du postulat de base qui est lacceptation du changement, quand on utilise Scrum on considre que le primtre est la variable dajustement. Il existe de nombreuses faons de rendre les contrats plus agiles. Pour en citer quelques-unes :
Dcomposer lappel doffres en deux parties : une premire pour valuer

la capacit du fournisseur (ou des fournisseurs) et une deuxime avec un engagement sur sa vlocit. Faire un contrat avec une enveloppe xe et un primtre valu par morceaux, de faon similaire ce qui se pratique pour les TMA (notion dunit duvre pour la tierce maintenance applicative). Faire un contrat de faon habituelle, mais en introduisant deux nouvelles clauses : changement gratuit et gagnant-gagnant . Dans tous les cas, la faon de faire les appels doffres devrait tre adapte pour introduire une faon de procder plus agile. Le backlog de produit est un lment essentiel de la dmarche agile. Il peut, selon les caractristiques du projet, tre annex lappel doffres ou ralis en commun entre client et fournisseur.

19.2 Des freins la diffusion ?

261

La clause changement gratuit


Cette clause offre la possibilit au client de changer davis sans que cela ne remette en cause le contrat, en restant prix constant. Le principe est le suivant : chaque n de sprint, le client peut changer davis sur le contenu du backlog (pour les stories qui nont pas encore t dveloppes), condition que ce quil ajoute soit contrebalanc par ce quil retire. Cela suppose que :
les lments du backlog soient estims en points, le client et le fournisseur sont daccord sur ces estimations, le Product Owner joue vraiment son rle en participant activement au projet.

Lintrt pour le client est quil peut avoir plus de valeur ajoute (ou utilit) pour un prix quivalent.

Story S Valeur ajoute

Story A

3 points

Cot

Figure 19.2 Plus de valeur pour le mme prix en ajoutant la story S et supprimant la story A

En fait, ce type de changement est dj pratiqu dans la plupart des projets au forfait au cours de ngociations entre client et fournisseur, mais en cachette puisque cest contraire au principe du primtre x lavance qui est la base juridique des contrats classiques.

La clause gagnant-gagnant
Cette clause permet au client darrter le contrat la n de chaque sprint. Comme lquipe livre une version la n de chaque sprint, le client peut faire du feedback et modier le backlog (cest la clause changement gratuit). Il peut aussi se rendre compte que le produit apporte sufsamment de valeur et dcider de le dployer en mettant un terme au contrat sans attendre la n prvue initialement. Dans ce cas, le fournisseur est pay au prorata des travaux effectus (les lments du backlog qui sont nis) plus un pourcentage (par exemple 20 %) de la diffrence entre le prix x au dpart et la somme obtenue par le prorata.

262

Chapitre 19. Scrum en France

Tout le monde sy retrouve :


le client parce quil a un produit qui lui apporte de la valeur et cote moins cher

que prvu (il a par exemple pay 60 % du prix pour un ensemble de stories qui reprsentent 80 % de son besoin en termes de valeur ajoute), le fournisseur parce quil est pay (le pourcentage) alors quil ne consomme plus de ressources (cette somme complmentaire sert aussi ddommager le prestataire qui doit raffecter ses quipes dans des dlais courts et non prvus initialement).

Valeur attendue au bout des 5 sprints 80% de la valeur

Valeur ajoute

Fin du sprint 3

Sprints

Figure 19.3 Le client a plus de 80 % de la valeur attendue la fin du sprint 3 pour 60 % du cot envisag (3 sprints sur 5)

Cette clause a un sens parce que les priorits dnissant lordre de ralisation dans les sprints sont bases sur la valeur. Le client peut ainsi mettre ce qui a le plus dutilit dans les premires itrations et dcider darrter parce que ce qui reste faire possde moins de valeur que cela ne cote.

19.3 LE FRENCH FLAIR POUR SCRUM


La France a bien adopt le rugby import dAngleterre il y a plus de 100 ans et a a donn le french air qui, bien sil se perde malheureusement un peu, est toujours la rfrence du jeu la franaise. Le french air est possible par la libert qui est laisse au joueur pour prendre des initiatives en fonction de la situation plutt que de suivre aveuglment les schmas de jeu dnis lavance. Dans une quipe Scrum, comme dans une quipe de rugby, la libert de se rebeller doit tre permise, voire favorise. Le bon fonctionnement dune quipe nempche pas

19.3 Le french flair pour Scrum

263

quune personne fasse, un moment du projet, ce dont elle a envie et qui va nalement rpondre au besoin de tous. Cest ce quon appelle lintelligence situationnelle. On peut aussi considrer que la transition vers un processus agile est une rbellion positive. Cest une remise en question des normes tablies et de lautorit hirarchique ainsi quune volont de faire sauter le vernis des hypocrisies, des traditions surannes et des prjugs tenaces. Je pense que le dveloppeur franais, peut-tre par sa culture de descendant de rvolutionnaire, garde souvent cette libert dinitiative. Cest ce que me conrme Jamel Marzouki1 , qui aprs avoir travaill en France ctoie des quipes amricaines et chinoises ; il vit Chicago depuis plus de dix ans et se dplace souvent Shanga : Les Franais, dans le domaine du logiciel, sont plus enclins lvolution et au changement quailleurs ... Je pense que cela est d lducation : les tudiants reoivent trs tt une introduction la culture Gnie Logiciel dans sa globalit, ne se rduisant pas uniquement aux langages de programmation. De mon ct, jai eu moins de contacts avec des dveloppeurs dautres pays ; mais les quelques Allemands que jai vu travailler mont paru bien moins agiles que les Franais. lpoque o jtais dveloppeur, les initiatives taient encourages et il y avait un rel plaisir raliser un projet en quipe. Ctait il y a longtemps et depuis, il semble que la qualit de vie des informaticiens se soit dgrade en France, au moins dans les grandes structures. Mon souhait est que Scrum contribue remettre laspect humain au cur des projets, tout en contribuant renforcer la qualit des produits dvelopps. Cest dans cet esprit que jenseigne Scrum mes tudiants en gnie logiciel et, les voyant lappliquer, je nai aucun doute sur ladquation des mthodes agiles avec le caractre franais

1. Au cours dune conversation personnelle.

Rfrences bibliographiques
Webographie Articles sur Scrum rfrencs dans le livre En anglais Scrum Guide, Ken S CHWABER , http://www.scrumalliance.org/resources. En franais Scrum et XP depuis les tranches, Henrik Kniberg, traduit en franais par Guillaume Mathias, Bruno Orsier, Emmanuel Etasse, Christophe Bunn, http://henrik-kniberg.developpez.com/livre/scrum-xp/. Blogs
En anglais Il y en a des dizaines ! Un bon nombre apparaissent dans cet

agrgateur : http://www.agilevoices.com/aggregator/sources.
En franais Les plus intressants sur Scrum et les mthodes agiles :

tre agile, Thierry C ROS, http://etreagile.thierrycros.net Le blog agile dAlex, Alexandre B OUTIN, http://www.agilex.fr/ Quality Street, Jean-Claude G ROSJEAN, http://www.qualitystreet.fr/ Emmanuel C HENU, http://emmanuelchenu.blogspot.com/

Bibliographie
En anglais

Mike C OHN, Succeeding with Agile : Software Development using Scrum, Addison Wesley, 2009. Mike C OHN , Agile Estimating and Planning, Prentice Hall, 2005. Roman P ICHLER, Agile Product Management with Scrum : Creating Products that Customers Love, Addison Wesley, 2010. Ken S CHWABER , Agile Project Management with Scrum, Microsoft Press, 2004. James S HORE, The Art of Agile Development, OReilly, 2007. En franais Per K ROLL et Philippe K RUCHTEN , Guide pratique du RUP, Campus Press, 2003. Vronique M ESSAGER R OTA , Gestion de projet, Vers les mthodes agiles, Eyrolles, 2007. Pierre V ILLEPREUX et Vincent B LACHON , Lesprit Rugby, Pearson Education, 2007.

Index

A
agilit 3

D
dfaut 140, 189, 217 dette technique 141, 214 directeur de produit 26

B
backlog de produit 29, 55, 57, 71, 124, 170, 178, 228 lment 62 priorit 60, 170 build 121, 212, 225 burndown chart 70, 99, 197 de release 83 de sprint 111

E
quipe 37, 44, 65, 71, 90, 97, 101, 106, 131, 179 auto-organisation 1, 51 espace de travail ouvert 91 estimation 75, 192 de backlog 76 de la valeur 193 tches 96 Extreme Programming 5

C
capacit 80, 199 crmonial Scrum 2 chef de produit 25 de projet 41 Cohn, Mike 18, 159, 168 cycle agile 12 de dveloppement 9, 10, 16 de vie 9 de vie Scrum 18 en V 9

F
features 168, 228

G
geeks 45

I
IceScrum 26, 83, 224 impediment 106

266

Scrum

intgration continue 212 itration 10

J
jalon 9, 15

Product Owner 25, 66, 90, 259 backlog 65 disponibilit 33 responsabilits 28 tests 37

R L
Lean 244 Software 5 RAF 207 refactoring 213 rfrentiel des exigences 56 release 10, 19, 70, 147, 167 n 23, 73, 141 remaniement de code 213 rtrospective 129, 130, 144 runions 2 de planication du sprint 90 revue de sprint 119, 144 dmonstration 122 roadmap 225

M
Manifeste agile 2, 156 mthode agile 1, 12 mtier 30 modle de cycle 9

O
obstacle 43, 110 outil 39, 60

S
Schwaber, Ken 5, 19, 35, 92, 151, 155 Scrum 5, 155 utilisateurs 255 Scrum Alliance 5 scrum quotidien 106 ScrumMaster (responsabilits) 42, 179 signication de ni 134, 139, 178 spike 217 sprint 10, 146, 188 but 95 de stabilisation 23 dure 14, 78 rtrospective 129 zro 20 StakeHolder 225 standup meeting 106 story 145 test 184 type 63

P
personas 172 phases 9, 15 plan de release 81, 123, 232 de sprint 98, 111 planication de release 70, 144 de sprint 235 de sprint 144 planning poker 76, 193 point 193 pratiques 3, 4, 152, 243 priorit 60, 229 priority poker 170 processus 9, 42

Index

267

storyless 91 Sutherland, Jeff 112

U
use-cases 176 user stories 173 utilit cardinale 194 ordinale 194

T
tableau des tches 236 tches 95, 115 technical debt 141 test dacceptation 203, 237 timebox 13, 74 timeline 133 traabilit 176

V
vlocit 70, 80, 87, 123, 198 vision 28, 166, 227