Développement logiciel : le mode projet a-t-il atteint ses limites ?
[article original écrit par Bruno Chassagne de la société D2SI, voir l’original]
Le “mode projet”, dans son acception la plus classique, est-il vraiment adapté au monde du développement de logiciel et à l’accélération constante des changements de l’arène économique ? Ne génère-t-il pas de la dette technique, synonyme de coûts marginaux et d’impacts environnementaux évitables ?
Dans cet article de synthèse, nous retraçons les origines et les derniers développements d’un mouvement de fond qui pourrait bien bouleverser un paradigme pourtant solidement ancré dans l’industrie informatique.
Les origines du débat
Depuis quelques mois, il existe sur Twitter un “signal faible” qui pourrait prendre de l’ampleur dans les années à venir : #beyondprojects / #noprojects. La première salve a été tirée en 2011 par feu P. Grant Rule, expert en développement Agile et Lean, dans un article intitulé “Quel est le problème avec l’approche projet ? ”, qui partait d’un constat simple : les projets informatiques échouent très souvent, et dans les grandes largeurs, au point de mettre parfois en danger l’existence même de l’entreprise porteuse (cf. cette étude McKinsey d’octobre 2012). Et cela depuis au moins quarante ans.
Un logiciel utile évolue tout le temps et ne meurt jamais
Depuis cet article fondateur, qui fait écho aux travaux de Mary et Tom Poppendieck (Lean Software Development), Donald Reinertsen (Product Development Flow), David Anderson (Kanban), etc., le mouvement #beyondprojects / #noprojects s’est accéléré grâce à plusieurs articles d’Allan Kelly et Stephen Smith durant l’année 2013. Allan Kelly nous fait remarquer une chose toute simple : il n’y a pas de “date de fin” pour un logiciel qui rencontre du succès. Prenez par exemple Mozilla Firefox : ce navigateur omniprésent est perfectionné régulièrement, par incréments successifs livrés mondialement toutes les six semaines, à la manière d’un flux continu de valeur ajoutée.
Or comment la norme ISO 10006:2003 définit-elle un projet ? Processus unique qui consiste en un ensemble d’activités coordonnées et maîtrisées comportant des dates de début et de fin, entrepris dans le but d’atteindre un objectif conforme à des exigences spécifiques, incluant les contraintes de délais, de coûts et de ressources.
Dans le développement de logiciel, cela se traduit généralement par :
- L’allocation d’une enveloppe budgétaire fixe.
- L’allocation d’une durée de vie de projet fixe.
- La constitution, puis la dispersion, d’une “équipe projet” temporaire.
Les limites du célèbre tryptique coûts / délais / périmètre
En fait, cette approche “en bloc” ressemble à celle utilisée pour construire une maison, par exemple. L’ennui, c’est qu’en terme de nature de produit, un logiciel et une maison n’ont rien à voir : un logiciel n’est jamais “fini”, et pour demeurer profitable doit continuellement évoluer pour s’adapter aux demandes changeantes du marché, pour saisir des opportunités technologiques, pour répondre à des contraintes réglementaires, etc. Un logiciel qui n’évolue plus, c’est un logiciel mort.
Et ça tombe bien, beaucoup de projets de développement de logiciel sont, une fois terminés, suivis d’une “phase de maintenance évolutive” qui consiste bien souvent à éponger les bugs accumulés lors de la “phase projet”, mais aussi à faire évoluer le produit pour les raisons évoquées précédemment. Malheureusement, l’équipe en charge de la “maintenance évolutive” est rarement la même que “l’équipe projet”, ce qui entraîne fatalement un perte de connaissances au passage.
Par ailleurs, le “mode projet” suggère que l’on peut en contrôler l’exécution par la mesure des déviations des dimensions du fameux “triangle de fer” :
- Déviation par rapport à la durée estimée ;
- Déviation par rapport au coût estimé ;
- Déviation par rapport aux périmètre initial d’exigences fonctionnelles.
Naturellement, ces déviations sont de facto considérées comme indésirables alors que, ainsi que Reinertsen l’a démontré dans Product Development Flow, les espérances de perte ou de gain économiques sont asymétriques, à la manière des options financières. Par exemple, une déviation positive en durée peut se justifier économiquement si le temps supplémentaire a permis de capturer une opportunité de marché émergente, non identifiée au début du projet, mais se révélant très profitable pour l’organisation.
Se (re)focaliser sur la performance économique
Ces mesures de la “performance” d’un projet de développement de logiciel sont des “distractions”, comme le dit Allan Kelly. Elles détournent l’attention de ce qui compte vraiment : la performance économique du produit, réalisée sur tout son cycle de vie. Car c’est cette performance qui, sur le long terme, pèsera douloureusement sur les comptes de l’entreprise, ou au contraire fera sa fortune. Evidemment, la performance économique du produit doit être envisagée sur tout son cycle de vie, ce qui pousse à investir plus de temps au début du projet pour intégrer une démarche d’écoconception et d’accessibilité. Deux garanties de réduire significativement le coût économique et environnemental pour le premier, et d’élargir l’audience pour le second.
Sortir du “mode projet” consiste à s’organiser autour de produits évoluant au fur et à mesure des besoins du marché – et aussi rapidement qu’il est nécessaire à cet égard – grâce à des flux délivrant de la valeur en continu, gérés par des “équipes produit” stables, performantes, engagées sur le long-terme, autonomes et ayant une fine connaissance des attentes du marché. Dans l’industrie du développement de logiciel, cela passe par des approches telles que les méthodes Agiles, Feature-driven development, Lean Startup, Kanban, du financement itératif, ou encore Continuous Delivery.
Source : http://blog.d2-si.fr/2014/04/09/au-dela-du-mode-projet/, avec GreenIT.fr
Frédéric Bordage
Expert en green IT, sobriété numérique, numérique responsable, écoconception et slow.tech, j'ai créé le collectif Green IT en 2004. Je conseille des organisations privées et publiques, et anime GreenIT.fr, le Collectif Conception Numérique Responsable (@CNumR) et le Club Green IT.