Méthodes agiles

2,709 views

Published on

Une présentation sur les méthodes agiles

Published in: Business, Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,709
On SlideShare
0
From Embeds
0
Number of Embeds
201
Actions
Shares
0
Downloads
1
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

Méthodes agiles

  1. 1. Méthodes Agiles<br />Un parcours des méthodes agiles<br />1<br />
  2. 2. Introduction<br />2<br />Nos echecs<br />
  3. 3. Introduction<br />3<br />Taux de réussite des projets<br />
  4. 4. Introduction<br />4<br />Critères de réussite<br />
  5. 5. Introduction<br />5<br />Autres industries : Renault Zoé (2012)<br />
  6. 6. Introduction<br />6<br />Autres industries : Batman 3 (Juillet 2012)<br />
  7. 7. Introduction<br />7<br />Succès d’un projet<br />
  8. 8. Introduction<br />Et notre industrie ? Quelques désastres<br /><ul><li>Duke Nukem n’est jamais sorti 
  9. 9. Satellite perdu de la NASA : deux modules n’utilisaient pas les mêmes unités de mesure (125 M$)
  10. 10. Panama : 8 personnes atteintes du cancer sont mortes à cause d’une erreur de calcul du dosage des radiations</li></ul>8<br />
  11. 11. Introduction<br />9<br />
  12. 12. Introduction<br />10<br />Facteurs d’échec<br />
  13. 13. Introduction<br />11<br />Conduite classique d’un projet<br />
  14. 14. Introduction<br />12<br />Implications<br />
  15. 15. Principes Agiles<br />13<br />Principes agiles<br />
  16. 16. Principes agiles<br />Manifesto agile 2001<br /><ul><li>17 chefs de projets se sont réunis à l’Utah (USA)
  17. 17. Lassés par la lourdeurs des processus classiques
  18. 18. Ils ont formé l’alliance agile</li></ul>14<br />
  19. 19. Les principes agiles<br />15<br />
  20. 20. Les principes agiles<br />Individus et interactions au lieu de processus et outils<br /><ul><li>Les collaborateurs sont la clé du succès
  21. 21. Les « seniors » échoueront s’ils ne collaborent pas en tant qu’équipe
  22. 22. Un bon collaborateur n’est pas un forcément un bon programmeur. C’est quelqu’un qui travaille bien en équipe
  23. 23. Une surabondance d’outils est aussi mauvaise que le manque d’outils
  24. 24. Démarrer petit et investir peu au démarrage
  25. 25. Construire l’équipe c’est plus important que construire l’environnement</li></ul>16<br />
  26. 26. Les principes agiles<br />Logiciel fonctionnel au lieu de documentation massive<br /><ul><li>Un code sans documentation est un désastre
  27. 27. Trop de documents est pire que pas de documents
  28. 28. Difficulté à produire et à synchroniser avec le code
  29. 29. Souvent les documents sont des mensonges formels
  30. 30. Le code ne ment jamais sur lui-même
  31. 31. Produire toujours des documents aussi courts que possible</li></ul>17<br />
  32. 32. Les principes agiles<br />Collaboration du client au lieu de la négociation de contrats<br /><ul><li>Très difficile de décrire la totalité du logiciel depuis le début
  33. 33. Les projets réussis impliquent les clients d’une manière fréquente et régulière
  34. 34. Le client doit avoir un contact direct avec l’équipe de développement</li></ul>18<br />
  35. 35. Les principes agiles<br />Réagir aux changements au lieu de suivre un plan<br /><ul><li>Un logiciel ne peut pas être planifié très loin dans le futur
  36. 36. Tout change : technologie, environnement et surtout les besoins
  37. 37. Les chefs de projets classiques fonctionnent sur la base de GANTT, PERT et le système de tâches
  38. 38. Avec le temps, les diagrammes se dégradent car des tâches s’ajoutent et d’autres deviennent non nécessaires
  39. 39. Une meilleure stratégie est de planifier très court (02 semaines à 01 mois)
  40. 40. Plannings détaillés pour la semaine à venir, rigoureux pour les trois mois et très vagues au-delà</li></ul>19<br />
  41. 41. Les principes agiles<br />Les 12 principes agiles<br />Toujours satisfaire le client à travers des livraisons rapides et continues<br />Bien accueillir tous les changements même les tardifs<br />Livrer fréquemment un système fonctionnel<br />Les clients et les développeurs doivent collaborer<br />Conduire le projet autour d’équipes motivées<br />La meilleure méthode de faire circuler l’information c’est le contact direct entre collaborateurs<br />La première mesure d’avancement c’est un logiciel fonctionnel<br />Le développement doit être durable et à un rythme constant<br />La bonne conception et l’excellence technique augmentent l’agilité<br />Simplifier au maximum<br />Les meilleurs architectures, besoins et conceptions proviennent d’équipes qui s’organisent d’elles-mêmes<br />L’équipe s’améliore d’une manière autonome et régulière<br />20<br />
  42. 42. Méthodologie XP<br />21<br />Méthodologie xp<br />
  43. 43. La méthodologie XP<br />22<br />
  44. 44. Planification Agile<br />23<br />Planification agile<br />
  45. 45. Planification Agile<br />Planification<br /><ul><li>Les développeurs et le client discutent du système (identifier les fonctions)
  46. 46. Ne pas chercher à avoir une liste exhaustive des fonctions
  47. 47. Chaque fonction est traduite en user stories
  48. 48. Les user stories sont écrites sur des cartes (ou équivalent)
  49. 49. Les développeurs collaborent à estimer les user stories
  50. 50. L’estimation ne se fait pas en temps mais en points
  51. 51. Une user stories de 8 points durera logiquement deux fois plus qu’une user stories de 1 point
  52. 52. Les user stories trop longues sont réparties en plusieurs user stories
  53. 53. Une user story trop petite est fusionnée avec une autre
  54. 54. La fusion et la division n’est pas une science exacte en terme de points</li></ul>24<br />
  55. 55. Planification Agile<br />Planification<br /><ul><li>Chaque itération un ensemble de user stories sont terminées
  56. 56. La vélocité est le nombre de points finalisés durant la semaine ou l’itération
  57. 57. Après 03 ou 04 semaines, l’équipe a une idée de sa vélocité
  58. 58. Au début, la vélocité est très imprécise puis se stabilise dans le temps
  59. 59. Après la stabilisation de la vélocité, on peut déduire la durée d’un release en terme d’itérations
  60. 60. Une user story n’est finalisée que si elle passe tous ses tests d’acceptation</li></ul>25<br />
  61. 61. Planification Agile<br />Planification<br /><ul><li>Les développeurs divisent les user stories en tâches
  62. 62. Les tâches sont créées et enregistrée
  63. 63. Chaque développeur s’inscrit à une ou plusieurs tâches durant l’itération
  64. 64. Chaque développeur connaît le nombre de points de son itération précédente
  65. 65. Il prend des tâches jusqu’à atteindre ce nombre de points
  66. 66. Si des tâches restent, les développeurs négocient pour prendre le reste</li></ul>26<br />
  67. 67. Planification Agile<br />Planification<br /><ul><li>Au milieu d’une itération, une réunion entre développeurs est organisée
  68. 68. Théoriquement, la moitié des user stories devraient êtres terminées
  69. 69. Dans le cas contraire, l’équipe se réorganise pour assurer une bonne terminaison de l’itération</li></ul>27<br />
  70. 70. Planification Agile<br />Planification<br /><ul><li>A chaque fin d’itération le produit est montré et évalué par le client
  71. 71. Le client suit de près l’évolution du produit</li></ul>28<br />
  72. 72. Planification Agile<br />Planification<br /><ul><li>Le suivi par des outils informatiques
  73. 73. Project ou Excel sont des exemples d’outils de suivi
  74. 74. TFS est un excellent support de suivi </li></ul>29<br />
  75. 75. Introduction<br />30<br />
  76. 76. Planification Agile<br />31<br />Conception agile<br />
  77. 77. Conception agile<br />Qu’est-ce que la conception agile ?<br /><ul><li>L’analyse concerne le « quoi », la conception concerne le « comment »
  78. 78. Les diagrammes UML n’est pas la conception mais une partie de la conception
  79. 79. La conception est un concept abstrait
  80. 80. Le code EST la conception
  81. 81. La conception agile est l’application continue des principes agiles</li></ul>32<br />
  82. 82. Conception agile<br />Pourquoi une bonne conception<br /><ul><li>Livrer plus rapidement
  83. 83. Etre prêt au changement
  84. 84. Gérer la complexité</li></ul>33<br />
  85. 85. Introduction<br />34<br />
  86. 86. Conception agile<br />Symptômes d’une mauvaise conception<br />35<br />
  87. 87. Conception agile<br />Rigidité<br /><ul><li>Difficile à faire évoluer même avec de petits changements
  88. 88. Difficile de se retrouver dans une structure complexe
  89. 89. Difficile voire impossible d’estimer les changements
  90. 90. L’impact du changement est imprévisible</li></ul>36<br />
  91. 91. Conception agile<br />Fragilité<br /><ul><li>Plusieurs modules tombent alors qu’un seul a été modifié
  92. 92. Régler un problème engendre la création d’autres problèmes</li></ul>37<br />
  93. 93. Conception agile<br />Immobilité<br /><ul><li>Une conception est immobile si elle contient des parties réutilisables mais l’isolement de ces parties est à la fois difficile et risqué</li></ul>38<br />
  94. 94. Conception agile<br />Viscosité<br /><ul><li>Viscosité du logiciel :lorsque les changements impliquant le changement de la conception sont plus facile à faire que ceux qui ne l’impliquent pas
  95. 95. Viscosité de l’environnement : compilation lente, check-in fastidieux,….</li></ul>39<br />
  96. 96. Conception agile<br />Complexité inutile<br /><ul><li>Souvent causée par l’anticipation
  97. 97. L’anticipation conduit souvent à l’effet inverse</li></ul>40<br />
  98. 98. Conception agile<br />Répétition inutile<br /><ul><li>Abuser du copier-coller
  99. 99. Même code mais sous différentes formes</li></ul>41<br />
  100. 100. Conception agile<br />Opacité<br /><ul><li>Code et structure difficile à comprendre
  101. 101. Les développeurs doivent se mettre à la place des lecteurs</li></ul>42<br />
  102. 102. Conception agile<br />Causes d’une mauvaise conception<br /><ul><li>Dépendance incorrecte entre les modules
  103. 103. Manque de vision</li></ul>43<br />
  104. 104. Conception agile<br />Causes d’une bonne conception<br /><ul><li>Haute cohésion
  105. 105. Couplage moindre</li></ul>44<br />
  106. 106. Conception agile<br />Principes de conception agile<br />45<br />
  107. 107. SRP<br />Single-ResponsibilityPrinciple<br /><ul><li>Cohésion des fonctions
  108. 108. Chaque responsabilité est un axe de changement</li></ul>46<br />
  109. 109. SRP<br />Exemple de violation de SRP<br />47<br />
  110. 110. SRP<br />Amélioration pour prendre en considération le SRP<br />48<br />
  111. 111. SRP<br />Exemple de violation de SRP<br />49<br />
  112. 112. SRP<br />Amélioration SRP<br />50<br />
  113. 113. SRP<br />Single-ResponsibilityPrinciple<br /><ul><li>Il faut apprendre à faire la balance entre SRP et la complexité du système
  114. 114. Ajouter la persistance dans les entités métier est une violation du SRP</li></ul>51<br />
  115. 115. OCP<br />Open – ClosedPrinciple<br /><ul><li>Les entités logicielles doivent être fermées à la modification, ouvertes à l’extension
  116. 116. Un changement sur un système mal conçu conduit à une cascade d’effets sur des modules dépendants</li></ul>52<br />
  117. 117. OCP<br />Open – ClosedPrinciple<br /><ul><li>Comment fermer la modification et ouvrir l’extension  abstraction
  118. 118. Abstraction  classes abstraites et / ou interfaces</li></ul>53<br />
  119. 119. OCP<br />Exemple<br />54<br />
  120. 120. OCP<br />Exemple<br />55<br />
  121. 121. OCP<br />Exemple<br />56<br />
  122. 122. LCP<br />LCP – The Liskov Substitution Principle<br /><ul><li>L’héritage est une solution à OCP mais comment réguler l’héritage ?
  123. 123. Principe : Les sous-types doivent être des substituts pour leur ancêtres</li></ul>57<br />
  124. 124. LCP<br />Exemple<br />58<br />
  125. 125. LCP<br />Exemple – Problème LCP<br />59<br />
  126. 126. LCP<br />LCP – Remèdes<br /><ul><li>Eviter une vision isolatrice des entités
  127. 127. Avoir une vision plus globale et plus anticipative</li></ul>60<br />
  128. 128. DIP<br />Dependency Inversion Principle<br /><ul><li>Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau
  129. 129. Les abstractions ne doivent pas dépendre des détails, Les détails doivent dépendre des abstractions</li></ul>61<br />
  130. 130. DIP<br />DIP - Exemple<br />62<br />
  131. 131. Conception Agile<br />63<br />
  132. 132. ISP<br />Interface SegregationPrinciple<br /><ul><li>Les clients ne doivent pas être forcées à dépendre de méthodes qu’elles n’utilisent pas</li></ul>64<br />
  133. 133. ISP<br />ISP- Exemple<br />65<br />
  134. 134. ISP<br />ISP- Exemple<br />66<br />
  135. 135. Refactoring<br />67<br />refactoring<br />
  136. 136. Refactoring<br />Refactoring<br />Le refactoring est le processus d’améliorer la structure interne du code sans en altérer le fonctionnement<br />68<br />
  137. 137. Refactoring<br />Refactoring<br />Un module de code a les fonctions suivantes :<br /><ul><li>Assurer la fonction pour laquelle il a été créé
  138. 138. Permettre l’évolution
  139. 139. Communiquer avec ses lecteurs / utilisateurs</li></ul>69<br />
  140. 140. Refactoring<br />Refactoring avec VS2010<br />70<br />
  141. 141. Refactoring<br />71<br />
  142. 142. TDD<br />72<br />Test-drivendevelopment<br />
  143. 143. TDD<br />Qu’est-ce que le TDD<br />Conduire tous nos développements par les tests. Le test doit être le vecteur de la conception.<br />TDD fait partie des meilleures pratiques agiles car la qualité d’une itération sous-entend le passage de tous les tests unitaires et les tests d’acceptation<br />73<br />
  144. 144. TDD<br />Etapes du TDD<br />74<br />
  145. 145. TDD<br />Intérêts<br /><ul><li>Ecrire le test avant le programme permet une meilleure visibilité sur le résultat
  146. 146. Anticipe la conception
  147. 147. Augmente la confiance en soi
  148. 148. Estimer l’état d’avancement</li></ul>75<br />
  149. 149. TDD<br />76<br />
  150. 150. TDD<br />Problème avec les grands systèmes<br /><ul><li>Des modules peuvent dépendre d’autres systèmes non encore implémentés
  151. 151. Solution Mock</li></ul>77<br />
  152. 152. TDD<br />MockObjects<br /><ul><li>Les objets mock miment le comportement de vrais objets
  153. 153. Exemple : tests de crash de voitiure (faux conducteur)</li></ul>78<br />
  154. 154. TDD<br />MockObjects - Utilisation<br />Les mocks sont utilisés dans les cas suivants :<br /><ul><li>Les objets renvoient des résultats non déterministes
  155. 155. Des états difficiles à reproduire (par exemple panne réseau)
  156. 156. Des objets pour des tests uniquement
  157. 157. Des objets qui n’existent pas encore ou qui doivent évoluer</li></ul>79<br />
  158. 158. TDD<br />80<br />

×