EXPOSE REALISE PAR : …………………………….. …………………………… LES PROJETS AGILES EXPOSE REALISE PAR : …………………………….. ……………………………

Plan Introduction Qu’est-ce qu’un projet Agile ? Principe de fonctionnement « Agile » Les valeurs Agile Les méthodes Agile et leur tronc commun La contractualisation Conclusion

Introduction

La réussite d’un projet informatique est le souci majeur dans toute relation Client / Fournisseur dans le domaine de l’ingénierie des Systèmes d'Information. En effet, une approche traditionnelle attend généralement du client une expression détaillée et validée du besoin en entrée de réalisation, laissant peu de place au changement. La réalisation dure le temps qu'il faut et le rendez vous est repris avec le client pour la recette. Cet effet tunnel peut être très néfaste, on constate souvent un déphasage entre le besoin initial et l'application réalisée. On se rapporte alors aux spécifications validées et au contrat. De plus il n'est pas rare que certaines fonctionnalités demandées se révèlent finalement inutiles à l'usage alors que d'autres découvertes en cours de route auraient pu donner plus de valeur au produit.

Enquête du «Standish Group» Une enquête de 1994 du « Standish Group » fait le constat suivant sur ces fameuses approches traditionnelles : « 31 % des projets informatiques sont arrêtés en cours de route, 52 % n'aboutissent qu'au prix d'un important dépassement des délais et du budget et en offrant moins de fonctionnalités qu'il n'en était demandé ; seuls 16 % des projets peuvent être considérés comme des succès. ». Cette même enquête renouvelée en 2008 indique un taux de réussite de 35% ce qui est plutôt positif mais cela demeure assez faible, le problème reste entier. Parmi les motifs d'échecs arrivent en tête : Manque d'implication des utilisateurs finaux : 12,8 % Spécifications incomplètes : 12,3 % Changement de spécifications en cours de projet : 11,8 % De ce besoin sont nées les méthodes Agiles.

Qu’est-ce qu’un projet Agile ?

Le terme "Agile" définit une approche de gestion de projet de développement qui prend en quelque sorte le contre-pied des approches traditionnelles prédictives et séquentielles (cycle en V).

Principe de fonctionnement « Agile »

Le client élabore sa vision du projet et liste les fonctionnalités du produit à réaliser sans rentrer dans les détails. l'équipe de développement estime le coût de chacune d'entre elles, pour avoir une idée approximative du budget global.  Le client attribue à chaque fonctionnalité une valeur métier permettant de prioriser les besoins.

L'équipe développe le produit dans l'ordre ainsi établi au fil d'itérations courtes. A la fin de ces dernières, le produit partiel est montré au client. Le client peut alors se rendre compte du travail réalisé, et vérifie l'alignement sur les besoins. Ainsi, Les risques sont levés très tôt. Réduction éventuelle du "time to market" si le client estime que le produit en l'état (partiel) peut aller en production, économisant ainsi son budget et récoltant un premier retour sur investissement. Possibilité de changer en cours de route la priorité des fonctionnalités qui n'ont pas encore été développées ou ajouter d’ une nouvelle fonctionnalité en échange du retrait d'une autre (respectant ainsi son budget),...

Les valeurs Agile L'approche agile consiste donc à s'adapter au changement. Selon les quatre principes d'opposition suivants :

« Les personnes et interaction priment sur les processus et outils » Dans l'optique agile, l'équipe est bien plus importante que les moyens matériels ou les procédures. Il est préférable d'avoir une équipe soudée qui communique. La communication est une notion fondamentale. « Une application qui fonctionne prime sur la documentation exhaustive » Il est vital que l'application fonctionne. Le reste, et notamment la documentation, est secondaire. La documentation représente une charge de travail importante, mais peut pourtant être néfaste si elle n'est pas à jour. Attention, cela ne veut pas dire que l'on s'en passe. On doit simplement s'assurer que cette dernière reste synthétique, lisible et facile à maintenir, bref le "Juste ce qu'il faut". 

« La collaboration avec le client prime sur la négociation de contrat » Le client doit être impliqué dans les travaux de réalisation. On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes imprévues du client qui ne manquerons pas de survenir en cours de route. En contrepartie, le client doit collaborer avec l'équipe et fournir un feed-back continu sur l'adaptation du logiciel à ses attentes, prendre des décisions importantes et faire des choix en temps voulu, aider l'équipe à lever les obstacles quand c'est de son ressort... « L'ouverture au changement prime sur le suivi d'un plan » La planification initiale et la structure du logiciel doivent être flexibles afin de s'adapter aux changements et aux imprévus tout au long du projet. Citation de Darwin : « Les espèces qui survivent ne sont pas les espèces les plus fortes, ni les plus intelligentes, mais celles qui s'adaptent le mieux aux changements. ».

Les méthodes Agile et leur tronc commun

Différentes déclinaisons ont émergé : RAD (Rapid Application Development), DSDM (Dynamic System Development Method), XP (eXtrem Programming), SCRUM Mais elles ont tous en commun un ensemble de principes fondamentaux :

1 - Les pratiques liées aux ressources humaines Participation de l'utilisateur final aux groupes de travail. Spécification et validation permanente des Exigences. 2 - Les pratiques liées au pilotage du projet Pilotage par les enjeux et les risques. Réalisation en jalons par prototypage actif itératif et incrémental. Recherche continue d'amélioration des pratiques.

3 - Les pratiques liées à la qualité de la production Recherche d'excellence technique de la conception. Vision graphique d'une modélisation nécessaire et suffisante. Vision de la documentation nécessaire et suffisante. Architecture à base de composants.

La contractualisation

La contractualisation des projets Agile n'est pas la partie la plus facile étant donné que le périmètre est par définition variable. La régie ferait bien l'affaire mais difficile de rassurer le client avec un tel contrat. D’où la dominance du contrat au forfait, surtout sur les gros projets. Malheureusement pour le fournisseur - dans le cadre d'un forfait classique - tous les risques sont pour lui (aussi bien en approche Agile que traditionnelle). On peut limiter ces risques en prenant quelques précautions, mais on limite également la souplesse offerte par une approche Agile. Ceci dit, cela ne veut pas dire qu'il n'existe pas de solutions. La forfaitisation de chaque itération avec la possibilité pour le client d'arrêter le contrat à la fin de chaque itération est assez intéressante.

Conclusion L'approche Agile propose de supprimer purement et simplement l’effet tunnel en donnant davantage de visibilité et en impliquant le client du début à la fin du projet en adoptant un mode itératif et incrémental. Elle considère que le besoin ne peut être figé et propose de s'adapter à ce dernier. Mais pas sans un minimum de règles.