Pourquoi les méthodes agiles peinent-elles à pénétrer l’entreprise ?

La décision est prise, demain matin vous devez développer un logiciel pour votre entreprise. Un budget est disponible et un premier choix s’impose à vous : la méthode de travail. Il en existe deux grands types : la cascade (ou cycle en V) et la construction incrémentale pilotée par les tests. Dans une cascade, l’accent est mis sur le produit, que l’on considère comme descriptible dans un cahier des charges, puis des spécifications détaillées. Il est ensuite codé et enfin testé. Dans une approche incrémentale, l’accent est mis sur le process : il n’est pas nécessaire de décrire exhaustivement le produit mais plutôt ses grandes lignes, puis on développe cas d’usage par cas d’usage, en montant progressivement en complexité. Chaque cas d’usage est associé à des tests de recette qui seront automatisés, donc rejoués à coût marginal.

La cascade représente 99% du portefeuille projet des grandes entreprises, l’incrémental 99% des projets Open Source et des sites Web grand public les plus connus (Amazon, Telemarket ..). L’observation des faits devrait aiguiller votre choix : la cascade échoue dans ses grandes lignes, l’incrémental piloté par les tests permet la maîtrise de logiciels aussi complexes que ceux des grands éditeurs. Cette observation semble manichéenne, mais elle ne fait que corroborer la théorie du Defect Cost Increase énoncée par Barry Boehm dans les années 80 : Le coût de correction d’un défaut croît exponentiellement à chaque phase du cycle de développement dans laquelle il est détecté. Le processus en cascade crée structurellement du risque qu’il refoule, tandis que l’incrémental intègre ce risque en le mitigeant par des cycles de livraison rapides.

Alors comment expliquer que malgré ces faits, votre choix se portera très vraisemblablement sur la cascade ? J’y vois trois facteurs : un mythe fondateur, l’insouciance d’une jeune industrie dispendieuse, et un système de valeur hérité du Fordisme.

Commençons par le mythe fondateur du cahier des charges : pour réussir un projet de développement, il suffit de rassembler les besoins dans un document complet et exhaustif, puis d’écrire un logiciel qui soit conforme à cette spécification. Le philosophe Wittgenstein nous avait pourtant mis en garde dans les années 50 contre cette fausse assertion héritée du positivisme. Tout exercice du langage qui n’est pas étayé par des cas concrets finit en abîme de sens. Il n’y a pas de « beauté », il n’y a que l’expérience que chacun s’est forgé de la beauté. Ainsi Wittgenstein démontre à quel point seul des tests dans des cas concrets peuvent cerner un sens exprimé : « c’est beau quand c’est jaune », « c’est beau si c’est rond » …

Tout processus tend à être découpé en phases et en tâches, auxquelles sont rattachées des équipes spécialisées. Cette vision s’applique à merveille dans certaines chaînes de valeur industrielle, mais très mal dans un processus de construction logiciel, par essence risqué donc requérant des cycles courts, sans circulations hiérarchiques. Construire du logiciel, sera donc avant tout construire une équipe intégrée, ce qui reste compatible avec l’informatique d’entreprise, massive et interconnectée.

About these ads

À propos de Hicham AIT BASLAM

Une expérience de plus de 14 ans, passée dans le conseil et le management de projets complexes à dimension internationale impliquant des équipes pluridisciplinaires, à traiter de problématique d’intégration (FrontOffice, BackOffice) et d’architecture SI, d'alignement du SI sur la stratégie de l'entreprise, d'amélioration continue des équipes. Elle est constituée sur le terrain par la direction de nombreux projets de la phase amont jusqu'à la réalisation et livraison, marquée aussi par la Transformation et Refonte de plusieurs SI Stratégique, par le redressement de projets informatiques en difficultés, Business développement de plusieurs SSII, développement de nouvelles offres sur le marché). Toutes ces expériences m’ont permis d’avoir une vision générale des systèmes d’information éclairés sous différents angles et sur les solutions globales à haute valeur ajoutée. Aujourd'hui, je me positionne dans des postes à fort dimension (Internationale, Managériale, Business, Technologique), je me consacre entièrement à accompagner de grands comptes à réussir la transition vers l'agilité et à la traduction de la vision stratégique en résultat.

Publié le 07/08/2012, dans Méthodes Agiles. Bookmarquez ce permalien. Un commentaire.

  1. abdelmouneim ahid

    Très intéressant, c’est effectivement « Le » sujet d’actualité et surtout pour le contexte marocain.
    Néanmoins, travailler « agile » n’empêche pas de décrire un cahier des charges. Au contraire, il faut définir le besoin global pour connaitre l’objectif avec toute ses composantes, mais attaquer la réalisation par petit bout pour éviter « l’effet tunnel » comme le veut l’agilité. En effet, les contraintes contractuelles/financières dues à une sous-traitance de l’activité de réalisation chez un tiers imposent de définir le périmètre fonctionnel à un certain niveau de détail évitant tout conflit; un conflit qui n’arrange aucune partie de l’équation (ni le client, ni le sous-traitant). D’ailleurs, et même pour une réalisation en interne, je ne vois pas comment une DSI pourrait justifier le budget réclamé s’elle n’a pas abordé le projet à un niveau microscopique dans ses aspects métiers…

    Après coût, ce cahier de charge n’est qu’un travail permettant d’affiner la cohérence du besoin dans sa globalité et d’avoir un garde fou fonctionnel, et un ordre de grandeur financier, car l’expérience prouve qu’il sera remis en cause durant toute la vie du projet.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :