Une présentation sur les méthodes agiles

1. Méthodes Agiles Un parcours des méthodes agiles 1

2. Introduction 2 Nos echecs

3. Introduction 3 Taux de réussite des projets

4. Introduction 4 Critères de réussite

5. Introduction 5 Autres industries : Renault Zoé (2012)

6. Introduction 6 Autres industries : Batman 3 (Juillet 2012)

7. Introduction 7 Succès d’un projet

9. Satellite perdu de la NASA : deux modules n’utilisaient pas les mêmes unités de mesure (125 M$)

10. Panama : 8 personnes atteintes du cancer sont mortes à cause d’une erreur de calcul du dosage des radiations8

11. Introduction 9

12. Introduction 10 Facteurs d’échec

13. Introduction 11 Conduite classique d’un projet

14. Introduction 12 Implications

15. Principes Agiles 13 Principes agiles

17. Lassés par la lourdeurs des processus classiques

18. Ils ont formé l’alliance agile14

19. Les principes agiles 15

21. Les « seniors » échoueront s’ils ne collaborent pas en tant qu’équipe

22. Un bon collaborateur n’est pas un forcément un bon programmeur. C’est quelqu’un qui travaille bien en équipe

23. Une surabondance d’outils est aussi mauvaise que le manque d’outils

24. Démarrer petit et investir peu au démarrage

25. Construire l’équipe c’est plus important que construire l’environnement16

27. Trop de documents est pire que pas de documents

28. Difficulté à produire et à synchroniser avec le code

29. Souvent les documents sont des mensonges formels

30. Le code ne ment jamais sur lui-même

31. Produire toujours des documents aussi courts que possible17

33. Les projets réussis impliquent les clients d’une manière fréquente et régulière

34. Le client doit avoir un contact direct avec l’équipe de développement18

36. Tout change : technologie, environnement et surtout les besoins

37. Les chefs de projets classiques fonctionnent sur la base de GANTT, PERT et le système de tâches

38. Avec le temps, les diagrammes se dégradent car des tâches s’ajoutent et d’autres deviennent non nécessaires

39. Une meilleure stratégie est de planifier très court (02 semaines à 01 mois)

40. Plannings détaillés pour la semaine à venir, rigoureux pour les trois mois et très vagues au-delà19

41. Les principes agiles Les 12 principes agiles Toujours satisfaire le client à travers des livraisons rapides et continues Bien accueillir tous les changements même les tardifs Livrer fréquemment un système fonctionnel Les clients et les développeurs doivent collaborer Conduire le projet autour d’équipes motivées La meilleure méthode de faire circuler l’information c’est le contact direct entre collaborateurs La première mesure d’avancement c’est un logiciel fonctionnel Le développement doit être durable et à un rythme constant La bonne conception et l’excellence technique augmentent l’agilité Simplifier au maximum Les meilleurs architectures, besoins et conceptions proviennent d’équipes qui s’organisent d’elles-mêmes L’équipe s’améliore d’une manière autonome et régulière 20

42. Méthodologie XP 21 Méthodologie xp

43. La méthodologie XP 22

44. Planification Agile 23 Planification agile

46. Ne pas chercher à avoir une liste exhaustive des fonctions

47. Chaque fonction est traduite en user stories

48. Les user stories sont écrites sur des cartes (ou équivalent)

49. Les développeurs collaborent à estimer les user stories

50. L’estimation ne se fait pas en temps mais en points

51. Une user stories de 8 points durera logiquement deux fois plus qu’une user stories de 1 point

52. Les user stories trop longues sont réparties en plusieurs user stories

53. Une user story trop petite est fusionnée avec une autre

54. La fusion et la division n’est pas une science exacte en terme de points24

56. La vélocité est le nombre de points finalisés durant la semaine ou l’itération

57. Après 03 ou 04 semaines, l’équipe a une idée de sa vélocité

58. Au début, la vélocité est très imprécise puis se stabilise dans le temps

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. Une user story n’est finalisée que si elle passe tous ses tests d’acceptation25

62. Les tâches sont créées et enregistrée

63. Chaque développeur s’inscrit à une ou plusieurs tâches durant l’itération

64. Chaque développeur connaît le nombre de points de son itération précédente

65. Il prend des tâches jusqu’à atteindre ce nombre de points

66. Si des tâches restent, les développeurs négocient pour prendre le reste26

68. Théoriquement, la moitié des user stories devraient êtres terminées

69. Dans le cas contraire, l’équipe se réorganise pour assurer une bonne terminaison de l’itération27

71. Le client suit de près l’évolution du produit28

73. Project ou Excel sont des exemples d’outils de suivi

74. TFS est un excellent support de suivi 29

75. Introduction 30

76. Planification Agile 31 Conception agile

78. Les diagrammes UML n’est pas la conception mais une partie de la conception

79. La conception est un concept abstrait

80. Le code EST la conception

81. La conception agile est l’application continue des principes agiles32

83. Etre prêt au changement

84. Gérer la complexité33

85. Introduction 34

86. Conception agile Symptômes d’une mauvaise conception 35

88. Difficile de se retrouver dans une structure complexe

89. Difficile voire impossible d’estimer les changements

90. L’impact du changement est imprévisible36

92. Régler un problème engendre la création d’autres problèmes37

95. Viscosité de l’environnement : compilation lente, check-in fastidieux,….39

97. L’anticipation conduit souvent à l’effet inverse40

99. Même code mais sous différentes formes41

101. Les développeurs doivent se mettre à la place des lecteurs42

103. Manque de vision43

105. Couplage moindre44

106. Conception agile Principes de conception agile 45

108. Chaque responsabilité est un axe de changement46

109. SRP Exemple de violation de SRP 47

110. SRP Amélioration pour prendre en considération le SRP 48

111. SRP Exemple de violation de SRP 49

112. SRP Amélioration SRP 50

114. Ajouter la persistance dans les entités métier est une violation du SRP51

116. Un changement sur un système mal conçu conduit à une cascade d’effets sur des modules dépendants52

118. Abstraction  classes abstraites et / ou interfaces53

119. OCP Exemple 54

120. OCP Exemple 55

121. OCP Exemple 56

123. Principe : Les sous-types doivent être des substituts pour leur ancêtres57

124. LCP Exemple 58

125. LCP Exemple – Problème LCP 59

127. Avoir une vision plus globale et plus anticipative60

129. Les abstractions ne doivent pas dépendre des détails, Les détails doivent dépendre des abstractions61

130. DIP DIP - Exemple 62

131. Conception Agile 63

133. ISP ISP- Exemple 65

134. ISP ISP- Exemple 66

135. Refactoring 67 refactoring

136. Refactoring Refactoring Le refactoring est le processus d’améliorer la structure interne du code sans en altérer le fonctionnement 68

138. Permettre l’évolution

139. Communiquer avec ses lecteurs / utilisateurs69

140. Refactoring Refactoring avec VS2010 70

141. Refactoring 71

142. TDD 72 Test-drivendevelopment

143. TDD Qu’est-ce que le TDD Conduire tous nos développements par les tests. Le test doit être le vecteur de la conception. 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 73

144. TDD Etapes du TDD 74

146. Anticipe la conception

147. Augmente la confiance en soi

148. Estimer l’état d’avancement75

149. TDD 76

151. Solution Mock77

153. Exemple : tests de crash de voitiure (faux conducteur)78

155. Des états difficiles à reproduire (par exemple panne réseau)

156. Des objets pour des tests uniquement

157. Des objets qui n’existent pas encore ou qui doivent évoluer79

158. TDD 80