CHAPITRE 3 : LES METHODES AGILES? UE Gestion de Projet Master 1 STIC 2014/2015 Céline Joiron 2 Introduction Après avoir présenté les cycles de vie «classiques» de la gestion de projet L objectif de ce chapitre est de présenter l approche de Gestion de Projet véhiculée par les méthodes agiles Philosophie de «l Agilité» ou «Agility» Les principes généraux des méthodes agiles Les cycles de vies des principales méthodes agiles Pourquoi? A ce jour, elles sont devenues la majorité des méthodes de développement logiciel utilisées en entreprise 1
3 Plan 1 Définition et principes 2 Origine et valeurs 3 Principales méthodes 4 Bilan 5 Pour compléter? 4 1 Définition et principes Définitions «Une méthode agile est une approche itérative et incrémentale, qui est menée dans un esprit collaboratif, avec juste ce qu il faut de formalisme. Elle génère un produit de haute qualité tout en prenant en compte l évolution des besoins des clients.» [Messager, 2013] «Le terme «Agile» définit une approche de gestion de projet qui prend le contre-pied des approches traditionnelles prédictives et séquentielles de type cycle en V ou waterfall (en cascade).» www.agiliste.fr «Les méthodes agiles sont des groupes de pratiques de projets de développement en informatique (conception de logiciel), pouvant s'appliquer à divers types de projets. Elles ont pour dénominateur commun l'agile Manifesto....» Wikipédia (L agile Manifesto est présenté plus loin dans ce chapitre) 2
5 1 Définition et principes Construites sur les failles (avérées ou non) de l approche en cascade Rigidité de l approche cascade car pas de retours arrière possibles Peu de marge laissé au client pour préciser et faire évoluer ses attentes Effet tunnel (boite noire) : Des besoins è??? è Un produit Une mauvaise communication Levée tardive des facteurs de risques Tests d intégrité ou de performance à la fin par exemple Documentation pléthorique Pour se prémunir contre les risques, on documente tout, car une fois le codage commencé, c est «irréversible» 6 1 Définition et principes Une approche itérative et incrémentale Découpage du projet en itérations = étapes d une durée de quelques semaines Au cours d une itération une version minimale du produit attendu est développée puis soumise, dans sa version intermédiaire, au client pour validation Les fonctionnalités sont intégrées au fur et à mesure du cycle de vie è mode incrémental Le système s enrichit progressivement pour atteindre le niveau de satisfaction et de qualité requis. Chaque itération est un mini-projet qui comporte les activités d analyse, de conception, de codage, de tests et de gestion de projet. A l issue de chaque itération, on a un sous-ensemble opérationnel du système cible Au terme de la dernière itération, la version finale du produit Les itérations se succèdent et ne peuvent être parallélisées, leur date de fin est généralement fixe Mobiliser les efforts sur des objectifs clairs à courts terme Si les objectifs ne sont pas atteints, les enseignements en sont tirés lors du bilan de l itération pour corriger les conditions de l itération suivante 3
7 1 Définition et principes Un esprit collaboratif Placer les individus et leurs interactions au centre du dispositif Privilégier la communication entre l équipe mais aussi avec les interlocuteurs tels que client ou utilisateur Partage d information, échange de points de vue différents ou complémentaires, entraide et non concurrences Un formalisme léger Seulement quelque livrables à produire an plus de l essentiel (ie les versions intermédiaires de produits) Quelques rôles, quelques étapes, quelques réunions et la démarche est formalisée Ne pas doter l équipe d outils complexes auxquels elle devra s adapter et se former è approche adaptative 8 1 Définition et principes Un produit de haute qualité Si l on considère que le niveau de qualité minimal d un produit est sa capacité à satisfaire le client, tant sur le plan fonctionnel que sur celui des exigences de performance, de facilité d utilisation ou d évolutivité Sélection des fonctionnalités à implémenter en priorité Feedback permanent recueilli du client Campagnes de tests et contrôle qualité à chaque itération Nettoyage régulier (quotidien? ) du code et respect de normes de codage partagées Adoption d un approche adaptative Comprendre autrement, en image : Comparaison approche prédictive et agile : http://youtu.be/adeohwgrysi 4
9 Plan 1 Définition et principes 2 Origine et valeurs 3 Principales méthodes 4 Bilan 5 Pour compléter? 10 2 Origine et valeurs En 2001, 17 experts en développement logiciel se sont réunis pour échanger et trouver un socle commun de valeurs et de bonnes pratiques è «Manifeste pour le développement logiciel agile» è Création de l Agile Alliance (www.agilealliance.org) chargée de promouvoir l agilité dans les organisations et d apporter du soutien aux équipes qui veulent démarrer un projet agile Les quatre valeurs du Manifeste Les individus et leurs interactions avant les processus et les outils Des fonctionnalités opérationnelles avant la documentation Collaboration avec le client plutôt que contractualisation des relations Acceptation du changement plutôt que conformité aux plans è cela ne signifie pas qu aucun processus n est défini, qu on ne se dote d aucun outil J ; des plans et une documentation, plus réduits, sont produits 5
11 2 Origine et valeurs Origine et valeurs des méthodes agiles (suite) En 2005 a été publié la «déclaration d interdépendance» Signée par les acteurs majeurs de l Agile Alliance 6 concepts doivent être considérés de façon interdépendante : valeur, incertitude, client, individus, équipe, contexte «Vous ne pouvez créer de la valeur si vous ne collaborez pas avec un client, qui précisément, définit ce qu est sa valeur; vous ne pouvez attendre d une équipe qu elle soit performante si vous ne reconnaissez pas la contribution des individus qui la composent; vous ne pouvez maîtriser l incertitude si vous ne prenez pas en considération la spécificité du contexte.» 12 2 Origine et valeurs 13 principes des méthodes agiles Manifeste agile www.agilemanifesto.org 1 - Notre priorité est de satisfaire le client en lui livrant très tôt et régulièrement des versions opérationnelles de l application, source de valeur Grace au développement itératif, chaque livraison intermédiaire donne lieu à une validation par le client; son feedback est essentiel pour garantir la conformité de la livraison avec ses attentes, pour prendre en compte ses remarques et (re)prioriser 2 Accepter le changement dans les exigences, même tard dans le cycle de vie, pour garantir la compétitivité du client Cet état d esprit caractérise une équipe agile qui démontre ainsi sa capacité à comprendre et apprendre comment satisfaire encore mieux la demande 3 Livrer le plus souvent possible des versions opérationnelles de l application, à une fréquence allant de deux semaines à deux mois Une version intermédiaire du produit final, visible et testable, satisfait davantage le client qu une documentation à valider. Il a, de ce fait, la preuve tangible que le projet avance et peut exprimer son point de vue sur le résultat présenté 4 Client et développeurs doivent coopérer quotidiennement tout au long du projet Les relations conflictuelles ne font pas partie de l esprit agile, on préférera des relations collaboratives et de partenariat basées sur la confiance et le consensus. Le client (ou son représentant) est accessible et disponible, totalement impliqué dans toutes les phases du projet. 6
13 2 Origine et valeurs 5 Construire des projets autour d individus motivés. Leur donner l environnement et le support dont ils ont besoin et leur faire confiance pour remplir leur mission Le facteur clé de réussite d un projet est l équipe. Tout obstacle à son bon fonctionnement doit être levé; un changement, s il s avère nécessaire sera apporté aux processus, aux outils, à l environnement, à la composition de l équipe. 6 - La méthode la plus efficace de communiquer des informations à une équipe et au sein de celle-ci reste la conversation en face-à-face Par défaut, on privilégie l échange oral à l écrit, pour lever toute ambiguïté et favoriser la rapidité de compréhension. Tout ne peut être formalisé par écrit, notamment la «connaissance tacite», c est à dire l information «informelle», la culture de projet, détenues par chacun au sein d une équipe. 7 Le fonctionnement de l application est le premier indicateur de l avancement du projet Il n existe pas d autre indicateur plus pertinent que le pourcentage ou le nombre d exigences satisfaites; on ne mesure pas un projet à la quantité de documents produits ou au nombre de lignes de codes, non significatifs pour le client. 8 Les méthodes agiles recommandent que le projet avance à un rythme soutenable La qualité du travail fourni dépend du rythme de travail qui doit être adapté en fonction des spécificités du projet. Le rythme doit être soutenu et soutenable sur la durée du projet. 14 2 Origine et valeurs 9 Sponsors, développeurs et utilisateurs devraient pouvoir maintenir un rythme constant indéfiniment Ce rythme est à déterminer par l ensemble des membres de l équipe et par le client en fonction de la productivité de l équipe et des priorités du client. Mais travailler en heures supplémentaires, surtout pour corriger des bogues ou des régressions, n apporte aucune valeur ajoutée. 10 Porter une attention continue à l excellence technique et à la conception améliore l agilité Maintenir un code propre, évolutif et performant est un objectif permanent de l équipe; il ne s agit pas de produire du code non exploitable par les autres, ni du «jetable». De plus, cela évité surtout d enliser les développements ultérieurs avec des modifications cassant un développement fragile, nécessitant des interventions à des endroits variés du code. 11 La simplicité art de maximiser la quantité de travail non fait est essentielle La simplicité garantit l évolutivité du système. La complexité, au contraire, coûte davantage et rend plus difficile les évolutions inhérentes au développement incrémental. La conception ne doit comporter que des éléments utiles. 12 Les meilleurs architectures, spécifications et conceptions sont le fruit d équipes qui s auto-organisent Le chef de projet agile n est plus celui qui attribue des tâches. L équipe, elle-même, se responsabilise et définit ses travaux à réaliser, le partage des tâches s effectuant sur la base du volontariat. 13 A intervalles réguliers, l ensemble de l équipe s interroge sur la manière de devenir encore plus efficace, puis ajuste son comportement en conséquence. L environnement d un projet n est pas constant; l équipe agile, qui en a conscience, s interroge en permanence sur la façon d améliorer son fonctionnement afin de s adapter aux nouvelles conditions. C aussi l acceptation du changement. 7
15 2 Origines et valeurs Comprendre un peu plus en image avec une vidéo qui illustre la mise en action des méthodes agiles : http://youtu.be/lqficcsknis 16 Plan 1 Définition et principes 2 Origine et valeurs 3 Principales méthodes 4 Bilan 5 Pour compléter? 8
17 3 Principales méthodes Les méthodes les plus connues (et reconnues) s appuient sur les principes du manifeste Tronc commun pratique Se différencient par leurs degrés de formalisme Poids de la méthodologie dans la documentation, étapes formelles, revues d itération, rythme du projet ou durée des itérations Principales méthodes agiles présentées dans ce chapitre RAD : Rapid Application Development ASD : Adaptive Software Development DSDM : Dynamic Software Development Method XP : extreme Programming Processus Unifié (PU) ou Unified Porcessing (UP) Scrum 3 Principales méthodes Le cycle RAD (Rapid Application Development) Objectif : Développement rapide dans des délais réduits. Participation organisée et contrôlée des utilisateurs. Découpage temporel introduisant systématiquement une session participative entre l équipe projet et le groupe d utilisateurs au milieu de chaque phase Le cycle global conjugue modèles en cascade et en spirale. L étape construction se compose d un nombre variable de cycles de prototypage, mais strictement dans un temps limité (time box) à ne pas dépasser. 18 9
3 Principales méthodes 19 Le cycle ASD (Adaptative Software Development) Objectif : Approche collaborative pour gérer les projets complexes Modèle proposant une série de cycles en 3 volets : Spéculation : initier le projet, déterminer sa durée, le nombre d itérations (4 à 8 semaines par itération), affecter un objectif à chaque itération, dresser la liste des tâches. Collaboration : livraison des composants, communication forte et assez informelle Apprentissage : contrôle qualité, suivi et bilan d avancement, communication forte et assez informelle Caractéristiques : Focaliser sur l objectif ; se baser sur des composants; itérer ; time boxing ; pilotage par les risques ; accepter le changement. 3 Principales méthodes DSDM (Dynamic Software Devlopment Method) Objectif : utilisation de RAD de façon structurée et indépendante (Grande Bretagne) Modèle temporel itératif : Etude de faisabilité : définition du problème, étude faisabilité technique, méthodologique et budgétaire. Etude du business : analyse des processus métier, hiérarchisation des besoins en ateliers avec les utilisateurs ; définition de l architecture globale et du plan global de prototypage. Modèle fonctionnel itératif : description des besoins en détail, identification des modules logiciels constituant un prototype fonctionnel Conception et développements itératifs : fourniture d un système conforme aux besoins définis. Mise en œuvre : livraison, prise en main pour test ; bilan. Caractéristiques : implication active des utilisateurs, livraisons fréquentes, développement itératif et incrémental, intégration des tests dans tout le cycle de vie. Modèle fonctionnel itératif Etude de faisabilité Etude du business Conception et développements itératifs 20 Mise en oeuvre 10
21 3 Principales méthodes XP (extreme Programming) Objectif : approche systématique (extrême) des tests, de l implication des utilisateurs, des livraisons fréquentes. Le développement au cœur du projet. Pratiques de programmation : Conception simple : concision, modularité, lisibilité ; faciliter la maintenance Développement piloté par les tests unitaires Tests de recette Remaniement continu ou refactorisation du code : rendre le code le plus «propre» possible Programmation en binôme Règles de codage Propriété collective du code Métaphore : afin de faciliter échanges entre techniciens et fonctionnels Intégration continue Client sur site Séances de planification Livraisons fréquentes Rythme soutenable par les équipes 22 3 Principales méthodes Processus Unifié (PU) ou Unified Process (UP) Origine : Collaboration entre Ivar Jacobson, Grady Booch, et James Rumbaugh, tous trois à l origine des travaux sur l orienté objet et du langage de modélisation UML But : standardiser les bonnes pratiques en ingénierie logicielle Démarche itérative et incrémentale s'appuyant sur UML UML est un langage de modélisation (spécification, visualisation, construction et documentation) d un système logiciel Le problème est qu ont ne sait pas forcément bien comment mettre tous ces modèles en scènes ni à quels moments du cycle de vie d un projet informatique è «la méthode n est pas livrée avec la boite à outil» La méthodes élaborée = le Processus Unifié A voir comme le processus de développement logiciel, qui permet de répondre aux questions : qui? Quoi? Quand et Comment? 11
23 3 Principales méthodes Processus Unifié Utilise la modélisation UML pour la description de l'architecture du logiciel (fonctionnelle, logicielle et physique) la mise au point de cas d'utilisation permettant de décrire les besoins et exigences des utilisateurs 4 phases principales, qui se décomposent en itérations Inception : obtenir un consensus de l ensemble des parties prenantes sur la vision ou la portée du projet, le périmètre et l estimation globale Elaboration : établir et valider l architecture de référence, lever les principaux risques ainsi que spécifier en détail les exigences; c est une phase exploratoire Construction : livrer une première version opérationnelle du système, accompagnée de sa documentation Transition : déployer et mettre en production la version finale de l application, testée par les utilisateurs Chaque phase se compose d itérations Inception : itération 0 ou itération(s) préliminaire(s) Elaboration : itération 1 et 2 Construction : autant d itérations que nécessaires Transition : autant d itérations que nécessaires 24 3 Principales méthodes Processus Unifié Chaque itération s appuie sur 9 disciplines (ou processus) Décrites par des activités, des rôles er des artefacts 12
25 3 Principales méthodes Processus Unifié Dans chaque itération, et selon les phases et les processus, les diagrammes et modèles UML appropriés sont élaborés PU est centré autour des Cas d Utilisation (UML) Orienté Architecture Pour en savoir davantage sur le PU, un cours plus approfondi http://laurent.henocque.com/oldsite/doc/processus%20unifie%20rational %20Henocque%20Esil%20Info%202006.pdf Livres de référence sur le Processus Unifié, en français è disponible à la BU UPJV 26 3 Principales méthodes SCRUM Objectif : Travailler en équipes pluridisciplinaires intégrées et soudées dans une stratégie flexible Principe des petits ajustements fréquents Caractéristiques ou piliers de SCRUM : Visibilité : une fonctionnalité implémentée est considérée comme terminée lorsque tous les acteurs s entendent sur les modalités d évaluation des résultats tangibles. Scrum met l'accent sur le fait d'avoir un langage commun entre l'équipe et le management. Ce langage commun doit permettre à tout observateur d'obtenir rapidement une bonne compréhension du projet. Inspection : vérifier les écarts par rapport à l objectif initial ; nombreux points de contrôle. Adaptation : en cas de constat d écarts, ajustements décidés immédiatement. Si une dérive est constatée pendant l'inspection, le processus doit alors être adapté. Scrum fournit des rituels, durant lesquels cette adaptation est possible. Il s'agit de la réunion de planification de sprint, de la mêlée quotidienne, de la revue de sprint ainsi que de la rétrospective de sprint. SCRUM en images : Explaining Scrum in Less than 120 seconds : http://youtu.be/wxiue-1ujcm 13
27 3 Principales méthodes - SCRUM Modèle temporel itératif, reposant sur des sprints de 1 à 4 semaines : En amont du sprint : définition des Fonctionnalités attendues au cours du sprint (Sprint Backlog) en fonction des priorités du client (Customer Priority) et des fonctionnalités du produit dans son ensemble (Product Backlog) Sprint Backlog = Fonctionnalités définies pour 1 Sprint Sprint de 1 à 4 semaines pour produire ces fonctionnalités A la fin du Sprint : un nouvel incrément du produit 28 3 Principales méthodes - SCRUM Organisation de l équipe pour 1 sprint Sprint planning meeting : au début pour débfiir et présenter le Sprint Backlog c est à dire sélection des exigences prioritaires pour le client Daily Scrum Meeting : Réunion d avancement quotidienne (le Scrum Manager, avec toute l équipe). Sprint Review Meeting : démonstration des derniers développements faite au client Rétrospective : revue de fin de Sprint, bilan qualitatif interne à l équipe sur le fonctionnement de l équipe. Rôles dans SCRUM Le Product Owner Représente des clients et des utilisateurs. Son objectif est de maximiser la valeur du produit développé. Explicite les éléments (Items) du Product Backlog. Ses composantes sont exprimées sous forme d'histoires Utilisateur (User Stories). Rédige les spécifications et les cas de tests Définit l ordre de priorité des développement, notamment les objectifs de chaque sprint Doit avoir le niveau de prise de décision nécessaire et doit être disponible Le Scrum Master Responsable de la méthode, et rien d autre!!! Rôle de facilitateur et son objectif est maximiser la valeur produite par l'équipe dans le respect des règles de la méthode Scrum Dans certains cas, il peut être assimilé à un coach. Le développeur Tous les autres! Il n y a pas de rôles prédéfinis puisque l équipe est «auto-gérée» et autonome 14
29 3 Principales méthodes Avantages de Scrum Entièrement développé et testé pour de courtes itérations Simplicité des processus Organisation personnelle Responsabilisation de chacun Cohésion d équipe Combinaison possible avec XP Inconvénients de Scrum Peu, voire pas, de documentation écrite Violation de responsabilité (pas de hiérarchie) Pratiques assez nouvelles donc conduite du changement à prévoir Très difficile à mettre en place avec une équipe virtuelle Disponibilité accrue du client Livre DUNOD sur SCRUM, disponible à la BU UPJV (image ci-dessus) Site web de la méthode Scrum www.scrum.org Téléchargez le Guide Scrum en français https://www.scrum.org/portals/0/documents/scrum%20guides/2013/scrum-guide- FR.pdf#zoom=100 30 Plan 1 Définition et principes 2 Origine et valeurs 3 Principales méthodes 4 Bilan 5 Pour compléter 15
31 4 - Bilan PU et RAD ne sont pas classés par tout le monde comme étant des méthodes agiles Certains concepts relèvent de l agilité, Le management de projet et leur application peuvent rendre leur utilisation «agile» ou pas Les méthodes agiles, au delà de démarches et de formalisme, véhiculent une certaine philosophie et un certain «art» de la gestion de projet On adhère ou on adhère pas Si l on adhère pas à l ensemble des préconisations du Manifeste, possibles échecs des projets Discours un peu chronique qui dirait que les «bons» sont du coté agile et les «méchants» sont du coté waterfall Un peu manichéen comme vision du monde Le principe est peut-être de garder un esprit critique vis à vis de tout ceci et se faire sa propre idée 32 4 - Bilan Attention au modèle avalanche! «Anti-modèle» de gestion de projet informatique Combinaison d'un cycle de vie de type cascade avec des méthodologies Agiles Ce qui surviendrait lorsqu un chef de projet tente d'appliquer des techniques agiles à un projet, quand tout ce qu il sait gérer ou a appris s apparente à un cycle de vie séquentiel Bien souvent, au lieu de découper le projet en plusieurs unités qui vont subir les différentes phases de développement, l'ensemble du projet suit toutes les phases de développement en même temps. Conséquence probables è confusion de masse, gaspillage d'efforts, voir produit ne pouvant pas répondre aux spécifications du cahier des charges 16
33 4 - Bilan http://www.versionone.com/state-of-agile-survey-results/ Sondage Version One 2012 Scrum serait la méthode agile la plus populaire (54% des usages de méthodes agiles se seraient orientés vers Scrum suivis à 11% par des usagers d une solution hybride Scrum/XP) 83% des personnes interrogées envisagent d utiliser une méthode agile (contre 53% l année précédente) Causes énoncées des échecs de projets agiles 12% pour cause de non alignement entre la philosophie ou la culture de l entreprise avec les valeurs agiles 11% pour des problèmes organisationnels ou de communication 11% suite à des pressions externes pour revenir à un cycle de vie plus séquentiel 18% affirment n avoir connu aucun échec de projet avec les méthodes agiles 34 4 Bilan Autre vidéo à regarder sur Youtube : Conférence de Véronique Messager à l AgileTour2011 «Améliorez l efficacité de vos cérémonies agiles» : http://youtu.be/xvjz0vib78a Autre méthode : La RACHE A prendre au moins au deuxième degré!!! J http://byatoo.com/la-rache/ 17
35 5 Références Pour construire ce chapitre : Bibliographie Messager V. «Gestion de projet Agile avec Scrum, Lean, extreme Programming», Eyrolles, 2013. Guérin B.A., «Conduite de projets informatiques, Développement, analyse et pilotage 2 e édition», eni éditions, 2012. Webographie «La gestion de projet» de Xavier Liénart http://xavier.lienart.pagesperso-orange.fr/gdp/gdp.html Wikipédia Youtube VersionOne.com Ramsoft.com 18