Sans s'opposer réellement aux méthodes traditionnelles en matière de projets informatiques, les méthodes agiles proposent une autre approche basée sur l'identification et l'intégration du changement tout au long du projet. Elles ont pour objectif d'éviter la dérive et les échecs des projets, trop fréquents.
Les méthodes agiles ont pour nom RAD, RUP, XP...

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.