La méthode de gestion de projet

Pourquoi une méthode ?

Merise, Unified Process, RAD-PUMA, XP, Scrum, Lean, Kaban, PRINCE2, Crystal Clear... au fur et à mesure de l’évolution du cycle des développements, les méthodes se succèdent, toutes promettant des résultats spectaculaires et conduisant aux mêmes constats. Elles ne garantissent en aucune manière la réussite d’un projet. Pourtant, nous cherchons tous à y croire alors que ce constat n’est pas nouveau. Depuis des siècles, l’homme cherche à rationaliser des processus sous forme de méthodes afin de formaliser un savoir acquis par essai erreur. De l’Organon d’Aristote, jusqu’aux pratiques agiles, en passant par le Fordisme de F.W. Taylor, elles ont toute apporté leur lot de bénéfices et de contraintes, mais ce ne sont que des outils utilisés un temps, puis remplacés par un autre que l’on juge plus performant. Ainsi, les méthodes agiles éclipsent d’anciennes méthodes, tout comme le Novum Organum de Lord Francis Bacon supplanta l’Organon d’Aristote.

Si les méthodes ne garantissent pas la réussite d’un projet, l’application stricte d’une méthode, adaptée au contexte, présente de réels bénéfices.

Le premier est chiffré par le Standish Group, rendu célèbre...

Bénéfices d’une méthode

Elle permet aux différents acteurs de communiquer en partageant une culture et un langage commun. Si l’on mesure avec soin le nombre d’échecs causés par des défaillances de communication, ce bénéfice à lui seul est remarquable.

Elle permet, en théorie, de supplanter la méthode de l’essai-erreur que nous utilisons le plus naturellement depuis la découverte du feu. En cela, une bonne méthode devrait indiquer les erreurs à ne pas commettre, au même titre que la conduite à tenir.

La méthode doit être maîtrisée par tous les acteurs et considérée comme véritablement bénéfique. Tout parent sait pertinemment qu’imposer une méthode ou une règle nécessite un acte de foi de la part de l’enfant qui la reçoit. La méthode « ne touche pas la porte du four mon chéri, tu risques de te brûler les doigts » aboutit invariablement à la seconde déclaration « je te l’avais bien dit ».

Lorsqu’elle est acquise et appliquée, elle atténue les tensions et la défiance en reportant certaines responsabilités sur la méthode au lieu des individus. Ce faisant, elle a parfois tendance à laisser admettre pour...

Cycle en cascade

C’est une méthode dite séquentielle qui recommande de gérer un projet par étapes successives, chacune terminée par une validation de la part du client donnant le feu vert pour passer à l’étape suivante. Tant que le client n’a pas validé l’étape en cours, les travaux doivent se poursuivre.

Le cycle en cascade est formalisé en 1970 par Winston W. Royce pour faire face à la complexité croissante des applications informatiques. Pour mémoire, jusqu’en 1980, les ordinateurs étaient encore très souvent équipés de lecteurs de cartes perforées. D’ailleurs, les écrans des terminaux de l’époque comptaient 80 colonnes, comme les cartes perforées. Oui, on parlait de terminal, grosse machine bruyante qui se connectait à une machine encore plus grosse (par exemple : les mainframes IBM s360).

Si chaque fabricant cherche alors à imposer son langage de programmation, le COBOL sera le plus utilisé, car il est le fruit d’un consensus entre les constructeurs et les instances gouvernementales américaines. C’est un langage dit de troisième génération, plus proche du langage humain, et reposant sur des librairies qui permettent d’importants gains de productivité.

Il faut bien comprendre que l’obsolescence...

Cycle en V

Dans les années 80, le cycle en V (Goldberg, McDermid, Knut Ripken & Ali) remplace, ou plutôt étend, progressivement le cycle en cascade jusqu’à devenir un standard normalisé de production informatique (ISO, AFNOR).

Il décompose la phase de conception (design) en plusieurs étapes intermédiaires et implémente d’importants standards de tests. Plutôt que de s’attaquer à la cause des échecs des projets menés avec un cycle en cascade, il contribue à en minimiser les effets par davantage de spécifications et de tests. Au fur et à mesure des évolutions de la méthode, de nombreux documents types seront ajoutés :

Cycle en spirale

Il faut attendre une nouvelle décennie pour que le cycle en spirale commence à remettre en question les méthodes précédentes. En 1990, le cycle en spirale (Boehm 1988) reprend le cycle en V, mais propose d’itérer le produit jusqu’à le rendre de plus en plus complet, ou bien de le scinder en plusieurs lots plus petits et de les produire les uns après les autres.

Il introduit également les notions d’analyse et de gestion de risques, et d’ingénierie concourante, c’est-à-dire impliquer les équipes de production dans la conception.

Ces deux concepts seront repris, ou plutôt dilués, dans les méthodes précédentes, sous forme de nouvelle version complexifiant encore plus des processus qui l’étaient déjà et reléguant davantage les phases de production au dernier rang d’intérêt. Le cycle en spirale, précurseur des méthodes agiles, connaîtra une mise en œuvre confidentielle.

Un premier événement va cristalliser toute l’attention du monde informatique, le bug de l’an 2000. Si la qualité logicielle inquiétait l’exécutif, cet événement va totalement le faire paniquer. Des milliards sont en jeu, on parle de survie au journal télévisé, les termes « fin du monde » et « apocalypse » sont employés par les journalistes professionnels.

Et comme la loi de Murphy le prédit, dans la foulée, un second événement essentiel pour le business mobilise les ressources, le passage à l’euro.

Ces deux éléments contribuent à mettre en lumière une nouvelle contrainte : une application informatique ne doit pas simplement fonctionner correctement, elle doit aussi être maintenable, donc parfaitement documentée.

Dans ce contexte, l’apparition d’Internet pour le grand public passe quasiment inaperçue dans les entreprises. Certains y croient, comme Thierry Lhermitte qui, devant un Jean-Claude Brialy déchaîné, explique...

Cycle itératif

L’an 2000 a bien sonné la fin d’un monde, celui des méthodes séquentielles. Malgré le bénéfice contractuel qu’elles ont apporté aux acteurs les ayant adoptées, leur déclin était inéluctable face aux contraintes imposées par les applications web :

Concomitamment, plusieurs solutions vont être mises en œuvre pour tenter de régler les problèmes de qualité de l’ingénierie informatique.

En phase de conception les wireframes remplacent les storyboards, les rendant plus interactifs et plus proches du résultat final. Ils permettent à l’utilisateur de mieux appréhender la solution que le maître d’œuvre leur propose de mettre en place.

De nombreux frameworks permettent des gains de temps considérables lors de la réalisation, offrant de plus grandes possibilités de réactivité. Dans certains cas, une modification sur un code existant n’implique plus de réécrire...

Devenir agile

Le plus souvent, la méthode de conduite de projet est imposée, ou vivement recommandée, par l’entreprise. Plus elle est partagée et maîtrisée par un grand nombre d’intervenants sur le projet, plus elle sera bénéfique (Hackman & Morris, 1975). Si vous devez déployer une solution novatrice et que, de surcroît, vous utilisez une méthode récemment adoptée, vous multipliez clairement les risques. Dans ce cas, il peut être sage de conduire le projet en utilisant une méthode plus ancienne présentant théoriquement moins de bénéfices, mais mieux maîtrisée par un plus grand nombre.

Cependant, les projets de communication ont la particularité d’avoir des impacts forts sur l’image de l’entreprise et la gestion de ce type de projet peut s’avérer délicate avec certaines méthodes. Le modèle en cascade, hérité du bâtiment et visant à ne passer à la phase de production que lorsque toute la conception est réalisée, pose de nombreux problèmes, principalement mais pas exclusivement, de réactivité et d’adaptabilité. Mais un projet web peut parfaitement être conduit avec une méthode non agile, à condition de faire preuve d’organisation. Le couplage entre les applications métier et le front-office doit être aussi faible que possible afin d’offrir à ce dernier une forte capacité d’adaptabilité et de réactivité permettant de répondre aux contraintes concurrentielles et d’évolution technologique. Une méthode agile sera beaucoup plus efficace dans ce type de projet, mais si vous devez travailler avec des ressources qui pensent que Scrum est un groupe de hard rock, une méthode non agile restera plus efficace...