Méthodes traditionnelles ou méthodes agiles ?
CHAPITRE 2
41
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 plus une anomalie
est détectée tardivement, plus le retour arrière est complexe, plus sa correction coûtera
cher et plus les effets de bords seront menaçants.
Une documentation pléthorique
Afin de se prémunir contre ces risques, l’approche « en cascade » s’attache fortement à la
production d’une documentation importante.
La documentation permet de repousser le moment où il va falloir aborder la phase de
codage, phase irréversible.
Elle rassure et, s’il en était nécessaire, elle apporte la preuve que la réalisation progresse ;
elle matérialise l’avancement et engage les parties prenantes. En effet, il est plus aisé de
s’opposer au changement en brandissant un document contractuel validé précédemment !
Malheureusement, cette documentation, souvent trop pléthorique, ne reflète pas la réalité
des développements : on a beau valider un document d’architecture, celle-ci reste théorique et conceptuelle tant qu’elle n’est pas implémentée et testée dans des conditions réelles ; on a beau présenter des maquettes papier au client, celui-ci est plus sensible à ce
qu’il voit concrètement sur un écran (IKIWISI, I’ll Know It When I See It !).
Au final, on s’interroge sur l’utilité de cette documentation, qui n’est, en outre, pas
toujours mise à jour tout au long du projet et devient donc vite inexploitable.
Dans ce contexte de méthodes trop rigides, comment augmenter le niveau de satisfaction des
clients tout en facilitant la gestion des projets et en améliorant la qualité des développements ?
C’est précisément avec les méthodes dites « agiles » que l’on va pouvoir adopter une
approche plus souple, plus « adaptative » aux aléas du projet.
GestProjInform Livre Page 41 Vendredi, 3. avril 2009 12:07 12
CHAPITRE 2
41
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 plus une anomalie
est détectée tardivement, plus le retour arrière est complexe, plus sa correction coûtera
cher et plus les effets de bords seront menaçants.
Une documentation pléthorique
Afin de se prémunir contre ces risques, l’approche « en cascade » s’attache fortement à la
production d’une documentation importante.
La documentation permet de repousser le moment où il va falloir aborder la phase de
codage, phase irréversible.
Elle rassure et, s’il en était nécessaire, elle apporte la preuve que la réalisation progresse ;
elle matérialise l’avancement et engage les parties prenantes. En effet, il est plus aisé de
s’opposer au changement en brandissant un document contractuel validé précédemment !
Malheureusement, cette documentation, souvent trop pléthorique, ne reflète pas la réalité
des développements : on a beau valider un document d’architecture, celle-ci reste théorique et conceptuelle tant qu’elle n’est pas implémentée et testée dans des conditions réelles ; on a beau présenter des maquettes papier au client, celui-ci est plus sensible à ce
qu’il voit concrètement sur un écran (IKIWISI, I’ll Know It When I See It !).
Au final, on s’interroge sur l’utilité de cette documentation, qui n’est, en outre, pas
toujours mise à jour tout au long du projet et devient donc vite inexploitable.
Dans ce contexte de méthodes trop rigides, comment augmenter le niveau de satisfaction des
clients tout en facilitant la gestion des projets et en améliorant la qualité des développements ?
C’est précisément avec les méthodes dites « agiles » que l’on va pouvoir adopter une
approche plus souple, plus « adaptative » aux aléas du projet.
GestProjInform Livre Page 41 Vendredi, 3. avril 2009 12:07 12