Gestion de projets Les méthodes Agiles

Gestion de projets Les méthodes Agiles

Méthodologies Agiles RAD, XP, SCRUM 2

Méthodes de gestion de projets o La Méthode en Cascade o Le Modèle en V o Les Méthodes RAD (Rapid Application Developement) Les méthodologies Agiles avec: SCRUM XP (extreme Programming) AUP (Agile Unified Process) Crystal FDD (Feature Driven Development) 3

Systèmes Complexes Non prédictibles N ont pas une seule bonne réponse. Comportent un grand nombre d éléments interagissant entre eux d une façon non linéaire. Des petits changements peuvent entrainer de graves, conséquences (Effet papillon). Organisation très dynamique et en perpétuel changement. La complexité du tout est plus complexe que la somme des complexités des parties. Ont un historique très lié au présent et dépendent de l environnement extérieur. 4

Catégorisation de la complexité des systèmes 5

1. Pré-étude/Planification La Méthode en cascade = Faisabilité/Phases, Taches, Temps, Ressources 2. Spécifications = Quoi = Ce qu il faut produire 3. Conception Technique = Comment = Organisation, Structure 4. Construction = Code + Documents 5. Test = Validation du code et de la Documentation 6. Installation = Mise en Production 7. Déploiement = Utilisation et Maintenance 6

La Méthode en cascade 7

Avantages et Inconvénients de la Cascade Avantages Modèle prédictive Simple et robuste Facile à implémenter Inconvénients Orienté planification Cycles trop longs Manque de flexibilité Faible Réactivité Retour aux étapes précédentes si anomalie Le résultat peut ne plus correspondre aux besoins Prédictive, Robuste, implémentation Facile Long, Peu Réactive, Obsolète, Rigide 8

Le Modèle en V 1. Analyse des besoins et faisabilité 2. Spécification 3. Conception architecturale 4. Conception détaillée 5. Codage 6. Test unitaire 7. Test d'intégration 8. Test de validation 9. Recette 9

Le Modèle en V 10

Avantages et Inconvénients du modèle en V Avantages Modèle Prédictive Cycles moins longs Plus de flexibilité Meilleur Réactivité Limite les retours en arrière si anomalie Inconvénients Orienté planification Plus complexe que le modèle en cascade Plus difficile à mettre en œuvre Difficile de séparer les phases de conception et de réalisation Le résultat peut ne plus correspondre aux besoins Prédictive, Plus réactive, Limite les retours Complexe, Difficile à mettre en œuvre 11

Méthode Spirale Cyclique 12

Avantages et Inconvénients de la spirale Avantages Modèle plus adaptatif que Prédictif Cycles courts, RAD (Rapid Application Development) Grande Flexibilité, Grande Réactivité Plus de collaboration et d interactivité avec les utilisateurs Plus adapté aux Nouvelles Technologie Le résultat final est conforme aux besoins Amélioration continue Inconvénients Manque de recul au départ Le produit final n est pas disponible immédiatement Nécessite un effort continue et soutenu Adaptative, Flexible, Réactive, Cycles Courts Manque de recul, Effort continu et soutenu 13

Les Méthodologies Agiles Les méthodes Agiles sont des pratiques qui s'appliquent aux projets de développement logiciel Elles sont plus pragmatiques que les méthodes traditionnelles Elles permettent une grande réactivité aux demandes utilisateurs Ce sont des structures cycliques, itératives, incrémentales et adaptatives Elles sont orientées satisfaction des besoins client et non contrat Officialisée en 2001 par le Manifeste Agile (Agile Manifesto), signé par 17 personnalités Elles reconnaissent leur parenté directe avec les Méthodologies RAD (Développement rapide d'applications) de James Martin (1991) Les plus connues sont : Scrum (1996) XP (extreme Programming, 1999) 14

Les Méthodologies Agiles Approche collaborative, Itérative et incrémentale La difficulté est repartie sur plusieurs parties (Le projet est décomposé) Livraisons de résultats fréquents et validation continue Gère mieux les demandes de changements en cours - Accepte d introduire des changements plutôt que de suivre strictement un plan rigide Orienté résultat plus que documentation Orienté interactions plus que processus et outils Collaboration avec l utilisateur plutôt que relation contractuelle 15

Agile Manifesto 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale 4. Business people and developers must work together daily throughout the project 5. Build projects around motivated individuals 6. Give them the environment and support they need, and trust them to get the job done 7. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation 8. Working software is the primary measure of progress 9. Agile processes promote sustainable development 10. The sponsors, developers, and users should be able to maintain a constant pace indefinitely 11. Continuous attention to technical excellence and good design enhances agility 12. Simplicity, the art of maximizing the amount of work not done is essential 13. The best architectures, requirements, and designs emerge from self-organizing teams. 14. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts 15. its behavior accordingly 16

Les 12 principes de la méthodologie Agile 1. Satisfaire le client en lui livrant fréquemment une application utilisable rapidement 2. Accepte les changements de l utilisateur même dans des étapes tardives 3. Livraisons fréquentes de fonctions qui «marchent» (toutes les deux semaines et au plus tard tous les deux mois) - Cycles très courts 4. Travail quotidien entre l équipe projet et les utilisateurs 5. La motivation des équipes est le centre d intérêt de la méthode 6. Privilégie les rencontres directes (Face to face) plutôt que du travail à distance ou par mail 17

7. La fonction livrée est l unité de mesure de l avancement du projet 8. La méthodologie encourage un rythme soutenu du développement 9. Attention continue à l excellence technique et à une meilleur conception 10. Produire uniquement ce qui est nécessaire 11.Des équipes autogérées 12. Amélioration continue 18

Les méthodologies Agiles Les Méthodologies Agiles sont: Excellents pour les développement de logiciels Un cadre de travail, un Framework plus qu une méthodologie pour les projets «non prédictibles» et complexes Les Pratiques SCRUM (Mêlée, Rugby) XP (extreme Programming) AUP (Agile Unified Process) Crystal FDD (Feature Driven Development) 19

Méthodologies Classiques Vs Agiles 20

Rapid Application Development La méthode RAD se base sur les publications de Barry Boehm (modèle en spirale), Tom Gilb (cycle de vie évolutif), Scott Shultz (production en itérations rapides) ainsi que Brian Gallagher et Alex Balchin. La méthode RAD intègre aussi les techniques JRP (Joint Requirements Planning) et JAD (Joint Application Design / Development / Delivery). Les principes de JAD furent initiés par Dan Gielan, puis formalisés par Chuck Morris d'ibm en 1984 et vulgarisés sous forme de livres en 1989 par, entre autres, J. Wood et D. Silver. James Martin formalisa la méthode RAD et la publia en avril 1991 21

La méthode RAD, après deux courtes phases de formalisation structurée de l'expression des besoins (CADRAGE) et de définition globale de l'architecture technique (DESIGN), inclut dans sa phase principale (CONSTRUCTION) la réalisation, la validation immédiate et les tests d'une application en mode itératif-incrémentaladaptatif. L'objectif de la méthode, qui implique activement l'utilisateur final dans un principe de «validation permanente», est d'obtenir un applicatif en adéquation avec les réels besoins. La planification adaptative de la méthode RAD répondait, à l'origine, aux besoins de projets simples. Elle se limitait généralement à jouer sur un des trois côtés du fameux triangle de gestion de projet (qui restaient fixes dans les méthodes cascades), à savoir : durée, coût, périmètre. Le but étant de fixer au moins l'un des trois paramètres en fonction du besoin immédiat de l'utilisateur (valeur ajoutée). 22

Le RAD préconise la formation d'une équipe de développement particulière : le SWAT. Cette équipe est autonome, spécialement formée, concrètement motivée et outillée. Elle se compose essentiellement d'un profil unique de concepteurs-développeurs formés à des spécialités techniques complémentaires. Le rôle de chef de projet, n'est ni prohibé, ni obligatoire. Par contre, les décisions concernant l'organisation du projet sont consensuelles. L'équipe travaille avec les utilisateurs et, généralement avec un animateur, dans une salle dédiée, isolée, spécialement équipée dans le style «war room», où les murs sont utilisés pour afficher un «radiateur d'information» (une forme de cockpit de gestion de projet). 23

Un cycle de développement sécurisant et court fondé sur un phasage simple : Cadrage, Design, Construction et l absolu respect d une dimension temporelle (90 jours optimum, 120 jours maximum) Une architecture de communication engageant des groupes de travail de structure et de composition variables selon les besoins des phases et respectant un mode opératoire précis structuré en trois étapes : pré-session, session, post-session Des méthodes, techniques et outils permettant de définir et d appliquer des choix portant sur quatre natures d'objectifs potentiellement contradictoires : budget, délais, qualité technique, qualité fonctionnelle et visibilité Une architecture de conception s appuyant sur les techniques de l'objet et particulièrement sur celles qui permettent une conception «en vue de modifications» Une architecture de réalisation qui impose, pour garantir la qualité technique, des normes minimales, des revues de projet, des jalons zéro-défaut et qui recommande, pour garantir la qualité fonctionnelle, le prototypage actif et les focus de visibilité 24

Cycle RAD - Agile 25

La méthode RAD structure le cycle de vie du projet en 5 phases (dont 3 systématiques) : L initialisation prépare l organisation, puis détermine le périmètre et le plan de communication Le CADRAGE définit un espace d objectifs, de solutions et de moyens Le DESIGN modélise la solution et valide sa cohérence systémique La CONSTRUCTION réalise en prototypage actif (validation permanente) La finalisation est réduite à un contrôle final de qualité en site pilote. 26

Cycle RAD - Agile 27

Avantages et Inconvénients de RAD Avantages Modèle plus adaptatif que Prédictif Cycles courts, RAD (Rapid Application Development) Grande Flexibilité, Grande Réactivité Plus de collaboration et d interactivité avec les utilisateurs Plus adapté aux Nouvelles Technologie Le résultat final est conforme aux besoins Amélioration continue Inconvénients Nécessite un effort continue et soutenu Adaptative, Flexible, Réactive, Cycles Courts Effort continu et soutenu 28

XP extreme Programming 29

XP extreme Programming XP est une méthode de programmation légère et agile qui améliore la production des logiciels en les développant et en les testant rapidement Crée par Kent Beck et Ron Jeffries en 1996 Correspond plus aux petites équipes Réduit significativement la partie administrative des projets (Cérémonies) qui éloigne l équipe de la productivité l'équipe se focalise sur l'objectif du projet afin d'obtenir un produit logiciel qui fonctionne et le plus rapidement possible L équipe de développement travaille directement avec les utilisateurs sur des sprints courts (1 ou 2 semaines) 30

puisque la revue de code est une bonne pratique, elle sera faite en permanence (par un binôme) ; puisque les tests sont utiles, ils seront faits systématiquement avant chaque mise en œuvre ; puisque la conception est importante, elle sera faite tout au long du projet (refactoring) ; puisque la simplicité permet d'avancer plus vite, nous choisirons toujours la solution la plus simple ; puisque la compréhension est importante, nous définirons et ferons évoluer ensemble des métaphores ; puisque l'intégration des modifications est cruciale, nous l'effectuerons plusieurs fois par jour ; puisque les besoins évoluent vite, nous ferons des cycles de développement très rapides pour nous adapter au changement. XP est axé sur l'équipe de développement, propose certaines pratiques poussées à l'extrême comme le Pair Programming (Travail en binôme) Relecture du code par le binôme Le Refactoring Le TDD - Test Driving Developpement. Livraisons rapides et fréquentes pour obtenir le feedback utilisateurs le plus rapidement possible. Tests unitaires générés automatiquement (TDD) Gestion commune des sources (CVS, ClearCase, Git, Bazzar, subversion, Mercurial) Constitution automatique de la version (Build avec Ant) KISS: Keep It Simple & Stupid, commencer par les fonctionnalités les plus simples, les autres après 31

Le Cycle de Développement XP Le cycle de développement XP consiste en 2 phases: Release Planning (ce qu'il faut produire et avec quelle priorité) Iteration Planning (Décomposer en taches et planifier les activités) Release planning : Le projet est décomposé en petite Releases, décomposées en user stories L'utilisateur écrit la user story sur la user card. Le développeur analyse le scenario et estime le temps L'utilisateur attribue les priorités aux taches Iteration planning : Estimer les taches et Assigner chaque tache à deux développeurs Les développeurs valident l'estimation et s'engagent Conception de la tache Développer un plan de test Développer le code, revoir et vérifier le code Conduire le test unitaire, conduire le test fonctionnel 32

XP Cycle de vie 33

XP TDD TDD (Test Driven Development) - Développement conduit par les tests et par l'intégration continue des parties qui composent le produit final. Il commence par construire des cas d'utilisation (use case) avant de construire le code lui-même Les besoins fonctionnels sont exprimés comme cas de tests (test cases) qui sont extraits des scenario utilisateurs (User Stories) la méthode d'implémentation développe le code nécessaire pour satisfaire les cas de test et vérifie que celui-ci se déroule correctement en exécutant le code développé 34

Le cycle préconisé par TDD comporte cinq étapes : 1.écrire un premier test 2.vérifier qu'il échoue (car le code qu'il teste n'existe pas), afin de vérifier que le test est valide 3.écrire juste le code suffisant pour passer le test 4.vérifier que le test passe 5.puis réusiner le code, c'est-à-dire l'améliorer tout en gardant les mêmes fonctionnalités. 35

XP Résumé Pour résumer, on peut dire que XP est une méthodologie légère qui met l accent sur l activité de programmation et qui s appuie sur la communication, la simplicité et le feedback utilisateur. Elle est bien adaptée pour des petits et moyens projets où le contexte (besoins utilisateurs, technologies informatiques) évolue en permanence Il ne s agit pas de se jeter sur l écriture de code en négligeant de formaliser les besoins des utilisateurs et d élaborer une architecture et une conception technique robuste et évolutive 36

XP Résumé Simplicité Développement Incrémental Flexible au changement Documentation et processus simples et légers Produire de la qualité Commencer petit et grandir avec le temps Communication honnête et amicale S adapter en fonction de la situation Mesurer que ce qui est nécessaire (indicateurs) Accepter la responsabilité et prendre Attitude positive Contribuer à la motivation de l'équipe. 37

SCRUM 38

SCRUM Scrum est une méthode agile dédiée à la gestion de projets informatiques Son objectif est d'améliorer la productivité des équipes Le mot «Scrum» vient du mot «mêlée» du rugby, (le concept a été initié par Takeuchi et Nonaka, 1986) Le processus s'articule autour d'une équipe soudée, qui cherche à atteindre un but, comme en rugby pour avancer avec le ballon pendant une mêlée. la méthode n'est pas une technique de programmation, il faut lui associer une méthode de développement comme: XP (extreme Programming) ou la «Construction structurée» de la méthode RAD 39

SCRUM La méthode scrum est fondée sur la conviction que le développement logiciel est une activité par nature non-déterministe et que l'ensemble des activités de réalisation d'un projet complexe ne peut être anticipé et planifié. C'est en cela que le scrum s'oppose aux démarches prédictives telles que le cycle en V ou en cascade. Représentation schématique 40

Les Composants de la Méthodologie SCRUM Les spécifications (Backlogs) Les Réunions (Cérémonies) Les Rôles (Roles) Les outils (Tools) 41

Les spécifications (Backlogs) Le product backlog Le référentiel des exigences initiales est dressé et hiérarchisé avec le client. Il constitue ce que l on nomme le product backlog. Il ne doit pas nécessairement contenir toutes les fonctionnalités attendues dès le début du projet, il va évoluer durant le projet en parallèle des besoins du client. «Sorte de cahier des charges évolutive» 42

User Story Les fonctionnalités décrites portent le nom de User Stories et sont décrites en employant la terminologie utilisée par le client. Une User Story ou Story contient généralement les informations suivantes : ID un identifiant unique. Nom un nom court (entre 2 et 10 mots), descriptif de la fonctionnalité attendue par le client (ex. Export / Import Standard Sales Item). Le nom doit être suffisamment clair pour que les membres de l équipe et le Product Owner comprennent de quelle fonction il s agit. Le nom ne doit pas introduire d ambigüités. Importance un entier qui fixe la priorité des Stories. La priorité d une story peut être changée en cours de réalisation du projet. Estimation La quantité de travail nécessaire pour développer, tester, et valider cette fonctionnalité. L unité de mesure peut être un nombre de jours idéaux (jours à 100% dédiés à la fonctionnalité) ou un nombre de points. Les estimations se font en relatif en comparant les estimations des stories terminées avec la story à estimer. Demo Un test relativement simple (ex : exporter un objet en XML puis l effacer de la base, l importer depuis le XML, à la fin l objet doit être dans la base). Ce test constitue un test de validation. Notes toute autre information : clarifications, références documentaires 43

Les Réunions(Cérémonies) Les Cérémonies La Planification du Sprint (Sprint Planning) La Revue du Sprint (Sprint Review) La mêlée quotidienne (Daily Scrum Meeting) La réunion de rétrospective (Retrospective ) 44

Le Sprint C est le processus de base du développement dans SCRUM De 1 semaine à 1 mois Plusieurs sprints par projet Il commence par le «Sprint Planning Meeting», se termine par le «Sprint Review» et comporte plusieurs «Daily Scrum Meeting» Vélocité du sprint = Quantité de travail faite par sprint N inclut que les éléments du backlog ayant la plus haute priorité et donc la plus grande valeur ajoutée au produit 45

le sprint planning meeting On organise, avant chaque sprint, une réunion de planification, le sprint planning meeting. Ce planning sélectionne dans le product backlog les exigences les plus prioritaires pour le client. Elles seront développées, testées et livrées au client à la fin du sprint. Elles constituent le sprint backlog, un sous ensemble du product backlog. Le Product Owner décrit à l équipe les éléments du sprint backlog selon l ordre des priorités Durée : 2 à 3 heures Participants : Product Owner Scrum Master Team Autres expert dans le sujet ou membre de la direction 46

La mêlée(daily Scrum Meeting) Durée : 15 à 30 minutes MAX Au cours du sprint, il est organisé, chaque jour, une réunion d avancement (environ 15 min) avec tous les membres de l équipe afin de s assurer que les objectifs du sprint seront tenus, c est le Scrum ou mêlée. Chaque jour, après la réunion Scrum, le Scrum Master maintient un graphique appelé sprint burndown chart. Ce graphique donne une très bonne vision de ce qui a été fait et du rythme de travail de l équipe. Il permet également d anticiper si toutes les stories du Sprint Backlog seront terminées à la fin de l itération ou non. 47

La mêlée (Daily Scrum Meeting) Cette réunion n a pas seulement un but purement informatif, mais aussi de stimuler l esprit de travail en équipe et le niveau d engagement de chaque membre de l équipe dans le projet. Durant la réunion chaque membre de l équipe doit prendre la parole et présenter principalement les choses suivantes : Ce que j ai fait hier et les éventuels problèmes rencontrés. Ce que je vais faire aujourd hui. Est ce que j ai des difficultés pour continuer mon travail. En faisant cet exercice quotidiennement chaque membre de l équipe est au courant de ce que font ses collègues et il peut coordonner son travail et aider ou se faire aider en cas de difficultés. 48

Sprint Review Objectif: Améliorer le produit Démontre les Réalisations Les utilisateurs voient les résultats et donnent leur «feedback» Durée: 2 heures Objectif: Améliorer l équipe Améliore le processus Responsabilise l équipe et l encourage à réussir Durée: 2 heures 49

Sprint Restrospective La rétrospective du sprint est faite en interne à l'équipe scrum (équipe de réalisation, propriétaire du produit et scrum master). Elle dure trois heures pour un sprint d'un mois. Elle a pour but l'adaptation aux changements qui surviennent au cours du projet et l'amélioration continue du processus de réalisation. L'objectif est d inspecter l'itération précédente, afin de déterminer quels sont les éléments du processus de développement qui ont bien fonctionné et ceux qui sont à améliorer. L'équipe de développement déduit un plan d'actions d'amélioration qu'elle mettra en place lors de l'itération suivante. 50

Les Outils (Tools) 51

sprint backlog En début de sprint, un but est décidé. Pour atteindre cet objectif, l'équipe de développement choisit lors de la réunion de planification de sprint quels éléments du carnet de produit seront réalisés. Ces éléments sont alors groupés dans un carnet de sprint. Chaque équipe met à jour régulièrement le carnet de sprint au cours de son activité, afin que celui-ci donne une vision la plus précise possible de ce que l'équipe prévoit de réaliser pour atteindre l'objectif du sprint. Le carnet de sprint est sous la responsabilité de l'équipe et elle est seule à pouvoir le modifier en cours d'itération. 52

Les Rôles Le Product Owner (Commanditaire du projet Coordinateur Utilisateurs) Expert métier, définit les spécifications fonctionnelles Etablit la priorité des fonctionnalités à développer ou corriger Valide les fonctionnalités développées Joue le rôle du client C est le Rôle No. 1 Définit le Produit Il est responsable: Du Backlog du Produit (Product Backlog) De la priorisation des éléments du Backlog (Backlog Items) De la validation finale du produit C est l équivalent du commanditaire du projet (Sponsor) et/ou du coordinateur des utilisateurs 53

Les Rôles L équipe (L équipe Projet) Pas de rôle bien déterminé : architecte, développeur, testeur. Tous les membres de l équipe apportent leur savoir faire pour accomplir les tâches. Taille de 6 à 10 personnes en général et pouvant aller jusqu à 200 personnes. C est le Rôle No. 2 Construit le Produit Elle est responsable de développer le produit et de faire les estimations Elle est Polyvalente (multifonctionnelles) Il n y pad vraiment des rôles (pas de hiérarchie) La responsabilité est partagée 54

Les Rôles Le Scrum Master (Le Chef de Projet) S assure que les principes et les valeurs de Scrum sont respectés. Facilite la communication au sein de l équipe. Cherche à améliorer la productivité et le savoir faire de son équipe. C est le Rôle No. 3 Expert du Processus Il est responsable de: Coordonner l équipe Scrum Résoudre les problèmes qui l équipe rencontre Faire écran pour l équipe qu il protège des éléments extérieurs Aider à la réussite de l objectif du projet Aide la prise de décision dans l équipe 55

Les outils IceScrum (gratuit) ScrumWorks (version gratuite et pro payante) Agilo (version gratuite et pro payante) GreenHopper - plugin JIRA (payant) Pivotal Tracker (payant) Mingle (Payant) Banana Scrum (Saas payant) TargetProcess (payant) VersionOne (payant) 56

IceScrum: http://www.icescrum.org/ 57

ScrumWorks Basic: http://www.danube.com/scrumworks/basic 58

Scrum Résumé Agile et un processus de gestion de projet, XP est une Technique de développement Principes aux antipodes des méthodes traditionnelles On ne peut pas tout connaitre ou anticiper, il faut donc avancer petit à petit (itérations) afin de s adapter au fur et a mesure Il n'y a pas qu'une seule façon de faire Penser simple, agir efficacement, et produire de la Qualité Avancement basé sur du concret Ajustements réguliers Livraisons fréquentes de logiciels de qualité 59

Scrum Résumé Ne produire que ce qui est nécessaire Feedback fréquents et rapprochés Une démarche d'amélioration continue visant à augmenter la qualité et la productivité Une construction itérative et incrémentale du logiciel Plus grande réactivité, Flexibilité aux changements Contact direct du métier, le client est au cœur du projet Une organisation favorisant la communication entre les équipes projet et les utilisateurs métiers Le pilotage par les tests pour assurer la non régression au fil des évolutions Maîtriser les coûts de développement 60

Scrum Résumé Maximiser le ROI des projets Améliorer le moral et la motivation des équipes projet Penser court terme plutôt que long terme Logiciel fonctionnel qui marche plutôt que de la documentation excessive et lourde Répondre aux changements plutôt que suivre un plan Réactivité aux besoins de l'utilisateur plutôt qu'une relation contractuelle Les individus et leurs interactions plutôt que les processus et les outils Le résultat de qualité plutôt que du blabla Le contenu est plus important que la présentation 61

62