Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Methodes agiles

1,241 views

Published on

Ce cours présente les principes des méthodes agiles, une attention particulière est portée pour les méthodes XP, Scrum et Crystal.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Methodes agiles

  1. 1. LES MÉTHODES AGILES Khalid Nafil Email : knafil@gmail.com Année universitaire : 2011/12 1
  2. 2. Méthodes agiles Introduction Contexte de développement Méthodologies Approche Prédictive contre Adaptative 2
  3. 3. Introduction Au cours des dernières années, Intérêt croissant pour les méthodes agiles (légères) Alternatives aux méthodes classiques Ont suscité l’intérêt de la communauté informatique Orientées vers l’humain (people first) 3
  4. 4. Contexte de développement Le développement informatique classique est de type “coder puis débuguer” Les logiciels sont écrits sans plan Longue phase de tests Alternative : l’adoption des méthodologies 4
  5. 5. Les méthodologies Imposent un processus rigoureux de développement Objectif : rendre le développement plus prévisible et plus efficace Maleureusement, elles ne débouchent pas sur un succès flagrant Elles ne sont pas populaires Elles sont qualifiées comme “bureaucratiques” 5
  6. 6. ...Les Méthodologies L’avancement du développement est ralenti On parle de méthodologies lourdes ou “monumentales methodologies” 6
  7. 7. ...Les Méthodologies ...Un nouveau groupe de méthodologies est apparu : Les méthodes agiles 7
  8. 8. Les Méthodes Agiles (Caractéristiques) Moins orientés documentation Orientées code S’adaptent au changement Orientées client plutôt que processus 8
  9. 9. Approche Prédictive contre Adaptative Les méthodologies classiques s’inspirent des techniques d’ingénierie Mise en avant de la planification avant la construction On distingue entre conception et construction 9
  10. 10. Imprésivibilité des besoins Les besoins, en développement logiciel, changent souvent Les changements de besoins sont la norme Que faire pour s’adapter ? 10
  11. 11. Adaptation aux besoins Traiter les changements comme résultat d’une mauvaise analyse des besoins Mettre en place des procédures pour limiter les changements après signature de l’utilisateur sur la base de ses besoins 11
  12. 12. ...Adaptation aux besoins En réalité, Fixer les besoins avec les utilisateurs du logiciel demande beaucoup d'énergie Ce qui peut être un bon ensemble de besoins maintenant, n'est pas forcément bon dans six mois 12
  13. 13. PROBLÈME DE PRÉVISION Est-il possible d’utiliser une méthode prédictive dans une situation imprévisible. 13
  14. 14. Contrôler un processus imprévisible Processus adaptatifs Les seuls plans stables sont des plans à court terme qui sont faits d'une seule itération Développement itératif Livraisons intégrées et testées 14
  15. 15. Durée des itérations XP suggère une à trois semaines SCRUM suggère un mois Crystal étend plus la période 15
  16. 16. L’humain au centre du processus Équipes de développement plug and play Programmeurs comme professionnels responsables Processus orienté vers l’individu Leadership Métier Processus Auto-Adaptatif 16
  17. 17. Équipe de développement Dans l’approche classique - Développer un processus où les personnes sont remplaçables - Les rôles sont plus importants que les individus • Les méthodes agiles rejettent cette notion de remplaçabilité 17
  18. 18. Équipe de développement Les personnes sont le facteur le plus important dans le développement logiciel L’individu compte avant tout 18
  19. 19. Les programmeurs sont des professionnels responsables À la différence du Taylorisme Reconnaître la compétence des programmeurs Les personnes brillantes sont de plus en plus attirées par l’informatique 19
  20. 20. Processus orienté vers l’individu Acceptation du processus plutôt que imposition du processus Accepter un processus demande une motivation et l’implication de toute l’équipe Seuls les développeurs peuvent choisir de suivre un développement adaptatif Les développeurs doivent être capables de prendre toutes les décisions techniques L’accès à un poste de management, signifie une perte rapide de compétences techniques 20
  21. 21. Rôle du leadership Métier Les techniciens ne peuvent assumer l’ensemble du processus par eux mêmes Requirent une assistance sur les besoins métiers Besoin de contact rapproché et continu avec l’expertise métier 21
  22. 22. Le processus Auto-Adaptatif Le processus, lui même, est sujet à l’adaptabilité Faire des revues régulières du processus à la fin de chaque itération Qu’est ce qu’on a bien fait ? Qu’est ce qu’on a appris ? Qu’est ce qu’on peut faire mieux ? Qu’est ce qui nous inquiète/étonne ? 22
  23. 23. Le processus Auto-Adaptatif Ces questions vont apporter des idées pour adapter le processus à partir de la prochaine itération Le processus, alors, s’améliore et s’adapte de mieux en mieux à l’équipe qui l’utilise 23
  24. 24. Les Méthodologies Plusieurs méthodes de type agiles existent Se ressemblent et se distinguent On peut citer : XP Crystal Open Source SCRUM DFD RUP 24
  25. 25. La méthode XP (eXtreme Programming) La plus connue Apparaît en 1999 par Ken Beck de Chrysler 25
  26. 26. La méthode XP Marquée par ses quatre valeurs : La communication Le retour d’information La simplicité Le courage 26
  27. 27. La méthode XP Les tests sont au coeur du développement Les tests sont intégrés dans un processus de compilation et d’intégration continue 27
  28. 28. Les pratiques d’XP XP décline ses valeurs en 13 pratiques, réparties sur 3 catégories : • Programmation • Collaboration • Gestion de projet 28
  29. 29. La famille Crystal de méthodologies Crée par Alistair Cockburn Très fortement adaptable aux spécifités de chaque projet Plusieurs principes doivent être partagés par l’ensemble de l’équipe 29
  30. 30. Principes de la famille Crystal La communication et la collaboration entre les membres de l’équipe est omniprésente Le nombre de membres de l’équipe ne peut dépasser 6 personnes Toute l’équipe doit travailler dans la même pièce Les diagrammes de modélisation doivent être élaborés en groupe et sur tableau blanc La collaboration avec le client est étroite Livrer fréquemment des parties exécutables 30
  31. 31. Démarche de Crystal Observer les utilisateurs dans leur travail pour bien identifier les besoins Classer par ordre de priorité les différents cas d’utilisation en concertation avec les utilisateurs Élaboration d’une ébauche de conception, impliquant les outils à utiliser Élaborer le planning des itérations (itération de 2 à 3 mois) Développement des itérations 31
  32. 32. La méthode SCRUM Scrum est une méthode agile pour la gestion de projets Conçue pour améliorer la productivité dans les équipes Développée en 1996, par J.Sutherland et K.Schwaber 32
  33. 33. Philosophie de la méthode SCRUM Scrum, terme emprunté au rugby, veut dire mêlée Processus centré sur une équipe soudée qui cherche à atteindre un but 33
  34. 34. Principes de SCRUM Concentrer l’équipe, de manière itérative, sur un ensemble de fonctionnalités à réaliser Une itération, appelée Sprint, dure 30 jours Chaque Sprint a un but à atteindre Un Sprint aboutit sur la livraison d’un produit partiel fonctionnel La participation du client est déterminante pour le choix des priorités dans les fonctionnalités du logiciel 34
  35. 35. Rôles définis par SCRUM Le Directeur de produit Le ScrumMaster l’Équipe 35
  36. 36. Les rôles dans SCRUM 36
  37. 37. Directeur du produit Représentant des clients et des utilisateurs Définit l’ordre de développement des fonctionnalités Décide sur les orientations importantes du projet Travaille, de préférence, dans la même pièce que l’équipe 37
  38. 38. ScrumMaster Veille sur la protection de l’équipe, des éléments perturbateurs, extérieurs à l’équipe Veille à résoudre les problèmes non techniques Veille à l’application des valeurs de Scrum 38
  39. 39. Équipe Auto-gérée Décisions prises ensemble Contact direct avec le directeur de produit (product owner) 39
  40. 40. La planification de projet Planification à trois niveaus : Sprint : itération de 30 jours Release/projet : regroupement d’itérations Quotidien : réunion (srcum) de mise au point 40
  41. 41. Outils pour Scrum Outils libres : IceScrum (open source) Outils propriétaires : ScrumWorks VersionOne 41

×