11.2005 - La Lettre de novembre 2005

Gestion de projets : méthodes agiles

Trop d'échecs

La dérive ou les échecs des projets informatiques ne relèvent pas toujours d'un problème spécifique de mauvaise gestion.
Les éléments extérieurs tels que les évolutions technologiques, les changements de stratégies, les besoins nouveaux des utilisateurs sont autant d'aléas qui pèsent sur le projet. Par ailleurs, le durcissement du marché et le manque de perspective des entreprises françaises rendent fragiles les budgets informatiques considérés bien souvent comme de véritables gouffres financiers.
Cet état de fait est en constante progression. On constate depuis 1987, d'après une étude du Standish Group, une augmentation significative non seulement des coûts informatiques mais aussi des échecs et des dérives des projets.
Une étude du Gartner Group montre que 20% des budgets informatiques sont gaspillés sur des projets qui seront purement et simplement abandonnés.

Une démarche classique trop rigide

En regard de cette vulnérabilité, on constate que les méthodes et normes actuelles en matière de gestion de projet basées structurellement sur des activités séquentielles (je définis mon produit, je le développe puis je le teste) sont de moins en moins efficaces. En effet, elles n'autorisent pas, ou mal, l'adaptabilité et la réactivité pourtant devenues indispensables au sein des organisations informatiques.
Il existe donc aujourd'hui une réelle nécessité d'orienter la gestion de projet vers une démarche plus agile. Tout le monde s'accorde sur un fait : les méthodes actuelles sont lourdes, sources de nombreuses tâches qui ne concourent finalement pas aux bonnes fins de projets. Elles garantissent mal l'évolutivité et la maintenabilité des systèmes d'information (Michel Entat, DSI TF1 Publicité).

Méthodologies : un passé lourd et opaque

Il serait nécessaire de dresser un bilan objectif des méthodes, normes, pratiques en matière de gestion de projet.
Or, ce bilan est rendu difficile car il passe par une plus grande transparence des coûts et des retours sur investissement dans les projets informatiques et une homogénéité entre les divers modes d'imputations comptables. De plus, il faudrait prendre en compte de très nombreux événements tels que les avenants, les arbitrages, les maintenances évolutives et correctives, etc.
Le panorama est d'autant plus difficile à dresser que les méthodologies de gestion de projet sont nombreuses et variées. On pense au cycle en V, Merise, Racine et Cascade issus de l'industrie dans les années 70, au RAD ou approche par prototype des années 80, à l'UP (Unified Process) issue de l'UML (Unified Modeling Language) des années 90, aux normes nationales et internationales en matière de gestion de projet ou d'organisation d'activités informatiques : ISO12207, ISO 15504, CMM, SPICE, tout ceci multiplié, modifié, adapté autant de fois qu'il existe des organisations informatiques qui ont choisi des pratiques qui leur sont propres.

L'approche agile

C'est dans ce cadre dense et opaque que sont donc apparues les nouvelles méthodologies de développement dites Agiles.
Le fondement des méthodes agiles repose sur l'identification et l'intégration continue des changements tout au long du projet. L'événement extérieur n'est donc plus considéré comme une perturbation mais est intégré comme élément de l'organisation même du projet.
Pour autant, les méthodes agiles ne s'opposent pas aux méthodes traditionnelles. Ces dernières restent valables dans le cas des projets où l'expression du besoin peut être figée dès le départ du projet, par exemple :

• migration technique d'un système à iso-fonctionalité,
• prise en compte d'une nouvelle législation ou d'une nouvelle règle fiscale.

Historique des méthodes agiles

Les premières approches en matière d'Agilité sont essentiellement apparues au cours des années 1990 sous le nom de RAD (Rapid Application Development) puis RUP(Rational Unified Process).
Cependant, si elles apportaient des premières réponses en matière de développement agile, ces méthodes restaient basées en grande partie sur les schémas traditionnels de développement.
C'est réellement avec l'arrivée de la méthode XP (eXtrem Programming), apparue aux Etats Unis fin des années 90 que l'Agilité prit réellement ses lettres de noblesse.
Kent Beck, Ward Cunningham et Ron Jeffries ont créé cette méthode d'une manière générique et applicable quel que soit son contexte même si elle était, à son origine, issue des nouvelles technologies.

Principe de la méthode agile XP

Dédiée essentiellement à la partie basse d'un projet (couche développement), XP repositionne les hommes au cœur du projet informatique et met en avant quatre valeurs fondamentales :

• la communication, comme une valeur primordiale, car, sans elle la résolution des problèmes ne peut se faire de manière constructive
• la simplicité comme gage de la robustesse et de pérennité de la solution délivrée aux utilisateurs. C'est aussi une preuve d'humilité de la part des concepteurs et un facteur clé pour gagner en productivité.
• le feedback comme outil de réduction de risque. Il concerne les relations entre tous les membres de l'équipe mais aussi entre les développeurs et les maîtrises d'ouvrage.
• le courage de prendre des bonnes décisions et de reconnaître ses erreurs dès qu'elles apparaissent plutôt que de tenter de les dissimuler.

Avancées méthodologiques

Voici quelques avancées méthodologiques significatives apportées par l'Agilité en matière d'état de l'art de méthodologie de gestion de projet :

• le projet agile ne se focalise plus sur le produit à réaliser mais d'avantage sur le service à rendre.
  Le maître d'œuvre n'est donc plus engagé sur un livrable clés en main mais sur le respect des services qu'il met à disposition de son client pour réaliser le produit.
  Son engagement est traduit dans une convention de service et non dans un contrat d'intégration au forfait par exemple.

• l'utilisateur ou son représentant est présent au cœur même des plateaux de développement pour apporter la connaissance métier de l'entreprise au bon moment et intégrer dans sa réflexion des contraintes qu'il ne mesurait jusqu'alors que par les termes çà coûtera plus et ce sera pour plus tard.
• un projet agile ne se gère plus par les délais mais par les tassements et les glissements. En d'autres termes, il est plus important de conserver la possibilité de déplacer un travail ou d'en modifier son contenu que de la réaliser à une date précise au détriment du reste. Dans ce contexte, les diagrammes de Gant ou de Pert deviennent donc obsolètes.

• des cartographies des produits et des services sont réalisées et placées directement sur des pans muraux. Ce type de représentation permet en un coup d'œil de comprendre la dimension du projet et de suivre son avancement, ce qui est impossible à réaliser avec les outils de planification existants. De plus, ainsi réalisées, ces cartographies deviennent d'excellents outils de communication et de pilotage de projet.

• l'étape de test est inversée dans le déroulement du projet et remplace l'étape de spécification des méthodes traditionnelles. Cette façon de procéder garantit l'automatisation des tests de non régression indispensable au mécanisme d'intégration continue (cf. ci-après) et évite ainsi la mise à jour récurrente des spécifications, lourdeur bien connue des méthodes traditionnelles.
• l'organisation des équipes change complètement afin de garantir une responsabilité globale du projet. Il n'y a plus de cloisonnement des responsabilités, plus de séparation tayloriste des rôles.
• la gestion du temps est différente d'un projet traditionnel. En particulier, la méthode s'appuie sur des paramètres humains connus comme la durée de mémorisation, la capacité de traitement de concepts en parallèle, le travail en binôme. Ce dernier point est fondamental en matière d'Agilité et est assez "révolutionnaire". Il s'appuie sur le constat simple que 2 personnes de même niveau ont une capacité de production supérieure à 200% du fait du partage des idées et de la sollicitation intellectuelle qu'elles s'auto-générent entre elles.
• le projet est rythmé par des cycles de livraison de l'ordre de quelques semaines, voire quelques jours. Ce mécanisme de livraison fréquente allant jusqu'à l'intégration continue permet de fournir à la Maîtrise d'Ouvrage des informations claires sur les niveaux de maturité des produits et constitue un facteur clé en matière de prise en compte des changements.
• l'Agilité touche même les formations des équipes de projet.
  Les formations aux méthodes XP sont souvent ludiques et légères, pour garantir une assimilation rapide de ses principes. Des formations ludiques garantissant des assimilations rapides :

Bénéfices

Sur le plan quantitatif, même s'il est difficile de définir un gain financier, on estime que les bénéfices sont de l'ordre de 10 à 15% pour l'ensemble du projet.
Cette estimation prend en compte notamment la disparition ou de l'allégement des tâches consommatrices de temps et ayant peu de valeur ajoutée :

• la diminution du nombre d'avenants,
• la baisse des coûts de tests de non-régression (par l'automatisation des tests),
• la baisse des coûts de maintenance et d'apprentissage (par le maintien de la qualité du code).

Sur le plan qualitatif, on gagne surtout en satisfaction du Client Interne : les difficultés qu'il éprouvait à exprimer son besoin complet à l'entrée du projet sont fortement diminuées par le mécanisme d'intégration continue. A cela, s'ajoute la satisfaction d'avoir des résultats tangibles et directement exploitables très rapidement.
Coté Maîtrise d'œuvre, la responsabilité collective est un facteur clé de réussite. Il n'existe plus ce cloisonnement des responsabilités qui induisait une certaine forme de désolidarisation entre membres de l'équipe opérationnelle. Ce facteur humain est extrêmement important : on limite l'usage de parapluies pour se protéger ou justifier de tel ou tel choix, c'est l'efficacité qui prime avant tout.

Méthode Célérial

Les principes de l'XP qui s'appliquent bien à de petites équipes et de petits projets ont été repris dans le programme de recherche Européen Célérial et étendus aux aspects non couverts ou peu couverts par la méthode tels que le pilotage des grands projets et la gestion des relations entre les équipes utilisateurs clientes et les équipes informatiques en mode service.
D'une manière très synthétique, l'application de Célérial repose sur 4 composantes :

• la vision : suivre la progression dans le temps des services rendus et du produit réalisé (vision floue => vision nette).
• la composition : s'assurer que les services réalisés du produit restent efficients au fil de l'intégration continue du produit.
• la trajectoire : suivre l'énergie fournie pour réaliser les services. Energie qui doit décroître dans le temps (phénomène de convergence)
• la maturité : gérer la maturité globale et parcellaire du produit (sa stabilité).