Gestion de projet agile

Des approches prédictives aux méthodes agiles

Rassemblant plus de quinze années d’expérience en gestion de projet informatique, cet ouvrage, non sans rappeler les méthodologies traditionnelles – qui définissent à l’avance les besoins, les activités à réaliser, leur séquencement, les rôles et les livrables à produire –, introduit aux méthodes agiles, dont le succès s’affirme d’année en année. Ces dernières prennent le contre-pied des méthodes prédictives en évitant une définition trop précoce et figée des besoins ; elles ont montré une surprenante efficacité en pariant sur la souplesse des équipes.

Un repère pour le chef de projet informatique

Ce guide aidera les chefs de projet, chevronnés ou débutant dans le métier, à évaluer et améliorer leurs compétences en gestion de projet. Il guidera également architectes, analystes, développeurs ou testeurs dans la conduite de leurs projets, ainsi que tous les clients ou experts métier non informaticiens souhaitant appréhender rapidement les enjeux et la répartition des rôles au sein d’un projet.

Un livre incontournable pour les chefs de projet qui souhaitent évoluer vers les méthodes agiles !

Experte de la gestion de projet informatique et de la conduite du changement, Véronique Messager accompagne, depuis près de quinze ans, des équipes projet et des organisations en phase de transition agile, tant sur le plan méthodologique que comportemental. Certifiée ScrumMaster et coach certifiée HEC, elle est également l’auteur, dans la même collection, de Coacher une équipe agile : Guide à l’usage des ScrumMasters, chefs de projets, managers... et de leurs équipes, aux Éditions Eyrolles (2012).

Avec la contribution de Christophe Addinquy, Claude Aubry, Jérôme Barrand, Laurent Bossavit, Antoine Contal, Elisabeth Ducarre, Marc Dumonte, David Gageot, Jean-Claude Grosjean, Marie-Pia Ignace, Freddy Mallet, Régis Médina, Pascal Pratmarty, Alain Pujol, Jean Tabaka, Dominic Williams.

AU SOMMAIRE
Chef de projet : un métier complexe • Gérer un projet : mission (im)possible ? • Diagnostiquer sa gestion de projet • Expression de besoins, relations avec la maîtrise d’ouvrage, planification, suivi et reporting, tests et contrôle qualité, répartition des rôles, productivité • Limites de méthodes traditionnelles • Qu’est-ce qu’une méthode agile ? • Approche itérative et incrémentale • Esprit collaboratif • Formalisme léger • Vers une haute qualité • Principales méthodes agiles • ASD • Crystal • DSDM • Lean • Lean Six Sigma • Scrum • UP • eXtreme Programming • L’organisation agile • Recueillir les besoins • Partager une vision • Vers une collaboration efficace avec le client • Ergonomie agile • Boucle de feedback et techniques de recueil • Formaliser les besoins • L’approche IEEE • Cas d’utilisation d’UML • User stories • Modèle de Kano • Poids relatifs • Méthode MOSCOW • Planifier son projet • Prédiction versus adaptation • Définir une enveloppe globale • Techniques d’estimation • Points de fonction • Story points • Ideal days • Wide Band Delphi (WBD) • Vision, roadmap, plan de la release, plan de l’itération, cycle quotidien • La technique Pomodoro • Suivre et piloter son projet • Indicateurs • Performance, qualité, risques • Gérer les hommes • Rôles et responsabilités • Animer en leader ou en facilitateur • Équipes multiples ou distantes • Sous-traitants • Adopter une approche agile • Risques ou facteurs clés de réussite ? • Mesure de succès et symptômes d’échec • Comment démarrer ? • Projet pilote • Degré de formalisme et cycle de vie • Criticité et nombre de personnes • Choisir pratiques et outils • Communiquer • Résistance ou enthousiasme ? • Convaincre • Apports d’un coach • Cadre • Contrat au forfait • Démarche CMMI • Projet offshore • Cohabiter avec un cycle en cascade • Annexes • Experts • Outils de gestion de projet • Glossaire • Bibliographie.

CHEZ LE MÊME ÉDITEUR

Du même auteur

V. MESSAGER. – Coacher une équipe agile. Guide à l’usage des ScrumMasters, chefs de projet, managers... et de leurs équipes !
N°13414, 2012, 300 pages.

Méthodes agiles

J.-L. BÉNARD, L. BOSSAVIT , R. MÉDINA, D. WILLIAMS. – Gestion de projet Extreme Programming.
N°11561, 2002, 300 pages (e-book).

C. HOHMANN. – Lean management.
N°55381, 2012, 424 pages.

Gestion de projet, normes et qualité

S. BORDAGE, D. THÉVENON, L. DUPAQUIER, F. BROUSSE. – Conduite de projet Web.
N°13308, 6e édition, 2011, 432 pages (collection Solutions d’entreprise).

Y. CONSTANTINIDIS. – Expression des besoins pour le SI. Guide d’élaboration du cahier des charges.
N°13653, 2e édition, 2013, 294 pages (collection Solutions d’entreprise).

H.-P. MADERS. – Animer une équipe projet avec succès.
N°55523, 2012, 264 pages (collection Gestion de projets).

R. HENNION, H. TOURNIER, É. BOURGEOIS. – Cloud Computing. Décider, concevoir, piloter, améliorer.
N°13404, 2012, 242 pages.

X. DELENGAIGNE, P. MONGIN. – Boostez votre efficacité avec FreeMind et Freeplane. Bien démarrer avec le Mind Mapping.
N°12696, 2e édition, 2010, 280 pages.

A. FERNANDEZ-TORO. – Management de la sécurité informatique. Implémentation ISO 27001
N°12697, 3e édition, 2012, 322 pages (collection Solutions d’entreprise).

O. ENGLENDER, S. FERNANDES. – Manager un projet informatique.
N°55524, 3e édition, 2012, 360 pages (collection Gestion de projets).

Y. CONSTANTINIDIS. – Mémento Cahier des charges informatique.
N°13289, 2011, 14 pages.

D. MOISAND, F. GARNIER DE LABAREYRE. – CobiT. Pour une meilleure gouvernance des systèmes d’information.
N°12427, 2009, 258 pages (collection Solutions d’entreprise).

C. DUMONT. – ITIL pour un service informatique optimal. Mis à jour avec ITIL v3 et la norme ISO 20000.
N°12102, 2e édition, 2007, 378 pages (collection Solutions d’entreprise).

D. MOUTON. – Sécurité de la dématérialisation.
N°13418, 2012, 314 pages (collection Solutions d’entreprise).

A. ALTINIER. – Accessibilité web. Normes et bonnes pratiques pour des sites plus accessibles.
N°12889, 2012, 340 pages (collection Accès libre).

Collection Design Web

S. DAUMAL. – Design d’expérience...

Véronique Messager

Préface de Jean Tabaka

Gestion de projet agile

avec Scrum, Lean, eXtreme Programming…

ÉDITIONS EYROLLES
61, bd Saint-Germain
75240 Paris Cedex 05
www.editions-eyrolles.com

La 3e édition de cet ouvrage a fait l’objet d’un reconditionnement à l’occasion de son 3e tirage (nouvelle collection et nouvelle couverture). Le texte de l’ouvrage reste inchangé par rapport au tirage précédent.

Remerciements à Christophe Addinquy, Claude Aubry, Jérôme Barrand, Laurent Bossavit, Antoine Contal, Elisabeth Ducarre, Marc Dumonte, David Gageot, Jean-Claude Grosjean, Marie-Pia Ignace, Freddy Mallet, Régis Médina, Pascal Pratmarty, Alain Pujol, Jean Tabaka, Dominic Williams.

En application de la loi du 11 mars 1957, il est interdit de reproduire intégralement ou partiellement le présent ouvrage, sur quelque support que ce soit, sans l’autorisation de l’Éditeur ou du Centre Français d’exploitation du droit de copie, 20, rue des Grands Augustins, 75006 Paris.
© Groupe Eyrolles, 2007, 2009, 2010, ISBN : 978-2-212-12750-8
© Groupe Eyrolles, 2013, pour la nouvelle...

Préface

En février 2001, dix-sept personnes se sont réunies pour faire une déclaration innovante sur ce qu’elles considéraient être un socle de facteurs clés de succès dans le développement logiciel. Elles sont tombées d’accord sur le fait que, durant leurs expériences de développement ou d’assistance au développement, le succès d’une livraison ne se produisait a priori pas dans des approches qui s’appuyaient sur des plans ou de la documentation. Au contraire, elles reconnurent qu’un ensemble de valeurs et de pratiques totalement différentes étaient à l’origine de la réussite des projets.

De cette réunion résulta leur déclaration présentant une approche dénommée le développement logiciel agile. Les dix-sept participants ont résumé leurs convictions dans un document intitulé le « Manifeste pour le développement logiciel agile », qu’ils signèrent tous, en mettant en avant les valeurs suivantes :

les individus et leurs interactions plutôt que des outils et des processus ;

des fonctionnalités opérationnelles plutôt qu’une documentation abondante ;

la collaboration avec le client plutôt que la négociation d’un contrat ;

s’adapter au changement plutôt que suivre un plan.

Cette déclaration a eu un écho partout dans le monde et un vrai mouvement du développement logiciel agile a vu le jour. Ce mouvement a fait émerger toute une série de pratiques qui tendent à illustrer les quatre valeurs du manifeste. Certaines pratiques focalisent sur les disciplines d’ingénierie ; d’autres s’intéressent à de nouvelles formes de gestion de projet ; et d’autres encore présentent de nouvelles responsabilités pour les équipes. Toutes peuvent déconcerter les équipes qui envisagent de passer à une nouvelle approche de développement logiciel.

Mon travail personnel, en tant qu’« évangéliste » du développement logiciel agile, et compte tenu de ma croyance profonde dans la valeur de l’agilité pour les petites, moyennes ou grandes organisations, m’a conduite à travers l’Europe, l’Amérique du Nord et certaines parties de l’Asie. J’ai eu suffisamment de chance pour être impliquée dans de vraies mutations organisationnelles basées sur les disciplines et les pratiques présentées dans cet ouvrage. En tant qu’auteur de Collaboration Explained: Facilitation Skills for Software Project Leaders, j’entends avec plaisir les voix qui, comme celles de Véronique Messager Rota, considèrent que l’agilité est le chemin le plus approprié pour livrer des logiciels tout en dégageant de la valeur ajoutée. C’est en travaillant avec elle que j’ai pu mesurer sa conviction dans le message qu’elle délivre.

Dans l’ouvrage de Véronique Messager Rota, Gestion de projet – Vers les méthodes agiles, on a la chance de bénéficier de ses propres expériences et de ses réflexions sur ce qu’est une transition vers des pratiques agiles. On peut ainsi prendre du recul et évaluer l’état actuel de ces pratiques et la façon dont elles sont mises en œuvre par les différents experts du monde agile. Guidée par son ouverture d’esprit, Véronique invite ses lecteurs à considérer le mérite de ces pratiques par rapport aux approches en cascade. Tout ce que nous avons appris des approches fondées sur les plans comme un cycle en cascade ne doit pas être condamné ; tout ce que nous découvrons avec le développement logiciel agile ne constitue pas une solution miracle. Les deux approches sont riches d’enseignements. Véronique en propose adroitement des comparaisons utiles, suivies de recommandations. Cette information est inestimable pour les organisations qui envisagent d’adopter des pratiques agiles.

En outre, ce livre est particulièrement intéressant puisqu’il s’adresse à la communauté francophone. Véronique avait le souhait profond de présenter ce thème stratégique en langue française et d’y associer des commentaires de quelques experts francophones de tout premier plan. Ces contributeurs y partagent leur expérience pratique et émettent quelques suggestions pour soutenir l’adoption des méthodes agiles. Cette association des conseils donnés par Véronique et par ses contributeurs fait de cet ouvrage un support très crédible et précieux pour améliorer vos performances. Parce que Véronique rend le sujet accessible à la fois à des techniciens et des non-techniciens, l’ouvrage devrait avoir une large audience de lecteurs intéressés par l’agilité. Cela constitue un autre point positif en faveur du livre.

Le développement logiciel agile n’est plus complètement nouveau ; il ne devrait plus vous effrayer. Cependant, ne partez pas seul à sa découverte. Cherchez plutôt un guide expérimenté qui saura vous accompagner avec encouragements et prudence. Véronique Messager Rota est ce guide. Avec son livre, vous pouvez vous attendre, vous et vos équipes, à tirer profit des fondements du manifeste de 2001 qui a changé le monde du développement logiciel. Je vous souhaite un excellent voyage !

Jean Tabaka,
coach et mentor agile
chez Rally Software...

Remerciements

Avant de mourir, il faut avoir fait un enfant, écrit un livre et planté un arbre.

Proverbe chinois.

L’idée d’un livre, un soir au printemps 2006, suggérée par Yann... et le projet démarre ainsi. Merci à toi, Yann, pour ta persuasion et tes encouragements ; merci pour ta patience, car cela n’a pas été tous les jours facile de supporter ce stress.

Merci, également, à Muriel Shan Sei Fan, éditrice chez Eyrolles, pour sa confiance ; d’emblée, elle a cru à ce projet et m’a confié cette responsabilité de représenter, en tant qu’auteur, la maison Eyrolles.

Merci à Christophe Addinquy, pour la qualité de tes relectures sans complaisance – c’est un euphémisme ! –, ton immense culture, ton humour et surtout ta disponibilité, ta générosité pour me proposer ton aide au beau milieu de tes vacances alors que je t’appelai à la rescousse ! À charge de revanche, Christophe, quand tu te seras décidé à écrire ton livre !

Merci à Alain Pujol, le premier et, sans doute, le seul directeur qualité qui m’a fait comprendre, il y a quelques années, ce qu’était la qualité vue avec pragmatisme ; merci pour ton intelligence, tes conseils toujours avertis, tes remarques pertinentes et justes, tes suggestions qui ont toujours été très précieuses.

Merci à tous les contributeurs de cet ouvrage. Jean Tabaka, avant tout, avec laquelle nous avons immédiatement partagé le même esprit agile, dès notre première rencontre lors de ta venue en Europe. Merci pour ta grande expérience, ton dynamisme, ton professionnalisme et ton appui dans ce projet. Merci à Claude Aubry, Laurent Bossavit, Antoine Contal, Élisabeth Ducarre, Marc Dumonte, David Gageot, Jean-Claude Grosjean, Marie-Pia Ignace, Freddy Mallet, Régis Medina, Pascal Pratmarty, Dominic Williams, tous actifs dans la communauté agile en Europe ; et pour cette troisième édition, merci à Jérôme Barrand, spécialiste de l’agilité stratégique et comportementale des organisations.

Merci à Sophie Hincelin, Karine Joly et toute l’équipe Eyrolles, pour leurs conseils techniques et leur soutien moral lorsque tout paraît perdu au pied des échéances !

Ma gratitude va aussi à mes anciens collègues de Valtech et Valtech Training, des experts de haut niveau, au contact desquels j’ai tellement appris ; à mes clients et mes stagiaires, qui par leurs attentes, leurs questions et leurs projets me poussent à être plus pédagogue, plus professionnelle et plus exigeante encore pour mieux les servir.

Merci à tous ceux qui m’entourent et m’ont encouragée dans cette entreprise ô combien enrichissante.

Bonne lecture à vous tous.

Table des matières

Introduction – Chef de projet : un métier complexe

Le chef de projet multicompétent

Maîtriser les techniques de gestion de projet

Comprendre l’environnement de chaque projet

Manager les hommes

La solitude du chef de projet

La certitude de l’incertitude

Accepter l’incertitude

S’adapter

Anticiper

Gérer un projet : mission (im)possible ?

CHAPITRE 1

Diagnostiquer sa gestion de projet

Les questions à se poser

Question 1 : la vision du projet

Question 2 : le délai de réalisation

Question 3 : l’expression des besoins

Question 4 : les relations avec la maîtrise d’ouvrage

Question 5 : la planification du projet

Question 6 : l’élaboration du planning

Question 7 : le suivi du projet

Question 8 : le reporting

Question 9 : les tests

Question 10 : le contrôle qualité

Question 11 : la gestion des changements

Question 12 : le rythme des livraisons

Question 13 : la satisfaction des clients

Question 14 : la répartition des rôles

Question 15 : la productivité de l’équipe

Question 16 : la gestion des sous-traitants

Question 17 : la gestion des équipes off-shore

Question 18 : la méthodologie de gestion de projet

Question 19 : vous, chef de projet, vous diriez

Question 20 : en résumé, si vous êtes objectif, vous diriez que vous êtes...

Analysez la tendance de vos résultats

Analyse globale

Analyse détaillée par question

CHAPITRE 2

Méthodes traditionnelles ou méthodes agiles ?

Limites des approches classiques

Caractéristiques d’une approche « en cascade »

Les failles d’une approche « en cascade »

Une alternative : les méthodes agiles

Qu’est-ce qu’une méthode agile ?

Origine et valeurs des méthodes agiles

Principes des méthodes agiles

Principales méthodes agiles

Avantages des méthodes agiles

Synthèse des différences fondamentales entre approche traditionnelle et approche agile

L’organisation agile

CHAPITRE 3

Recueillir efficacement les besoins

Pourquoi est-ce si difficile ?

Une mauvaise communication

L’illusoire exhaustivité

La défaillance du client

Partager une vision

Vers une collaboration efficace avec le client

Les compétences « techniques » ou savoir-faire

Les compétences comportementales ou savoir-être

Faire émerger les besoins

Ce qui doit être exprimé

L’émergence des besoins

La boucle de feedback

Les techniques de recueil

Formaliser les besoins

Pourquoi formaliser les besoins ?

L’approche IEEE

Les cas d’utilisation d’UML

L’approche par les user stories

Quelle technique choisir : user story ou use case ?

Le product backlog

Hiérarchiser les besoins

Le bénéfice financier attendu

Le coût de développement estimé

L’opportunité d’apprentissage pour l’équipe

Le risque de développement

Le degré de satisfaction du client

Ce qu’il faut retenir

CHAPITRE 4

Planifier son projet

Pourquoi planifier ?

Définir sa stratégie de planification

L’approche prédictive : tout planifier au début

L’approche adaptative : planifier au fil de l’eau

Définir une enveloppe globale

Avec une démarche prédictive

Avec une démarche agile

Fiabiliser sa démarche d’estimation

Planifier avec une démarche prédictive

Étape 1 : estimer le délai

Étape 2 : estimer le coût

Étape 3 : recenser les activités

Étape 4 : calculer la durée des activités

Étape 5 : ordonnancer les activités

Étape 6 : établir le planning

Étape 7 : ajuster le planning

Planifier avec une démarche agile

Niveau 1 : vision du produit

Niveau 2 : « roadmap » ou jalon

Niveau 3 : plan de la release

Niveau 4 : plan de l’itération

Niveau 5 : cycle quotidien

La technique Pomodoro

Ce qu’il faut retenir

CHAPITRE 5

Suivre et piloter son projet

Quels indicateurs suivre ?

La performance

La qualité

Les risques

Comment suivre ces indicateurs ?

Mesurer la performance

Suivre la qualité

Suivre les risques

Comment présenter ces indicateurs ?

Comment piloter le projet ?

Ce qu’il faut retenir

CHAPITRE 6

Gérer les hommes

Constituer l’équipe

Définir les rôles et responsabilités

Déterminer la composition de l’équipe

Contracter les ressources

Animer l’équipe

En leader...

En facilitateur...

Développer la collaboration

Créer un environnement de travail efficace

Gérer des équipes multiples ou distantes

Gérer les sous-traitants

Ce qu’il faut retenir...

CHAPITRE 7

Adopter une approche agile

Dresser l’état des lieux

Recenser les zones de dysfonctionnement

Poser les bonnes questions

Risques ou facteurs clés de réussite ?

Fixer des objectifs réalistes

Comment mesurer le succès de la démarche ?

Quels sont les symptômes de l’échec de la démarche ?

Comment démarrer ?

Désigner le projet pilote

Nommer un « champion »

Choisir la méthode

Choisir les pratiques

Choisir les outils

Évaluer et adapter

Communiquer

Initialiser la conduite du changement

Pourquoi faut-il accompagner le changement ?

Résistance ou enthousiasme ?

Qui convaincre ?

Arguments contre objections

Les apports d’un coach

Pour le chef de projet

Pour l’équipe

Conclusion

Et dans le cadre...

D’un contrat au forfait ?

D’une démarche CMMI ?

D’un environnement traditionnel résistant

D’un projet offshore ?

Ce qu’il faut retenir

Épilogue

ANNEXE A

Présentation des experts

Christophe Addinquy

Claude Aubry

Jérôme Barrand

Laurent Bossavit

Antoine Contal

Élisabeth Ducarre

Marc Dumonte

David Gageot

Jean-Claude Grosjean

Marie-Pia Ignace

Freddy Mallet

Régis Medina

Pascal Pratmarty

Alain Pujol

Jean Tabaka

Dominic Williams

ANNEXE B

Les outils de gestion de projet

Planification, suivi de projet

Outils spécifiques dédiés à la gestion de projet agile

Gestion de la connaissance, communication

Wikis et blogs

Chat et messagerie instantanée

Conférence électronique

ANNEXE C

Glossaire

ANNEXE D

Bibliographie

Gestion de projet « classique »

Gestion de projet itérative ou agile

Lean

Agilité, mandgement des équipes et des hommes, coaching

...

Introduction

Chef de projet : un métier complexe

La pleine conscience de l’incertitude, de l’aléa, de la tragédie dans toutes choses humaines est loin de m’avoir conduit à la désespérance. Au contraire, il est tonique de troquer la sécurité mentale pour le risque, puisqu’on gagne ainsi la chance. Les vérités polyphoniques de la complexité exaltent, et me comprendront ceux qui comme moi étouffent dans la pensée close, la science close, les vérités bornées, amputées, arrogantes.

Edgar Morin (Le Paradigme perdu, p. 233, Points n° 109).

Rigueur, ouverture, disponibilité, intégrité, bon sens, organisation, anticipation, écoute active, autodiscipline, capacités analytiques, diplomatie, leadership, transparence, proactivité, capacités relationnelles, professionnalisme... Voilà tout ce qu’on demande à un chef de projet aujourd’hui : de réunir l’ensemble de ces qualités... et la liste pourrait s’allonger. Un « mouton à cinq pattes », allez-vous dire. En effet, dans un environnement complexe, de surcroît, contraint par le time to market, il doit (faire) développer un produit au moindre coût dans des délais de plus en plus courts avec une qualité irréprochable.

Capitaine du navire, chef d’entreprise ou chef d’orchestre, clé de voûte de l’édifice que constitue son équipe, le métier de chef de projet est loin d’être simple et confortable ! D’autant que si tout va bien, il recueille rarement les félicitations du client ou de sa hiérarchie (« après tout, il n’a fait que son travail ! ») ; en revanche, si quelque chose tourne mal, il en sera responsable.

En référence à la métaphore de Jérôme Barrand, dans son ouvrage sur Le Manager agile1, on pourrait comparer le chef de projet à « Tarzan » dont le talent est « avant tout d’être sensible aux signaux pertinents dans la jungle, univers d’ombre et de "bruit", univers de turbulence fait de menaces d’espèces concurrentes et d’opportunités végétales et animales ! Son talent a alors été d’inventer tous les jours des solutions innovantes pour survivre puis de trouver un équilibre et surtout de communiquer malgré tout avec tous les acteurs de son environnement [...] ».

Débutant ou expérimenté, n’avez-vous jamais ressenti ce sentiment de solitude dans cette jungle qu’est l’entreprise, un univers dans lequel risques et menaces rendent le chemin plus ardu ? Ne vous êtes-vous jamais senti à cours d’imagination pour trouver des réponses et des solutions aux écueils rencontrés ? N’avez-vous jamais été envahi par l’incertitude liée à l’imprévisibilité des événements ? N’avez-vous jamais rencontré de difficultés à mobiliser tous les membres de votre équipe ? N’avez-vous jamais eu l’impression d’être abandonné par votre hiérarchie ? Pouvez-vous, enfin, affirmer avoir réussi tous les projets que vous avez menés ?

Être chef de projet est un métier passionnant mais difficile à exercer. Avant tout, parce que le chef de projet, lui-même, doit être multicompétent : c’est-à-dire maîtriser les techniques de gestion de projet, appréhender, chaque fois, les spécificités du projet et en plus être un bon leader d’équipe. Ensuite, il est souvent seul, pour faire face, notamment, à l’incertitude qui l’entoure. Alors, gérer un projet serait-ce une mission (im)possible ?

Le chef de projet multicompétent

Le périmètre des responsabilités du chef de projet est large mais variable.

En effet, selon la taille et le contexte particulier du projet, le métier change.

Il est fréquent de rencontrer des chefs de petits projets qui por tent plusieurs « casquettes » ; ils font tout, depuis l’expression de besoins jusqu’aux tests en passant par les développements.

Après tout, ne voit-on pas, parfois, un chef d’orchestre cumuler son rôle avec celui de soliste voire avec celui de premier instrumentiste d’un pupitre !

Sur de gros projets, la répartition des rôles est plus nette, le chef de projet se concentrant sur le pilotage, la coordination du projet et l’animation d’équipe.

Dans le cadre d’un projet où tout ou partie des développements est sous-traité, son rôle est davantage orienté...

1

Diagnostiquer sa gestion de projet

Il est aussi difficile de s’évaluer sur l’échelle des compétences en gestion de projet que de repérer les axes d’amélioration sur ses propres projets. D’autant qu’en observant les statistiques du Standish Group, on ne peut que rarement – et de façon objective – se positionner du côté des projets qui réussissent sur toute la ligne, il faut bien le reconnaître.

Que vous soyez très expérimenté ou encore débutant, prenez quelques minutes pour faire ce test ; il s’agit simplement de repérer les aspects de votre gestion qui méritent d’être mieux explorés : sans doute, certains pourront être professionnalisés, améliorés, d’autres partagés pour être reproduits sur d’autres projets.

En tout état de cause, l’analyse de vos résultats devrait aiguiser votre curiosité à poursuivre la lecture de cet ouvrage pour repérer ces axes de progrès.

Les questions à se poser

Pour chacun des thèmes évoqués, trois affirmations vous sont proposées. Choisissez celle qui correspond le mieux à votre environnement. Retenez le symbole qui y est attaché (, , ). À l’issue du test, comptez le nombre d’occurrences de chaque symbole et reportez-vous à l’analyse de votre résultat.

Question 1 : la vision du projet

  L’objectif de mon projet est clairement défini ; il y a même un consensus entre toutes les parties prenantes sur les livrables attendus, leurs critères d’évaluation et les moyens mis en œuvre pour les réaliser.

  L’objectif de mon projet est défini, mais tous les besoins ne sont pas précisément identifiés.

  L’objectif de mon projet est mal défini, il n’y a pour ainsi dire aucune formalisation des besoins ; des informations contradictoires m’arrivent chaque jour.

Votre réponse : .....

Question 2 : le délai de réalisation

  Le délai a été estimé approximativement ; il est donné à titre indicatif.

  Le délai a été imposé par le client ; il est indiscutable et immuable.

  Je n’ai aucune idée du délai de réalisation ; je ne saurais m’engager et engager l’équipe.

Votre réponse : .....

Question 3 : l’expression des besoins

  Les utilisateurs n’en finissent pas de modifier leurs besoins, nous n’arrivons pas à obtenir un premier niveau de fonctionnalités attendues.

  Les besoins sont formalisés dans un cahier des charges, mais sont susceptibles d’évoluer fréquemment durant le projet.

  Les besoins sont clairement exprimés et formalisés par les utilisateurs. Le périmètre fonctionnel est stable.

Votre réponse : .....

Question 4 : les relations avec la maîtrise d’ouvrage

  Elles sont relativement bonnes avec certains utilisateurs mais nous avons du mal à les impliquer tout au long du projet.

  Nous n’avons aucun contact avec les utilisateurs ou leurs représentants qui n’ont aucune disponibilité.

  Nous avons un interlocuteur unique qui est un expert métier ; il sait ce que veulent les utilisateurs.

Votre réponse : .....

Question 5 : la planification du projet

  J’ai établi, sans difficulté, un plan de management du projet qui décrit toutes les phases, les jalons, les activités et les livrables jusqu’à la fin du projet.

  On ne peut jamais rien planifier, puisque tout change systématiquement compte tenu de l’opacité des besoins et des contraintes.

  Le plan du projet comporte un plan de développement logiciel sommaire et un macroplanning prévisionnel donnés à titre indicatif, car susceptibles d’être ajustés.

Votre réponse : .....

Question 6 : l’élaboration du planning

  Chaque fois que j’élabore un planning, il est systématiquement obsolète au moment où il est validé.

  Pour établir mon planning, je...

2

Méthodes traditionnelles ou méthodes agiles ?

L’entreprise doit avoir l’agilité du banc de poisson qui agit et réagit avec vitesse, simultanéité et précision.

Jean-Pierre Chardon, P-DG Schneider Electric France, préface in Jérôme Barrand, Le Manager agile, Dunod, 2006.

Depuis des décennies, les projets sont gérés avec une approche classique, le plus fréquemment « en cascade » ou son adaptation « en V », basée sur des activités séquentielles : on recueille les besoins, on définit le produit, on le développe puis on le teste avant de le livrer au client.

Ces méthodologies se caractérisent par un attachement farouche à tout planifier, « tout doit être prévisible », en tout début de projet. Voilà pourquoi on les qualifie d’approches « prédictives ». Un plan de management du projet décrit comment et quand le travail sera réalisé, les modalités de planification, d’exécution, de suivi et de clôture du projet.

Cette volonté persistante de vouloir piloter le projet par les plans (plan-driven development) a conduit les acteurs d’un projet à redouter, voire à s’opposer systématiquement à tout changement : changement dans le contenu ou le périmètre du projet, dans le processus de développement, au sein de l’équipe, bref à toute modification des plans initiaux, auxquels on doit rester conforme.

« Quand on trouve une recette qui marche bien, on a du mal à la quitter même si l’on constate que son efficacité semble diminuer ; il existe une inertie due à la peur du changement, à la recherche de facilité ou à l’ivresse du succès (ce qui marchait hier doit marcher demain...). Eh bien non !!!1 »

Fort du constat que les plans initiaux sont finalement toujours modifiés et que les besoins évoluent en permanence pour répondre aux changements du marché, ces approches prédictives se sont révélées trop « rigides » parfois, exposant les organisations à trop peu de réactivité dans le contexte de nouveaux projets stratégiques.

Sont alors apparues, dans les années 1990, des méthodes moins prédictives, plus souples face aux besoins d’adaptation, facilitant ainsi l’agilité des organisations face aux contraintes du marché.

Ce sont les méthodes dites « agiles ».

Limites des approches classiques

Caractéristiques d’une approche « en cascade »

Figure 2-1

Les phases du cycle « en cascade »

Le cycle en « cascade » se caractérise par des phases séquentielles, qui se succèdent après la validation des livrables produits lors de la phase précédente :

Tous les besoins sont exprimés et recueillis lors de la première phase, puisque l’analyse détaillée de ces besoins, puis la conception du système qui répondra à ces besoins, en dépendront.

La conception du système, bien que textuelle ou représentée sous forme de diagrammes, doit être validée avant le démarrage des développements.

Les développements doivent être achevés pour permettre à l’équipe de testeurs de lancer ses campagnes de tests fonctionnels et techniques.

Enfin, une fois, et seulement une fois, que les anomalies ont été corrigées, on peut procéder à l’intégration globale finale et à la mise en production du système.

Dans ce contexte, et sur la base du périmètre défini, on demande au chef de projet de s’engager sur un planning détaillé de réalisation, prévoyant les jalons de début et fin de phases, et les activités à mener.

On devine très rapidement, si l’on ne les a déjà expérimentées, les failles de cette approche.

Les failles d’une approche « en cascade »

Métaphore du chalet

Prenons l’exemple du projet de construction d’un chalet à la montagne : le client souhaite un chalet différent de ceux qui peuplent déjà la station, original, construit avec des matériaux écologiques et respectant les nouvelles normes environnementales. Il a confié la réalisation des plans à un architecte qui a pris en compte ces considérations ; mais le client sait que certains choix et certaines décisions ne pourront être définitifs qu’après avoir vu réellement le chalet prendre forme. Il sait que le coût du chalet ainsi que le délai de réalisation pourront évoluer en fonction de ces choix définitifs, même s’il dispose d’une enveloppe globale qu’il ne souhaite pas dépasser et d’une date de livraison approximative.

Cet exemple paraît tout à fait courant pour celui qui a déjà été confronté à un tel projet et personne ne contesterait la légitimité des hésitations de ce client devant un engagement important.

Comment, dans ces conditions, fournir un planning détaillé de tous les travaux, de toutes les ressources matérielles et humaines, de toutes les fournitures... en sachant qu’au gré des choix du client, la nature même des travaux et des matériaux pourrait évoluer ? Comment fournir un budget détaillé définitif, alors que le client, en fonction de certains choix, devra peut-être renoncer à tel ou tel équipement initialement prévu pour rester dans l’enveloppe budgétaire qu’il s’est fixée ?

Le développement d’un nouveau produit ou d’un nouveau logiciel est confronté aux mêmes conditions : le chef de produit marketing aura sondé ses consommateurs pour définir son nouveau produit, mais lors de la réalisation, certaines attentes ne pourront être satisfaites en raison d’un surcoût imprévu ou d’une nouvelle norme incompatible apparue en cours de développement ; le responsable des ressources humaines d’une grande entreprise aura associé ses collaborateurs pour définir les fonctionnalités d’un nouveau logiciel de recrutement en ligne ; mais la complexité technique sous-estimée au départ ou la difficulté d’intégration avec le système central en place contraindront peut-être l’équipe à revoir à la baisse ses attentes ou à accepter un délai supplémentaire ; ou bien encore, le site d’un concurrent faisant apparaître une nouvelle fonctionnalité attrayante amènera le responsable à faire évoluer son cahier des charges en ajoutant cette nouvelle demande en cours de projet.

La rigidité de l’approche

On déplore que la nouveauté, la marge de manœuvre laissée, à juste titre, au client pour préciser ou faire évoluer ses attentes, la non-prévisibilité de tous les événements soient difficilement compatibles avec une approche prédictive comme celle du cycle en cascade.

À la différence, lors des projets industriels de développement de produits sur une chaîne d’assemblage, tout est (presque) prévisible et le degré de nouveauté (presque) néant : les spécifications peuvent alors être précises dès le début et le budget ainsi que le délai sûrement établis.

En fait, une fois le plan de management du projet validé, il constitue la référence de base. La préoccupation majeure du chef de projet devient alors de coller au plus près au plan, quels que soient les événements ; tout écart constaté, concernant la durée des activités, la productivité ou la disponibilité des ressources ou encore les risques imprévus, est perçu comme un échec, vécu par certains comme une incompétence ou une incapacité à anticiper.

L’approche « en cascade » est par conséquent trop rigide pour permettre des retours en arrière ; elle suppose que l’on fasse bien du premier coup. Une décision ou une anomalie détectée dans une phase aval de la cascade peuvent remettre en cause partiellement ou totalement des travaux validés précédemment et considérés comme définitifs.

Comment revenir sur une conception validée il y a deux mois lorsque l’on constate, à la fin des développements, que l’architecture développée ne permet pas de respecter les exigences de performance ? D’autant que l’approche en cascade n’encourage pas, explicitement, le prototy-page qui aurait pu éviter cette mauvaise surprise.

L’effet tunnel

Figure 2-2

La « boîte noire »

L’effet tunnel est une autre des caractéristiques de l’approche « en cascade » : un projet dure un an, la phase de recueil des besoins dure deux mois et le client ne voit le résultat que neuf mois plus tard !

Que s’est-il passé entre-temps ? « On ne sait pas trop ce qu’ils font ces informaticiens ! », « Que va-t-il sortir de la « boîte » ? », « Mais, ce n’est pas ce que l’on attendait ! » ou bien « C’est ce que nous voulions mais notre besoin a un peu évolué depuis ! »

D’une part, la non-transparence des équipes de développement suscite des sarcasmes sur leur capacité à coopérer, d’autre part, la longueur des phases techniques auxquelles le client n’est pas associé rend celui-ci dubitatif sur le résultat à venir. Ce qui ne favorise pas la collaboration efficace entre informaticiens et utilisateurs !

D’autant plus si le résultat livré n’est pas conforme à ce qui est attendu.

Une mauvaise communication

L’absence de jalons intermédiaires prohibe la validation de ce que sera la version finale du produit. Il faut attendre que la phase de développement soit bien avancée pour découvrir les premiers écrans. Les mauvaises surprises en fin de cycle de vie et le refus du changement par les équipes de développement pénalisent la qualité des relations avec les utilisateurs. Elles en deviennent même parfois conflictuelles ; les uns s’attachent fermement à leurs plans initiaux pour livrer ce qui était convenu à l’échéance prévue, même si le résultat ne correspond plus ou pas totalement à ce qui est réellement attendu ; les autres ressentent cette rigidité comme un désintérêt pour la valeur ajoutée du produit final.

La succession d’intervenants, au travers des différents corps de métier, nuit également à la fluidité de l’information, crée même une déperdition d’information et d’énergie ainsi que de nombreuses ruptures de charge.

La levée tardive des facteurs à risques

Dans un cycle de vie « en cascade », les facteurs à risques sont levés tardivement, puisque les tests de performance ou d’intégration, par exemple, sont reportés après les développements, tout comme l’appréciation des IHM (Interface homme-machines), qui – on le sait – sont souvent sujettes à d’interminables débats très subjectifs.

L’impact des risques augmente avec l’avancement du projet, puisque...

A

Présentation des experts

Christophe Addinquy

Impliqué depuis 15 ans dans le développement orienté objet, Christophe Addinquy a notamment participé à l’émergence d’UML au sein de la société Softeam. Consultant Senior chez Valtech durant 8 ans, il a contribué au succès de nombreux projets par le biais de missions d’audit, de conseil ou de gestion de projet. Également formateur, Christophe a contribué à l’élaboration de nombreux cours (C++, UML, Design Patterns, gestion de projets avec Scrum).

Christophe est actuellement directeur de projets back-office chez Vidal où il procède à la refonte du système d’information en utilisant l’approche agile avec Scrum.

Christophe est auteur d’articles sur les Design Patterns et est crumMaster certifié. Vous pouvez consulter son blog sur http://jroller.com/addinquy et le contacter à addinquy@computer.org.

Claude Aubry

Claude Aubry est impliqué dans le développement de logiciels depuis 30 ans, dans différents domaines (télécoms, spatial, aéronautique, éditeurs de logiciels, énergie, transport, secteur public, sociétés de services...). Après avoir été développeur, architecte logiciel et système, chef de...