Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

Méthodes agiles: Scrum et XP

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Chargement dans…3
×

Consultez-les par la suite

1 sur 57 Publicité

Méthodes agiles: Scrum et XP

Télécharger pour lire hors ligne

Cette présentation, mise en scène les valeurs et les principes des méthodes agiles , ainsi qu'une présentation détaillée sur la méthode XP et la méthode Scrum.

Cette présentation, mise en scène les valeurs et les principes des méthodes agiles , ainsi qu'une présentation détaillée sur la méthode XP et la méthode Scrum.

Publicité
Publicité

Plus De Contenu Connexe

Diaporamas pour vous (20)

Similaire à Méthodes agiles: Scrum et XP (20)

Publicité

Plus récents (20)

Publicité

Méthodes agiles: Scrum et XP

  1. 1. Méthodes Agiles SCRUM et eXtrem Programming (XP) Youness BOUKOUCHI Enseignant-chercheur y.boukouchi@gmail.com Version1.1(2017)
  2. 2. Introduction Méthodologie agile eXtreme Programming SCRUM Outils de l’agilité 2
  3. 3. Introduction aux méthodes agile 3
  4. 4. Cycle de vie traditionnel Conception Réalisation Recette Nouvelles applications Applications améliorées Applications corrigées Applications retirées Demandes de Nouvelles applis Demandes D’amélioration Problèmes Défauts StratégiqueTactique Les utilisateurs sont sollicités dans un délai court pour valider l’intégralité du dossier de conception Il faut concevoir tout le produit et répondre à toutes les questions dès le début Introductionàl’agilité 4
  5. 5. Conception Réalisation Recette Nouvelles applications Applications améliorées Applications corrigées Applications retirées Demandes de Nouvelles applis Demandes D’amélioration Problèmes Défauts StratégiqueTactique Les utilisateurs sont sollicités dans des démonstrations trop longues leur montrant de nombreuses fonctionnalités Toutes les fonctionnalités sont intégralement développées sans arbitrages sur le R.O.I. Les travaux sont fortement parallélisés et sont souvent bloqués par des questions fonctionnelles Introductionàl’agilité Cycle de vie traditionnel 5
  6. 6. Conception Réalisation Recette Nouvelles applications Applications améliorées Applications corrigées Applications retirées Demandes de Nouvelles applis Demandes D’amélioration Problèmes Défauts StratégiqueTactique Les utilisateurs sont fortement sollicités sur une période très courte Certains points soulevés en recette peuvent remettre en cause profondément d’autres fonctionnalités Introductionàl’agilité Cycle de vie traditionnel 6
  7. 7. Une réalité constatée… Budget Dépassé Planning non-respecté Qualité insuffisante Non conforme au Business Introductionàl’agilité 7
  8. 8. Cycle de vie classique Nouvelles applications Applications améliorées Applications corrigées Applications retirées Demandes de Nouvelles applis Demandes D’amélioration Problèmes Défauts StratégiqueTactique Analyse des Exigences Système Analyse des Exigences Conception Générale Conception Détaillée Code et tests unitaires Intégration et tests d’intégration Installation et Déploiement Exploitation et Maintenace • Pilotée par la documentation (la plus détaillée possible) • Tâches enchaînées par des équipes cloisonnées • Résistances aux évolutions des exigences • Plus les modifications sont tardives = Plus le coût est élevé Introductionàl’agilité 8
  9. 9. Les principaux inconvénients de la méthode classique sont :  Il est très difficile de faire une conception exhaustive au démarrage du projet.  Les erreurs de conception ou de programmation ou variation du besoin sont détectées au dernier moment ce qui aggrave leurs conséquences.  Il n’est pas efficace de solliciter les utilisateurs de manière intense sur des périodes courtes.  L’application opérationnelle n’est disponible qu’à la fin du projet.  Il est difficile de communiquer directement avec les utilisateurs La méthode classique Introductionàl’agilité
  10. 10. Cycle de vie Agile Nouvelles applications Applications améliorées Applications corrigées Applications retirées Demandes de Nouvelles applis Demandes D’amélioration Problèmes Défauts StratégiqueTactique Planifier, Faire, Vérifier, Adapter Equipes Multi-compétentes qui intègrent le client, le développement, les tests et les autres profils nécessaires Livraison Incrémentale de fonctionnalités et d’une qualité de production à des intervalles réguliers Développements dirigés par les tests (TDD) pour mettre la qualité au premier rang des préoccupations
  11. 11. Expression des besoins Conception Développement Tests, recette & debugage Expression des besoins Conception Développement Tests, recette & debugage i 1 i 2 i 3 i n Les solutions AgilesLes solutions classiques Les équipes agiles font un peu de tout, tout le temps Introductionàl’agilité
  12. 12. Méthodologie agile 12
  13. 13. Rappel sur les méthodes agiles • 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 • Les Concepts de l’agilité sont formalisés en février 2001, aux États-Unis, par le Manifeste Agile (http://agilemanifesto.org). – dix-sept spécialistes du développement logiciel se sont réunis pour débattre du thème unificateur de leurs méthodes respectives, dites méthodes agiles. MéthodologieAgile 13
  14. 14. Manifeste pour le développement Agile Nous 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 : 1. Les individus et leurs interactions plus que les processus et les outils 2. Des logiciels opérationnels plus qu’une documentation exhaustive 3. La collaboration avec les clients plus que la négociation contractuelle 4. L’adaptation au changement plus que le suivi d’un plan Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers. Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas MéthodologieAgile 14
  15. 15. 1 - Priorité aux personnes et aux interactions sur les procédures et les outils (Individuals and interactions over processes and tools ) • La meilleure garantie de succès réside dans les personnes • Les interactions, les initiatives et la communication interpersonnelles qui feront le succès d’un projet. 2 - Priorité aux applications fonctionnelles sur une documentation pléthorique (Working software over comprehensive documentation) • la documentation est extrêmement consommateur de ressources. • La documentations succincte (les grandes lignes) régulièrement tenue à jour • Le meilleur transfert des connaissances s’effectue par la participation au travail de l’équipe. MéthodologieAgile Manifeste pour le développement Agile 15
  16. 16. 3 - La collaboration avec les clients plus que la négociation contractuelle (Customer collaboration over contract negotiation) • Le succès d’un projet requiert un feedback régulier et fréquent de la part du client. • Un contrat qui spécifie les exigences, le planning et le coût d’un projet a priori relève d’une vision utopique d’un projet informatique. 4 – L’adaptation au changement plus que le suivi d’un plan (Responding to change over following a plan) • La capacité à accepter le changement qui fait bien souvent la réussite ou l’échec d’un projet. • Lors de la planification, il est donc nécessaire de veiller à ce que le planning soit flexible et adaptable aux changements qui peuvent intervenir dans le contexte, les technologies et les spécifications. Manifeste pour le développement Agile MéthodologieAgile 16
  17. 17. L'équipe (« Personnes et interaction plutôt que processus et outils ») L'application (« Logiciel fonctionnel plutôt que documentation complète ») La collaboration (« Avec le client plutôt que négociation de contrat ») L'acceptation du changement (« Réagir au changement plutôt que suivre un plan ») Manifeste pour le développement Agile MéthodologieAgile 17
  18. 18. Les 12 principes (manifeste agile) Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client. Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts. Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet. MéthodologieAgile 18
  19. 19. Les 12 principes (manifeste agile) Réalisez les projets avec des personnes motivées. Fournissez- leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés. La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face. Un logiciel opérationnel est la principale mesure d’avancement. Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant. MéthodologieAgile 19
  20. 20. Les 12 principes (manifeste agile) Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité. La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle. Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées. À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence. MéthodologieAgile 20
  21. 21. Agile regroupe plusieurs méthodologies : – Extreme Programming (XP) – DSDM – Crystal – Scrum – FDD – … les méthodes Agile MéthodologieAgile 21
  22. 22. Méthode eXtreme Programming 22
  23. 23. MéthodeeXtremeProgramming • C’est une méthode plus récente basée sur le rassemblement de bonnes pratiques déjà connues et utilisées • C’est une méthodologie de développement basée sur les valeurs, les principes et les pratiques de l’agilité – Petites livraisons : entre 1 et 2 mois – Itérations : entre 2 à 3 semaines 23
  24. 24. Éléments fondamentaux d’XP 5 valeurs  Communication  Simplicité  Feedback  Courage  Respect MéthodeeXtremeProgramming 24
  25. 25. Les 5 valeurs d'XP Communication • la communication entre tous les intervenants : – entre développeurs (programmation en binôme), entre développeurs et managers (tests, estimations), entre développeurs et clients (tests, spécifications). • La communication permettre à chacun de se poser les bonnes questions et de partager l'information. Simplicité • XP encourage l'orientation vers la solution la plus simple qui puisse satisfaire les besoins du client. Feedback • un feedback permet de repérer et de corriger les erreurs plus facilement et d’accueillir les changements. – Des tests unitaires, fonctionnels – Du client: Revue avec le client toutes les deux à trois semaines – De l’équipe: Grace à la communication continuelle MéthodeeXtremeProgramming 25
  26. 26. Les 5 valeurs d'XP Courage • Le courage permet de sortir d'une situation inadaptée. • Certains changements demandent beaucoup de courage: – changer l'architecture d'un projet, – jeter du code pour en produire un meilleur – essayer une nouvelle technique. Respect • le respect pour les autres, ainsi que le respect de soi. • Les membres respectent leur propre travail en cherchant toujours la qualité et la meilleure conception pour la solution. – ne jamais valider les modifications qui cassent la compilation, – Ne jamais échouer les tests unitaires existants – Ne jamais retarder le travail de pairs. MéthodeeXtremeProgramming 26
  27. 27. Les 12 pratiques XP 1 - Planning game • Exprimer les besoins de client sous forme de "user stories" • Attribuer à chaque user story un nombre de points (Temps, priorité, effort) • Planifier les releases avec la participation des développeurs et le client. 2 - Petites releases • Pour une bonne gestion des risques, la sortie des releases doit intervenir le plus souvent possible. 3 - Utilisation de métaphores • Utiliser des métaphores pour décrire l'architecture du système. • Avoir une vision globale du système(comprendre ses éléments ainsi que leurs interactions). MéthodeeXtremeProgramming 27
  28. 28. Les 12 pratiques XP 4 - Conception simple •Développer la solution la plus simple possible et éviter de développer plus que ce dont on a besoin. C’est pas d’utiliser le moins possible de classes et de méthodes. •Produire la documentation seulement demandée par le client. 5 - Tests (unitaires et fonctionnels) •Les tests unitaires sont écrits et effectués pour vérifier le bon fonctionnement des méthodes ou des constructeurs. •Il est recommandé d'écrire les tests avant le code de l'application. •Les tests fonctionnels sont conçus par le client pour vérifier le fonctionnement global du système, de contrôler l'évolution du projet, et d' d'affiner l'expression de ses besoins. 6 - Refactoring du code •Simplifier, structurer le code, tout en faisant en sorte que tous les tests soient satisfaits. •le refactoring du code assure l’évolution et la maintenance de système. MéthodeeXtremeProgramming 28
  29. 29. Les 12 pratiques XP 7 - Programmation en binôme •Toute l'écriture du code se fait à deux personnes sur une même machine, •On distingue deux rôles : le pilote("driver") programme et le "partner" observe et suggère des solutions •Les binômes ne doivent pas être statiques : chacun change de partenaire relativement pour un meilleur partage des connaissances 8 - Appropriation collective du code •Toute l'équipe est sensée connaître la totalité du code (plus ou moins dans le détail selon les parties). •Tout le monde peut intervenir pour faire des ajouts ou des modifications sur une portion de code. 9 - Intégration continue •le code nouvellement écrit doit être intégré à l'existant de manière à avoir à tout moment un existant fonctionnel qui passe avec succès tous les tests. MéthodeeXtremeProgramming 29
  30. 30. Les 12 pratiques XP 10 - Pas de surcharge de travail • une équipe ne doit jamais être surchargée de travail plus de deux semaines consécutives. • Respecter la vélocité de l’équipe 11 - Client sur site • la présence sur site d'une personne minimum à temps plein pendant toute la durée du projet. • Cette personne doit avoir une vision plus globale du contexte pour pouvoir préciser les besoins, l’ordre de priorité de user stories, établir les tests fonctionnels, etc. 12 - Standards de code • Disposer de normes de nommage et de programmation (les bonnes pratiques). MéthodeeXtremeProgramming 30
  31. 31. Cycle de vie d’un projet XP Exploration • Au cours de cette phase, les développeurs se penchent sur des questions d'ordre technique destinées à explorer les différentes possibilités d'architecture pour le système. • Le client s'habitue à exprimer ses besoins sous forme de user stories que les développeurs devront estimer en terme de temps de développement. MéthodeeXtremeProgramming 31
  32. 32. Cycle de vie d’un projet XP Planning • Le planning de la première release (uniquement des fonctionnalités essentielles), à enrichir par la suite. • Le planning game dure un ou deux jours et la première release est en général programmée pour deux à six mois plus tard. MéthodeeXtremeProgramming 32
  33. 33. Cycle de vie d’un projet XP Itérations jusqu'à la première release • C'est la phase de développement sous forme d'itérations de une à quatre semaines. • Chaque itération produit un ensemble de fonctionnalités passant avec succès les tests fonctionnels associés. • La première itération est dédiée à la mise en place de l'architecture du système. • des brèves réunions réunissent toute l'équipe quotidiennement pour mettre chacun au courant de l'avancement du projet. MéthodeeXtremeProgramming 33
  34. 34. Cycle de vie d’un projet XP Mise en production • Des itérations plus courtes pour renforcer le feedback. • Au cours de cette phase, les développeurs procèdent à des réglages affinés pour améliorer les performances. • A la fin de cette phase, un produit réalisé avec toutes les fonctionnalités indispensables et parfaitement fonctionnelles. MéthodeeXtremeProgramming 34
  35. 35. Cycle de vie d’un projet XP Maintenance • continuer à faire fonctionner le système • adjoindre des fonctionnalités secondaires. • L'ajout de fonctionnalités secondaires donne lieu à des nouvelles releases, une nouvelle phase d'exploration rapide doit avoir lieu. MéthodeeXtremeProgramming 35
  36. 36. Cycle de vie d’un projet XP Mort • La fin d'un projet intervient quand le client n'arrive plus à écrire de user stories supplémentaires. MéthodeeXtremeProgramming 36
  37. 37. Rôles Développeur – Conception et programmation – Participe aux séances de planification, évalue les tâches et leur difficulté – Définition des test unitaires – Implémentation des fonctionnalités et des tests unitaire Client – Écrit, explique et maîtrise les scénarios – Spécifie les tests fonctionnels de recette – Définit les priorités Testeur – Écriture des tests de recette automatiques pour valider les scénarios clients – Peut influer sur les choix du clients en fonction de la testabilité des scénarios MéthodeeXtremeProgramming 37
  38. 38. Rôles Tracker – Suivre le planning pour chaque itération. – Interagir avec les développeurs pour le respect du planning de l'itération courante – Détection des éventuels retards et rectifications si besoin Manager – Responsable du projet – Apporte à l'équipe le courage et la confiance – Vérification de la satisfaction du client – Contrôle le planning Coach – Organise et anime les séances de planifications – Favorise la créativité du groupe, n'impose pas ses solutions technique – Au fur et à mesure de la maturation de l'équipe, sont rôle diminue et l'équipe devient plus autonome. MéthodeeXtremeProgramming 38
  39. 39. Utiliser XP quand…  Besoins flous  Périmètre mal défini  Petite équipe – 12 personnes maximum  Site unique  Pas de sous-traitance Ne pas utiliser XP si…  Besoins changeront peu  Périmètre bien défini  Équipe de plus de 12 personnes  Développement multi-sites  Développement offshore  Projets critiques MéthodeeXtremeProgramming 39
  40. 40. Méthode SCRUM 40
  41. 41. Principes clés • Scrum est une méthode agile qui permet de produire la plus grande valeur métier dans la durée la plus courte. • Méthode itérative et incrémentale: – Réalisation d’un ensemble de fonctionnalités par itération – Itération d’une durée fixe (de 2 à 4 semaines) => Sprint – Livraison d’un produit partiel fonctionnel par itération • Participation du client – Définition des fonctionnalités prioritaires – Ajout de fonctionnalités en cours de projet (pas pendant un sprint) MéthodeSCRUM 41
  42. 42. Les rôles  Le Product Owner : Il représente les utilisateurs, définit et priorise les demandes produit. Il est intégré à l’équipe et doit savoir être disponible.  Le Scrum Master : Ce n’est pas le chef de projet. Il a un rôle de facilitateur. Sa mission est de tout mettre en œuvre pour que l'équipe travaille dans de bonnes conditions et se concentre sur l'objectif du projet.  L’équipe SCRUM : Une équipe regroupant tous les rôles traditionnels : architecte, développeur, testeur, administrateur, etc. Cette équipe développe le produit et se gère en toute autonomie.  Coach agile : Il intervient de manière ponctuelle pour aider à mettre en place les outils Agile dans un domaine méthodologique MéthodeSCRUM
  43. 43. MéthodeSCRUM Les rôles 43
  44. 44. Le processus Scrum 1. Backlog produit (ou catalogue des besoins)  Besoins priorisés par le product owner  Besoins évalués par l’équipe MéthodeSCRUM De 2 à 4 semaines 44
  45. 45. Le processus Scrum 2. Backlog de sprint  Extrait du backlog produit  Besoins éclatés en tâches MéthodeSCRUM De 2 à 4 semaines 45
  46. 46. Le processus Scrum 3. Sprint  Développement des fonctionnalités du backlog de sprint  Aucune modification du backlog de sprint possible MéthodeSCRUM De 2 à 4 semaines 46
  47. 47. Le processus Scrum 4. Mêlée quotidienne  Point de contrôle quotidien de l’équipe  Interventions régulées – 2 min. par personne MéthodeSCRUM De 2 à 4 semaines 47
  48. 48. Le processus Scrum 5. Incrément logiciel : livré au Product owner à la fin du sprint. MéthodeSCRUM De 2 à 4 semaines 48
  49. 49. Outils de l’agilité 49
  50. 50. Outils de l’agilité • Le tableau des tâches (Le Sprint Board) Outilsdel’agilité 50
  51. 51. Le Burndown Chart Le Burndown chart permet de matérialiser l’avancement global du projet. Les courbes représentent la taille total du backlog ainsi que le nombre d’user stories restant à réaliser (en points de complexité). Outils de l’agilité Outilsdel’agilité
  52. 52. La vélocité La vélocité est le nombre de points recettes pour chaque itération. Cet indicateur permet d’avoir une bonne vision de la productivité globale de l’équipe projet. Outils de l’agilité Outilsdel’agilité
  53. 53.  Gestion d’une liste de tâche: AgileFant, IceScrum, etc. Outils de l’agilité Outilsdel’agilité 53
  54. 54. Conclusions 54
  55. 55. SCRUM : Gestion de projet : définition de rôles, itérations courtes de durées fixes, participation active du client, collaboration, communication, feedback, flexibilité aux changements, amélioration continue … XP (eXtreme Programming) : Gestion du développement logiciel : forte réactivité, travail d’équipe, qualité du code , développement dirigé par les tests (TDD), intégration continue, simplicité… Conclusions
  56. 56. Conclusions 56
  57. 57. Merci de votre attention 57

×