Les Méthodes AgilesPanorama et retours d’expériences29 août 2006
Changement de Paradigme
Le développement de nouveaux logiciels![Jones97] [BP88] “Last simple SW project was in 1969”                              ...
Approche classique de gestion de projet!Faire un plan détaillé!Affecter des ressources!Contrôler et rectifier les écarts!L...
Confusion de Paradigme                                       Analyse des                                    besoins et fai...
Approche classique vs Approche Agile    Projet classique                      Projet agile!Etablir et suivre un plan      ...
Développement Itératif                         Méthodes itératives et                              évolutives             ...
Agile != XP
Historique                                                            Lean Software Development, 2002                     ...
Livres
Livres
Livres
Web!www.agilealliance.com!www.scrumalliance.org!www.agilemodeling.com!www.featuredrivendevelopment.com!www.poppendick.com!...
HistoriqueQuestion :“What are the most exciting, promising software engineering ideastechniques on the horizon?”Réponse :“...
Preuves!IEEE Computer, Juin 2003, Larman et Basili
Estimé vs. Réel [DeMarco82, Little04]!p50 réel = 2x estimé!p90 réel = 3,25x estimé!La meilleure estimation initiale à 10% ...
Fonctionnalités inutiles ?Taux d’utilisation des fonctionnalités développées [Johnson02] surdes projets développés en méth...
Echec du processus en cascadeFacteurs clefs de succès/d’échec sur 1027 projets [Thomas01]!Les pratiques du processus en ca...
Processus Itératif et EvolutifEtude de deux ans [MacCormack01] :!La majorité des gains en productivité sont dus à :   ! De...
Productivité - Mauvaise Pratiques       Reuse of low-quality deliverables           -300%       Low management knowledge/e...
Productivité - Bonnes Pratiques       Reuse of high-quality deliverables            350%       High management experience ...
Facteurs de ProductivitéEtude d’équipes de développement hyper-productives [HC96] :   !Développement itératif,   !Organisa...
Facteurs de ProductivitéDeux études menées sur 15 projets montrent que :!La productivité est doublée si l’équipe évolue da...
Quelle organisation est la plus efficace ?
Quelle organisation est la plus efficace ?
Manifeste Agile                  Priorité aux personnes et aux interactions,                  plutôt que sur les processus...
Process Agile : Solution miracle ?“Process is a second-order effect” - Alistair Cockburn
Le Marché aux pratiques!Une cause d’échec des méthodes agiles est latentation de faire “son marché” dans les pratiques,!Le...
Méthodes Agiles!Lean Software Development,!eXtreme Programming,!Scrum,!DSSM,!Crystal.
Lean SoftwareDevelopment
Origines : Lean Production
Lean Thinking!5 principes à mettre en oeuvre!Montrent le but à atteindre :  !Complexe à maîtriser  !Pas de tout ou rien,  ...
Lean Thinking : 5 principes!Traquer les déchets (Waste),!Effectuer les tâches en petits lots (Small batches) à la demande ...
Lean Thinking!Cela peut sembler simple ou évident,!En fait cela demande un profond changement de mentalité et demanagement...
Lean Software Development!7 principes   !Eliminer les déchets,   !Accentuer l’apprentissage,   !Décider le plus tard possi...
Eliminer les déchets!Voir les déchets :  !Fonctionnalité partiellement réalisée,  !Processus trop lourd  !Fonctionnalités ...
Délivrer aussi vite que possible!Intégration continue,!Design patterns,!Améliorer la productivité :  !Recruter des dévelop...
Donner du pouvoir à l’équipe!Promouvoir l’auto-organisation,!Stand-up meeting journalier,!Retrospective de fin d’itération...
Phases vs Disciplines!Une itération met en oeuvre toutes les disciplines et se termine pas unproduit éxécutable           ...
Changement de terminologie                        Phase de                       Conception                             Ph...
Des équipes cross-fonctionnelles!Des Workshops,!Toute l’équipe :  !Analystes,  !Développeurs,  !Testeurs,  !Product Owner.
Equipe orientée Fonctionnalité                     Fonctionnalité                           !=                        Modu...
Workshop
Livre
Workshops étalés dans le temps
Développement Orienté Risque et Valeur     Développer      Feedback     Développer      Feedback     Développer      quelq...
eXtremeProgramming
Livre
eXtreme Programming!Origines :  !Initiative de Kent Back et Ron Jeffries en 1996, en collaboration avec  Wad Cunningham  !...
12 pratiques
L’environnement de travail             L’environnement                     productif                                 La di...
Intégration continue
Cruise Control / Information Radiator
XP : Points forts / Points faibles!Approche très radicale…  !Les « curseurs » sont au minimum ou au maximum !  !Nécessite ...
Scrum
Livre
Origines                                      Iterative,   The New, New                                    Incremental,   ...
Scrum!Principales pratiques :  !Élaboration et mise à jour d’un planning produit (product backlog),  !Des itérations de 30...
Scrum - Le cycle de développement
Iteration    =  Sprint
Scrum a été utilisé par...!Des éditeurs de logiciels,!Des société faisant partie de “Fortune 100”,!Des “start-up”,!Des équ...
Scrum a été utilisé pour...!Du logiciel critique dans le domaine médical,!Des applications financières,!De la biotechnolog...
4 manières de maîtriser un projet          Fonctionnalités                     Temps                                    Pr...
Iteration Burn Down Chart     60     45     30     15      0          1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Scrum : Points forts / Points faibles!Favorise la communication :  !Partage des informations grâce au scrum quotidien,  !I...
DSDM
Dynamic Software Development Method (DSDM)!Développée en GB, en 1994, sous la forme d’un consortium desociétés qui voulaie...
DSDM – le cycle de développement 1.     Étude de faisabilité      •    Définition du problème à        2.     Étude du « b...
DSDM : Points forts / Points faibles!Conformité avec la norme Iso 9001,!Trop d’autonomie donnée à l’équipe et aux utilisat...
Crystal
Livre
Crystal!Mise au point en 1990, par Alistair Cockburn, il s’agit plutôt d’unefamille de méthodologies adaptables à chaque t...
Crystal : Points forts / Points faibles!Adaptée à des petits projets de moins de 6 personnes,!La famille de méthodes Cryst...
Prochain SlideShare
Chargement dans…5
×

Tour d'horizon des méthodes agiles

3 924 vues

Publié le

Un état des lieux des méthodes agile en 2006

Publié dans : Technologie
0 commentaire
2 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
3 924
Sur SlideShare
0
Issues des intégrations
0
Intégrations
348
Actions
Partages
0
Téléchargements
69
Commentaires
0
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Tour d'horizon des méthodes agiles

  1. 1. Les Méthodes AgilesPanorama et retours d’expériences29 août 2006
  2. 2. Changement de Paradigme
  3. 3. Le développement de nouveaux logiciels![Jones97] [BP88] “Last simple SW project was in 1969” 60 50 % Changement d’exigences 40 30 20 10 0 0 10 100 1000 10000 100000 Taille du projet en points de fonction
  4. 4. Approche classique de gestion de projet!Faire un plan détaillé!Affecter des ressources!Contrôler et rectifier les écarts!La gestion de projets classique s’assure de la conformité du projet par rapport au plan, non de la bonne adéquation de ce plan « I have always found that plans are useless, but planning is indispensable » Dwight Eisenhower
  5. 5. Confusion de Paradigme Analyse des besoins et faisabilitéLa production en masse tend à Spécificationspromouvoir un processus : Conception !En cascade, architecturale !Design en amont, Conception détaillée !Un plan détaillé, Codage !Etapes pré-définies. Tests de validationLe développement de nouveaux Installationproduits nécessite un processus : Préparer !Itératif, !Evolutif, Faire !Adaptatif, !Empirique. Adapter
  6. 6. Approche classique vs Approche Agile Projet classique Projet agile!Etablir et suivre un plan !Planifier puis adapter!Avancement défini par des !Avancement mesuré par lalivrables intermédiaires livraison de fonctionnalités!Assignation des tâches !Prise en charge des tâches!Solution imposée !Solution émergente 6
  7. 7. Développement Itératif Méthodes itératives et évolutives Méthodes Agiles
  8. 8. Agile != XP
  9. 9. Historique Lean Software Development, 2002 Agile UP, 1999 Adaptive Software Development, 1998 xBreed, 1998 Feature-Driven Development, 1997 Crystal, 1997 XP, 1995 DSDM, 1992 Scrum, 1992 Spiral Model, 1987Lean Thinking, 1950s
  10. 10. Livres
  11. 11. Livres
  12. 12. Livres
  13. 13. Web!www.agilealliance.com!www.scrumalliance.org!www.agilemodeling.com!www.featuredrivendevelopment.com!www.poppendick.com!www.lean.org!www.extremeprogramming.org!www.testdriven.com!www.jimhighsmith.com!www.martinfowler.com!alistair.cockburn.us!www.craiglarman.com
  14. 14. HistoriqueQuestion :“What are the most exciting, promising software engineering ideastechniques on the horizon?”Réponse :“I don’t think that the promising ideas are on the horizon. They are alreadyhere and have been for years, but are not being used properly.” David L. Parnas
  15. 15. Preuves!IEEE Computer, Juin 2003, Larman et Basili
  16. 16. Estimé vs. Réel [DeMarco82, Little04]!p50 réel = 2x estimé!p90 réel = 3,25x estimé!La meilleure estimation initiale à 10% de chances de se réaliser
  17. 17. Fonctionnalités inutiles ?Taux d’utilisation des fonctionnalités développées [Johnson02] surdes projets développés en méthodes classiques. Souvent Parfois 13% 16% Rarement Toujours 19% 7% Jamais 45%
  18. 18. Echec du processus en cascadeFacteurs clefs de succès/d’échec sur 1027 projets [Thomas01]!Les pratiques du processus en cascade : !Phase amont d’analyse, !Planning sous forme de gantt-chart, !Planning “fixe”.!Sont la toute première cause d’échec des projets,!Cité en premier dans 82% des projets.
  19. 19. Processus Itératif et EvolutifEtude de deux ans [MacCormack01] :!La majorité des gains en productivité sont dus à : ! Des itérations avec un feedback précoce, ! Une intégration continue journalière (ou plus fréquente) de tout le code avec des tests automatiques de non-régression.Etude sur 23.000 projets [Standish98] :!2 facteurs clefs de succès sur 5 sont liés aux méthodes itératives : ! Implication fréquente des utilisateurs, ! Petites milestones, ! Objets métiers clairs, ! Chef de projet expérimenté, ! Support du management.
  20. 20. Productivité - Mauvaise Pratiques Reuse of low-quality deliverables -300% Low management knowledge/experience -90 Low staff knowledge/experience -87 High requirements creep -77 Inadequate development tools -75 No inspections -48 Inadequate management tools -45 Inadequate methods/process; not following -41 Poor estimation -40 High project complexity -35 Schedule pressure -30 Crowed office space; low table/wall space -27 Low-level languages -25 Geographic separation -24 Informal/sloppy cost/schedule estimates -22 Only generalist occupations -15 Low client participation -13
  21. 21. Productivité - Bonnes Pratiques Reuse of high-quality deliverables 350% High management experience 65 High staff experience 55 Really followed an effective method/process 35 Used adequate management tools 30 Used effective development tools 27 High-level language 24 Used estimating tools 19 Specialist occupations 18 Client participation 18 Formal cost/schedule estimates 17 Unpaid overtime 15 Inspections 15 Low project complexity 15
  22. 22. Facteurs de ProductivitéEtude d’équipes de développement hyper-productives [HC96] : !Développement itératif, !Organisation simples; moins de rôles que d’ordinaire, !L’architecte a été un développeur, !Forte composant communication ; un focus technique tous les jours, !Le noyau a été développé en premier, par une équipe très aguerrie.Les études montrent qu’un facteur 5:1 à 10:1 sépare le développeur lemoins productif du développeur le plus productif.
  23. 23. Facteurs de ProductivitéDeux études menées sur 15 projets montrent que :!La productivité est doublée si l’équipe évolue dans un Openspacesans aucune frontière ni barrière.
  24. 24. Quelle organisation est la plus efficace ?
  25. 25. Quelle organisation est la plus efficace ?
  26. 26. Manifeste Agile Priorité aux personnes et aux interactions, plutôt que sur les processus et les outils. L’accent est sur les individus, l’expertise, l’esprit d’équipe. Des applications fonctionnelles opérationnelles, plutôt qu’une documentation pléthorique. On privilégie le code testé. Collaborer avec le client, plutôt que négocier un contrat. Le client est un partenaire qui participe au projet pour donner son feedback Réactivité au changement, plutôt que suivre un plan. Le planning est flexible pour accepter les modifications.
  27. 27. Process Agile : Solution miracle ?“Process is a second-order effect” - Alistair Cockburn
  28. 28. Le Marché aux pratiques!Une cause d’échec des méthodes agiles est latentation de faire “son marché” dans les pratiques,!Les méthodes agiles sont basées sur desprincipes et des valeurs plus que des pratiques,!Les pratiques doivent être adaptées : !aux individus, !au contexte, !en cours de projet.Se donner comme objectif d’adopter une pratiquesdétourne de l’objectif de livraison d’un produit dequalité dans les temps et budget impartis.
  29. 29. Méthodes Agiles!Lean Software Development,!eXtreme Programming,!Scrum,!DSSM,!Crystal.
  30. 30. Lean SoftwareDevelopment
  31. 31. Origines : Lean Production
  32. 32. Lean Thinking!5 principes à mettre en oeuvre!Montrent le but à atteindre : !Complexe à maîtriser !Pas de tout ou rien, !Pas de maintenant ou jamais.
  33. 33. Lean Thinking : 5 principes!Traquer les déchets (Waste),!Effectuer les tâches en petits lots (Small batches) à la demande (Pull),!Voir le système dans son intégralité. Pas d’optimisations locales,!Equipe soudée et motivée (Jelled Team)!Apprendre et améliorer le processus en continu (KAISEN)!Manager qui écoute et règle les problèmes de son équipe (GEMBA) échets rimer les d aleur et supp Maxim iser la v
  34. 34. Lean Thinking!Cela peut sembler simple ou évident,!En fait cela demande un profond changement de mentalité et demanagement : !On se focalise sur la production de valeur pour les utilisateurs, !Le chef de projet gestionnaire devient un facilitateur, !Le processus évolue continuellement, !Il ne s’affine pas, il évolue en fonction des demandes, !L’équipe est au coeur du processus d’amélioration continu, !Ils cherchent à améliorer leur environnement de travail pour produire plus de valeur. !Les optimisations locales sont monnaie-courante, !Financer les moyens plutôt que les objectifs.
  35. 35. Lean Software Development!7 principes !Eliminer les déchets, !Accentuer l’apprentissage, !Décider le plus tard possible, !Délivrer aussi vite que possible, !Donner du pouvoir à l’équipe, !Maintenir l’intégrité, !Voir le système dans sa globalité.!22 principes concrets ou “ThinkingTools”
  36. 36. Eliminer les déchets!Voir les déchets : !Fonctionnalité partiellement réalisée, !Processus trop lourd !Fonctionnalités inutilisées !Changement de tâche !Attente !Passage de documents !Anomalies, bugs, !Duplication.!Modélisation agile,!Eviter un design détaillé en amont,!Ne pas écrire de document sans besoin réel,...
  37. 37. Délivrer aussi vite que possible!Intégration continue,!Design patterns,!Améliorer la productivité : !Recruter des développeurs expérimentés, !Un seul site, !Outillage agile, !Open space, !...
  38. 38. Donner du pouvoir à l’équipe!Promouvoir l’auto-organisation,!Stand-up meeting journalier,!Retrospective de fin d’itération : !Aux mains de l’équipe, !Analyser, !Adapter, !Le processus : !Outils, !Pratiques, !Eliminer le déchet en évitant les optimisations locales.!Attention : Pas de tout ou rien ! Ni de maintenant ou jamais !
  39. 39. Phases vs Disciplines!Une itération met en oeuvre toutes les disciplines et se termine pas unproduit éxécutable e a lys An on epti o nc C st n Te tat io n me m plé I
  40. 40. Changement de terminologie Phase de Conception Phase de Test
  41. 41. Des équipes cross-fonctionnelles!Des Workshops,!Toute l’équipe : !Analystes, !Développeurs, !Testeurs, !Product Owner.
  42. 42. Equipe orientée Fonctionnalité Fonctionnalité != Module Fonctionnalité = Centrée Utilisateur
  43. 43. Workshop
  44. 44. Livre
  45. 45. Workshops étalés dans le temps
  46. 46. Développement Orienté Risque et Valeur Développer Feedback Développer Feedback Développer quelques quelques quelques fonctionnalités fonctionnalités fonctionnalités Risques Valeurs
  47. 47. eXtremeProgramming
  48. 48. Livre
  49. 49. eXtreme Programming!Origines : !Initiative de Kent Back et Ron Jeffries en 1996, en collaboration avec Wad Cunningham !Projet C3 chez Chrysler!5 valeurs : !4 activités essentielles : !Communication, !Conception (un peu mais tout le !Simplicité, temps), !Feedback, !Codage (pas mal) et refactoring, !Courage, !Tests (beaucoup), !Respect. !Ecoute.
  50. 50. 12 pratiques
  51. 51. L’environnement de travail L’environnement productif La diffusion de l’information
  52. 52. Intégration continue
  53. 53. Cruise Control / Information Radiator
  54. 54. XP : Points forts / Points faibles!Approche très radicale… !Les « curseurs » sont au minimum ou au maximum ! !Nécessite beaucoup de discipline.!… adaptée aux petits projets : !Pas plus de 10-12 personnes.!Centrée sur l’ingénierie, plus légère sur le management,!Favorise la qualité : !Client présent sur le site de développement, !Mais cela a un coût ! !Tests omniprésents.!Le pair-programming n’est pas toujours bien ressenti par lesdéveloppeurs : !Doit être basé sur le volontariat et l’autodiscipline.
  55. 55. Scrum
  56. 56. Livre
  57. 57. Origines Iterative, The New, New Incremental, Product Lean Thinking Development, Development Game Timeboxes Scrum (1993) Dr Jeff Sutherland Ken Schwaber
  58. 58. Scrum!Principales pratiques : !Élaboration et mise à jour d’un planning produit (product backlog), !Des itérations de 30 jours (sprint), !Planification de chaque itération (sprint backlog), !Réunion d’avancement quotidienne (scrum), !Isolation des développeurs (face au chaos extérieur), !Revue de fin d’itération (sprint review meeting).!3 rôles : !Scrum Master, !Product Owner, !Team.
  59. 59. Scrum - Le cycle de développement
  60. 60. Iteration = Sprint
  61. 61. Scrum a été utilisé par...!Des éditeurs de logiciels,!Des société faisant partie de “Fortune 100”,!Des “start-up”,!Des équipes de développement en interne,!Des équipes sur des contrats au forfait.
  62. 62. Scrum a été utilisé pour...!Du logiciel critique dans le domaine médical,!Des applications financières,!De la biotechnologie,!Des systèmes pour les Centres d’appels,!De environnements de développement,!Des systèmes disponibles 24x7, 99.99999%,!Des applications base de données de plusieurs terabytes,!Des applications Web innovantes.
  63. 63. 4 manières de maîtriser un projet Fonctionnalités Temps Projet Tests Ressources!Une fois une itération commencée, ne JAMAIS changer la date de fin,!On peut par contre enlever des fonctionnalités
  64. 64. Iteration Burn Down Chart 60 45 30 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
  65. 65. Scrum : Points forts / Points faibles!Favorise la communication : !Partage des informations grâce au scrum quotidien, !Isolation et protection des développeurs,!Approche plus axée sur le management,!Adaptée au développement de progiciels au sein d’équipes« produit » : !Présence d’un Product Owner,!Bonne complémentarité avec XP = méthode XBreed.
  66. 66. DSDM
  67. 67. Dynamic Software Development Method (DSDM)!Développée en GB, en 1994, sous la forme d’un consortium desociétés qui voulaient utiliser RAD et le développement itératif.!9 principes de base : !Implication active des utilisateurs, !Pouvoir de décision des équipes, !Livraisons fréquentes, !Adéquation aux besoins, !Développement itératif et incrémental, !Modifications réversibles, !Définition globale des besoins, !Intégration des tests dans tout le cycle de vie, !Collaboration et coopération entre toutes les parties prenantes.
  68. 68. DSDM – le cycle de développement 1. Étude de faisabilité • Définition du problème à 2. Étude du « business » résoudre • Étude des processus à automatiser et des besoins en informations • Évaluation des coûts (ateliers facilités) • Ébauche de la solution • Priorisation des fonctionnalités technique • Définition de l’architecture système3. Modèle fonctionnel 4. Conception et itératif développement itératifs • Spécifications détaillées • Réalisation du système • Modules logiciels conforme aux standards 5. Mise en oeuvre • Mise en production • Formation • Documentation • Capitalisation 68
  69. 69. DSDM : Points forts / Points faibles!Conformité avec la norme Iso 9001,!Trop d’autonomie donnée à l’équipe et aux utilisateurs dans la prisede décision, par rapport au « payeur »,!Faire trop simple peut nuire à l’évolutivité de l’application,!Peut-être la moins agile des méthodes agiles, assez proche d’UP.
  70. 70. Crystal
  71. 71. Livre
  72. 72. Crystal!Mise au point en 1990, par Alistair Cockburn, il s’agit plutôt d’unefamille de méthodologies adaptables à chaque type de projet,!9 propriétés : !Livraisons fréquentes, !Améliorations permanentes, !Communication osmotique, !Confiance, sécurité personnelle, !Focus sur l’objectif et disponibilité, !Contact permanent avec les utilisateurs, !Environnement de travail et automatisation des tâches, !Coopération avec toutes les parties prenantes, !Réflexion sur les propriétés.
  73. 73. Crystal : Points forts / Points faibles!Adaptée à des petits projets de moins de 6 personnes,!La famille de méthodes Crystal offre une large possibilitéd’adaptation à chaque type de projet : !Mais les autres « membres de la famille » ne sont pas encore décrits, !Ni même fortement expérimentés.

×