Téléchargé 46 fois
Téléchargé parKhalid Nafil
Methodes agiles
Le document présente une analyse des méthodes agiles en développement logiciel, contrastant ces approches avec les méthodologies classiques, souvent perçues comme bureaucratiques. Les méthodes agiles, telles que XP et Scrum, mettent l'accent sur l'adaptabilité, la collaboration et le rôle central de l'individu dans le processus. Elles répondent à l'imprévisibilité des besoins en développant un processus auto-adaptatif et itératif, permettant une meilleure satisfaction des utilisateurs.
Methodes agiles
- 1. LES MÉTHODES AGILES Khalid Nafil Email: knafil@gmail.com Année universitaire : 2011/12 1
- 2. Méthodes agiles Introduction Contexte dedéveloppement Méthodologies Approche Prédictive contre Adaptative 2
- 3. Introduction Au cours desderniè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. Contexte de développement Ledé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. Les méthodologies Imposent unprocessus 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. ...Les Méthodologies L’avancement dudéveloppement est ralenti On parle de méthodologies lourdes ou “monumentales methodologies” 6
- 7. ...Les Méthodologies ...Un nouveaugroupe de méthodologies est apparu : Les méthodes agiles 7
- 8. Les Méthodes Agiles (Caractéristiques) Moinsorientés documentation Orientées code S’adaptent au changement Orientées client plutôt que processus 8
- 9. Approche Prédictive contre Adaptative Lesmé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. Imprésivibilité des besoins Lesbesoins, en développement logiciel, changent souvent Les changements de besoins sont la norme Que faire pour s’adapter ? 10
- 11. Adaptation aux besoins Traiterles 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. ...Adaptation aux besoins Enré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. PROBLÈME DE PRÉVISION Est-il possibled’utiliser une méthode prédictive dans une situation imprévisible. 13
- 14. Contrôler un processus imprévisible Processusadaptatifs 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. Durée des itérations XPsuggère une à trois semaines SCRUM suggère un mois Crystal étend plus la période 15
- 16. L’humain au centredu 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. Équipe de développement Dansl’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. Équipe de développement Lespersonnes sont le facteur le plus important dans le développement logiciel L’individu compte avant tout 18
- 19. Les programmeurs sontdes 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. Processus orienté vers l’individu Acceptationdu 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. Rôle du leadershipMé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. Le processus Auto-Adaptatif Leprocessus, 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. Le processus Auto-Adaptatif Cesquestions 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. Les Méthodologies Plusieurs méthodesde type agiles existent Se ressemblent et se distinguent On peut citer : XP Crystal Open Source SCRUM DFD RUP 24
- 25. La méthode XP(eXtreme Programming) La plus connue Apparaît en 1999 par Ken Beck de Chrysler 25
- 26. La méthode XP Marquéepar ses quatre valeurs : La communication Le retour d’information La simplicité Le courage 26
- 27. La méthode XP Lestests sont au coeur du développement Les tests sont intégrés dans un processus de compilation et d’intégration continue 27
- 28. Les pratiques d’XP XPdécline ses valeurs en 13 pratiques, réparties sur 3 catégories : • Programmation • Collaboration • Gestion de projet 28
- 29. La famille Crystalde 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. Principes de lafamille 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. Démarche de Crystal Observerles 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. La méthode SCRUM Scrumest 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. Philosophie de lamé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. Principes de SCRUM Concentrerl’é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. Rôles définis parSCRUM Le Directeur de produit Le ScrumMaster l’Équipe 35
- 36. Les rôles dansSCRUM 36
- 37. Directeur du produit Représentantdes 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. ScrumMaster Veille sur laprotection 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. Équipe Auto-gérée Décisions prises ensemble Contactdirect avec le directeur de produit (product owner) 39
- 40. La planification deprojet 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. Outils pour Scrum Outilslibres : IceScrum (open source) Outils propriétaires : ScrumWorks VersionOne 41