Gestion de projet – Vers les méthodes agiles
116
Définir une enveloppe globale
L’estimation de l’enveloppe globale est déterminante, en premier lieu, dans les phases
préalables, pour évaluer l’opportunité de démarrer ou pas le projet et en second lieu pour
donner un cadre général à une planification plus détaillée.
La planification d’un projet débute par une estimation globale, et ce, quelle que soit
l’approche retenue. Ce sont les techniques utilisées qui varient.
Avec une démarche prédictive
Une démarche en trois étapes
La démarche se déroule généralement en trois étapes : l’estimation de la taille du projet,
la prise en compte de ses spécificités et l’estimation de la charge.
C’est la formule retenue par Steve McConnell, « Count, Compute, Judge », dans son
ouvrage 1 sur les techniques d’estimation.
Les directions et les clients n’accepteront jamais de ne pas disposer d’un planning détaillé en
début de projet. Comment procéder d’ailleurs dans le cadre d’une réponse à appel d’offres ?
La réponse de l’expert Régis Medina, consultant indépendant spécialisé dans l’accélération des projets
de développement.
Pour pouvoir tenir un planning détaillé et figé, il faut que l’environnement fonctionnel et technique
du projet soit bien maîtrisé, et que l’équipe de maîtrise d’ouvrage ait eu le temps de bien décortiquer le problème au préalable de manière à ce que l’enveloppe fonctionnelle soit bien connue.
Si c’est le cas, il est vrai que le client préférera certainement la visibilité à la souplesse. Mon
approche consistera alors à conserver un « emballage » de projet classique mais en utilisant les
pratiques XP en interne pour mieux contrôler les risques : itérations fréquentes en interne pour
mesurer l’avancement réel des développements, ordonnancement des tâches toujours en
interne pour adresser les points les plus importants et/ou risqués en premier, tests automatiques
pour éviter les surprises de dérapage de fin de projet, etc.
En revanche, certains problèmes ou certains contextes projet ne sont pas aussi bien maîtrisés et
peuvent tourner au cauchemar dans une approche classique. J’ai participé à quelques projets au
forfait pour des grands comptes il y a quelques années, et nous avions plutôt affaire à des spécifications incomplètes et changeantes, du fait d’un environnement fonctionnel et technique à la fois
nouveau et complexe. Dans la plupart des cas, client et fournisseur finissaient par passer leur
temps à se battre autour du document de spécifications.
Je pense que l’approche agile peut séduire des clients qui souhaitent une relation plus souple
avec leur fournisseur, pour s’attaquer ensemble à des problèmes moins bien cernés. Dans ce
cas, une solution consiste pour le fournisseur à démarrer comme d’habitude – proposition
technique générale avec planning gros grain pour déterminer le budget global – mais ensuite à
proposer de découper le projet comme suit : un premier projet aussi court que possible pour
mettre en place une version minimale de l’application, puis une suite de mini-projets qui
fassent chacun l’objet d’un contrat ou d’un avenant spécifique, le tout étant par exemple
soumis à un contrat cadre qui fixe certaines variables tout au long du projet.
1. Voir Steve McConnell, Software Estimation: Demystifying the Black Art, Microsoft Press, 2006.
GestProjInform Livre Page 116 Vendredi, 3. avril 2009 12:07 12
116
Définir une enveloppe globale
L’estimation de l’enveloppe globale est déterminante, en premier lieu, dans les phases
préalables, pour évaluer l’opportunité de démarrer ou pas le projet et en second lieu pour
donner un cadre général à une planification plus détaillée.
La planification d’un projet débute par une estimation globale, et ce, quelle que soit
l’approche retenue. Ce sont les techniques utilisées qui varient.
Avec une démarche prédictive
Une démarche en trois étapes
La démarche se déroule généralement en trois étapes : l’estimation de la taille du projet,
la prise en compte de ses spécificités et l’estimation de la charge.
C’est la formule retenue par Steve McConnell, « Count, Compute, Judge », dans son
ouvrage 1 sur les techniques d’estimation.
Les directions et les clients n’accepteront jamais de ne pas disposer d’un planning détaillé en
début de projet. Comment procéder d’ailleurs dans le cadre d’une réponse à appel d’offres ?
La réponse de l’expert Régis Medina, consultant indépendant spécialisé dans l’accélération des projets
de développement.
Pour pouvoir tenir un planning détaillé et figé, il faut que l’environnement fonctionnel et technique
du projet soit bien maîtrisé, et que l’équipe de maîtrise d’ouvrage ait eu le temps de bien décortiquer le problème au préalable de manière à ce que l’enveloppe fonctionnelle soit bien connue.
Si c’est le cas, il est vrai que le client préférera certainement la visibilité à la souplesse. Mon
approche consistera alors à conserver un « emballage » de projet classique mais en utilisant les
pratiques XP en interne pour mieux contrôler les risques : itérations fréquentes en interne pour
mesurer l’avancement réel des développements, ordonnancement des tâches toujours en
interne pour adresser les points les plus importants et/ou risqués en premier, tests automatiques
pour éviter les surprises de dérapage de fin de projet, etc.
En revanche, certains problèmes ou certains contextes projet ne sont pas aussi bien maîtrisés et
peuvent tourner au cauchemar dans une approche classique. J’ai participé à quelques projets au
forfait pour des grands comptes il y a quelques années, et nous avions plutôt affaire à des spécifications incomplètes et changeantes, du fait d’un environnement fonctionnel et technique à la fois
nouveau et complexe. Dans la plupart des cas, client et fournisseur finissaient par passer leur
temps à se battre autour du document de spécifications.
Je pense que l’approche agile peut séduire des clients qui souhaitent une relation plus souple
avec leur fournisseur, pour s’attaquer ensemble à des problèmes moins bien cernés. Dans ce
cas, une solution consiste pour le fournisseur à démarrer comme d’habitude – proposition
technique générale avec planning gros grain pour déterminer le budget global – mais ensuite à
proposer de découper le projet comme suit : un premier projet aussi court que possible pour
mettre en place une version minimale de l’application, puis une suite de mini-projets qui
fassent chacun l’objet d’un contrat ou d’un avenant spécifique, le tout étant par exemple
soumis à un contrat cadre qui fixe certaines variables tout au long du projet.
1. Voir Steve McConnell, Software Estimation: Demystifying the Black Art, Microsoft Press, 2006.
GestProjInform Livre Page 116 Vendredi, 3. avril 2009 12:07 12