Agile en quelques motsLe terme "Agile" définit une approche de gestion de projet 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 et conflictuel, 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 se terminent 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) 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 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é, en impliquant le client du début à la fin du projet et en adoptant un mode itératif et incrémental. Elle considère que le besoin ne peut être figé et propose au contraire de s'adapter aux changements ce dernier. Mais pas sans un minimum de règles. Principe de fonctionnementUne approche Agile part du principe que spécifier et planifier dans les détails l'intégralité d'un produit avant de le développer (approche prédictive) est contre productif. Cela revient à planifier dans les détails un trajet "Paris - Narbonne" en voiture par les petites routes. Spécifiant chaque villes et villages traversés, l'heure de passage associée, chaque rue empruntée dans les agglomérations, litres d'essence consommés, kilomètres parcourus, etc. Les imprévus ne manquerons pas d'arriver : embouteillages, déviations, travaux, sens de circulation inversés, voir la panne, etc. Rendant votre planification et vos spécifications très vite obsolètes. Combien de temps aurez vous passé à planifier cet itinéraire, comment réagirez vous face à vos frustrations de ne pas pouvoir appliquer votre plan à la lettre ? Une approche Agile consiste à se fixer un premier objectif à courts termes (une grande ville par exemple) et se lancer sur la route sans tarder. Une fois ce premier objectif atteint, on marque une courte pose et on adapte son itinéraire en fonction de la situation du moment. Et ainsi de suite jusqu'à atteindre la destination finale (approche empirique). L'équipe sélectionne ensuite une portion des exigences à réaliser dans une portion de temps courte appelée itération. Chaque itération inclut des travaux de conception, de spécification fonctionnelle et technique quand c'est nécessaire, de développement et tests. A la fin de chacune de ces itérations, le produit partiel est montré au client. Ce dernier peut alors se rendre compte par lui même très tôt du travail réalisé, de l'alignement sur le besoin. L'utilisateur final quant à lui peut se projeter dans l'usage du produit et émettre des feedbacks précieux pour les futures itérations. La visibilité ainsi offerte est clef. Cette transparence peut également apporter davantage de confiance et de collaboration dans la relation client/fournisseur. Les risques quant à eux sont levés très tôt. Si le client a priorisé avec soin son besoin, il peut saisir l'opportunité d'accélérer le "time to market" si il estime que le produit en l'état (partiel) peut aller en production, économisant ainsi son budget et récoltant un premier retour sur investissement. Il a aussi la possibilité de changer en cours de route la priorité des fonctionnalités qui n'ont pas encore été développées. Pour retarder une fonctionnalité dont le besoin n'est pas mûr, pour ajouter une nouvelle fonctionnalité cruciale en échange du retrait d'une autre (respectant ainsi budget et délais),... Cette souplesse ainsi offerte est donc un véritable atout pour le client. Témoignage clientThierry Roche, DSI de l'Apec Quels ont été les avantages de ces méthodes pour votre projet ? Déjà, on voit concrètement l'évolution du projet car après chaque itération, les utilisateurs peuvent visualiser un « bout » de projet qui fonctionne, ça brise l'effet tunnel des méthodes classiques. Cette évolution nous permet de prioriser nos réels besoins, l'application s'enrichit selon nos demandes. Le surplus n'existe pas, on ne développe pas des fonctionnalités qui ne nous serviront jamais comme c'est régulièrement le cas en adoptant des méthodes classiques. On atteint un bénéfice utilisateur plus rapidement mais aussi un gain financier non négligeable. Nous n'imaginons même pas un retour avec des méthodes classiques. Source : Le Monde Informatique
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. 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. Le terme "Agile" pour qualifier ce type de méthode est également né à cette occasion. 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. Ces derniers temps, on peut noter la prise de position en faveur de l'approche Agile de la part des organismes faisant "autorité" en matière de gestion de projet informatique :
Manifeste AgileLe manifeste Agile contient toute l'essence et la philosophie de l'approche en question. ValeursNous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. Ces expériences nous ont amenés à valoriser : Les individus et leurs interactions plus que les processus et les outils Des logiciels opérationnels plus qu’une documentation exhaustive La collaboration avec les clients plus que la négociation contractuelle L’adaptation au changement plus que le suivi d’un plan Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers. PrincipesNous suivons ces principes:
Le cadre méthodologique « Scrum »Pourquoi Scrum en particulier ? Tout simplement parce que Scrum est de très loin la méthodologie la plus utilisée parmi les méthodes Agile disponibles. Elle est donc la plus éprouvée, documentée et supportée. Livres, blogs, formations, vidéos, associations, séminaires traitant de Scrum ne manquent pas et bon nombre de ces ressources sont accessibles gratuitement. On pourrait pratiquement parler d'un standard Agile. Un autre atout important de Scrum est simple à comprendre, sa maîtrise est en revanche difficile. 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 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 et strictement limitées dans le temps (timebox):
Le schéma suivant résume le processus Scrum :  Scrum apporte également quelques outils très utiles comme le planning poker qui permet d'estimer collectivement et efficacement les exigences à réaliser. 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 ajoutée métier, du coût de chaque exigence et des risques identifiés. Les exigences seront réalisées dans l'ordre ainsi défini selon les contraintes de l'équipe chargée des développements et les éventuelles dépendances (exigence D à faire avant l'exigence X). 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. L'objectif de Scrum consiste à produire le plus tôt possible la plus grande valeur possible, afin de créer des opportunités d'accélération du "Time to market". 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 représentant l'évolution du travail restant à faire (ou RAF : Reste A Faire) en fonction du temps : En voici un exemple pour une release embarquant 200 unités de coût sur 11 itérations :  Mais qui utilise Scrum ?Voici une partie de la réponse : 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. On peut aussi trouver des approches gagnant-gagnant plus créative telles que : On peut trouver à l'adresse suivante les différents types de contrats proposés pour des projets Agile : http://alistair.cockburn.us/Agile+contracts Pour terminer, voici un article intéressant du cabinet d'avocats STAUB & ASSOCIES (avocats au barreau de Paris) : "Les méthodes Agiles : de la souplesse dans les contrats informatiques". |
|
|
|
Accueil >
Agile, c'est quoi ? |
