Ce livre porte sur la Yves et la . Il est destiné aux qui sou- CMMI v. … · 2015. 7. 6. · un...

Modèles

CMMI v. 1.3

Yves TRÉHIN

Modèles CMMI v. 1.3Manuel d’utilisation à l’usage des professionnels des systèmes d’information Ce livre sur les modèles CMMI s’adresse à tous les responsables soucieux de la bonne marche de leur organisation et souhaitant mettre en place ou consolider des processus performants et solides. Il propose un éclairage sur les modèles d’organisation que sont les modèles CMMI (en ver-sion 1.3) dédiés au développement de systèmes (CMMI-DEV), à leur acquisition (CMMI-ACQ) ou aux services (CMMI-SVC) et vise à donner une appréhension concrète de ces modèles pour leur utilisation pratique dans les organisations. Le premier chapitre présente une synthèse de ce qu’est un modèle CMMI, indépendamment de son orientation développement, acquisition ou service. Il y est notamment répondu aux ques-tions suivantes : Qu’est-ce qu’un modèle CMMI ? À quoi sert-il ? Comment le modèle CMMI a-t-il été élaboré ? Quel est son avenir ?Les chapitres 2 à 5 proposent ensuite une revue détaillée du contenu des modèles CMMI en expliquant la structure et en commentant les bonnes pratiques proposées pour chacun ; les liens qui les unissent sont mis en évidence afin de dégager une cohérence d’ensemble lors de leur mise en œuvre sur le terrain. L’objectif n’est pas ici de présenter une simple traduction des pratiques retenues par les modèles mis à disposition par le SEI (le CMMI-DEV pour le développement d’un produit, le CMM-SVC pour les services et le CMMI-ACQ pour l’acquisition de produit ou de ser-vice), mais d’appréhender le sens de leur mise en œuvre collective au sein des organisations. Le chapitre 6 relève du manuel d’utilisation. Il présente l’utilisation concrète des pratiques du CMMI à travers l’étude de cas d’une direction des systèmes d’information souhaitant mettre en place des processus conformes au CMMI, pour le développement de ses applications et de son infrastructure informatique, ainsi que pour leur exploitation, tout en externalisant une partie de ses activités.Le chapitre 7 clôture la présentation des modèles CMMI et de leur mise en œuvre par une conclu-sion d’ensemble.Enfin, une annexe apporte un complément de pratiques important autour de la sécurité in-formatique. Ces pratiques ne sont pas aujourd’hui pleinement intégrées dans les modèles CMMI. Sous l’égide de l’université Carnegie Mellon, il existe toutefois un modèle de gestion abordant ce sujet. Il en est donné une vue globale afin d’orienter le lecteur vers des pratiques dont la mise en place est inévitablement à considérer par toute direction informatique.Des éléments complémentaires sont en téléchargement sur www.editions-eni.fr, ils constituent un kit pratique d’aide au déploiement d’un niveau de maturité 2 du modèle CMMI-DEV. Ce kit est un complément au chapitre 6 avec la mise à disposition d’outils relatifs aux sept domaines de processus du niveau de maturité 2.

Ingénieur, licencié en droit et diplô-mé en gestion d’entreprise, Yves TRÉHIN est aujourd’hui cadre à la direction des systèmes d’informa-tion d’un grand groupe industriel, en charge du contrôle interne. Pré-cédemment, il a exercé des respon-sabilités en gestion de projets et contrats dans le domaine aéronau-tique et spatial au sein d’organisa-tions françaises et internationales. Il a également une dizaine d’années d’expérience en qualité de consul-tant expert en amélioration des processus de développement infor-matique.Instructeur CMMI certifié par le SEI, Yves TRÉHIN est titulaire de plu-sieurs certifications professionnelles dans le domaine du management de projet, des processus et de l’audit des systèmes d’information : CISA, CRISC, PMP, Lead Auditor ISO27001, ITIL, eSCM. Il est égale-ment intervenant au mastère SYVAT de l’école des Arts et Métiers Paris-Tech, spécialisé dans la conduite de projets de systèmes intégrés aux véhicules aérospatiaux et terrestres.

45 €

isbn

: 978

-2-7

460-

6422

-5

Manuel d’utilisation à l’usage des professionnels des systèmes d’information

Les modèles CMMI • Architecture et noyau des modèles CMMI • La part spécifique au modèle CMMI-DEV • La part spécifique au modèle CMMI-SVC • La part spécifique au modèle CMMI-ACQ •Démarche d’amélioration guidée par les modèles CMMI • Conclusion • Annexe : La sécurité informatique

Les chapitres du livre

Téléchargementwww.editions-eni.fr.fr

sur www.editions-eni.fr : b éléments d’aide au

déploiement d’un niveau de maturité 2 du modèle CMMI-DEV.

Mod

èles

CM

MI v

. 1.3

(Avec un complément de pratiques sur la sécurité)

Diriger un projet web Agile

Edgard MAILLOT

45 €

isbn

: 978

-2-7

460-

9661

-5

Utilisez la dynamique des groupes pour décupler Scrum

Diriger un projet web Agile Utilisez la dynamique des groupes pour décupler ScrumCe livre porte sur la direction de projets et aborde deux sujets en dé-taillant leur mise en œuvre opérationnelle : la méthode Scrum et la dy-namique des groupes. Il est destiné aux directeurs de projets qui sou-haitent rendre leur management plus agile afin de profiter pleinement des bénéfices de la méthode Scrum, mais également aux chefs de projets qui souhaitent endosser un rôle de direction, et enfin aux équipes Scrum qui désirent accroître leur efficacité.

Scrum impliquant de mettre en œuvre des équipes autogérées, sans « chef de projet », son adoption par les entreprises représente un nouveau mo-dèle de gestion de projet, tant sur le plan opérationnel qu’humain. Cette méthode bouleverse non seulement les processus, mais également les rapports de pouvoir, impactant fortement le mode de management. Le livre décrit les différentes techniques de gestion d’équipes autogérées, directement issues de la dynamique des groupes, permettant d’accroître l’efficacité et de conserver un contrôle opérationnel. Le livre met égale-ment en lumière les principales spécificités des projets liés au web : les inter-faces, l’expérience utilisateur et l’encadrement des directeurs artistiques.

Il est scindé en quatre parties représentant les grandes étapes de la vie d’un projet (la découverte du projet, son initialisation, sa réalisation, sa clô-ture), permettant au lecteur de constater les écarts entre ce qu’il pratique et ce qu’il faudrait pratiquer selon une chronologie qui lui est familière. Il aborde toutes les fonctions essentielles de la direction d’un projet, de la constitution et l’animation des équipes à la gestion des plannings et indicateurs de performances, en passant par l’organisation et l’ani-mation des différentes réunions et organes de décision liés à un projet.

Le livre apporte de manière méthodique des réponses concrètes, issues d’une expérience sur le terrain. Il décrit comment adapter un management efficace dans le cadre du déploiement de Scrum. Face à la démultiplication du web dans toutes les entreprises, il apporte un retour sur expérience pragmatique et essentiel à la bonne appropriation des spécifi-cités de ces nouvelles technologies.

Edgard Maillot est Directeur de projet depuis plus de 15 ans. Aujourd’hui, dans le cadre de son cabinet de conseil en stratégie digitale, il intervient auprès des entreprises sur des missions de maîtrise d’ouvrage, maî-trise d’œuvre, cadrage de projet, conseil en organisation. Sa longue expérience dans ce domaine lui a permis de voir les évolutions méthodologiques mais aussi humaines en termes de management de projets et four-nit au lecteur un livre réellement efficace sur la direction d’un projet Agile.

Avant-propos • Partie 1 : La découverte du projet • Identifier le périmètre • La méthode de gestion de projet • Partie 2 : Initialiser le projet • Organiser le projet • Constituer l’équipe • Planifier la produc-tion • Valider le projet • Partie 3 : Réaliser le projet • Spécificités du Web • Version zéro ou prototype • Gérer les itérations • Gérer l’équipe • Organiser les réunions • Piloter le projet • Partie 4 : Clore le projet • Sur le plan opérationnel • Sur le plan humain • Glossaire • Bibliographie

Les chapitres du livre

Dirig

er u

n pr

ojet

web

Agi

le

Pour plus d’informations :

1Table des matières

Avant-propos

1. Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2. Objectif de ce livre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3. À qui s'adresse ce livre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4. Comment est structuré ce livre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Partie 1 : La découverte du projet

Chapitre 1Identifier le périmètre

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2. L'origine du projet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3. L'impact du projet sur l'entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.1 Impact sur les utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2 Impact sur les contributeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3 Impact sur les acteurs indirects . . . . . . . . . . . . . . . . . . . . . . . . . . 213.4 Comment procéder ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4. L'engagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.1 L'engagement du sponsor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2 L'engagement des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.3 L'engagement des contributeurs . . . . . . . . . . . . . . . . . . . . . . . . . 244.4 Son engagement personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5. Se préparer méthodiquement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6. Les objectifs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.1 Analyse des objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.2 Utilisation d'une matrice SWOT. . . . . . . . . . . . . . . . . . . . . . . . . 33

7. Les moyens envisagés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

8. La reformulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2Utilisez la dynamique des groupes pour décupler Scrum


Chapitre 2La méthode de gestion de projet

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2. Pourquoi une méthode ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3. Bénéfices d'une méthode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4. Historique des cycles et méthodes . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5. Cycle en cascade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6. Cycle en V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7. Cycle en spirale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

8. Cycle itératif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

9. Devenir agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Partie 2 : Initialiser le projet

Chapitre 3Organiser le projet

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

2. Mode de pilotage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3. Contrainte majeure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4. Constitution d'une liste exhaustive des contraintes . . . . . . . . . . . . . 714.1 Contraintes d'image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.2 Contraintes contextuelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.3 Contraintes opérationnelles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.4 Contraintes techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.5 Contraintes légales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.6 Contraintes sociales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.7 Contraintes écoresponsables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5. Interdépendances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74


6. Macroplanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746.1 Formule McConnell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756.2 Modèle COCOMO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.3 Définir les itérations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

7. Définition du périmètre fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . 807.1 Solutions et méthodes de définition de périmètre . . . . . . . . . . . 817.2 Matrice de gestion de périmètre . . . . . . . . . . . . . . . . . . . . . . . . . 827.3 Granularité et exhaustivité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

8. Identification des dépendances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

9. Acteurs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

10. Les locaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

11. Outils projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

12. Évaluation des risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9212.1 Pilotage des risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9312.2 Criticité des risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9412.3 Identification des risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9512.4 Risques les plus fréquents sur un projet web . . . . . . . . . . . . . . . 96

Chapitre 4Constituer l'équipe

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

2. Agilité et dynamique des groupes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

3. Performance de l'équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

4. Objectif de la mission. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

5. Composition de l'équipe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

6. Constituer plusieurs équipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

7. Le leader agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

8. Ambiance au sein de l'équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

9. Gestion des indésirables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121



Chapitre 5Planifier la production

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

2. Missionner l'équipe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

3. Mise en place des comités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

4. Plan de communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1294.1 Cibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1304.2 Risques de communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1334.3 Angle de communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1334.4 Modes de communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1344.5 Communication montante ou descendante . . . . . . . . . . . . . . . 1354.6 Stratégie de communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 1354.7 Mesure de la communication . . . . . . . . . . . . . . . . . . . . . . . . . . 138

5. Plan qualité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1395.1 Le plan qualité, pour quoi faire ? . . . . . . . . . . . . . . . . . . . . . . . . 1415.2 Définition de la qualité du produit livré . . . . . . . . . . . . . . . . . . 141

6. KPI de gestion projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1446.1 EVPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1456.2 KPI de qualité produite. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1516.3 KPI de qualité perçue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

7. Lotissement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

8. Planification des lots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Chapitre 6Valider le projet

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

2. Pourquoi valider ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

3. Comment valider ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

4. Bien démarrer le projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166


Partie 3 : Réaliser le projet

Chapitre 7Spécificités du Web

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

2. Création graphique et méthodes agiles . . . . . . . . . . . . . . . . . . . . . . . 1692.1 Premier dilemme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1702.2 Second dilemme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1712.3 Commençons par ce qu'il ne faut pas faire . . . . . . . . . . . . . . . . 1722.4 Première solution : découplage du front office . . . . . . . . . . . . . 1732.5 Seconde solution : le brassage culturel . . . . . . . . . . . . . . . . . . . 173

3. Découplage des interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

4. Expérience utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

5. Importance des interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Chapitre 8Version zéro ou prototype

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

2. Avantages du prototype. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

3. Approche minimaliste : wireframe . . . . . . . . . . . . . . . . . . . . . . . . . . 182

4. Bénéficier pleinement du prototype . . . . . . . . . . . . . . . . . . . . . . . . . 1834.1 Approche jetable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1834.2 Approche pérenne. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185



Chapitre 9Gérer les itérations

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

2. Participer aux réunions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1872.1 Influence du manager sur l'équipe. . . . . . . . . . . . . . . . . . . . . . . 1882.2 Réalité du terrain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

3. Planning poker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

4. Fin de release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1934.1 Faire le bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1934.2 Annonce des prochaines étapes . . . . . . . . . . . . . . . . . . . . . . . . . 193

Chapitre 10Gérer l'équipe

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

2. Principes agiles et dynamique des groupes . . . . . . . . . . . . . . . . . . . . 195

3. Cycle de vie de l'équipe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1983.1 Forming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1983.2 Storming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1993.3 Norming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2003.4 Performing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2013.5 Adjourning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

4. Contrôler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2024.1 Contrôle non mesuré . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

4.1.1 Échange informel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2034.1.2 Échange formel irrégulier . . . . . . . . . . . . . . . . . . . . . . . . . 203

4.2 Contrôle mesuré . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2044.2.1 Échange formel régulier . . . . . . . . . . . . . . . . . . . . . . . . . . 204

4.3 Mesurer l'efficacité du Product Owner et du Scrum Master . . 204

5. L’effet Janis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207


6. Autres risques potentiels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2086.1 Pression sociale négative ou antiproductive . . . . . . . . . . . . . . . 2086.2 Déportation de menace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2096.3 Modification de l'équipe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2106.4 Polarisation de l'équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2116.5 Leader super-héros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2126.6 Leader antihéros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

Chapitre 11Organiser les réunions

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

2. Les différents types de réunions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2152.1 La réunion de détente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2162.2 La réunion d'information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

2.2.1 Le monologue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2182.2.2 Le dialogue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2182.2.3 L'échange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

2.3 La réunion de gestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2192.4 La réunion de prise de décision . . . . . . . . . . . . . . . . . . . . . . . . . 220

3. Préparer la réunion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2213.1 Préparation matérielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2213.2 Préparation des intervenants . . . . . . . . . . . . . . . . . . . . . . . . . . . 2223.3 Préparation opérationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2223.4 Préparation exceptionnelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

4. Initier la réunion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

5. Animer la réunion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2245.1 Respecter l'ordre du jour. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2245.2 Gérer chaque sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2245.3 Gérer les dépassements de délai . . . . . . . . . . . . . . . . . . . . . . . . . 2255.4 Ne pas mélanger tous les types de réunion en une seule . . . . . 225



6. Gérer les cas difficiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2256.1 Monsieur je-sais-tout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2256.2 Le silencieux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2266.3 Le saboteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2266.4 La girouette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2266.5 Le nomophobe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2276.6 L'excité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2276.7 Le déviant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

7. Clore la réunion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2297.1 Terminer à l'heure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2297.2 Résumer et conclure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2297.3 Partager le compte rendu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

Chapitre 12Piloter le projet

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

2. Pilotage par les indicateurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2312.1 Savoir lire entre les lignes des indicateurs . . . . . . . . . . . . . . . . . 2322.2 Interpréter correctement un burndown chart . . . . . . . . . . . . . 2332.3 Mesurer la vélocité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2352.4 Vélocité et dynamique des groupes . . . . . . . . . . . . . . . . . . . . . . 2362.5 Analyser le backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2382.6 Mesures croisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2392.7 Mesurer les changements de périmètre. . . . . . . . . . . . . . . . . . . 2402.8 Burndown chart de release alternatif . . . . . . . . . . . . . . . . . . . . 241

3. Application du Genchi Genbutsu . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

4. Gestion des dérives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2434.1 Story immature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2444.2 Release incomplète . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2444.3 Problèmes de vélocité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2454.4 Gérer le moral de l'équipe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245


4.5 S'exposer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

5. Gestion des conflits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2465.1 Étapes et formes de conflit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2475.2 Stratégie de gestion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2475.3 Résolution des conflits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2485.4 Focus sur les conflits dans l'équipe . . . . . . . . . . . . . . . . . . . . . . 249

6. Focus sur les objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2526.1 Modification des objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2526.2 Modifications subtiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

7. Saisir les opportunités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2537.1 Exemple du web call back . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2547.2 Fragilité des opportunités. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

8. Rendre compte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2568.1 Communiquer efficacement . . . . . . . . . . . . . . . . . . . . . . . . . . . 2568.2 Communiquer vers les bonnes cibles . . . . . . . . . . . . . . . . . . . . 2568.3 Communiquer régulièrement . . . . . . . . . . . . . . . . . . . . . . . . . . 2578.4 Gérer la pression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

Partie 4 : Clore le projet

Chapitre 13Clore le projet sur le plan opérationnel

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

2. Transférer les compétences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

3. Archiver les ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

4. Clore les communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

5. Faire le bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2645.1 Bilan matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2645.2 Bilan humain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2645.3 Partage des bilans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265



Chapitre 14Clore le projet sur le plan humain

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

2. Faire la rétrospective de projet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2672.1 Fixer clairement l'objectif et les moyens . . . . . . . . . . . . . . . . . . 2682.2 Convier les bonnes personnes . . . . . . . . . . . . . . . . . . . . . . . . . . 2682.3 Préparer la rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2692.4 Conduire la réunion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2692.5 Analyser et restituer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

3. Prendre le temps de se séparer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2703.1 Souligner les efforts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2703.2 Accorder un dernier moment d'intimité . . . . . . . . . . . . . . . . . . 271

Glossaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

Bibliographie

1. Méthodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

2. Dynamique des groupes ou sociologie . . . . . . . . . . . . . . . . . . . . . . . 283

3. Autre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

99

Chapitre 4

Constituer l'équipe

Constituer l'équipe1. Introduction

La constitution de l’équipe consistait autrefois à rassembler autant de chefs deprojets qu'il y avait de lots dans le programme pour leur déléguer à chacun unepart de responsabilité.

S'il est envisageable de procéder de la même manière avec Scrum et de n'appli-quer cette méthode qu'au niveau des équipes dépendant des chefs de projets,il est plus intéressant d'étendre l'agilité à l'ensemble du programme.

Cela implique alors de profondes modifications d'organisation, mais aussi demanagement, bref une revue quasi intégrale du modèle de gouvernance.

2. Agilité et dynamique des groupes

Toutes les méthodes agiles disposent d'un certain nombre de pointscommuns :

– On se focalise sur l'équipe qui réalise le produit plutôt que sur les processus.

– L'équipe est auto-organisée et respecte un cérémonial.

– Il n'y a plus de rôle de chef de projet. Le client ou l'utilisateur est en contactdirect avec l'équipe qui développe avec lui le produit dont il a besoin.

– Le produit est réalisé par itérations successives.

© E

dit

ions

EN

I -

All r

ights

rese

rved



Le fait que l'équipe soit autogérée nous amène naturellement à prendre encompte les effets démontrés dans la dynamique des groupes. Ce conceptpsychosocial, élaboré par Kurt Lewin après la Première Guerre mondiale,décrit les interactions entre les individus au sein d'un groupe et dans le cas quinous intéresse, l'équipe. De nombreux chercheurs ont démontré qu'au sein dechaque groupe s'exerce une pression sociale, c'est-à-dire un ensemble de codeset de comportements qui sont imposés au groupe par le groupe. Si le groupen'est pas dirigé par un chef, il engendrera naturellement un leader, figurereprésentative de l'ensemble des codes et comportements mis en place par legroupe. Ce chef peut être assimilé au chef de tribu, reconnu par les membrescomme son représentant incarnant les valeurs du groupe. Il se comporte plussouvent en guide qu'en dictateur. Une seconde figure peut également émerger,le chaman. Ce personnage ne se révèle pas par sa capacité à représenter, ouporter les valeurs du groupe, il peut parfois même être déviant. En revanche,il dispose d'un savoir utile et reconnu par le groupe, une expertise.

L'agilité présente de nombreux avantages en termes d'efficacité et de gain deperformance. Si ce constat est réellement mesurable sur le terrain, la littéra-ture scientifique sur la dynamique des groupes restreints conduit à en démon-trer les causes.

– L'équipe, définissant elle-même les conditions et constituantes de l'itérationen cours, contribue ainsi à fixer ses propres objectifs, réalistes, atteignableset utiles.

– L'équipe auto-organisée exerce sur elle-même une pression sociale renfor-çant le sentiment de former une entité unique créant ainsi une forte cohé-sion, ce qui accroît son efficacité.

– L'absence de leader imposé crée l'apparition d'un leader naturel. L'équipe aalors le sentiment de l'avoir choisi et son autorité est ainsi légitimée.

Ainsi dans le cas de Scrum, lorsque le Scrum Master est imposé, l'équipe com-mence par le défier plus ou moins ouvertement, ou éprouve ses compétences.A contrario, s'il est choisi par l'équipe, c'est toute l'équipe qui exercera unepression sur le membre qui mettrait en doute sa légitimité. Le Scrum Masterpeut alors agir en réel facilitateur.

101Constituer l'équipeChapitre 4

Sauf dans des cas extrêmes, mais nous approfondirons ce point dans la gestionde l'équipe lors de la production, il est préférable de laisser l'équipe désignerson propre Scrum Master plutôt que de l'imposer.

En revanche, de par sa nature et son rôle, le client, l'utilisateur, ou ProductOwner ne peut pas être considéré par l'équipe comme son chef, mais commele représentant d'un groupe externe à l'équipe et avec qui elle est obligée detraiter. Il agit donc sur l'équipe à la fois comme une contrainte à respecter,mais également comme une pression sociale externe.

Si le PO se montre exigeant dans la qualité des livrables, l'équipe aura tendanceà modifier son comportement et sa propre pression sociale. Les membreslivrant un travail de piètre qualité seront moins bien considérés que ceux cher-chant à atteindre l'excellence.

De la même manière, si le client ou Product Owner démontre par son attitudeun laisser-aller, privilégiant le ça fonctionne plutôt que le c'est optimum, l'équipemodifiera son comportement et adaptera la pression sociale qui la régit à cemodèle.

L'émergence naturelle du leader étant conditionnée par la légitimité qu'ilreprésente par rapport à la pression sociale exercée par le groupe, l'attitude duclient peut donc influer sur le choix du leader par l'équipe.

Ceci nous amène à un double constat :

1. Le client ou Product Owner a un impact très important sur l'équipe.

2. Il fait partie d'un autre groupe avec lequel l'équipe doit échanger.

Le deuxième point présente des enjeux majeurs pour le bon déroulement duprojet, principalement lors de la mise en œuvre d'un proxy Product Owner.

Il est évident que lorsqu'un membre des utilisateurs remplit le rôle de ProductOwner, la pression sociale exercée par son groupe d'appartenance (c'est-à-direses collègues, futurs utilisateurs de l'application développée pour eux) est for-tement bénéfique. Le Product Owner est alors non seulement investi d'unemission, mais ses collègues comptent sur lui et exercent ainsi une pression po-sitive. Les intérêts personnels de chaque membre de son groupe convergentvers un objectif, la réussite du projet. Le projet devra être facile à utiliser,simple à prendre en main, donc ne pas présenter trop d'innovations, mais uni-quement celles représentant une réelle valeur ajoutée.

© E

dit

ions

EN

I -

All r

ights

rese

rved



Dans le cadre d'un proxy Product Owner, la pression sociale que son grouped'appartenance exerce sur lui pourrait être différente.

S'il s'agit d'un consultant externe, il est recruté pour ses compétences sur uneméthode, ses facultés à modéliser des processus et sa connaissance du métierexercé par le client. Il passe du temps avec ce dernier pour comprendre lesenjeux du projet et les processus à informatiser, mais il n'appartient pas augroupe client. La pression sociale exercée par cette entité sur lui est quasimentnulle. En revanche, il est soumis à celle de sa société, qui a des objectifs biendifférents de ceux du client : compétitivité, fidélisation, satisfaction...

Dans ce contexte, le proxy Product Owner cherchera inconsciemment à satis-faire en priorité son client à lui. S'il est engagé par le client final donc contrac-tuellement lié à ce dernier, ce n'est pas le même schéma que si sa société a étéchoisie par le même service qui réalise le produit pour le client : dans le premiercas il cherche à satisfaire l’utilisateur final alors que dans le second cas ilcherche à satisfaire le maître d’œuvre.

Le choix du représentant du client est donc un élément critique participant àla bonne réalisation du projet. Les différents Product Owners missionnés surle projet formeront la colonne vertébrale de celui-ci et l'équipe rapprochée dudirecteur de projet. L’attention du directeur de projet en tant que managerdoit être focalisée sur ces quelques personnes.

3. Performance de l'équipe

Constituer puis gérer correctement une équipe nécessite de comprendre sesmodes de fonctionnement. Nous avons abordé rapidement les impacts desméthodes agiles sur les équipes mais il reste de nombreux points à prendre encompte si nous voulons mettre toutes les chances de notre côté.

En 1977, Tuckman a démontré qu'une équipe passait par cinq stades d’évolu-tion, qu'elle devait affronter successivement, et que sa performance s'accrois-sait à mesure qu'elle progressait :

1. Forming : c'est la rencontre de l'équipe où chacun va progressivementdécouvrir les autres membres avec leurs caractéristiques personnelles et pro-fessionnelles.

103Constituer l'équipeChapitre 4

2. Storming : c'est une étape de prise de position, d'affrontements, lors delaquelle les membres marqueront à la fois leur identité et leur appartenance augroupe.

3. Norming : à ce stade, l'équipe a trouvé ses marques et ses membres appren-nent à travailler ensemble, à respecter des codes de conduite inhérents àl'équipe.

4. Performing : l'équipe atteint sa pleine performance. Chaque membre saitcomment s'appuyer sur les autres, dans quel contexte et de quelle manière.

5. Adjourning : cette étape représente la dissolution de l'équipe.

Constituer et manager une bonne équipe, capable d'arriver à la phase quatreen peu de temps, est une tâche si complexe, qu'une vie entière consacrée à ceseul sujet ne suffirait pas pour en maîtriser toutes les subtilités. Pour s'enconvaincre, il suffit de consulter le nombre de publications parues autour dela dynamique des groupes initiée par Elton Mayo, Kurt Lewin et JacobMoreno autour des années 1930-1940, puis développée en France par DidierAnzieu, Roger Mucchielli et al.

Ces auteurs distinguent cinq types de groupes, allant de la foule au groupesecondaire. Dans cette littérature, nous nous focalisons sur un type particu-lier, le groupe primaire, ou groupe restreint, correspondant dans sa définitionà une équipe de production sur un projet web.

Si tout le monde s'accorde à dire que la réussite d'une équipe repose sur lasomme des compétences individuelles, de nombreuses études (dontHackman, 1990, Cohen et Bailey, 1997) ont démontré que certes c'est unfacteur déterminant, mais qu'il existe de nombreux autres éléments quiviennent le renforcer ou peuvent l'annihiler. Ainsi, si nous engagions BobMartin, Martin Fowler, Mike Cohn, Ken Schwaber, Craig Larman et j'enoublie, dans la même équipe, nous ne serions pas sûrs d'avoir la meilleureéquipe ? Eh bien non et c'est démontré. En réalité, il y a huit facteurs quiinfluencent la performance de l'équipe. Ils ont été déterminés au travers dedifférentes études menées via le modèle IPO (Input-Process-Output).

© E

dit

ions

EN

I -

All r

ights

rese

rved



1 - L'objectif de la mission doit être clair et accessible. Si l'équipe a la convic-tion qu'elle n'est pas en mesure d'atteindre l'objectif, elle doutera et arrivera àse démobiliser. Cette démobilisation peut se traduire par des taux d’absen-téisme élevés, ou par une perte d'initiative allant jusqu'à la stupide obéissance.Si l'objectif n'est pas clair, il y a également une perte d'efficacité en plus desrisques de dissension dans l'équipe, à cause des interprétations différentes quipeuvent survenir d'un objectif confus. (NB : selon les études, les places occu-pées par l'objectif, la composition de l'équipe et le rôle du leader se trouventinterverties mais restent dans les premiers éléments influençant la perfor-mance de l'équipe.)

2 - La composition de l'équipe, tant par la complémentarité des compé-tences mais également par la variété des personnalités ou de leur parcoursindividuel est un élément important que l'on retrouve de façon récurrentedans différentes études. La qualité de la composition de l'équipe est bien sûrdéterminée par les compétences de chaque membre, mais également par lenombre de membres de l'équipe. Plus le groupe est nombreux et plus les diffi-cultés de communication sont récurrentes. Des sous-groupes, ou clans se for-ment et l'efficacité de l'ensemble s'en trouve diminuée. La taille idéale d'uneéquipe est de cinq à sept personnes. Au-delà de dix, il est préférable de mettreen place plusieurs équipes distinctes.

3 - Le leader, et surtout le mode de management qu'il met en place, joue unrôle déterminant. Kurt Lewin, inventeur de la dynamique de groupe en distin-gue trois : autoritaire, démocratique et laisser-faire. En 1941, son expérienceauprès de six groupes de ménagères américaines démontre que si un manage-ment autoritaire appliqué aux trois premiers groupes a convaincu l'ensembledes auditeurs, après quelques semaines, seules 3 % des femmes appliquaientles conseils promulgués. Dans les trois autres groupes ayant participé à uneconférence similaire, mais avec un orateur optant pour un management plusparticipatif, les sondeurs notent qu'après 3 semaines, 32 % des femmes ontchangé leurs habitudes. Plus tard, Likert, puis Tannenbaum et Schmidt, pourne parler que des approches académiques, approfondiront ce sujet.

Ce livre porte sur la Yves et la . Il est destiné aux qui sou- CMMI v. … · 2015. 7. 6. · un...

Documents

Transcript of Ce livre porte sur la Yves et la . Il est destiné aux qui sou- CMMI v. … · 2015. 7. 6. · un...