Méthodes traditionnelles ou méthodes agiles ?
CHAPITRE 2
39
• 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.
GestProjInform Livre Page 39 Vendredi, 3. avril 2009 12:07 12
CHAPITRE 2
39
• 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.
GestProjInform Livre Page 39 Vendredi, 3. avril 2009 12:07 12