Methodes agile

10 723 vues

Publié le

Publié dans : Formation
1 commentaire
10 j’aime
Statistiques
Remarques
Aucun téléchargement
Vues
Nombre de vues
10 723
Sur SlideShare
0
Issues des intégrations
0
Intégrations
11
Actions
Partages
0
Téléchargements
566
Commentaires
1
J’aime
10
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Methodes agile

  1. 1. Les méthodes agiles UM2 –2011-20122011 - 2012 Les méthodes agiles – S. Mathon 1
  2. 2. 2 Sommaire Introduction L’origine des Méthodes Agiles Le déroulement d’un projet Scrum Au démarrage d’une version Au démarrage d’une itération/sprint Le déroulement d’une itération La fin d’une itération Pour aller plus loin : eXtreme Programming2011 - 2012 Les méthodes agiles – S. Mathon
  3. 3. Les ratages et l’informatique Une Histoire de bug2011 - 2012 Les méthodes agiles – S. Mathon 3
  4. 4. 4 Un projet raté, c’est un produit qui… Ne répond pas aux besoins A été livré trop tard A coûté trop cher N’est pas fiable « Il est incroyablement difficile de réaliser dans les délais prévus des logiciels satisfaisant leurs cahiers des charges »2011 - 2012 Les méthodes agiles – S. Mathon
  5. 5. 5 Un constat alarmant au niveau mondial Situation en 2002 Résultat des projets Par le Standish Group CHAOS Report (http://www.standishgroup.com) Type 1 : Projet terminé dans les temps, les budgets et avec les fonctionnalités prévues Type 2 : Projet terminé en retard, hors budget ou avec une limitation de fonctionnalité Type 3 : Projets abandonnés2011 - 2012 Les méthodes agiles – S. Mathon
  6. 6. 6 Résultats 2009 : une nette amélioration Projets terminés dans les temps, les budgets et avec les fonctionnalités prévues : 32% Projets terminés en retard, hors budget ou avec une limitation de fonctionnalité : 44% Projets abandonnés ou livrés mais jamais utilisés : 24%2011 - 2012 Les méthodes agiles – S. Mathon
  7. 7. 7 Causes d’échec en informatique selon le Standish Group Manque de clarté ou mauvaise définition des besoins Evolution des spécifications Manque de réactivité Priorités non définies Manque de qualité du logiciel Conception trop ambitieuse Evolutions non prévues Rarement parce que la programmation est mauvaise2011 - 2012 Les méthodes agiles – S. Mathon
  8. 8. « Le chemin est long du projet à la 8 chose» Molière2011 - 2012 Les méthodes agiles – S. Mathon
  9. 9. 9L’apparition des méthodes agiles 2011 - 2012 Les méthodes agiles – S. Mathon
  10. 10. 10 Manifeste des méthodes agiles Signé par 17 personnalités 4 valeursLéquipe « Personnes et interaction plutôt que processus et outils »Lapplication « Logiciel fonctionnel plutôt que documentation complète »La collaboration « Collaboration avec le client plutôt que négociation de contrat »Lacceptation du changement « Réagir au changement plutôt que suivre un plan »2011 - 2012 Les méthodes agiles – S. Mathon
  11. 11. 11 Méthodes agiles : les 12 principes Satisfaction client Changement bienvenu Livraisons fréquentes Collaboration quotidienne Motivation et encouragements Communication face-à-face Logiciel sert de mesure2011 - 2012 Les méthodes agiles – S. Mathon
  12. 12. 12 Les 12 principes (suite) Rythme soutenable Attention continue à la technique et à la conception Simplicité Auto-organisation Ajustements continus2011 - 2012 Les méthodes agiles – S. Mathon
  13. 13. 13 Exemples Scrum Extreme programming (XP) Rapid Application Development (RAD) Adaptive software development (ASD) Crystal clear Dynamic software development method (DSDM) Feature driven development2011 - 2012 Les méthodes agiles – S. Mathon
  14. 14. Scrum Le déroulement2011 - 2012 Les méthodes agiles – S. Mathon 14
  15. 15. 15 Scrum Les racines de Scrum se retrouvent dans la publication de Takeuchi et Nonaka dans "The New Product Development Game“ Ken Schwaber et Jeff Sutherland la formalisent en 1996 SCRUM est un framework de méthodologie SCRUM est un framework non prescriptif2011 - 2012 Les méthodes agiles – S. Mathon
  16. 16. 16 Les rôles Scrum Master Responsable de faire appliquer par l’équipe les valeurs et les pratiques de Scrum Facilite la résolution des problèmes Product Owner Cest le représentant des clients et des utilisateurs Cest lui qui donne les fonctionnalités à traiter, et qui prend les décisions importantes concernant lorientation du projet Il gère le Backlog de Produit et le Release Plan Team Member Tous les autres2011 - 2012 Les méthodes agiles – S. Mathon
  17. 17. 17 Pause : le jeu de la balle Chacun est membre d’une équipe Entre chaque participant, la balle doit voler (« air-time ») Chaque balle doit être touchée par chaque membre de l’équipe Vous ne pouvez pas passer la balle à votre voisin ou voisine de gauche ou de droite Chaque cycle de balle doit démarrer et se terminer par la même personne Une balle qui tombe par terre est perdue : elle doit recommencer le cycle Il y aura 5 itérations Les seules règles sont celles écrites ci-dessus2011 - 2012 Les méthodes agiles – S. Mathon
  18. 18. 18 Planning Explication des règles 2 min Création des équipes 2 min Organisation de l’équipe 1 min Estimation du temps 2 min itération 1 min debriefing de l’itération Après les 5 itérations : 10 min de debriefing commun2011 - 2012 Les méthodes agiles – S. Mathon
  19. 19. 19 Workflow Agile2011 - 2012 Les méthodes agiles – S. Mathon
  20. 20. 20 Définitions Sprint : itération dans Scrum – 2 semaines à 1 mois Scrum : mêlée quotidienne Product Backlog : cahier des charges initial User Story : terme eXtreme Programming, qui définit la manière d ’exprimer les attentes utilisateur Sprint Backlog : le contenu choisi pour un sprint Scrum daily meeting : réunion quotidienne de l’équipe développement2011 - 2012 Les méthodes agiles – S. Mathon
  21. 21. 21 Itératif vs Incrémental2011 - 2012 Les méthodes agiles – S. Mathon
  22. 22. 22 Les règles fondamentales Les itérations sont courtes : 2 semaines à 1 mois maximum Les itérations ne se chevauchent pas Les itérations ont toujours la même durée La date de fin du sprint n’est JAMAIS repoussée Les itérations s’enchaînent en général sans délai2011 - 2012 Les méthodes agiles – S. Mathon
  23. 23. Scrum Le démarrage d’une version2011 - 2012 Les méthodes agiles – S. Mathon 23
  24. 24. 24 Avoir la vision globale Comme pour toute méthode de gestion de projet, comprendre le contexte et les objectifs du projet. Déterminer les utilisateurs du projet Plusieurs approches possibles : Document de Vision Modèle Volere2011 - 2012 Les méthodes agiles – S. Mathon
  25. 25. 25 Objectifs du projet Résumer le projet en une phrase Quels sont les avantages « business » pour le client? Définir comment mesurer le succès du projet Le projet est-il réaliste/faisable? Est-ce que toutes les personnes impliquées l’approuvent? Quelle est l’importance du projet pour le client?2011 - 2012 Les méthodes agiles – S. Mathon
  26. 26. 26 Le Product Backlog Ensemble des évolutions prévues pour la version, plus ou moins précises Un Backlog est vivant Parfois modifications quotidiennes Surtout en réunions de sprint Représentation sous forme de liste Importance de la priorité : donne l’ordre de réalisation Le Backlog est partagé2011 - 2012 Les méthodes agiles – S. Mathon
  27. 27. 27 La User Story Les User Stories sont des « histoires » Avec : un acteur qui effectue une action dans un objectif donné. Une User Story doit pouvoir être développée entièrement pendant une itération. Un Backlog contient également des Stories techniques ou méthodologiques (Ex : tests unitaires)2011 - 2012 Les méthodes agiles – S. Mathon
  28. 28. 28 Exemple de Product BacklogID User Story Comment le Valeur Estimation Sprint démontrer001 Un <utilisateur> Soit sous forme Importance Effort pour Sprint fait une <action> de scénario, soit d’un point de implémenter dans dans un liste des vue la US lequel la <objectif> donné exigences utilisateur US est incontournables prise en compte 2011 - 2012 Les méthodes agiles – S. Mathon
  29. 29. 29 Le Plan de Release : pour garder le cap Répartition indicative des User Stories dans les sprints Prise en compte des dates fatidiques Fait par toute l’équipe 1- Définir le critère 3- Durée des de fin sprints Plan de release 2- Estimer les 5- Planifier laBacklog stories Backlog release estimé 4- Estimer la capacité de l’équipe2011 - 2012 Les méthodes agiles – S. Mathon
  30. 30. 30 Problèmes classiques de Backlog Les problèmes classiques de gestion des exigences : Stories exprimées sous forme de solution Stories exprimées sous forme technique Ambigüité/flou Manques/doublons/incompatibilité Product Backlog trop lourd Stories trop grosses2011 - 2012 Les méthodes agiles – S. Mathon
  31. 31. 31 L’estimation dans Scrum Estimer la taille/difficulté plutôt que la durée Estimation en points = jours/hommes idéaux Estimer de façon relative, par rapport à une story connue Les estimations sont INDICATIVES Cf Planning Poker http://www.planningpoker.com/detail.html2011 - 2012 Les méthodes agiles – S. Mathon
  32. 32. 32 Exercice : la planification culinaire Librement inspiré du Doggy Planning http://tastycupcakes.org/2009/06/dogg y-planning/ L ’équipe estime le contenu du Backlog Planning Poker : 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, Pause2011 - 2012 Les méthodes agiles – S. Mathon
  33. 33. 33 Backlog Votre Backlog contient les plats suivants : Nouilles au beurre Osso bucco Gâteau au chocolat Pizza au thon Waterzoi Ikita mashitsu Vous estimez le temps pour préparer chacun de ces plats – Unité : le Miam 20 min d’estimation2011 - 2012 Les méthodes agiles – S. Mathon
  34. 34. Scrum : les sprintsIllustration VisualExplainer2011 - 2012 Les méthodes agiles – S. Mathon 34
  35. 35. 35 La durée de sprint Durée fixe Consensus entre le besoin de feedback/la motivation vs le coût lié au sprint/la disponibilité du Product Owner Au minimum 4 sprints par version2011 - 2012 Les méthodes agiles – S. Mathon
  36. 36. 36 La réunion de planification de sprint 1- Le Product Owner présente l’objectif du sprint et les Stories candidates 1bis – La colonne « Comment le démontrer est remplie » 2- L’équipe liste les tâches nécessaires (<1 jour) et affine l’estimation 3- Accord sur le périmètre du sprint Consensus entre la capacité, la faisabilité et l’importance2011 - 2012 Les méthodes agiles – S. Mathon
  37. 37. 37 A préparer avant Le Product Backlog existe : Les exigences/User stories sont listées Le Product Owner a mis l’importance des stories les plus importantes et sélectionné ses candidates Le Scrum Master a calculé la capacité du sprint (quelle quantité de stories peut être traitée)2011 - 2012 Les méthodes agiles – S. Mathon
  38. 38. 38 Conditions Ailleurs que dans le bureau Tableau blanc Fixer la durée maximum à respecter : en général, 2*<durée du sprint (en semaines)> heures Ne pas commencer à résoudre les problèmes techniques, mais faire de la conception Poser les bonnes questions au Product Owner Garder du mou2011 - 2012 Les méthodes agiles – S. Mathon
  39. 39. 39 Le tableau blanc2011 - 2012 Les méthodes agiles – S. Mathon
  40. 40. 40 Et les tests? Prévoir les tests d’acceptation dès la planification du sprint Le scénarios de tests permettent : De comprendre les Stories De préparer la recette de sprint Les tests sont effectués en cours de sprint, pas à la fin2011 - 2012 Les méthodes agiles – S. Mathon
  41. 41. 41 Mise en bouche : jeu du ballon Mon cahier des charges : mon ballon2011 - 2012 Les méthodes agiles – S. Mathon
  42. 42. 42 Règle du jeu Chaque équipe a 2 minutes pour créer le plus possible de ballons et me les amener Résultats et debriefing 2ème itération2011 - 2012 Les méthodes agiles – S. Mathon
  43. 43. Scrum : en cours de sprint2011 - 2012 Les méthodes agiles – S. Mathon 43
  44. 44. 44 Déroulement du sprint Chaque développeur s’approprie des tâches des User Stories de l’itération Premières tâches attribuées à la réunion de sprint Ensuite, au cours des réunions quotidiennes Tous les matins, réunion café/standup meeting/scrum meeting pour débloquer les problèmes et mesurer l’avancement Au bout de l’itération, seules les User Stories complètes sont livrées2011 - 2012 Les méthodes agiles – S. Mathon
  45. 45. 45 Le Scrum Daily Meeting Faire le point sur les tâches depuis le dernier Scrum meeting S’attribuer de nouvelles tâches Organiser le travail de la journée en cas d’obstacle (besoin d’expertise, de travailler à 2, problèmes de serveurs…)2011 - 2012 Les méthodes agiles – S. Mathon
  46. 46. 46 Daily Meeting : les principes Tous les matins Pas plus d’1/4 heure Personne ne dirige la réunion, même si le Scrum Master peut l’animer Tout le monde participe Équipe (y compris Scrum Master) Product Owner au moins quelques fois par semaine Utilisation et mise à jour du tableau blanc L’équipe peut faire appel à des experts D’autres personnes peuvent y assister mais n’interviennent pas2011 - 2012 Les méthodes agiles – S. Mathon
  47. 47. 47 La notion de « fini » ou « done » Définir dès le départ ce que veut dire « fini » : Les stories : Est-ce que ça inclut la documentation? Est-ce que ça inclut des tests unitaires? Est-ce que ça inclut des tests d’intégration/croisés? La version Une story en particulier : chaque story ne nécessite pas le même travail Permet d’aborder la notion de « portée »2011 - 2012 Les méthodes agiles – S. Mathon
  48. 48. Scrum : la revue de sprint2011 - 2012 Les méthodes agiles – S. Mathon 48
  49. 49. 49 Les principes A lieu le dernier jour du sprint Durée maximum : de 2 à 4 heures Prend en général la forme d’une démonstration : Build avec les stories terminées Idéalement faite par le Product Owner ou un membre de l’équipe2011 - 2012 Les méthodes agiles – S. Mathon
  50. 50. 50 La préparation Tester ou faire tester les stories livrées Préparer un plan de démonstration basé sur les Stories livrées Convier des invités éventuels Installer sur une plateforme de test/démonstration, avec des données significatives2011 - 2012 Les méthodes agiles – S. Mathon
  51. 51. 51 Les participants Au minimum, toute l’équipe y compris Product Owner et Scrum Master Parfois les autres personnes intéressées Marketing/commercial Support Éventuellement clients ou partenaires2011 - 2012 Les méthodes agiles – S. Mathon
  52. 52. 52 Le contenu Le Product Owner émet des demandes de modification et recueille les feedbacks des participants Il mettra ensuite à jour le Product Backlog et le Plan de Release, qui serviront à la planification du sprint suivant Les demandes de changement et les bugs sont priorisés et pas forcément pris en compte dans le sprint suivant2011 - 2012 Les méthodes agiles – S. Mathon
  53. 53. 53 La rétrospective Revenir sur le déroulement du sprint pour optimiser l’organisation Réunion suite à la réunion de fin de sprint Bilan intermédiaire Qu’est-ce qui s’est bien passé? Qu’est-ce qui s’est mal passé? Comment nous améliorer? Idéalement, brainstorming Choisir 1 amélioration pour le sprint à venir2011 - 2012 Les méthodes agiles – S. Mathon
  54. 54. Scrum : résumé des rôles2011 - 2012 Les méthodes agiles – S. Mathon 54
  55. 55. 55 Actions du Scrum Master Veiller à ce que les pratiques Scrum soient appliquées Encourager l’équipe et le Product Owner et les inciter à devenir autonomes Protéger l’équipe des obstacles/interférences en cours de sprint Organiser et animer les réunions « Le Scrum Master est au service de l’équipe »2011 – 2012 Les méthodes agiles – S. Mathon
  56. 56. 56 Le Scrum Master idéal Bonne connaissance de Scrum Comprend les aspects techniques Communication Bon guide, fait confiance Médiateur Tenace Transparent Au service de l’équipe Sait prendre des risques2011 - 2012 Les méthodes agiles – S. Mathon
  57. 57. 57 Questions fréquentes Peut-on se passer de Scrum Master? Le Scrum Master doit-il être le Chef de Projet? Le Scrum Master peut-il venir en plus du Chef de Projet?2011 - 2012 Les méthodes agiles – S. Mathon
  58. 58. 58 Actions du Product Owner Participe aux réunions De début de sprint Quotidiennes, parfois De fin de sprint À la rétrospective Est responsable du Backlog de Produit Répond aux questions sur le produit Définit les tests d’acceptation Passe ou fait passer ces tests2011 - 2012 Les méthodes agiles – S. Mathon
  59. 59. 59 Le Product Owner idéal Bonne connaissance du domaine métier Maîtrise des techniques de définition de produit Capacité à prendre des décisions rapidement Capacité à détailler quand il le faut Ouvert au changement…mais sans changer d’avis tout le temps Aptitude à la négociation Disponible pour le rôle2011 - 2012 Les méthodes agiles – S. Mathon
  60. 60. 60 L’équipe Multi-disciplinaire Esprit d’équipe Pas d’élément perturbateur Mieux vaut un correct niveau moyen que des stars individuelles2011 - 2012 Les méthodes agiles – S. Mathon
  61. 61. 61 Ne pas oublierCe n’est pas parce que les rôles ont l’aird’être parfaitement définis que vous pouvezvous passer de les préciser au démarrage eten cours de projetLes pratiques ont l’air d’être définies maislaissent une certaine liberté : Faire du Scrum, c’est appliquer tous ses principes, mais réfléchir dès que nécessaire à la façon de les appliquer2011 - 2012 Les méthodes agiles – S. Mathon
  62. 62. Des pratiques supplémentaires XP… ou eXtreme Programming Rien à voir avec Windows2011 - 2012 Les méthodes agiles – S. Mathon 62
  63. 63. 63 XP et la gestion de projet Séance de Planification (Planning Game) Livraisons Fréquentes (Frequent Releases) Rythme Soutenable (Forty-hour Week) Client sur le Site (On-Site Customer)2011 - 2012 Les méthodes agiles – Sandrine Mathon
  64. 64. 64 XP et les développeurs Développement conduit par les Tests Unitaires (Unit Tests, Tests Driven Development) Conception Simple (Simple Design) et code maintenable Re-factorisation de Code pratiquée sans relâche Tests de Recette (Acceptance Tests)2011 - 2012 Les méthodes agiles – S. Mathon
  65. 65. 65 Les TDD Ecrire les tests unitaires Ecrire d’abord les tests unitaires Processus itératif : Un test qui produit une erreur Le code qui résout l’erreur Un test qui produit une erreur Le code qui résout l’erreur …etc… Les tests unitaires servent d’outil de conception2011 - 2012 Les méthodes agiles – S. Mathon
  66. 66. 66 Conception simple Conception architecturale simple Pas de conception détaillée Evitez d’anticiper toutes les évolutions probables : de toute façon, vous vous trompez Ne définissez QUE ce dont vous avez besoin pour l’itération2011 - 2012 Les méthodes agiles – S. Mathon
  67. 67. 67 Refactoring Remanier le code pour le simplifier Doit être pratiqué de façon permanente Pallie à l’absence de conception initiale Ne pas hésiter à jeter et ré-écrire Demande un sacré courage2011 - 2012 Les méthodes agiles – S. Mathon
  68. 68. 68 XP et l’équipe développements Propriété Collective du Code (Collective Code Ownership) Convention de Code (Coding Standard) Programmation En Binôme (Pair Programming) Intégration Continue (Continuous Integration) Métaphore (Metaphor)2011 - 2012 Les méthodes agiles – S. Mathon
  69. 69. 69 XP et l’équipe développement2011 - 2012 Les méthodes agiles – S. Mathon
  70. 70. 70 Propriété collective du code Pas de répartition par module Chaque développeur connaît TOUT le code Pas de panique en cas d’absence d’un développeur Facilite le refactoring2011 - 2012 Les méthodes agiles – S. Mathon
  71. 71. 71 Convention de code Parce que le code appartient à tout le monde Parce que le code devient l’outil de communication Noms de fonctions parlants Noms de variables clairs Le coach surveille aussi cette partie-là2011 - 2012 Les méthodes agiles – S. Mathon
  72. 72. 72 Programmation en binôme Première cause d’échec : Le travail en binôme mal compris 2 développeurs côte-à-côte, pas toujours les mêmes Choisir les moments où le binôme est nécessaire Permet une meilleure intégration des nouveaux Favorise la propriété collective du code2011 - 2012 Les méthodes agiles – S. Mathon
  73. 73. 73 Intégration continue Le code est compilé en permanence Ce qui est mis à l’intégration doit être terminé Le client a accès au produit en permanence pour tester Certaines équipes XP ou Scrum interdisent les demandes de changement de la part du client au cours d’une itération Intégration automatisée2011 - 2012 Les méthodes agiles – S. Mathon
  74. 74. 74 Métaphore Vous ne développez plus un logiciel, mais un « bureau » ou une « Ferrari » ou une « maison »… Pour la Ferrari, vous vous occupez de ses roues, de son moteur, de sa carrosserie… Crée une complicité autour du produit2011 - 2012 Les méthodes agiles – S. Mathon
  75. 75. Kanban, Lean Les « nouvelles » tendances2011 - 2012 Les méthodes agiles – S. Mathon 75
  76. 76. 76 Agile = Lean? Amélioration continue (Kaizen) Elimination des gaspillages : production excessive, attentes, transport et manutention inutiles, tâches inutiles, stocks, mouvements inutiles production défectueuse.2011 - 2012 Les méthodes agiles – S. Mathon
  77. 77. 77 Kanban agilehttp://henrik-kniberg.developpez.com/mattias-skarin/livre/scrum-kanban/?page=sommaire 2011 - 2012 Les méthodes agiles – S. Mathon
  78. 78. 78 Kanban agile : les principesVisualisez le workflow :Divisez votre travail, décrivez chaque élément sur une fiche et mettez-la au mur.Tracez des colonnes, donnez-leur le nom des étapes du workflow etplacez y les éléments de travail.Limitez le TAF (travail à faire) : fixez des limites précises indiquantcombien déléments peuvent être placés dans chaque étape duworkflow.Mesurez et optimisez le temps de cycle (temps moyen pourtraiter complètement un élément, appelé "lead time" en anglais),optimisez le processus pour que le temps de cycle soit aussi court etprévisible que possible.2011 - 2012 Les méthodes agiles – S. Mathon
  79. 79. 79 Les apports de Kanban Obliger à résoudre les problèmes (sinon la chaîne se bloque) Mettre l’accent sur les goulets d’étranglement et encourager la collaboration pour les lever Permet de fluidifier le travail Mettre en exergue la notion de fini Est compatible avec Scrum2011 - 2012 Les méthodes agiles – S. Mathon
  80. 80. 80 Les dangers de Kanban Favoriser la vision à très court terme Peu de principes définis, il faut donc réfléchir au reste Risque de prétexte pour ne rien organiser Impression de « chômage technique » en cas de blocage Et donc risque d’abandon de l’approche2011 - 2012 Les méthodes agiles – S. Mathon
  81. 81. 81 Les idées reçues sur l’Agile Pas de documentation Tout est défini, pas besoin de réfléchir à l’organisation L’équipe doit être autonome donc il ne faut pas la diriger Le client dirige l’équipe2011 - 2012 Les méthodes agiles – S. Mathon
  82. 82. 82 La documentation Les problèmes de la documentation: Specs difficiles à maintenir à jour Coupe la communication Agile ne veut pas dire « pas de doc » Oui à la doc comme recueil de connaissance sur le projet et source d’amélioration continue2011 - 2012 Les méthodes agiles – S. Mathon
  83. 83. 83 L’Agile dans l’entreprise2011 - 2012 Les méthodes agiles – S. Mathon
  84. 84. 84 Toutes les entreprises peuvent-elles être agiles? Je suis une SSII Je suis un éditeur de logiciel Je développe mes logiciels internes2011 - 2012 Les méthodes agiles – S. Mathon
  85. 85. 85 La culture d’entreprise2011 - 2012 Les méthodes agiles – S. Mathon
  86. 86. 86 Tous les projets peuvent-ils être agiles? Mon produit est un mélange d’informatique et d’électronique Petits projets d’une ou 2 personnes Énormes projets avec des équipes de plus de 20 personnes : gros projets OpenSource Nécessite des concepts objets forts, une bonne connaissance technique, au moins 1 très bon développeur2011 - 2012 Les méthodes agiles – S. Mathon
  87. 87. 87 Causes d’échec Le laxisme: tout n’est pas pré-mâché Le fanatisme Changement d’état d’esprit difficile Hostilité du management Le client n’est pas disponible Agilité ne veut pas dire changement de priorité ou interruption toutes les 5mn Il faut trouver le bon coach/scrum master Technologie pas assez souple (pas d’approche objet…) Mauvaise ambiance dans l’équipe2011 - 2012 Les méthodes agiles – S. Mathon
  88. 88. 88 Bénéfices Chaque développeur est 7 fois plus productif avec le TDD Motivation des équipes, augmentation du niveau Synergie Qualité du logiciel lissée Les retards ou problèmes sont détectés tôt2011 - 2012 Les méthodes agiles – S. Mathon
  89. 89. 89 Et la documentation? Idée reçue : Agile = pas de doc Idée à retenir : Non à la doc comme « interface » de communication Oui à la doc comme recueil de connaissance sur le projet et source d’amélioration continue2011 - 2012 Les méthodes agiles – S. Mathon
  90. 90. 90 Les outils Plateforme Eclipse Gestion de configuration : SVN, CVS, GIT Frameworks de Tests Unitaires : Junit, CPPUnit… Création de builds et fiches de livraison : Maven, Hudson Test de la couche graphique et applis WEB : Selenium, Squish Fit : framework de test collaboratif XPlanner : gestion de projet XP2011 - 2012 Les méthodes agiles – S. Mathon
  91. 91. L’Agile à Montpellier2011 - 2012 Les méthodes agiles – S. Mathon 91
  92. 92. 92 XP et Scrum Tissu de PMEs/TPEs TIC Agile = dynamisme et qualité des versions eXtreme Programming pour les entreprises naissantes SCRUM a le vent en poupe Agile Tour à Montpellier en 2011 pour la première fois2011 - 2012 Les méthodes agiles – S. Mathon
  93. 93. 93 Quelques entreprises Agile IGEOSS - Editeur de progiciel de modélisation géomécanique – XP NORMIND - Editeur de logiciel d’aide à la décision – Scrum, XP BSD Concept – Editeur de logiciels de généalogie - Scrum IOcean - SSII – Scrum Synapse – SSII – Scrum, XP La Poste!2011 - 2012 Les méthodes agiles – S. Mathon
  94. 94. 94 L’Agile et les approches qualité2011 - 2012 Les méthodes agiles – S. Mathon
  95. 95. 95 La qualité des produits Les entreprises mal gérées dépensent 90% de leurs efforts en qualité dans le traitement des symptômes Les entreprises bien gérées dépensent 80% de leurs efforts en qualité dans la prévention Les coûts de prévention sont beaucoup moins importants que les coûts de détection et de correction2011 - 2012 Les méthodes agiles – S. Mathon
  96. 96. 96 Les Normes Qualité ISO 9001:2000 – par ISO CMMi (Capability Maturity Model Integration) – par le SEI Commandé par l’armée américaine Le SEI est hébergé par la Carnegie Mellon University2011 - 2012 Les méthodes agiles – S. Mathon
  97. 97. 97 Domaines de processus CMMi2011 - 2012 Les méthodes agiles – S. Mathon
  98. 98. 98 Bénéfices de CMMi niveau2 Compréhension des besoins clients Bonne préparation des projets Bon suivi Réduction des coûts de développement Réduction des délais de livraison Amélioration de la qualité du produit2011 - 2012 Les méthodes agiles – S. Mathon
  99. 99. 99 Compatibilité avec l’Agile Obligation de documentation Possibilité d’automatiser la production des documents Histoires utilisateurs spécifications Analyse automatique du code conception détaillée Tests : tout est fait dans XP Principes fondamentaux semblables Difficultés La traçabilité des exigences Les CR de réunions PPQA2011 - 2012 Les méthodes agiles – S. Mathon
  100. 100. 100 Références« Scrum », par Claude Aubry, DUNODGestion de projet eXtreme Programming – Bénard, Bossavit, Medina,Williams – EyrolleseXtreme Programming, La Référence – Kent Beck – Campus Presshttp://www.agiletour.org/Cas pratique : http://henrik-kniberg.developpez.com/livre/scrum-xp/http://www.scrum.org/http://www.infoq.com/minibooks/kanban-scrum-minibookhttp://blog.octo.com/index.php/2008/01/25/69-pourquoi-les-methodes-agiles-peinent-elles-a-penetrer-lentrepriseJeux agiles: http://tastycupcakes.org 2011 - 2012 Les méthodes agiles – S. Mathon

×