Conduite de projets agiles Conduite · des méthodes agiles dans les processus de développement. C’est tout ce retour d’expé-rience qu’il livre dans ce livre pour le plus

Julien PLÉE

Con

duite

de

proj

ets a

gile

s - M

anag

emen

t alte

rnat

if

isbn

: 978

-2-7

460-

9603

-5

Conduite de projets agilesManagement alternatif dans une équipe de développement agile

Julien PLÉE est Directeur Tech-nique Adjoint chez Talentsoft, éditeur logiciel de solutions RH. Arrivé en 2009 en tant que dé-veloppeur, il accède par la suite à ce poste de Responsable de la R&D où l’une de ses missions a consisté en la mise en place des méthodes agiles dans les processus de développement. C’est tout ce retour d’expé-rience qu’il livre dans ce livre pour le plus grand bénéfice des lecteurs avides de success story dans ce domaine.

Les chapitres du livre

45 €

Pour plus d’informations :

Contexte • Passage à l’agile • Ce qu’il faut savoir pour lire la suite • Mise en place des sprints • Méthodes utilisées • Réunions agiles • Gérer son projet agile • Outillage pour l’agilité • Retour d’expérience

Ce livre sur la conduite de projets agiles est un exemple de mise en œuvre des méthodes agiles chez un éditeur logiciel. L’auteur, Directeur Technique Adjoint au sein de l’organisation, décrit tout d’abord le cheminement qui a permis de trans-former son organisation en une organisation agile : circonscrire le contexte afin d’identifier les enjeux et objectifs, évaluer les apports et les contraintes d’un passage à l’agile pour les différents rôles qui vont être impliqués dans la nouvelle organisation, connaître les grands principes qui régissent les principales méthodes agiles ; Scrum, Kanban, Lean. L’auteur décrit les bonnes pratiques liées à l’or-ganisation des équipes et des projets et induites par les méthodes agiles adoptées.

Il détaille ensuite la mise en place précise des sprints, ou itérations, qui vont successivement aboutir à un projet réussi, grâce aux méthodes et processus qui leur seront appliqués, ainsi qu’aux différentes réunions qui seront mises en place. À cette étape, les rôles de chacun doivent être redéfinis précisément et une aide particulière du management peut être mise en place pour que chaque rôle retrouve sa place, d’où la notion de management alternatif décrit par l’auteur.

L’ensemble de ces points permet la mise en place d’une gestion de projet agile, avec l’organisation des équipes qui en découle, la gestion du backlog de produit et du backlog des architectures logicielles, la gestion de la qualité des logiciels, l’estimation des fonctionnalités ou des User Stories, la plani-fication des projets ou encore la mesure de la productivité des équipes de développement. L’auteur décrit enfin les outils bien spécifiques utilisés pour la gestion de projets agiles et termine par le retour d’expérience qu’il est indispen-sable de recueillir pour l’amélioration continue des futurs projets.

Management alternatif dans une équipe de développement agile

Conduite de projets agiles

1Table des matières

Chapitre 1Contexte

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2. Enjeu de Talentsoft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3. Objectifs de Talentsoft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4. L’agilité comme remède miracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.1 Mise en place de l’agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.2 Les problématiques actuelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5. La solution hybride . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Chapitre 2Passage à l'agile

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2. Cas des dirigeants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3. Cas des Product Owners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.1 Rôle et missions du Product Owner . . . . . . . . . . . . . . . . . . . . . . 273.2 Caractéristiques du Product Owner . . . . . . . . . . . . . . . . . . . . . . 293.3 Disponibilité du Product Owner . . . . . . . . . . . . . . . . . . . . . . . . 30

4. Cas des architectes logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5. Cas des équipes de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.1 Deux types de réactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.2 Bénéfices de l’agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.2.1 Collaboration avec le client . . . . . . . . . . . . . . . . . . . . . . . . 355.2.2 Motivation des équipes . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6. Cas des managers d’équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.1 Rôle du leader technique R&D . . . . . . . . . . . . . . . . . . . . . . . . . . 396.2 Équilibrer la pression dans l’équipe . . . . . . . . . . . . . . . . . . . . . . 396.3 Équilibrer qualité et productivité . . . . . . . . . . . . . . . . . . . . . . . . 416.4 Accompagner le changement . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.5 Devenir un leader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2Management alternatif dans une équipe de développement agile


7. Cas des clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

8. Contractualisation des livrables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Chapitre 3Ce qu'il faut savoir pour lire la suite

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2. Le manifeste agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472.1 Des individus et des interactions . . . . . . . . . . . . . . . . . . . . . . . . 492.2 Des logiciels opérationnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502.3 Une collaboration avec les clients . . . . . . . . . . . . . . . . . . . . . . . . 512.4 Une adaptation au changement . . . . . . . . . . . . . . . . . . . . . . . . . 52

3. Les méthodologies agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.2 Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.2.1 Value Stream Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.2.2 Limitation des travaux en cours . . . . . . . . . . . . . . . . . . . . 573.2.3 Mesure de Lead Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.2.4 En quoi Kanban peut-il aider une équipe ? . . . . . . . . . . . 58

3.3 eXtreme Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.4 Différences entre Scrum, Kanban et XP . . . . . . . . . . . . . . . . . . . 613.5 Lean Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.5.1 Lean Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.5.2 MVP et Build/Measure/Learn . . . . . . . . . . . . . . . . . . . . . . 63

3.6 Quelle méthodologie choisir ? . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4. Le sprint (ou itération) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.1 Priorités changeantes et sprint en cours . . . . . . . . . . . . . . . . . . . 654.2 Le sprint est un incrément fonctionnel . . . . . . . . . . . . . . . . . . . 66

5. Les backlogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.1 Backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.2 Backlog de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68


6. Les personae . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706.1 Donner du réalisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706.2 Comment procéder pour créer le persona ? . . . . . . . . . . . . . . . . 71

7. Les User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717.1 Format des User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727.2 INVEST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737.3 Epic Stories et taille des stories . . . . . . . . . . . . . . . . . . . . . . . . . . 76

7.3.1 Taille des User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777.3.2 Epic Stories et fonctionnalités . . . . . . . . . . . . . . . . . . . . . 78

7.4 Visibilité des User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787.5 Estimation des User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797.6 Critères d’acceptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7.6.1 Critères d’acceptation et Definition of Done . . . . . . . . . 847.6.2 Utilisation des critères d’acceptation . . . . . . . . . . . . . . . . 847.6.3 Format des critères d’acceptation . . . . . . . . . . . . . . . . . . . 85

7.7 Représentation des différentes Stories . . . . . . . . . . . . . . . . . . . . 85

8. Les Technical Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 868.1 Dette technique et architecture d’entreprise . . . . . . . . . . . . . . . 878.2 Tâches communes à plusieurs User Stories . . . . . . . . . . . . . . . . 89

9. Les boards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919.1 Scrum Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919.2 Kanban Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939.3 Autres boards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

10. Le Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9710.1 Intérêt du Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9710.2 Autres types de Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . 99



Chapitre 4Mise en place des sprints

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

2. Définir des processus de développement . . . . . . . . . . . . . . . . . . . . . 1012.1 Utilité des processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1022.2 Définition des processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

3. Exemple de processus complet dans une méthodologie agile . . . . . 105

4. Passage d’une étape à l’autre : la Definition of Done . . . . . . . . . . . 1104.1 Spécifier ses Definitions of Done . . . . . . . . . . . . . . . . . . . . . . . 1114.2 Types de Definition of Done . . . . . . . . . . . . . . . . . . . . . . . . . . 1124.3 Exhaustivité et évolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1124.4 Bénéfices de la Definition of Done . . . . . . . . . . . . . . . . . . . . . . 114

4.4.1 Responsabilisation des développeurs . . . . . . . . . . . . . . . 1144.4.2 Qualité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

5. Rôle des architectes logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1155.1 Impacts des méthodes agiles sur le rôle de l’architecte . . . . . . 1165.2 Architectes (du) système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1195.3 Architectes d’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

6. Rôle du chargé de projet technique . . . . . . . . . . . . . . . . . . . . . . . . . 1246.1 Impacts des méthodes agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 1246.2 Rôle du chargé de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

7. Documentation des projets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

8. Gestion de la dette technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1308.1 Dette technique en environnement réel . . . . . . . . . . . . . . . . . 130

8.1.1 Impacts sur la satisfaction client . . . . . . . . . . . . . . . . . . 1318.1.2 Impacts sur la gestion de projet . . . . . . . . . . . . . . . . . . . 1318.1.3 Impacts sur la prévisibilité . . . . . . . . . . . . . . . . . . . . . . . 134

8.2 Gestion de la dette technique au quotidien . . . . . . . . . . . . . . . 1358.2.1 Sensibilisation du management . . . . . . . . . . . . . . . . . . . 1358.2.2 Dédier des ressources à la dette technique . . . . . . . . . . . 137


8.2.3 Résorber la dette technique dans tout développement . . . . . . . . . . . . . . . . . . . . . . . . 138

8.3 Incapacité à rembourser ses dettes . . . . . . . . . . . . . . . . . . . . . . 139

9. Durée d’un sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Chapitre 5Méthodes utilisées

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

2. Communiquer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1452.1 Favoriser la communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 1462.2 Identifier les problèmes de communication . . . . . . . . . . . . . . . 1482.3 Résoudre les problèmes de communication . . . . . . . . . . . . . . . 149

3. Taille d’équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

4. Mise en situation du développeur . . . . . . . . . . . . . . . . . . . . . . . . . . 1534.1 Comprendre son projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1534.2 Connaître les attentes du client . . . . . . . . . . . . . . . . . . . . . . . . 1544.3 Motiver en impliquant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

5. Travail en binôme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1565.1 Niveau 1 : répartition des tâches . . . . . . . . . . . . . . . . . . . . . . . 1575.2 Niveau 2 : Pair Programming . . . . . . . . . . . . . . . . . . . . . . . . . . 158

6. Règles de codage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1596.1 Référentiel de règles de codage . . . . . . . . . . . . . . . . . . . . . . . . . 1606.2 Champ d’application des règles de codage . . . . . . . . . . . . . . . . 160

7. Domain-Driven Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

8. Test-Driven Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1628.1 Bénéfices du TDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1648.2 TDD et dette technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

9. Behavior-Driven Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1659.1 Réduire la documentation produit . . . . . . . . . . . . . . . . . . . . . . 1659.2 Périmètre et coût . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166



10. Revues de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16810.1 Pair Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17210.2 Validation technique continue . . . . . . . . . . . . . . . . . . . . . . . . . 17210.3 Assurance qualité technique . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

11. Démonstrations régulières au Product Owner . . . . . . . . . . . . . . . . 173

12. Maquettage de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

13. Amélioration continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

14. Intégration continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17514.1 Couverture du code par les tests . . . . . . . . . . . . . . . . . . . . . . . . 17814.2 Analyse statique du code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17814.3 Automatisation des livraisons . . . . . . . . . . . . . . . . . . . . . . . . . 17914.4 Fréquence des livraisons et déploiement continu . . . . . . . . . . 17914.5 Intégration continue et dette technique . . . . . . . . . . . . . . . . . 181

15. Décliner le feedback pour en profiter au maximum. . . . . . . . . . . . . 18215.1 Early Adopters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18315.2 Tests A/B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18315.3 Utilité des réseaux sociaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18415.4 Fail Fast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18415.5 Rétrospectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18515.6 Encourager la communication . . . . . . . . . . . . . . . . . . . . . . . . . 185

16. 20 % de « Free Time » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18616.1 Essayer ses propres idées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18616.2 Origine des idées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18816.3 Organisation du Free Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

16.3.1Organisation du travail . . . . . . . . . . . . . . . . . . . . . . . . . . 18916.3.2Gestion du temps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

16.4 Distinguer Free Time et Roadmap . . . . . . . . . . . . . . . . . . . . . . 192


Chapitre 6Réunions agiles

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

2. Backlog Refinement Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1952.1 Utilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1962.2 Déroulement de la réunion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1972.3 Effets potentiels sur la priorisation . . . . . . . . . . . . . . . . . . . . . 198

3. Sprint Planning Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

4. Daily Scrum Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2004.1 Organisation des Scrum Meetings dans une grande équipe . . 2024.2 Scrum Meetings de Scrum Meetings . . . . . . . . . . . . . . . . . . . . 203

5. Revue de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

6. Rétrospective de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

7. Rétrospective d'anomalies (ou Post-Mortem) . . . . . . . . . . . . . . . . . 206

8. Présentations R&D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

9. Big Code Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

10. One on One Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

11. Synthèse des réunions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21111.1 Backlog Refinement Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . 21111.2 Sprint Planning Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21211.3 Daily Scrum Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21211.4 Revue de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21311.5 Rétrospective de sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21411.6 Rétrospective d'anomalies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21411.7 Présentations R&D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21511.8 Big Code Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21511.9 One on One Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216



Chapitre 7Gérer son projet agile

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

2. Gérer son équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2182.1 Organisation fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2192.2 Organisation en projets/produits . . . . . . . . . . . . . . . . . . . . . . . 2202.3 Organisation matricielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

3. Équipes et culture d’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

4. Gérer son backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2274.1 Prioriser son backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . 2274.2 Prioriser son backlog de sprint . . . . . . . . . . . . . . . . . . . . . . . . . 229

5. Gérer son backlog d’architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 2315.1 Effort d’architecture dans un projet . . . . . . . . . . . . . . . . . . . . . 2325.2 Organisation des travaux d’architecture . . . . . . . . . . . . . . . . . 2335.3 Organisation des équipes d’architecture . . . . . . . . . . . . . . . . . 234

6. Minimum Viable Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

7. Gérer la qualité et les anomalies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2367.1 Développer sur un socle instable . . . . . . . . . . . . . . . . . . . . . . . 236

7.1.1 Différents cas de figure . . . . . . . . . . . . . . . . . . . . . . . . . . 2377.1.2 Réduire la difficulté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

7.2 C’est l’auteur de l’anomalie qui la corrige . . . . . . . . . . . . . . . . 2407.2.1 Impliquer la chaîne de développement . . . . . . . . . . . . . 2407.2.2 Root Cause Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

7.3 Privilégier la qualité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

8. Estimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2428.1 Unité d’estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

8.1.1 Que représente un Story Point ? . . . . . . . . . . . . . . . . . . 2438.1.2 Estimation en unités de temps . . . . . . . . . . . . . . . . . . . . 2438.1.3 Estimation en Story Points . . . . . . . . . . . . . . . . . . . . . . . 246


8.2 Définir des Stories de référence . . . . . . . . . . . . . . . . . . . . . . . . . 2488.2.1 Périmètre de la référence . . . . . . . . . . . . . . . . . . . . . . . . . 2498.2.2 À quel moment définir des User Stories de référence ? . 250

8.3 Périmètre des User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2508.4 Manque d’informations pour estimer . . . . . . . . . . . . . . . . . . . 2518.5 Découpage en tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

8.5.1 Taille des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2538.5.2 Définir les tâches pour terminer une User Story . . . . . . 2538.5.3 Estimation des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

9. Planifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2559.1 Planification agile ou prédictive . . . . . . . . . . . . . . . . . . . . . . . . 2559.2 Vélocité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

9.2.1 Corriger la vélocité en fin de sprint . . . . . . . . . . . . . . . . 2629.2.2 Unifier la vélocité de plusieurs équipes . . . . . . . . . . . . . 2639.2.3 Planifier à long terme avec la vélocité . . . . . . . . . . . . . . 2649.2.4 Ne pas convertir les points en unités de temps . . . . . . . 265

9.3 Donner une date de fin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

10. Métriques agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26710.1 Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26710.2 Humeur de l’équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26910.3 Vélocité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

11. Vers l’autogestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

Chapitre 8Outillage pour l'agilité

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

2. Tableur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

3. Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

4. Tableau de post-its . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279



5. Outils d’ALM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2815.1 Jira Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

5.1.1 Pilotage des projets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2835.1.2 Simplification des tâches quotidiennes . . . . . . . . . . . . . 284

5.2 Team Foundation Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2845.2.1 Intégration de TFS dans l’écosystème logiciel . . . . . . . . 2855.2.2 Recueil du feedback avec TFS . . . . . . . . . . . . . . . . . . . . . 286

6. User Story Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

Chapitre 9Retour d'expérience

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

2. Retour des dirigeants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

3. Retour des Product Owners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290

4. Retour des architectes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

5. Retour du management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

6. Retour de l’équipe de développement . . . . . . . . . . . . . . . . . . . . . . . 292

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

101

Chapitre 4

Mise en place des sprints

Mise en place des sprints1. Introduction

Afin de parvenir à une mise en place efficace de ses sprints, l’équipe doitprendre en compte divers facteurs, qui vont de l’utilisation de processus précisde développement, à, par exemple, la définition du rôle des architectes logi-ciels qui va garantir leur bonne collaboration avec les équipes agiles, enpassant par la documentation des différentes fonctionnalités développées quin’est pas en option en développement agile.

2. Définir des processus de développement

Les processus sont inhérents au bon déroulement de tout projet, quelle quesoit la méthodologie employée pour en assurer la gestion.

De manière générale, travailler avec les méthodes agiles ne signifie certaine-ment pas travailler sans processus. La première valeur du manifeste Agile peutpourtant rapidement prêter à confusion :

« Individuals and interactions over processes and tools »

La page web officielle du manifeste agile donne la traduction suivante enfrançais : « les individus et leurs interactions plus que les processus et lesoutils ». Il faut comprendre que les individus et les interactions humaines pri-ment et non pas qu’elles effacent totalement les processus.

© E

dit

ions

EN

I -

All r

ights

rese

rved



Un projet de développement logiciel mené en agile ne pourrait être mené àbien sans une définition précise de processus.

2.1 Utilité des processus

Les processus permettent de définir, et de standardiser, les moyens et lesbonnes pratiques pour réaliser des étapes dans le cycle de développement logi-ciel. L’utilisation de processus dans l’équipe de développement permet donc denormaliser les méthodes de travail pour chaque étape et les livrables produitsqui leur sont relatifs.

Par exemple, il est utile de définir un processus de revue de code au sein del’équipe. Cela permet de poser les règles d’équipe sur la manière dont s’effec-tuent les revues, à quelle position se trouve la personne qui revoit le code parrapport à celle qui l’a codé, sur le moment où la revue s’effectue...

Exemple d’éléments définissant le processus pour la revue de code

Ci-dessous figurent deux exemples tirés de notre processus de revue decode. Le premier est relatif à la position du validateur par rapport au déve-loppeur, et le second est relatif au moment où s’effectue la revue dans lecycle de développement d’une User Story :

– « Le validateur ne doit pas faire partie du binôme qui a développé la UserStory afin d’éviter les biais cognitifs de conception. »

– « La revue s’effectue à chaque fin de User Story, et non à la fin de chaquetâche technique, pour que le validateur puisse mettre en relief le designtechnique avec la cohérence fonctionnelle des développements. »

Ce dernier exemple sur le moment auquel doit avoir lieu la validation induitaussi une définition de processus au sujet des User Stories car il induit lanécessité de disposer de User Stories avec un bon découpage, ce quipermet une revue qui a du sens. Ce afin que la validation d’une User Storyreste quelque chose d’efficace et de facilement intelligible pour le valida-teur.

103Mise en place des sprintsChapitre 4

Pour chaque étape du cycle de développement, il est donc nécessaire de sedemander fréquemment s’il ne manque pas un processus qui permettrait defluidifier, tout du moins de dégripper un mode de fonctionnement amélio-rable dans l’équipe. Ce questionnement introspectif sur la qualité de l’organi-sation du travail de l’équipe est à reproduire régulièrement dans une démarched’amélioration continue (cf. chapitre Méthodes utilisées - Décliner le feedbackpour en profiter au maximum).

La réciproque n’est pas vraie : cela ne signifie pas qu’il faille inclure des proces-sus dans toutes les étapes du cycle de développement. Il peut d’ailleurs s’avérerdangereux et contre-productif de le faire, car cela peut par exemple impacterles bénéfices d’une innovation qui pourrait être apportée par une liberté plusimportante laissée sur une étape de conception.

Pour saupoudrer le bon niveau de processus dans l’équipe, il faut partir duprincipe que les processus sont des aides, et non pas des contraintes. Tout pro-cessus coercitif pour l’innovation, qui fait perdre du temps en n’apportant pasde bénéfice, pas de qualité supplémentaire par exemple, ou un processus dereporting (suivi des travaux) sans aucun autre bénéfice que d’informer unresponsable qui n’en tire rien pour son propre travail, doit pouvoir être modi-fié ou retiré de l’ensemble des processus de l’équipe.

2.2 Définition des processus

Afin de réduire la définition des processus à son strict essentiel dès la créationde l’équipe, ou de la mise en place de son projet, il faut partir d’une feuilleblanche.

Pour rappel, une surenchère de processus conduirait inévitablement à unblocage des rouages de l’agilité, donc à un échec.

© E

dit

ions

EN

I -

All r

ights

rese

rved



Voici une méthode qui peut vous aider pour la mise en place des méthodesagiles dans votre structure :

– Démarrer à partir d’une feuille blanche.

– Reprendre dans l’ordre les valeurs du Manifeste agile (cf. chapitre Ce qu’ilfaut savoir pour lire la suite - Le manifeste agile) qui constituent un défri-chage des problèmes organisationnels en développement logiciel en suggé-rant les meilleures réponses d’après ses auteurs. Pour chaque valeur, mettreen place vos méthodes en ne vous basant que sur la première partie dechaque assertion. Ces méthodes permettent de mettre en œuvre ces valeurs.Par exemple, pour « les individus et leurs interactions plus que les processuset les outils », ne garder que « les individus et leurs interactions » puis com-mencer à lister les méthodes de votre organisation que vous pouvez mettreen place et qui répondent à cette phrase.

– Ensuite, si possible transformer chacune de vos méthodes, ou ajouter denouvelles méthodes, en prenant en compte la deuxième partie de chaqueassertion (celle qui commence par « plus que... »), et donc, en n’oubliant pasque cette deuxième partie est importante et qu’il y a de grandes chances quevos méthodes doivent également les prendre en compte pour le bonfonctionnement de votre organisation.

– Étoffer au besoin les méthodes déjà trouvées en vérifiant qu’elles répondentbien aux douze principes agiles découlant des quatre valeurs du manifeste(voir http://agilemanifesto.org/iso/fr/principles.html).

– Enfin, lister les problèmes rencontrés par le passé dans votre organisation etvos équipes et vérifier que les méthodes définies répondent également à cesproblèmes.

Remarque

Pour ce qui est de trouver les méthodes et les transformer afin de correspondreaux valeurs et principes du manifeste agile, connaître les méthodologiesagiles comme Scrum, Kanban, eXtreme Programming... est un accélérateur àla mise en place de bonnes méthodes. Il peut donc être utile de se renseignersur les principales méthodologies agiles avant d’effectuer vos définitions deméthodes.

105Mise en place des sprintsChapitre 4

C’est ainsi que vous obtenez une méthodologie qui prend en compte les pro-blèmes résolus par l’Agile et qui sont en l’occurrence, vos problèmes égale-ment. C’est ainsi que j’ai procédé dans la mise en place de l’agilité dans leséquipes de développement de mon entreprise pour obtenir finalement uneméthodologie composite qui utilise le meilleur de l’agilité pour notre contexte.

Il est également important de ne pas oublier les avantages des méthodologiesdites prédictives telles que le « cycle en V » ou la « cascade ». Nous avons prisle parti d’exécuter quelques rares projets dans ce mode car il convient parfoismieux (cf. chapitre Contexte - La solution hybride).

L’autre avantage de procéder ainsi est de mettre en pratique les principes duManifeste agile en partant de votre expérience dans votre société. Il est plusaisé de définir un mode de fonctionnement quand on est déjà bien au fait deses qualités et de ses limites, plutôt que de vouloir appliquer stricto sensu uneméthodologie qui pourrait subir l’effet de mode du moment sans savoir si elleest adaptée au contexte. L’effet pernicieux est alors qu’un processus peut pa-raître adapté au niveau « macro », c’est le principe de la vulgarisation d’uneméthodologie, mais provoquer des blocages au niveau « micro », et rendre pluslente et ardue l’adhésion de l’équipe au changement de méthodologie, équipequi aura alors la juste impression qu’on lui applique un changement aux ver-tus difficiles à percevoir...

3. Exemple de processus complet dans une méthodologie agile

Dans mes équipes de développement, nous avons mis en place un moyensimple et graphique pour que chacun puisse savoir quoi faire à chaque étapede développement d’une User Story : le cycle de vie d’une User Story est résu-mé à travers un tableau RACI (acronyme pour les rôles Responsable, Appro-bateur, Contributeur et Informé) qui est une matrice des responsabilités.

Les colonnes représentent les différents rôles en lien avec le développementd’une User Story et les lignes représentent les différentes phases du cycle devie de la User Story. Cela permet d’avoir une vision claire et rapide de ce quechacun doit faire à chaque étape de la réalisation.

© E

dit

ions

EN

I -

All r

ights

rese

rved



Cette pratique n’est a priori liée à aucune méthodologie agile, c’est juste unmoyen pratique de partager l’information.

Aussi, cette matrice RACI est un moyen simple d’exposer quelques-uns desprocessus liés à la réalisation d’une User Story dans les équipes de développe-ment.

Exemple de mise en œuvre d’une matrice RACI pour le cycle de vie d’une User Story :

Sur la capture d’écran ci-dessus, extraite du tableur constituant le RACI denos équipes, on peut voir les différentes étapes que franchit la User Story, deson écriture à la fin de sa réalisation, associées aux responsabilités des diffé-rents rôles de l’équipe.

Documents

Conduite de projets agiles Conduite · des méthodes agiles dans les processus de développement. C’est tout ce retour d’expé-rience qu’il livre dans ce livre pour le plus