Télécharger en tant que PDF, PPTX
Téléchargé parYouness Boukouchi
Méthodes agiles: Scrum et XP
Le document traite des méthodes agiles, en particulier Scrum et Extreme Programming (XP), mettant en avant leurs principes, pratiques et avantages par rapport aux méthodes classiques de développement. Il souligne l'importance de la collaboration, de la communication, de l'adaptabilité et de la livraison incrémentale pour répondre aux besoins des clients. Les rôles des membres de l'équipe et les cycles de vie des projets sont également abordés pour illustrer la mise en œuvre de ces méthodologies.
Méthodes agiles: Scrum et XP
- 1. Méthodes Agiles SCRUM eteXtrem Programming (XP) Youness BOUKOUCHI Enseignant-chercheur y.boukouchi@gmail.com Version1.1(2017)
- 2.
- 3. Introduction aux méthodesagile 3
- 4. Cycle de vietraditionnel 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. Conception Réalisation RecetteNouvelles 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. Conception Réalisation RecetteNouvelles 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. Une réalité constatée… BudgetDépassé Planning non-respecté Qualité insuffisante Non conforme au Business Introductionàl’agilité 7
- 8. Cycle de vieclassique 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. Les principaux inconvénientsde 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. Cycle de vieAgile 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. 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.
- 13. Rappel sur lesmé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. Manifeste pour ledé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. 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. 3 - Lacollaboration 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. L'équipe (« Personneset 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. 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. 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. 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. Agile regroupe plusieursméthodologies : – Extreme Programming (XP) – DSDM – Crystal – Scrum – FDD – … les méthodes Agile MéthodologieAgile 21
- 22.
- 23. MéthodeeXtremeProgramming • C’est unemé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. Éléments fondamentaux d’XP 5valeurs Communication Simplicité Feedback Courage Respect MéthodeeXtremeProgramming 24
- 25. Les 5 valeursd'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. Les 5 valeursd'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. Les 12 pratiquesXP 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. Les 12 pratiquesXP 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. Les 12 pratiquesXP 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. Les 12 pratiquesXP 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. Cycle de vied’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. Cycle de vied’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. Cycle de vied’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. Cycle de vied’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. Cycle de vied’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. Cycle de vied’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. Rôles Développeur – Conception etprogrammation – 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. Rôles Tracker – Suivre leplanning 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. 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.
- 41. Principes clés • Scrumest 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. Les rôles LeProduct 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.
- 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. 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. 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. 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. Le processus Scrum 5.Incrément logiciel : livré au Product owner à la fin du sprint. MéthodeSCRUM De 2 à 4 semaines 48
- 49.
- 50. Outils de l’agilité •Le tableau des tâches (Le Sprint Board) Outilsdel’agilité 50
- 51. Le Burndown Chart LeBurndown 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. 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. Gestion d’uneliste de tâche: AgileFant, IceScrum, etc. Outils de l’agilité Outilsdel’agilité 53
- 54.
- 55. SCRUM : Gestionde 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.
- 57. Merci de votreattention 57