Téléchargé 761 fois
Contenu connexe
Methodes agile
- 1. Les méthodes agiles UM2 –2011-2012 2011 - 2012 Les méthodes agiles – S. Mathon 1
- 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 Programming 2011 - 2012 Les méthodes agiles – S. Mathon
- 3. Les ratages etl’informatique Une Histoire de bug 2011 - 2012 Les méthodes agiles – S. Mathon 3
- 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 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és 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 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 mauvaise 2011 - 2012 Les méthodes agiles – S. Mathon
- 8. « Le cheminest long du projet à la 8 chose» Molière 2011 - 2012 Les méthodes agiles – S. Mathon
- 9. 9 L’apparition des méthodesagiles 2011 - 2012 Les méthodes agiles – S. Mathon
- 10. 10 Manifeste des méthodes agiles Signé par 17 personnalités 4 valeurs L'équipe « Personnes et interaction plutôt que processus et outils » L'application « Logiciel fonctionnel plutôt que documentation complète » La collaboration « Collaboration avec le client plutôt que négociation de contrat » L'acceptation du changement « Réagir au changement plutôt que suivre un plan » 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 mesure 2011 - 2012 Les méthodes agiles – S. Mathon
- 12. 12 Les 12 principes (suite) Rythme soutenable Attention continue à la technique et à la conception Simplicité Auto-organisation Ajustements continus 2011 - 2012 Les méthodes agiles – S. Mathon
- 13. 13 Exemples Scrum Extreme programming (XP) Rapid Application Development (RAD) Adaptive software development (ASD) Crystal clear Dynamic software development method (DSDM) Feature driven development 2011 - 2012 Les méthodes agiles – S. Mathon
- 14. Scrum Le déroulement 2011 - 2012 Les méthodes agiles – S. Mathon 14
- 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 prescriptif 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 C'est le représentant des clients et des utilisateurs C'est lui qui donne les fonctionnalités à traiter, et qui prend les décisions importantes concernant l'orientation du projet Il gère le Backlog de Produit et le Release Plan Team Member Tous les autres 2011 - 2012 Les méthodes agiles – S. Mathon
- 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-dessus 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 commun 2011 - 2012 Les méthodes agiles – S. Mathon
- 19. 19 Workflow Agile 2011 - 2012 Les méthodes agiles – S. Mathon
- 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éveloppement 2011 - 2012 Les méthodes agiles – S. Mathon
- 21. 21 Itératif vs Incrémental 2011 - 2012 Les méthodes agiles – S. Mathon
- 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élai 2011 - 2012 Les méthodes agiles – S. Mathon
- 23. Scrum Le démarrage d’une version 2011 - 2012 Les méthodes agiles – S. Mathon 23
- 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 Volere 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 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 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 Exemple de Product Backlog ID User Story Comment le Valeur Estimation Sprint démontrer 001 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 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 la Backlog stories Backlog release estimé 4- Estimer la capacité de l’équipe 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 grosses 2011 - 2012 Les méthodes agiles – S. Mathon
- 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.html 2011 - 2012 Les méthodes agiles – S. Mathon
- 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, ?, Pause 2011 - 2012 Les méthodes agiles – S. Mathon
- 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’estimation 2011 - 2012 Les méthodes agiles – S. Mathon
- 34. Scrum : lessprints Illustration VisualExplainer 2011 - 2012 Les méthodes agiles – S. Mathon 34
- 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 version 2011 - 2012 Les méthodes agiles – S. Mathon
- 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’importance 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 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 mou 2011 - 2012 Les méthodes agiles – S. Mathon
- 39. 39 Le tableau blanc 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 fin 2011 - 2012 Les méthodes agiles – S. Mathon
- 41. 41 Mise en bouche : jeu du ballon Mon cahier des charges : mon ballon 2011 - 2012 Les méthodes agiles – S. Mathon
- 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ération 2011 - 2012 Les méthodes agiles – S. Mathon
- 43. Scrum : encours de sprint 2011 - 2012 Les méthodes agiles – S. Mathon 43
- 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ées 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 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 pas 2011 - 2012 Les méthodes agiles – S. Mathon
- 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. Scrum : larevue de sprint 2011 - 2012 Les méthodes agiles – S. Mathon 48
- 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’équipe 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 significatives 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 partenaires 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 suivant 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 à venir 2011 - 2012 Les méthodes agiles – S. Mathon
- 54. Scrum : résumédes rôles 2011 - 2012 Les méthodes agiles – S. Mathon 54
- 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 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 risques 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 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 tests 2011 - 2012 Les méthodes agiles – S. Mathon
- 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ôle 2011 - 2012 Les méthodes agiles – S. Mathon
- 60. 60 L’équipe Multi-disciplinaire Esprit d’équipe Pas d’élément perturbateur Mieux vaut un correct niveau moyen que des stars individuelles 2011 - 2012 Les méthodes agiles – S. Mathon
- 61. 61 Ne pas oublier Ce n’est pas parce que les rôles ont l’air d’être parfaitement définis que vous pouvez vous passer de les préciser au démarrage et en cours de projet Les pratiques ont l’air d’être définies mais laissent 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 appliquer 2011 - 2012 Les méthodes agiles – S. Mathon
- 62. Des pratiques supplémentaires XP… ou eXtreme Programming Rien à voir avec Windows 2011 - 2012 Les méthodes agiles – S. Mathon 62
- 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 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 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 conception 2011 - 2012 Les méthodes agiles – S. Mathon
- 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ération 2011 - 2012 Les méthodes agiles – S. Mathon
- 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é courage 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 XP et l’équipe développement 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 refactoring 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 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 code 2011 - 2012 Les méthodes agiles – S. Mathon
- 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ée 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 produit 2011 - 2012 Les méthodes agiles – S. Mathon
- 75. Kanban, Lean Les « nouvelles » tendances 2011 - 2012 Les méthodes agiles – S. Mathon 75
- 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 Kanban agile http://henrik-kniberg.developpez.com/mattias-skarin/livre/scrum-kanban/?page=sommaire 2011 - 2012 Les méthodes agiles – S. Mathon
- 78. 78 Kanban agile : les principes Visualisez 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 et placez y les éléments de travail. Limitez le TAF (travail à faire) : fixez des limites précises indiquant combien d'éléments peuvent être placés dans chaque étape du workflow. Mesurez et optimisez le temps de cycle (temps moyen pour traiter complètement un élément, appelé "lead time" en anglais), optimisez le processus pour que le temps de cycle soit aussi court et prévisible que possible. 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 Scrum 2011 - 2012 Les méthodes agiles – S. Mathon
- 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’approche 2011 - 2012 Les méthodes agiles – S. Mathon
- 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’équipe 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 continue 2011 - 2012 Les méthodes agiles – S. Mathon
- 83. 83 L’Agile dans l’entreprise 2011 - 2012 Les méthodes agiles – S. Mathon
- 84. 84 Toutes les entreprises peuvent-elles être agiles? Je suis une SSII Je suis un éditeur de logiciel Je développe mes logiciels internes 2011 - 2012 Les méthodes agiles – S. Mathon
- 85. 85 La culture d’entreprise 2011 - 2012 Les méthodes agiles – S. Mathon
- 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éveloppeur 2011 - 2012 Les méthodes agiles – S. Mathon
- 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’équipe 2011 - 2012 Les méthodes agiles – S. Mathon
- 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ôt 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 continue 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 XP 2011 - 2012 Les méthodes agiles – S. Mathon
- 91. L’Agile à Montpellier 2011- 2012 Les méthodes agiles – S. Mathon 91
- 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 fois 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 L’Agileet les approches qualité 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 correction 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 University 2011 - 2012 Les méthodes agiles – S. Mathon
- 97. 97 Domaines de processus CMMi 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 produit 2011 - 2012 Les méthodes agiles – S. Mathon
- 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 PPQA 2011 - 2012 Les méthodes agiles – S. Mathon
- 100. 100 Références « Scrum », par Claude Aubry, DUNOD Gestion de projet eXtreme Programming – Bénard, Bossavit, Medina, Williams – Eyrolles eXtreme Programming, La Référence – Kent Beck – Campus Press http://www.agiletour.org/ Cas pratique : http://henrik-kniberg.developpez.com/livre/scrum-xp/ http://www.scrum.org/ http://www.infoq.com/minibooks/kanban-scrum-minibook http://blog.octo.com/index.php/2008/01/25/69-pourquoi-les-methodes- agiles-peinent-elles-a-penetrer-lentreprise Jeux agiles: http://tastycupcakes.org 2011 - 2012 Les méthodes agiles – S. Mathon