Le document traite des méthodes agiles, détaillant leurs principes fondamentaux et leur application dans le développement logiciel. Il souligne l'importance de la collaboration, de la flexibilité et d'une bonne conception pour assurer le succès des projets. Des méthodologies telles que XP et TDD sont également abordées, mettant l'accent sur l'importance des tests et du refactoring.

1. Méthodes AgilesUn parcours des méthodes agiles1

2. Introduction2Nos echecs

3. Introduction3Taux de réussite des projets

4. Introduction4Critères de réussite

5. Introduction5Autres industries : Renault Zoé (2012)

6. Introduction6Autres industries : Batman 3 (Juillet 2012)

7. Introduction7Succès d’un projet

8. IntroductionEt notre industrie ? Quelques désastresDuke Nukem n’est jamais sorti 

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. Introduction9

12. Introduction10Facteurs d’échec

13. Introduction11Conduite classique d’un projet

14. Introduction12Implications

15. Principes Agiles13Principes agiles

16. Principes agilesManifesto agile 200117 chefs de projets se sont réunis à l’Utah (USA)

17. Lassés par la lourdeurs des processus classiques

18. Ils ont formé l’alliance agile14

19. Les principes agiles15

20. Les principes agilesIndividus et interactions au lieu de processus et outilsLes collaborateurs sont la clé du succès

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

26. Les principes agilesLogiciel fonctionnel au lieu de documentation massiveUn code sans documentation est un désastre

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

32. Les principes agilesCollaboration du client au lieu de la négociation de contratsTrès difficile de décrire la totalité du logiciel depuis le début

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

35. Les principes agilesRéagir aux changements au lieu de suivre un planUn logiciel ne peut pas être planifié très loin dans le futur

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 agilesLes 12 principes agilesToujours satisfaire le client à travers des livraisons rapides et continuesBien accueillir tous les changements même les tardifsLivrer fréquemment un système fonctionnelLes clients et les développeurs doivent collaborerConduire le projet autour d’équipes motivéesLa meilleure méthode de faire circuler l’information c’est le contact direct entre collaborateursLa première mesure d’avancement c’est un logiciel fonctionnelLe développement doit être durable et à un rythme constantLa bonne conception et l’excellence technique augmentent l’agilitéSimplifier au maximumLes meilleurs architectures, besoins et conceptions proviennent d’équipes qui s’organisent d’elles-mêmesL’équipe s’améliore d’une manière autonome et régulière20

42. Méthodologie XP21Méthodologie xp

43. La méthodologie XP22

44. Planification Agile23Planification agile

45. Planification AgilePlanificationLes développeurs et le client discutent du système (identifier les fonctions)

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

55. Planification AgilePlanificationChaque itération un ensemble de user stories sont terminées

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

61. Planification AgilePlanificationLes développeurs divisent les user stories en tâches

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

67. Planification AgilePlanificationAu milieu d’une itération, une réunion entre développeurs est organisée

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

70. Planification AgilePlanificationA chaque fin d’itération le produit est montré et évalué par le client

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

72. Planification AgilePlanificationLe suivi par des outils informatiques

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

74. TFS est un excellent support de suivi 29

75. Introduction30

76. Planification Agile31Conception agile

77. Conception agileQu’est-ce que la conception agile ?L’analyse concerne le « quoi », la conception concerne le « comment »

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