Dans le cadre de la gestion de projet, l’agilité se traduit donc comme étant la capacité de s’adapter et à réagir à l’environnement. C’est la mise en avant de l’inter-activité entre les acteurs d’un projet par rapport à un formalisme. Ce dialogue a pour but d’augmenter le niveau de satisfaction du client.

Cette approche est relativement générale et a des implications dans de nombreux domaines tels que l’industrie, les transports, la logistique, le BTP ...

A la RATP, les méthodes agiles se développent sur les projets de service liés aux informations du transport voyageur. Au lieu d’attendre des mois et de mois la mise en place d’un produit, ceux ci sont maintenant mis à la disposition du public très tôt dans le « RATP Lab », concept emprunté à GOOGLE Lab.

Dans les formations en gestion des chaînes d’approvisionnement, les cursus incluent de plus en plus la prise en compte de la nécessité d’être agile.

Dans la mécanique, l’utilisation de prototypes est depuis longtemps rentrée dans les moeurs et ce à tous les niveaux aussi bien pour le design (concept car) que pour valider un fonctionnement (pré-série).

Dans les biotechnologies et l’industrie pharmaceutique, malgré de cycle particulièrement long (une phase d’étude pour un médicament pouvant durer plusieurs années), l’agilité peut être assimilée à la culture de l’échec. Cette pratique en plein développement consiste à retirer le maximum d’information de l’échec d’un projet de médicament. C’est une forme de mise en place d’un dé-cloisement entre les projets.

Dans l’informatique, la notion d’agilité prend plusieurs sens :

 Parfois, on entend par logiciel agile un logiciel qui s’adapte à l’utilisateur donc extrêmement paramétrable.

 Parfois, on entend par agile un certain découpage de l’entreprise en processus et en départements métier.

 Parfois, on cantonne aussi le développement agile à un certain type d’architecture logiciel dit « composant » ou « modulaire ».

Néanmoins, plus généralement, lorsque l’on parle d’agilité, on parle plutôt du processus projet en général et de son management. Les méthodes agiles ne s’appliquent pas au produit final en terme de flexibilité mais plutôt à son processus de développement.

Par exemple, le fait qu’un produit soit modulaire ne signifie pas que son processus de développement ait suivi une démarche agile.

Les méthodes agiles se présentent comme une alternative aux méthodes de développement classiques basées sur la modélisation (fonctionnelle, entité relation, ou objet). et l’ingénierie.

Agile Alliance :

En Février 2001, un certain nombres d’acteurs importants du monde des méthode agiles tels que Kent Beck, Ken Schwaber Alistair Cockburn, Jim Highsmith et des praticiens des méthodes agiles tel que XP, SCRUM, ASD, FFD, Crystal Method, DSDM se regroupent pour créer l’alliance agile.

Ils mettent au point et signent un manifeste (voir annexe) résumant les principales valeurs des méthodes agiles :

 Individus et interaction plutôt que processus et outils.

 Logiciel fonctionnel plutôt que documentation exhaustive.

 Collaboration avec le client plutôt que négociation de contrat.

 Réaction face au changement plutôt que suivi de plans.

de ces quatre valeurs découlent douze principes généraux communs aux méthodes agiles :

 Satisfaction très tôt du client par des livraisons de versions fonctionnelles régulières et fréquentes : le client peut éventuellement décider de mettre en production l’application.

 Acceptation des demandes de changement, même tard dans le processus de développement. Le but est de produire des systèmes flexibles en adéquation avec les besoins clients.

 Des livraisons le plus fréquemment possible des versions opérationnelles, pour encore une fois, coller au maximum aux besoins clients

 Coopération au quotidien entre clients et développeurs

 Construction des projets en se concentrant sur les individus et leurs motivations et mettant en avant la confiance.

 Le fonctionnement de l’application est le premier critère

 Rythme soutenable si le rythme de développement n’est pas soutenable, la qualité du code s’en ressentira au final

 Excellence technique doit être promue et la conception doit être mise en avant car elle améliore l’agilité.

 Répondre le plus simplement aux besoins tout en restant adaptable et en évitant de développer des chose inutiles

 L’auto-organisation des équipes afin laisser émerger la conception, les spécifications, l’architecture. Cela permet également de partager les responsabilités

 L’introspection de l’équipe, à intervalles de temps réguliers ; l’équipe doit s’interroger sur la façon de devenir plus efficace et s’ajuster à son environnement

Historique :

Généralement, l’approche proposée par Toyota connue sous le nom de « LEAN » (ou encore système Toyota), est considérée à l’origine des méthodes agiles. Celle-ci n’est pas au départ destinée aux projets de développements informatiques. L’origine des méthodes agiles en informatique est datée du milieu des années 1990 et provient du constat suivant :

Constat :

Au début années 1990, les maîtrises d’oeuvre informatique appliquent majoritairement un cadre méthodologique sérieux et des méthodes héritées de la « crise du logiciel ». Ce cadre repose essentiellement :

 des normes tels que DOD2167, ISO 12207...

 des cycles Merisiens, en V ou en cascade.

 des procédures qualités, ISO9001, et recommandation 9000-3 pour le logiciel.

 CMMI.

La conséquence de cette approche est une grande insatisfaction des maîtrises d’ouvrage qui reprochent trop de dérives des coûts, des dérives des plannings, de produits inadaptés.

Analyse :

L’utilisation des méthodes de développement produit sur les projets une avalanche d’informations telles que les demandes de modifications fonctionnelles, les bugs, changements d’architecture ...entraîne une inadéquation entre les changements rapides des besoins utilisateur et les logiciels produits et des réorganisations fréquentes.

Ces dernières produisent à leur tour des arrêts et reprises des développements, des ruptures technologiques, et finalement le désengagement des investissements.

Il y a dérive des coûts, de la qualité mais aussi et surtout des délais . A cette époque seulement 30% des projets sont livrés avec des développements conformes aux prévisions. En réaction à cette hyper-spécification et sur-modélisation, une nouvelle approche est devenue nécessaire

Une nouvelle approche :

Dans cette nouvelle approche, les équipes doivent palier aux défauts des méthodes d’ingénierie classique et assumer les contraintes liées à l’innovation. En particulier elle doivent maintenant :

 Vivre dans le changement et s’adapter.

 Intégrer le fait que ce fonctionnement est normal.

 Chercher à obtenir les résultats essentiels le plus rapidement et se concentrer dessus.

 S’organiser autrement.

 Définir des priorités différentes.

 Découper le travail autrement, segmenter et cadencer les projets.

 Faire simple.

La première prise en compte de ces concepts est réalisée au cours des années 1990 avec l’arrivée d’une méthode RAD (Rapid Application Développement). Cette méthode intègre une bonne partie des principes de base de l’agilité tel que le prototypages, la réalisation d’incréments bien qu’elle reste dans le fond basée sur des schémas traditionnels.

Les « vrais » méthodes agiles n’arrivent que plus tard avec la création de l’alliance agile (agile alliance) et la rédaction du manifeste agile qui servira de base aux méthodes comme Scrum, XP.