Agile en quelques motsLe 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 ou waterfall). En effet, une approche dite 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. Certains projets vont jusqu'à se terminer dans la douleur (surtout dans le cadre d'un projet signé au forfait) au risque de compromettre la relation client. 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. Une enquête de 1994 du « Standish Group » (Certes controversée. Comme toutes les enquêtes j'ai envie de dire) fait
le constat suivant sur ces fameuses approches traditionnelles : 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 :
L'approche Agile propose au contraire de supprimer purement et simplement cet 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.
Un peu d'histoireJe ne vais pas rentrer dans les détails en citant les grands noms qui sont à l'origine de l'approche « Agile », de ses méthodes ou l'ensemble des événements agiles de ces 20 dernières années. Nous sommes des gens pressés, concentrons nous sur l'essentiel. La première chose à savoir est que l'approche Agile n'est pas un effet de mode né de la dernière pluie. En effet la première approche de gestion de projet de développement itératif date de 1986. La première mise en œuvre de "Scrum" (une des méthodes Agile les plus réputées) date de 1993. La seconde concerne un événement majeur rassemblant, en 2001, dix sept figures éminentes du développement logiciel pour débattre du thème unificateur de leurs méthodes respectives, dites méthodes agiles. De cet évènement est né le Manifeste Agile rassemblant à la lueur des expériences de chacun les critères pour définir une nouvelle façon de développer des logiciels. Aujourd'hui ces méthodes ont fait leurs preuves. Tout le monde ou presque a au moins entendu parler d'une méthode Agile (Scrum, XP, RAD, Chrystal Clear,...). L'outillage associé est maintenant disponible sur le marché y compris dans le secteur Open Source, les événements et séminaires se multiplient. Les valeurs AgileL'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 communL'ensemble des méthodes agile respectent ces 4 valeurs ainsi le tronc commun de pratiques suivantes : 1 - Les pratiques liées aux ressources humaines
2 - Les pratiques liées au pilotage du projet
3 - Les pratiques liées à la qualité de la production
Chaque méthode se distingue cependant des autres. L'approche idéale consiste à appliquer ce tronc commun et tirer des différentes méthodes, les outils ou pratiques spécifiques appropriés au contexte du projet. La Méthode « Scrum »Le package ScrumScrum est considéré comme un cadre ou « framework » de gestion de projet. Ce cadre est constitué d'une définition des rôles, de réunions et d'artefacts. Scrum définit 3 rôles : le « product owner » (représentant du client), le « Scrum Master » (équivalent au chef de projet) assurant le respect de la méthode et l'équipe. Le principal artefact est la liste d'exigences priorisée ou « product backlog ». La vie d'un projet Scrum est rythmée par un ensemble de réunions clairement définies :
Le schéma suivant illustre le processus Scrum :  Scrum apporte également quelques outils très utiles comme le planning poker qui permet de chiffrer très efficacement des tâches (ou exigences). L'organisation généraleDémarrageL'approche Scrum propose de commencer par lister les exigences du client afin de produire le « Product Backlog » qui ressemblerait un peu à ça pour la réalisation d'un site d'e-commerce :
Le Product Owner priorise ensuite la liste en fonction de la valeur métier : « Qu'est ce qui est le plus important pour lui ou autrement dit : qu’est ce qui doit être fait en priorité ? » et du coût de chaque exigence. Les exigences seront réalisées dans l'ordre ainsi défini selon les contraintes de l'équipe chargée des développements. On fixe ensuite la durée d'une itération ou « Sprint » durant laquelle un certain nombre d'éléments du « Product Backlog» seront réalisés. Planification d'un SprintUne fois que le « Product Backlog » est complet et que la durée du Sprint est fixée en accord avec le client, il n'y a plus qu'à remplir le Sprint avec des éléments du backlog. Le Product Owner peut à tout moment revoir la priorité des exigences qui n'ont pas encore été planifiées dans le sprint en cours. Progression du projetGrâce aux estimations du « Product Backlog » et la segmentation en sprint et en exigences, on peut aisément produire un graphique de suivi d'avancement d'une simplicité enfantine : En voici un exemple :  Mais qui utilise vraiment Scrum ?1&1 AG, 24.com, Adelaide Bank, Adobe Systems, Advanced Micro Devices, Agfa Healthcare, andrena objects ag, APL, Argo, Ariba, Artinsoft, ASPgems, ATSC, Attenex, AvidXchange, b+m Informatik AG, Bank of America, Bantrel, Barentz, Baufest, BBC, Beenox (Activision), BenQ, Bentley Systems, BMC Software, BNA Software, Booz Allen Hamilton, Bose, British Telecom, C.E.S.A.R, California State Automobile Association (AAA) - It Department, CAN, Canada Post, Capital One Financial, CENI2T, CIBER, Inc, Citerus AB, CitrixOnline, ClearChannel, CNN, Commerce360, Computer Associates - Wiley Div, Conchango, Connected Innovation, CoreTrek AS, Cornell University, Crisp AB, Cubika, Dicom, Economist (newspaper), eFunds, Inc., Eviture Limited, Federal Reserve Bank, FormScape, FPF, GE Energy, Georgia Institute of Technology, Gestalt, GIGA - PUC-Rio, Google, Hogeschool van Arnhem en Nijmegen (HAN University), HP, IBM, IDX, Infopark AG, Intelligenx, InterAct Public Safety Systems, InterBusiness Technologies, JDA Software Group, Key Bank, Knowtec, Korbitec, Kronos, Lash Group, Leapfrog Online, Lexis-Nexis, LMCO, Löwenfels Partner AG, Lulu.com, Lunar Logic Polska, Marshall Wace LLP, McKinsey & Co, Medtronic, Merrill Lynch, Microsoft, Midway, Mobile Fun Limited, mondora.com, Motley Fool, Inc, Motorola, NIIT Technologies, Nokia, Nokia Siemens Networks, Nortel, Novell, Océ, OnCast Technologies, Ontario Legislative Assembly, OpenLogic, Inc., OpenSource Connections, Outformations, Inc., Outsource Partners International, Palewar Techno Solutions (PTS), Patientkeeper, Inc., Philips Electronics India, Philips Research Miplaza/SES, Pinesoft, Pitney Bowes Busines Insight, Polycom, Primavera, Qpass/Amdocs, Qualcomm, Quantum Leap Innovations, Reaktor Innovations, Renew Data Corp, SAIC, Sammy Studios, SAP, Security Benefit - SE2, Siemens Austria, Siemens Medical Solutions, Smith Seckman Reid, Inc., Softhouse, Softtek, SolutionsIQ, State Farm, State Street Bank, Sun, Symphony Services Corp. (India) Pvt. Ltd, Synapse Technologies Ltd, Syntechnologies AB, SysOpen Digia, Systematic, TechMahindra, Telegraaf Media Group NV, The New Teacher Project, TransUnion, Trifork, Turner Broadcasting, Ultimate Software, Valtech, Vanguard Group, Vertical Communications, Vision Service Plan (VSP), Vision Software, Wells Fargo, Wizard Information Services, Xerox, Yahoo, BNP Paribas, Generali, Orange, Sagem, La Poste, Areva, M6, Pierre Fabre, Allianz GI France,... La contractualisationLa 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. En France et ailleurs, le contrat au forfait domine; 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. Ainsi que le principe de troc d'exigence : réalisation d'une exigence imprévue en échange du retrait d'une autre moins importante, de priorité faible et de même coût. Après quelques recherches, j'ai trouvé 2 compromis intéressants proposant des variantes du forfait classique permettant une meilleure collaboration client/fournisseur (win-win) :
Vous trouverez à l'adresse suivante les différents types de contrats pratiqués sur des projets Agile : http://alistair.cockburn.us/Agile+contracts |
|
|
|
Accueil >
Agile, c'est quoi ? |
