Gestion de projet – Vers les méthodes agiles
40
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.
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.
L’effet tunnel
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.
À 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.
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 prototypage qui aurait pu éviter cette mauvaise surprise.
Figure 2-2
La « boîte noire »
?
Des besoins
Un produit
La boîte noire
GestProjInform Livre Page 40 Vendredi, 3. avril 2009 12:07 12
40
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.
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.
L’effet tunnel
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.
À 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.
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 prototypage qui aurait pu éviter cette mauvaise surprise.
Figure 2-2
La « boîte noire »
?
Des besoins
Un produit
La boîte noire
GestProjInform Livre Page 40 Vendredi, 3. avril 2009 12:07 12