Les méthodes ”agiles” de management de projets informatiques

Les méthodes « agiles » : une nouvelle tendance managériale

Le secteur informatique participe d’une évolution générale qu’ont connue les industries de logiciels, dans les vingt dernières années. Cette évolution se trouve à l’origine de la rapidité et de la complexité des projets informatiques : instabilité et obsolescence des demandes, fortes exigences des clients, accélération du marché technologique, diversification des offres, etc.
Comme nous l’avons déjà précisé, l’anticipation des besoins des clients et la définition complète de l’ensemble des demandes sont devenues très risquées. Dans un tel contexte, les soucis de réactivité, de réduction des délais de mise sur le marché et d’adaptabilité se sont progressivement imposés.
Comment transformer les pratiques d’ingénierie et les modes de management pour produire plus rapidement les applications informatiques? Comment concilier la qualité des produits et les délais de livraison ? Comment rendre les logiciels conformes aux attentes évolutives des clients ? Comment concilier la dialectique entre le niveau de connaissances acquis et les capacités d’actions dans un projet ? C’est en répondant à cet ensemble de questions qu’un groupe de professionnels et d’experts en matière de développement informatique a mis en œuvre, à la fin des années 1990, un ensemble de méthodes classées sous le qualificatif « agile ».

Vers un consensus autour de la définition de l’agilité

Depuis la fin des années 1990, un nombre croissant de professionnels du développement de logiciels se sont intéressés au concept d’agilité et ont tenté, à travers divers articles et ouvrages, d’y apporter une définition. Pour Erickson et ses collègues (Erickson, Lyytinen & Siau, 2005), l’«agilité» permet de s’emparer de la rigidité des méthodes de développement « traditionnelles » et incite à répondre, de manière très rapide, aux changements de l’environnement et aux contraintes imposées par les délais, toujours plus courts, de livraison de projets. Dans une même optique, d’autres auteurs ont apparenté le développement « agile » aux notions de flexibilité, de rétroaction et d’adaptation au changement rapide et continu. Pour ces personnes, les méthodes « agiles » ont été mises en place dans le but d’intégrer le changement plutôt que de le freiner ou de le détourner. Elles constituent un moyen pour les sociétés de développement de survivre dans un environnement instable (Abrahamsson, Salo & Ronkainen, 2002 ; Williams & Cockburn; 2003 ; Beck & Andres, 2004). D’autres définitions ont, quant à elles, mis l’accent sur l’aspect humain. Du point de vue de leurs auteurs, l’imprévisibilité de l’environnement est surmontée à travers les individus et leur créativité (Dyba, 2000 ; Beck, 2004). Si l’ensemble de ces définitions s’accordent sur les principes d’adaptabilité et de flexibilité, elles ne permettent pas d’avoir une vision précise de ce que représente concrètement le concept d’agilité en matière de développement et de management de projets informatiques.

Les enjeux du développement « agile » de logiciels

L’attention actuelle accordée au développement « agile » procède d’une double explication : les enjeux de réactivité et les avantages du développement rapide. Ces enjeux ont déjà été à l’origine d’autres modèles d’organisation et de management de projets en général, à titre d’exemple, le modèle d’ingénierie concourante, que nous présenterons brièvement.
La saturation des marchés, l’hétérogénéité des demandes et les difficultés d’anticipation des besoins ont transformé les systèmes de production des industries manufacturières. Le modèle de l’économie réactive s’est ainsi imposé au niveau de ces industries remettant en cause les modèles de la standardisation et de variété . Dans une économie de concurrence, les entreprises modifient leur système productif pour réduire les délais de mise sur le marché et gagner en réactivité. A cet effet, de nouvelles stratégies ont été adoptées par les organisations à la recherche d’un avantage compétitif durable: la stratégie de niche pour capter les demandes les plus exigües et la stratégie d’obsolescence (Garel, 2003). On postule que les demandes sont volatiles et se transforment rapidement.
Bien que cette hypothèse soit également soutenue par les « agilistes », les stratégies de réponse adoptées par ces derniers s’avèrent différentes. Si l’ingénierie concourante repose sur une logique d’offre proactive, les méthodes « agiles », quand à elles, mettent l’accent sur l’adaptation aux besoins émergents des clients. Le processus de développement relève d’une collaboration forte entre le client et l’équipe de développement.
Par ailleurs, le développement rapide de produits, valorisé tant par l’ingénierie concourante que par les approches « agiles », présente des avantages : d’une part, le client a peu de chance de changer son avis si le produit lui est livré rapidement et d’autre part, les coûts et les dépenses supplémentaires liés à la découverte tardive de défaillances sont limités. Les cycles de développement courts procurent une vision concrète et progressive par rapport à la partie développée réduisant ainsi les risques de non-conformité aux attentes (Poppendieck, 2006).

Les sources d’inspiration des méthodes « agiles »

Transposition du modèle Toyota au développement de logiciels

Les années 1980 et 1990 témoignent de la transformation des systèmes d’organisation largement inspirés du taylorisme et du fordisme. L’expansion des principes de gestion issus du modèle japonais, connu aujourd’hui sous le système de production Toyota (TPS), semble être à l’origine d’un tel changement. Les concepts clés dont relève ce système renvoient principalement à l’autonomation et à la production juste à temps. L’autonomation regroupe un ensemble d’outils (l’andon qui consiste à arrêter automatiquement la production en cas de problème) et de méthodes (pareto des causes, la méthode des 5 Pourquoi) dont le but est d’inciter l’ensemble des employés d’une entreprise à améliorer ex ante la qualité des produits et des services vendus plutôt que d’éliminer ex post les rebus. Le principe de juste-à-temps, quant à lui, consiste à organiser son entreprise de telle sorte qu’elle puisse livrer exactement et au bon moment la quantité de biens souhaités par ses clients. La production est tirée par la demande. En d’autres termes elle est déclenchée par les demandes des clients (Houy, 2009). Après le succès spectaculaire du Système de Production Toyota traduit sous le terme de lean management, de nombreux constructeurs de véhicules ont tenté de reproduire, au sein de leur organisation, l’ensemble des principes et pratiques relevant de cette approche managériale dans le but d’améliorer la performance et la productivité de leur système de production. La réussite commerciale affichée par les industries lean et leur forte médiatisation n’ont fait qu’élargir l’expansion de ce système à différents secteurs, dépassant ainsi son domaine d’application initial, celui de la production industrielle. Il n’est donc pas surprenant que le lean finisse par intéresser le marché des industries de logiciels en pleine mutation et croissance. L’industrie japonaise, capable de livrer très rapidement des produits de haute qualité, va constituer une base empirique et théorique pour le management des projets informatiques. Divers facteurs de vitesse de développement de projet ont été exposés par Imaii et alii en 1985 (Imaii & alii en 1985 dans Garel, 2003) dont certains ont été repris par les « agilistes » : l’auto-organisation des équipes, le multi-apprentissage, l’ajustement mutuel, le partage d’informations dans un environnement de travail ouvert et le regroupement des acteurs dans un même espace physique.

L’agile manufacturing

L’« agile manufacturing » a été créé dans les années 1990 par des chercheurs américains, de Lehigh University, chargés d’améliorer la performance des industries américaines. Les défaillances du système de production de masse et les menaces des pays industrialisés d’Asie ont poussé les firmes américaines à changer leur mode de production et à emprunter la voie de l’ « agilité ». Un rapport, publié par les chercheurs de l’institut Iacocca, intitulé « 21st Century Manufacturing Enterprise Strategy » (Nagel, Dove, Goldman & Preiss, 1991), présente les caractéristiques de l’agile manufacturing. Bien que divers chercheurs ont tenté de définir l’agile manufacturing, il n’existe pas à l’heure actuelle une définition universelle. A cet effet, nous présentons trois définitions de l’agilité organisationnelle qui relèvent de différentes dates de publications.
L’agile manufacturing a tout d’abord été défini comme une entreprise robuste, adaptative avec une capacité de reconfiguration rapide pour répondre aux opportunités du marché. Une telle entreprise est fondée sur des processus et des structures appropriés ainsi que sur un système coordonné de personnes, d’organisation et de technologies permettant d’acquérir une performance compétitive supérieure à celle des pratiques existantes.

Le développement lean

Le modèle lean provient du best seller des années 1990 nommé « The machine that changed the world: the story of lean production » (Womack & Jones, 1990 dans Poppendieck, 2003). Inspiré du Toyota Production System, le lean qualifie un ensemble de pratiques managériales basées sur deux piliers fondamentaux : la production « juste à temps » et l’« autonomation » (Houy, 2008). Le Toyota Production System est désigné comme un système de management qui vise l’élimination radicale du gaspillage « The Toyota production system is a management system for the absolute elimination of waste…All we are doing is looking at the timeline from the moment a customer gives us an order to the point when we collect the cash » (Ohno, 1988 dans Poppendieck, 2006). Fondé par Taïchi Ohno dans les années 1970, les objectifs essentiels sur lesquels repose ce système est la réduction des coûts de production et l’amélioration de la satisfaction des clients. Deux principes sont dès lors mis en avant : l’élimination du gaspillage ou tout ce qui dépasse la quantité minimale requise en termes de matériels, d’équipements, d’espace et de temps et par conséquent ne crée pas de la valeur ; et la valorisation des employés à travers leurs responsabilisation et leur développement continu (Sugimori, Kusunoki, Cho & Uchikawa, 1977).
Après l’immense succès qu’a connu le système de production Toyota dans les industries automobiles, traduit, plus tard, sous l’approche du lean management, les principes lean ont été exportés au-delà de l’industrie automobile et se sont progressivement étendus à d’autres services et secteurs d’activités. Aujourd’hui, l’application des principes du lean management au développement informatique est en pleine expansion (Enquête Scrum Alliance 49, 2009). Mary et Tom Poppendieck se sont beaucoup intéressés à la question d‘application des principes du lean management au développement de logiciels. Dans leur ouvrage « Implementing lean software development: from concept to cash », paru en 2006, ils décrivent les différents principes qui constituent le « lean thinking ». Avant de procéder à la présentation de ces principes, il apparaît judicieux de préciser que le lean development ne renvoie pas à une méthodologie de développement et de management de projet analogue aux méthodes « agiles ».

Les outils de support au management

Les travaux de recherches publiés sur le système de production Toyota ont accordé beaucoup d’importance aux outils visuels de communication capables d’améliorer la transparence au niveau des systèmes de production : détection des défauts grâce au système alerte «l’andon», identification de la quantité des pièces à produire en recourant aux étiquettes « kanban », etc.
Dans le domaine du développement « agile » de logiciels, ces outils visuels renvoient aux « story-cards » et « story-board ». Leur fonction est d’assurer un environnement informatif en représentant le flux du travail et en rendant visible et accessible, à tous les membres d’une équipe, l’avancement du projet. Différentes informations sont habituellement renseignées correspondant aux étapes « à faire », « en cours », «à relire» et « terminé ». Sur chaque étape sont affichés les « story-cards » sous forme de « post-it ». Le « story-board » sur lequel sont affichés les « story-cards » ainsi que le « product-backlog » semblent créer un environnement informatif améliorant la visibilité du projet (Cockburn, 2002; Robinson & Sharp, 2004 ; Sharp & Robinson, 2007, 2008, Petersen & Wohlin, 2009, Middleton & Joyce, 2010) et assurer le suivi de l’avancement des projets. Ces outils permettent d’avoir une vision partagée des demandes (Martin, Biddle & Noble, 2004) et favorisent également la communication et la coordination du travail des équipes (Martin, Biddle & Noble, 2004; Sharp & Robinson, 2007 ; Sharp, Robinson & Petre, 2009).
En outre, d’autres instruments de gestion ont été étudiés comme les outils d’identification et d’analyse des causes racines des problèmes. Ces derniers semblent, à leur tour, éliminer le travail de correction et améliorer la qualité des fonctionnalités produites (Middleton, Flaxel & Cookson, 2005).
Toutefois, le partage de ces outils s’avère difficile entre les membres d’une équipe distribuée. Le remplacement d’artefacts physiques par des artefacts électroniques nécessite des mises à jour régulières ainsi qu’une infrastructure technologique de qualité favorisant les échanges à distance (Kircher, Jain, Corsaro & Levine, 2001 ; Danait, 2005, Berczuk, 2007, Paasivaara, Durasiewicz & Lassenius, 2008, 2009).

Les méthodes « agiles » v/s méthodes « classiques » : quelles méthodes privilégier ?

Après la publication des premiers ouvrages sur les méthodes « agiles », de nombreux experts en matière de développement ont tenté de comprendre les rapports qui existent entre ces méthodes émergentes et les anciennes approches de développement. Plusieurs hypothèses ont été avancées. Si pour certains, les méthodes « agiles » constituent une alternative aux approches centrées sur les processus ou sur la planification (Murru & Deias & Mugheddu, 2003), elles s’avèrent pour d’autres complémentaires (Turner, 2002 ; Boehm & Turner, 2003 ; 2005 ; Kähkönen & Abrahamsson, 2004). C’est dans cette perspective qu’un modèle multidimensionnel a été proposé aux industriels afin qu’ils aient la possibilité de sélectionner l’approche de développement en fonction de leur type de projets (Cockburn, 2002b ; Boehm & Turner, 2003).
La tendance des chercheurs à exposer les approches « agiles » comme un moyen permettant aux équipes de développement d’accroître leur productivité (Agerfalk & Fitzgerald, 2006) et de s’adapter rapidement aux changements (Highsmith & Cockburn, 2002 ; Chong, 2005) ne va pas dans le même sens que les résultats observés avec les méthodes « classiques » qui, quant à elles, défendent l’idée d’un environnement stable où l’intégration des changements constitue des coûts supplémentaires.
Comme nous l’avons précisé dans notre introduction, les approches « classiques » ont fait l’objet de nombreuses critiques : mauvaise définition et compréhension des besoins, livraisons tardives causées par le développement séquentiel, obsolescence des plans et de la documentation, etc. De fait, les méthodes itératives et incrémentales constituent un moyen pour répondre à ces problèmes et réduire les risques associés aux activités de définition, en amont, de l’ensemble du système. Selon certaines études, les entreprises recourant aux méthodes « agiles » jouissent d’une relation plus satisfaisante avec leurs clients contrairement aux méthodes « classiques » (Sillitti, Ceschi, Russo & Succi, 2005). Ceci s’explique par le fait que le client fait partie intégrante de l’équipe de développement. Par conséquent, sa communication avec celle-ci et sa participation dans le processus de développement améliore la qualité du système (Hikka, Tuure & Matti, 2005).

Table des matières

Introduction générale 
Première partie : De la question des méthodes « agiles » comme « innovations managériales» 
Chapitre I : Présentation des méthodes « agiles » : principes et instruments de gestion
1. Des méthodes classiques de management de projet aux méthodes « agiles »
1.1 Les méthodes « classiques » : une démarche « lourde » de conduite de projet
1.2 Les méthodes « agiles » : une nouvelle tendance managériale
1.3 Les sources d’inspiration des méthodes « agiles »
2. Présentation des méthodes « agiles » 
2.1 La méthode « scrum »
2.2 La méthode « Extreme Programming »
2.3 Le lean développement
2.4 « Scrum », « xp » et le développement « lean » : différences et complémentarité
Chapitre II : Analyse de la mise en pratique des « innovations managériales »
1. Les pratiques « agiles » les plus référencées : avantages et limites 
1.1 Les pratiques d’ingénierie
1.2 Les pratiques de collaboration et de coordination
1.3 Les outils de support au management
2. Les méthodes « agiles » v/s méthodes « classiques » : quelles méthodes privilégier ?
3. L’application des pratiques « agiles » dans un environnement géodistribué 
3.1 Les principaux défis du développement « agile » distribué
3.2 Les recommandations des praticiens face aux défis remontés
3.3 Regard complémentaires des experts sur le développement « agile » globalisé
Chapitre III : Stratégie de recherche : une approche « par la pratique »
1. La « fabrique de la stratégie » : champ de recherche émergent en sciences sociales
1.1 Le strategizing : à l’intersection des pratiques, praxis et praticiens
1.2 Qui sont les stratégistes et que font-ils ?
2. Le modèle du sensemaking
2.1 Les propriétés du sensemaking
2.2 L’organisation appréhendée comme un processus d’organizing
Deuxième partie : De la fabrique d’une « innovation managériale » : la construction d’une
démarche « agile » 
Chapitre IV : Conduire une approche « par la pratique » 
1. Présentation « à plat » du cas d’entreprise étudié
1.1 Description du contexte d’étude
1.2 Mise en place de la démarche « lean »
2. Démarche d’investigation
2.1 Choix d’une étude longitudinale
2.2 Procédés de collecte de données
2.3 Choix d’une méthode d’analyse thématique
2.4 Triangulation des données et des chercheurs
Chapitre V : Variables de création de sens
1. Le gaspillage dans les projets pilotés par Nextv 
1.1 Analyse et classification des dysfonctionnements par type de gaspillage
1.2 Démarche plausible de résolution des dysfonctionnements
2. Facteurs d’influence de la démarche « lean »
2.1 La taille et la distribution des équipes
2.2 La structure organisationnelle
2.3 Mode de management de projet
2.4 Les ressources mobilisées
2.5 Les parties prenantes du projet « lean »
Chapitre VI : Discussion
Conclusion générale
1. Résumé des principaux résultats de recherche
2. Les apports de ce travail de recherche
3. Limites et pistes futures
Bibliographie 
Annexes

Télécharger le rapport complet