Zephyr (./35) :
[cross] Oui mais le but n'est pas de passer à XP pour passer à XP, encore faut-il que ça présente un intérêt. Dans le cas du projet que je prenais en exemple, qui existe depuis 7 ans et continue chaque année à prouver la qualité de ses méthodes de développement, je ne vois pas ce qu'XP pourrait apporter de bénéfique.

Et puis (je vais faire bondir Jackos, mais tant pis ^^) à un projet est aussi associé des méthodes de travail qui ont été spécifiées en amont. Toutes les équipes sont calées sur un rythme donné, qui n'est pas forcément optimal quand on a du recul, mais qu'il serait extrêmement couteux en temps, en coût-homme et en motivation, de modifier fondamentalement. Alors en effet, si toutes les équipes étaient au top de la méthodologie, ça ne serait pas un problème ; mais il faut compter avec l'existant. Ce qui ne veut pas dire laisser de côté tout ce qui a été mis en place au fil du temps, mais peut-être le réserver pour les nouveaux projets, pensés ainsi dès le début. Sinon, c'est un coup à passer son temps à modifier la méthodologie pour être optimal mais, au final, ne rien produire parce qu'on s'est trompé de combat.

Il faut aussi faire avec un problème (qui existe dans toutes les branches, mais qui explose avec les nouvelles technologies) et qui est le décalage générationnel. Quand je vois la façon dont j'ai abordé la POO en Java (JDK 1.2 à l'époque) en 2000-2001 et la façon dont mon frangin l'a abordée deux ans plus tard (JDK 1.5 je crois, mais surtout beaucoup plus de recul sur les méthodes), je n'ose imaginer le décalage avec quelqu'un qui est rentré dans l'info 20 ans avant (enfin, j'y suis confronté tous les jours ; dans mon équipe, on n'est que deux à avoir suivi une "vraie" formation informatique, les autres sont issus de la finance, de l'électronique, il y a un MBA, et un génie-civil (si, si ).