Comme Laurent, j'aime bien cet article et souscris à sa conclusion. ProxiAD vous parle d'IT est d'ailleurs un excellent blog au demeurant, qui parle aussi de MDSD agile. Comme ça on est au moins 2 à y croire encore ;-)
Non, tous les projets dits “traditionnels” ne dépassent pas leur délais et/ou leurs charges. Non, tous les projets “traditionnels” ne livrent pas à leurs clients des produits à 100 000 lieux des besoins clients.
Oui mais attention, les faits sont là :
=>
- 70% des projets échouent depuis 20 ans (cycle en V principalement)
- 60% des causes en sont la définition des besoins
- 20% des fonctionnalités seulement sont utilisées souvent ou toujours
(Standish Group et autres consorts, toujours vrai en 2009)
Et non, désolé je vous assure qu'il y a encore pas mal de cycle en V (et des vrais s'il vous plait !) dans ce bas monde, et je ne sais pas pourquoi, surtout à Toulouse :-(
Sans parler des référentiels méthodologiques des entreprises qui invitent lourdement à définir des jalons de phases en silos (voir cela pour s'en sortir).
Je connais bien toutes les formes de cycles, cela faisant partie de mon expertise et mon offre de services.
RUP, 2TUP, W etc ont apporté du mieux, c'est incontestable. Néanmoins, il ne garantissent pas autant de collaboration et de fluidité que les méthodes agiles et retombent facilement dans les rigidités (j'aime bien ce mot comme "contraire de l'agilité") que nous cherchons désormais à éviter.
Moi, oui, je suis d'accord avec vous, il n'y a pas que Scrum ou XP dans la vie, un RUP ou un 2TUP peut être hautement agilisé (d'ailleurs il existe AgileUP mais qui n'est en fait qu'un amaigrissement du RUP)
A l'inverse, on aurait beaucoup à dire sur l'agilité de certaines méthodes prétendues en être. Feature Driven Development par exemple, propose des concepts intéressants, notamment sa capacité à adresser intrinsèquement de gros projets, grâce à un cycle semi-itératif. Mais quand on regarde comme la méthode est présentée, i.e. bourrée de diagrammes UML sophistiqués et peu lisibles, on se permet d'en douter ! Et à mon sens, les méthodes agiles connues pourraient apporter des réponses plus claires, plus homogènes, et en tous cas davantage rassurantes pour les décideurs, sur des sujets critiques tels que l'architecture, les gros projets, le model driven, le normatif etc. Ce ne sont pas les idées qui manquent mais elles demeurent éparses et manquent de lisibilité.
Les principes Lean me paraissent de bons candidats pour constituer une vision plus générale et plus fédératrice des solutions actuelles à la gestion de projet informatique.
En conclusion c'est encore une fois les valeurs qui l'emportent, qui fédèrent une "communauté d'artisans pragmatiques qui ne cherche qu'à livrer des logiciels de qualité et avec du sens"
Notez que mon site n'a jamais changé d'intitulé : Consultant Indépendant - Gestion de Projets Informatiques et Méthodes. Cette année, j'aurais pu le changer pour Coach agile ou qqchose comme ça puisque j'interviens presque exclusivement sur des projets Scrum et XP ces dernières années. Mais comme je l'ai déjà exprimé à droite à gauche, je suis parfois gêné par ce fameux Bulldozer Agile qui écrase tout sur son passage et ressemble parfois plus à un dogme qu'à une ouverture d'esprit.
Et non, je n'ai même pas honte d'aller piocher de bonnes idées dans le PMI, le RUP, les référentiels méthodo des grandes entreprises.
Il est peut être temps de changer de terme : agile est devenu un incroyable fourre-tout ou un symbole de militantisme parfois extrême. Certains s'y emploient j'ai l'impression... (à suivre)