Je crois que tu oublies la pierre angulaire : le sponsor.
Lorsqu'un projet est parti en vrille dès le début, qu'il a fallu rajouter des dizaines et centaines de milliers d'euros alors qu'à la première mise en production c'était une catastrophe, que les utilisateurs ont à peu près ce qu'ils veulent mais ils doivent quand même retraiter des choses à la main derrière... Penses-tu qu'ils seraient chaud pour repayer un an de dev supplémentaire quand on leur dit "on va tout raser, on va tout refaire ?"
Non, c'est du charlatanisme.
Désolé, je ne savais pas trop quoi répondre à ce truisme.
A chacun ses expériences. Je pense que personnellement le problème principal suit simplement le flot du projet : les CDC sont rarement clairs. L'interview client est souvent limitée. La conception a des manquements. Coté technique, il y a souvent des oublis.
Dans tous les cas ce n'est pas grave, si on ne mettait pas autant de temps à réagir. Quelqu'un m'a dit un jour : lorsqu'on découvre une anomalie à un point d'un projet, le facteur de résolution est de 10. Grosso modo, si un Business Analyst a mal fait son boulot et aurait pu réparer son erreur en un jour, ça produit quand même 10 jours côté dev.
Maintenant, va dire à un utilisateur que tu interviews qu'il prenne un jour pour répondre à résoudre une problématique sinon ça en prendre 100 chez le développeur. Sa réaction ? "j'ai pas le temps et/ou c'est pas mon problème. On validera en prod et après je pèterai un câble, et c'est la TMA à Madrid qui va s'en occuper".
En soit oui, tu n'as pas tort, on manque toujours de rigueur en développement. Que ce soit des gars qui testent à l'arrache ou mal faire l'inventaire des livrables... mais si le projet était déjà mal défini, si le business analyst s'entête à mélanger des choux et des carottes, si le business analyst est pas assez technique ou pas assez fonctionnel et n'arrive pas à décrire le besoin et établir un modèle ou travailler correctement avec l'architecture fonctionnelle... bah rigoureux ou pas le projet ne pourra que se planter et être un pataquès d'ajouts.
Au passage, le postulat de l'article, à la base, c'est qu'une équipe de développement veut tout raser parce que c'est plus dur d'essayer de comprendre, maintenir, et faire évoluer un code sur lequel ils n'ont pas travaillé. Ton message sous-entend qu'on peut faire un ReX avec d'anciens acteurs du programme. Mais dans un monde lié à la prestation biennale / triennale et à la promotion interne express, nous n'avons plus ces acteurs et nous n'avons plus de ReX. Ou alors ils s'en dédouanent carrément.
Partager