Successfully reported this slideshow.

Agile Methodologies

623 vues

Publié le

Presentation in French of Agile methodologies: SCRUM and eXtreme Programming

Publié dans : Business
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Agile Methodologies

  1. 1. Introduction à eXtreme Programming et Scrum
  2. 2. eXtreme Programming ● Méthode Agile de gestion de projet ● Utilisé la première fois en 1996 ● Publié pour la première fois en 1999 par Kent Beck
  3. 3. Histoire des méthodes de développement de projet
  4. 4. Le manifeste des méthodes Agile We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: ● Individuals and interactions over processes and tools ● Working software over comprehensive documentation ● Customer collaboration over contract negotiation ● Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more
  5. 5. eXtreme Programming : la théorie L'Équipe Planification Petite Livraison Retour Client Norme de code Rythme endurant Vision Simple Intégration en continue Code appartient à l'équipe TDD Programmation par paire Factorisation Design Simple
  6. 6. eXtreme Programming : Diagramme général
  7. 7. eXtreme Programming : la théorie Les 12 points (1) ● L'Équipe ● Planification ● Scénario utilisateur et jeu de test ● Petite livraison régulière ● Design Simple ● Programmation par paire
  8. 8. eXtreme Programming : la théorie Les 12 points (2) ● Développement piloté par les tests (TDD) ● Factorisation ● Intégration en continue ● Code appartient au groupe ● Norme de Code ● Vision commune et Rythme endurant
  9. 9. eXtreme Programming : la théorie l'Équipe ● Se rassemble autour du Client ● Rassemble des développeurs généraux ayant des compétences spécifiques ● Tous ont un ou plusieurs rôles dans l'équipe avec des fonctions précises ● Environnement de travail favorisant la communication
  10. 10. eXtreme Programming : la théorie Les rôles (1) ● Client – Définit les scénarios et les tests fonctionnels ● Développeur – Estime les scénarios – Produit le code et les tests unitaires – Définit les tâches
  11. 11. eXtreme Programming : la théorie Les rôles (2) ● Coach – Regarde tout – Envoi des signaux obscures à l'équipe – Pilote chaque membre – Remet sur les rails du projet ceux qui s'en éloigne (cas extrême se sépare d'elle) – Gère les problèmes d'ego ● Testeur – Implémente et exécute les tests fonctionnels – Dans certains cas aide le Client à définir les tests
  12. 12. eXtreme Programming : la théorie Les rôles (3) ● Messager de l'Apocalypse – Faire en sorte que tout le monde comprenne les risques – Faire en sorte que les mauvaises nouvelles ne soient pas masquées ou écartées – Faire en sorte que les mauvaises nouvelles ne prennent pas trop de proportions ● Manager – Organise les réunions – S'assure du bon déroulement de celles-ci – Renvoie les comptes rendus – Ne dicte pas : ● Ce qu'il faut faire (Client) ● Quand il faut le faire (planning des itérations)
  13. 13. eXtreme Programming : la théorie Planification Réponds à deux questions clefs : – Quelles fonctionnalités seront présentes à la livraison ? – Que fait-on ensuite ? Dirige le projet au lieu d'avoir une prédiction exacte de ce qu'il faut et du temps.
  14. 14. eXtreme Programming : la théorie Planification 2 types de plannings distincts : – Planning de Livraison Jeu de fonctionnalités totales présentes à la fin du projet – Planning des itérations Jeu de fonctionnalités présentes à la fin de l'itération
  15. 15. eXtreme Programming : la théorie Planning Game Pièces : les scénarios utilisateurs sous forme de cartes à jouer But : Mettre le maximum de valeur dans le produit sur la durée du jeu Joueurs : les membres de l'équipe Business (Client, Manager) face aux Développeurs Coups : ● Écrire Histoire (Business) ● Estimer Histoire (Développeurs) ● Introduire Histoire (Business) ● S'engager - Création de la liste d'Histoire - Ordonnancement ● Revenir sur un engagement ● Changer Valeur (Business) ● Pic (Business) ● Ré-estimation (Développeurs)
  16. 16. eXtreme Programming : la théorie Programmation par paire ● Deux personnes par station de travail ● Les paires ne sont pas statiques ● Dans une paire les deux personnes sont actifs ● Difficile à mettre en place ● Le temps de développement augmente de 15 % environ ● Peux générer des problèmes d'ego ● Il ne faut pas tomber dans des relations maître / étudiant ● La qualité du code augmente ● Les connaissances sur les points sont mieux réparties ● Le code est revue par l'ensemble de l'équipe Problèmes Avantages
  17. 17. eXtreme Programming : la théorie Développement pilotés par les tests 1.Pensez à ce que vous devez faire 2.Pensez comment vous allez le tester 3.Écrire un petit test, pensez aux API requises 4.Écrire un code qui ne passera pas le test 5.Voir le test raté 6.Écrire un code qui passe le test 7.Voir le test réussir 8.Logique doublée ? Code incompréhensible → factorisation 9.Relancer tout les tests Pour chaque nouveau test imaginé. Reprendre le cycle complet
  18. 18. eXtreme Programming : la théorie Scénario Utilisateur ● Écrit par le Client ● Décrive le comportement de l'application ● Permet une évaluation raisonnable du temps de développement ● Servent à établir le Planning de Livraison ● Servent de base pour les scénarios de tests
  19. 19. eXtreme Programming : la théorie Petite Livraison ● Après chaque itération ● Montre l'évolution au Client ● Permet le test par le Client Final ● Assure des remontées rapides.
  20. 20. eXtreme Programming : la théorie Design Simple ● Définition de Simple Pas ou peu de temps à développer ● Mesure de la simplicité ? – TUBE (Testable – Understandable – Browsable – Explainable) – Beck
  21. 21. eXtreme Programming : la théorie Factorisation ● Faire évoluer le design ● Supprimer les doublons ● Augmenter la cohérence ● Réduire les liens forts ● Retester l'ensemble
  22. 22. eXtreme Programming : la théorie Intégration en continue ● Intégrer les différents modules ● Reconstruire le projet Quotidiennement ➔Évite les problèmes d'intégration en fin de projet ➔Évite les gels du code trop long }
  23. 23. eXtreme Programming : la théorie Code appartient au groupe ● Évite un mauvais placement des fonctionnalités ● Toute l'équipe de développement participe aux composants (via la Programmation par Paire) ● Code constamment relu et améliorer ● Un bon code est un code où aucun développeur peut dire « c'est moi qui est fait cette fonctionnalité »
  24. 24. eXtreme Programming : la théorie Norme de code ● Impose des règles d'écriture stricte de code à l'équipe ➔Baisse du sentiment d'appropriation du code ➔Augmente la cohérence du code ➔Augmente la qualité de celui-ci ➔Facile la compréhension de celui-ci
  25. 25. eXtreme Programming : la théorie Vision simple et Rythme endurant ● Utilisation du même vocabulaire entre les membres de l'équipe ➔ Meilleur communication interne Toute l'équipe œuvre pour la finalisation du projet. Ils ne sont pas là pour se tuer à la tâche. Source : Extreme Programming Explained – 2nd Edition
  26. 26. eXtreme Programming : Diagramme Projet
  27. 27. eXtreme Programming : Diagramme Itération
  28. 28. eXtreme Programming : Diagramme Développement
  29. 29. eXtreme Programming : Diagramme Code appartient au groupe
  30. 30. eXtreme Programming : cas pratique
  31. 31. Scrum ● Apparaît en 1995 ● Ensemble de règles de management ● Méthodologie itérative & incrémentale ● Ne couvre pas la partie technique d'ingénierie du logiciel
  32. 32. Scrum : Diagramme
  33. 33. Scrum ● 3 rôles principaux : – Propriétaire du Produit – Équipe de Développement – Scrum Master ● 4 étapes – Planification du Sprint – Mêlée quotidienne – Revue de Sprint – Rétrospective du Sprint
  34. 34. Scrum : Sprint ● Durée d'un mois maximum ● Cette durée reste constante tout au long du projet ● Possède un but et une liste de fonctionnalités ● Pendant un sprint – Le but est inaltérable – L'Équipe doit être constante – La qualité est non négociable – Les fonctionnalités sont sujettes à négociations
  35. 35. Scrum : Le Propriétaire du Produit – Responsable de la maximisation du ROI (Retour sur  Investissement) du développement – Responsable de Vision du produit – Priorise constamment les fonctionnalités du produit – Ajuste sur le long terme les attentes – Décisionnaire sur les pré requis – Accepte/Rejette les livraisons aux itérations – Décide de la livraison – Décide la continuité des développements
  36. 36. Scrum : L'équipe de développement – Transverse (testeurs, architecte, analyste,...) – Autogérer sans rôles extérieurs – Négocie les développements avec le Product  Owner, une itération à la fois – Autonome sur la réalisation – Collaborative – Équipe de 7 personnes environs
  37. 37. Scrum : Le Scrum Master – Facilite le processus – Aide à la résolution des obstacles – Créé un environnement aidant l'équipe à s'autogérer – Protège l'équipe des interférences extérieurs – Assure le respect des temps – Promeut et améliore des pratiques d'ingénierie – N'a aucune autorité sur l'équipe
  38. 38. Scrum : Planification du Sprint  ● Lieu au début de chaque nouveau sprint ● Entre le Propriétaire du Produit et l'équipe ● Définit le but du sprint ● Choisit les fonctionnalités à réaliser ● Découpe les fonctionnalités en tâches à  réaliser
  39. 39. Scrum : Mêlée Quotidienne Répondre à trois questions :  – Qu'ai je réalisé hier? – Que vais-je faire aujourd'hui? – Quel problème ai-je eu? ➔ Permet de déceler les nouvelles tâches à  réaliser pour finir le Sprint
  40. 40. Scrum : Revue de sprint ● Présentation de ce qui a été réalisé pendant le  sprint ● Validation par le Propriétaire du Produit ● Revue de la liste des fonctionnalités restantes
  41. 41. Scrum : Rétrospective du Sprint ● Analyse par l'équipe des problèmes  rencontrés ● Réflexion sur les solutions aux problèmes
  42. 42. Scrum :  cas pratique
  43. 43. Forces et Faiblesse des méthodes  Agiles ✔ Productivité ✔ Qualité ✔ Souplesse ✔ Environnement  ✗ Échelle des équipes ✗ Équipe expérimenté ✗ Non applicable à tout  les projets ✗ Coûts variables

×