ongoing · Doing It Wrong
Comment peut-on encore s’enliser dans des projets interminables et honteusement coûteux à l’ère du code libre, de la virtualisation des serveur et du développement Agile ?
« Stop the madness! » Un cri du coeur d’un développeur, chez Sun Microsystems, qui dénonce les modes de développement de systèmes d’entreprise qui résultent en des projets extrêmement coûteux et souvent, en échecs (mais, combien profitables pour les grandes sociétés-conseils qui sont assurées de remporter des appels d’offres taillés sur mesure).
Amusingly, all the IT types who write about this agree that the problem is “excessive complexity”, whatever that means. Predictably, many of them follow the trail-of-tears story with a pitch for their own methodology, which they say will fix the problem.
Développement itératif et culture agile
Bien que la modernisation de systèmes patrimoniaux (ou « legacy systems », ces systèmes aux technologies à présent obsolètes et dont la création remonte parfois à la fin des années 60) présente des difficultés particulières, c’est la méthodologie et les choix technologiques que dénonce l’auteur.
The time between having an idea and its public launch is measured in days not months, weeks not years. Same for each subsequent release cycle. Teams are small. Progress is iterative. No oceans are boiled, no monster requirements documents written.
Le billet renvoie également à des sources qui tiennent des listes de projets informatiques désastreux.
Quelques exemples de projets désastreux au Québec
Commission de la santé et sécurité du travail (2009) – Projet de modernisation abandonné au bout de 2 ans et demi. Radiation de 30 millions de dollars.
GIRES (2003) – Méga projet de gestion intégrée des ressources (intégration d’un millier de logiciels dans 138 ministères et organismes, au gouvernement du Québec. Débuté en 1999, le projet est abandonné après plus de 400 millions de dollars investis.
Société des alcools du Québec (2003) – Système de gestion intégrée d’entreprise (ERP) – L’opération qui devait s’étendre sur 18 mois et coûter 57 millions de dollars, a demandé près de 3 ans et coûté 95 millions.
Hydro-Québec (2003) – Projet de modernisation (plus de 200 applications), non encore terminé et dont le coût devrait atteindre plus de 600 millions de dollars.
C’est surtout une question de culture selon moi. Pour citer Bray:
« So if your enterprise wants the sort of outcomes we’re seeing on the Web (and a lot more should), you’re going to have to adopt some of the cultures and technologies that got them built.
It’s not going to be easy; Enterprise IT has spent decades growing a defensive culture based on the premise that you only get noticed when you screw up, so that must be avoided at all costs. »
Donc plus de petits projets, qui fonctionnent ensemble, sur des protocoles et standards web, small pieces loosely joined. Si c’est assez sécuritaire et « scalable » pour Amazon qui gère des millions en transaction chaque années, ça devrait être bon pour un gouvernement (en tenant compte des spécificités comme la vie privée, bien entendu, autre débat).
Tiens, je pourrais donner ça comme conférence à Web Éducation: comment livrer son projet à chaque semaine, toutes les semaines, tout le temps (c’est ça que font les startups intelligentes).
La « loi de Gall » cité dans les commentaire est un excellent résumé de la solution.
http://en.wikipedia.org/wiki/Gall%27s_law
Sylvain, ton 2e commentaire vaut à lui seul un billet et rappelle à quel point les commentaires de blogues sont utiles.