Your SlideShare is downloading. ×
0
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
2009 scrum&xp
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

2009 scrum&xp

1,571

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,571
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
144
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • It’s a creative process; if you make your own thing that works it’s fine – it’s a good deal; Don’t look outside for a methodology
  • 31
  • 64
  • 82
  • 96
  • Transcript

    • 1. 1 Développement Agile avec Scrum et XP www.xebia.fr
    • 2. • Session 1 : Introduction o Pourquoi les méthodes agiles ? • Session 2 : Scrum o Présentation de Scrum o Les rôles dans Scrum o Les artefacts de Scrum o Les cérémonies de Scrum • Session 3 : Introduction a l’eXtreme Programming • Session 4 : Piloter un projet agile o Gérer les exigences o Estimations agiles o Planification • Session 5 : Sujets avancés Agenda www.xebia.fr
    • 3. • Quel est votre nom et votre rôle dans l’organisation ? • Quel est votre niveau d’expérience professionnelle ? • Quelle expérience avez-vous des méthodes agiles ? Introductions…
    • 4. • Qu’attendez-vous de la formation ? o Ecrivez un test et placez-le sur le tableau o Par exemple : • J’ai compris comment, en tant que développeur, je serai impacté • Je sais comment me préparer à l’agilité • J’ai identifié les principaux obstacles à la mise en place de l’agilité dans mon organisation • Je connais des méthodes permettant de lutter contre une mauvaise communication Objectifs de la formation
    • 5. 5 1ère session Pourquoi les méthodes agiles ?
    • 6. • Dr Winston W. Royce, Managing the development of large software systems, 1970 Le cycle de développement classique Cycle en V, Waterfall…
    • 7. • Planifier le travail, travailler selon le Plan (Gantt) • Piloter l’avancement par rapport au Plan (effort/RAF) • Contrôle centralisé • Contraindre le changement • Recherche d'optima locaux • Segmentation des responsabilités • Fige les choix tôt, échoue tardivement L’hypothèse de prédictibilité
    • 8. Taux de succès des projets Échec des projets selon la taille (CHAOS report 2004: Standish group) Principalement par manque : – D’implication des utilisateurs – De support du management – De clarté dans les objectifs métiers 29%18% 53% Challenged Failed Succeeded
    • 9. Attentes utilisateurs
    • 10. • Dépassement du budget / des délais • Non réalisation du business case • Faible capacité à s’adapter et évoluer • Utilisation non optimale de ressources • Individus découragés et non disciplinés • Gaspillages à de multiples niveaux • Problèmes non visibles Symptômes www.xebia.fr
    • 11. • Prédictible ou production en masse o Production d’une voiture o Suivre une recette de cuisine • Développement de nouveau produit o Créer un nouveau modèle de voiture o Créer une nouvelle recette Deux types de projets www.xebia.fr Le développement logiciel est du développement de nouveau produit
    • 12. • Non prédictible • Apprentissage par l’expérimentation • Amélioration continue • Tolérant au changement • Repousser les décisions irréversibles o Garder un maximum d’options • Des Best Practices comme point de départ Développement de produit www.xebia.fr
    • 13. Prédictif vs. Agile www.xebia.fr ` ` Résultat Business Case Minimisation des coûts Maximisation de la valeur Défensive Offensive Création de valeur Gestion des responsabilités Partage des responsabilités ConfianceContractuelle Business CasePlanning Management LeadershipStyle d’organisation interne Nature des interactions entres les parties Organisation et priorisation des activités Vue adaptativeVue prédictive
    • 14. Méthodes de développement www.xebia.fr AgileEvolutionaryItératif • Itérations multiples • Entre 1 et 6 semaines • Timebox : ressources et durée fixe • Périmètre figé durant l’itération • Impose l’apprentissage • Recueil évolutif des besoins • Piloté par le feedback utilisateur • Planification, processus adaptatifs • Tailler sur mesure : éliminer les gaspillages • Focus sur la communication et les individus • La qualité comme un moyen pour maintenir productivité élevée • Satisfaction du client en livrant tôt et régulièrement du logiciel utile
    • 15. www.xebia.fr 2001: Le Manifeste Agile We are uncovering better ways of developing software by doing it and helping others do it. February 11 – 13, 2001 Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
    • 16. 16 L’ombrelle agile Agile Methodologies • eXtreme Programming Kent Beck, Ward Cunningham, Ron Jeffries • Scrum Ken Schwaber and Jeff Sutherland • Crystal Methods Alistair Cockburn • Feature Driven Development Jeff DeLuca • Dynamic Systems Development Method DSDM Consortium Agile Management Frameworks • Agile Project Management Jim Highsmith, Sanjiv Augustine • Agile Management, KanBan David Anderson • eXtreme Project Management Rob Thomsett • Lean Software Development Tom & Mary Poppendieck
    • 17. • Eliminate waste o Fonctionnalités inutiles, « churn », frontières • Build quality in o Discipline, règles o Test, test, test • Create knowledge o Feedback, amélioration continue • Defer commitment o Planification continue • Deliver fast • Respect people • Optimize the whole o Value Stream Map Lean Software Developpment www.xebia.fr INSPECT & ADAPT
    • 18. • Meilleure planification • Emphase sur le business case • Conçu pour les changements • Suppression des gaspillages • Visibilité sur les obstacles • Utilisation optimisée des ressources • L’excellence comme ligne de conduite • Des individus respectés, responsabilisés, motivés Bénéfices procurés par l’Agile www.xebia.fr
    • 19. Réduire le coût du changement
    • 20. Résumé www.xebia.fr FEEDBACK Principes Agiles Principes Classiques Petits Lots Fonctionnalités développées en itérations courtes, de 2 à 4 semaines, et mises en production aussi souvent que possible. Large Batches Livraisons à un rythme typique de 2 à 3 versions par an. Accepter le changement Accepter l’incertutude, s’adapter aussi bien aux changement externes (marché) qu’internes, en modifiant aussi bien les plans que les approches. Utiliser certains principes d’ingénierie pour faciliter les évolutiosn de la base de code. Baseline and Change Control Typiquement, contraindre fortement voire supprimer toute possibilité de changement significatif autre que l’abandon de certaines fonctionnalités. Suivre le plan initial, même si celui-ci s’est révélé faux (rétro-planning). Itérations et amélioration continue Les rétrospectives en fin d’itérations permettent aux équipes de s’introspecter, d’apprendre et de s’adapter en permanence. Leçons tirées uniquement à la Fin Le feedback négatif est rarement voire jamais formulé. Et s’il est formulé, c’est généralement trop tard (REX). Equipes petites, intégrées Des équipes de petite taille, pluridisciplinaires, qui simplifient la communication, permettent à chacun d’avoir une vision d’ensemble et créent les conditions d’une discipline collective. Equipes en silo Les équipes sont organisées par fonction et communiquent à travers des documents. Focus sur le “Highest Value First” Le projet, le produit et la vision sont alignés en priorisant les développement en fonction des besoins métier. Le développement incrémental permet d’obtenir un ROI accéléré. Tout ou rien La phasage classique interdit de livrer quoi que ce soit avant que tout soit terminé.
    • 21. Le nouveau profil des projets IT
    • 22. Etat de l’Art Sources: http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standish http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf http://www.ambysoft.com/surveys/agileFebruary2008.html Team location Success percentage Co-located Team 83% Distributed teams but physically reachable 72% Distributed across geographies 60% Average: 75% success rate Agile Adoption Rate Survey Feb 2008 642 respondents State of Agile Development Survey July 2008 3061 respondents in 80 countries Comparison Average project: 30% success rate Agile project: 60-80% success rate
    • 23. 23 Fin de la 1ère session Questions ? www.xebia.fr
    • 24. 24 2ème session Scrum
    • 25. L'Agilité n'est pas une recette www.xebia.fr LeanAgile Systémique Philosophie XP Principes Pratiques YOU ! Scrum Implémentation
    • 26. 26 Présentation de Scrum
    • 27. Scrum ?
    • 28. “The … ‘relay race’ approach to product development … may conflict with the goals of maximum speed and flexibility. Instead a holistic or ‘rugby’ approach — where a team tries to go the distance as a unit, passing the ball back and forth - may better serve today’s competitive requirements.” Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, January 1986 Origine de Scrum
    • 29. • Équipe responsable, en auto organisation • Avancement du produit par une série de « sprints » d’un mois ou moins • Exigences définies comme des éléments d’une liste appelée « backlog du produit » • Pas de prescription de pratiques d’ingénierie • Utilisation de règles génériques permettant de créer un environnement agile pour un projet • Un des « processus agiles » Caractéristiques de Scrum www.xebia.fr
    • 30. Un peu de terminologie Scrum XP Definition Sprint Iteration Période de durée fixe Release Small Release Mise en production Sprint/Release Planning Planning Game Réunions de planification agile Product Owner Customer Représentant du métier Retrospective Reflection Réunion de type “REX” ScrumMaster Project Manager Leader de l’équipe Daily Scrum Daily Standup Réunion quotidienne
    • 31. Scrum : la production en flux
    • 32. • Les projets Scrum progressent par série de Sprints • La durée d’un Sprint varie de 2 à 4 semaines • Une durée constante permet un meilleur rythme • Le produit (partiel) est conçu, codé, testé pendant le sprint Sprints www.xebia.fr
    • 33. • 4 volontaires, SVP ! • 1er round : o Le premier travailleur positionne tous les dés sur 1 o Le second travailleur positionne tous les dés sur 2 o Etc. • 2ème round o Le premier travailleur positionne 1 dé sur 1, puis le passe au second travailleur, puis passe au second dé o Le second travailleur positionne le 1er dé su 2, puis le passe, etc. • On mesure : o Combien de temps il faut pour que le premier dé sorte du cycle o Combien de temps il faut pour traiter tous les dés Une petite simulation de Scrum…
    • 34. Un peu de tout tout le temps
    • 35. Production incrémentale Piloter la progression 1 2 3 4 5
    • 36. Production incrémentale Explorer (prototypage) 1 2 3 4 5
    • 37. Synthèse
    • 38. • Scrum est un simple framework d’inspection et d’adaptation qui définit 3 rôles, 3 cérémonies et 4 artefacts et est conçu pour livrer du logiciel fonctionnel par itération de 30 jours maximum • Rôles : Product Owner, ScrumMaster et Équipe • Cérémonies : Planification de Sprint, Revue de Sprint et Daily Scrum • Artefacts : Product Backlog, Sprint Backlog Burndown Chart et logiciel fonctionnel • Facile à implémenter, dur à exécuter Le cadre Scrum www.xebia.fr
    • 39. 39 Les rôles dans Scrum
    • 40. Scrum définit 3 rôles www.xebia.fr Product Owner Équipe ScrumMaster
    • 41. • Définit les fonctionnalités du produit • Décide de la date et du contenu des release • Est responsable du ROI • Priorise les développements en fonction de la valeur métier • Gère les risques à moyen et long terme, coordonne les travaux complémentaires (Anticipation) • Peut changer les fonctionnalités et les priorités à chaque Sprint Le Product Owner www.xebia.fr
    • 42. • Responsable de la bonne application des valeurs et pratiques de Scrum • Facilite une coopération poussée entre tous les rôles et fonctions • Résout les problèmes, supprime les obstacles et gère les risques à court terme • Recherche des moyens d’améliorer la productivité de l’équipe • Protège l'équipe des interférences extérieures Le Scrum Master www.xebia.fr
    • 43. • 7 membres +/- 2 • Regroupant tous les rôles, de préférence à temps plein o Architecte, concepteur, développeur, spécialiste IHM, testeur, etc • Se focalise sur la livraison régulière de fonctionnalités de haute qualité • Propose des options pour garantir l’exécution de la vision • Gère ses activités à l’intérieur de chaque Sprint L’équipe www.xebia.fr
    • 44. Organisation de l’équipe Scrum 44 Traditional Silos Customer BA Designer DeveloperPM Core Team (EXAMPLE) BA / Tester BA Tester Product Owner Developer Designer Developer / BA SM Release Manager Capacity Planner Prod. Architect Tech Ops Business Sponsor Risk Assessor Security 44 BAAnalysts DeveloperDeveloperDeveloper Designers Tester La Core Team idéalament 5 à 9 membres dédiés (7 +/- 2). L’équipe étendue qui contient d’autres membres, dont le rôle est important mais dont l’effort n’est typiquement pas dédié au projet TesterTestersDevs
    • 45. Le principe de co-localisation La Team Room
    • 46. 46 Les artefacts de Scrum
    • 47. Le Product Backlog
    • 48. • Liste de fonctionnalités priorisées et estimées o Exprimées sous forme de User Stories • Produit en flux Le Product Backlog
    • 49. Product Backlog élémentaire Priority Backlog item Acceptance Criteria Estimate 1 Allow a guest to make a reservation • Confirmation email is sent • Must be made >24 hours in advance 3 2 As a guest, I want to cancel a reservation • Confirmation email is sent • Must be canceled 15 days in advance 5 3 Guest can change reservation dates … 3 4 Hotel employee can see future reservations for her hotel … 8 5 Improve exception handling … 15 41 … … 50
    • 50. Sprint Discussion : Définir READY et DONE Ready In Process Done
    • 51. Le Sprint Backlog
    • 52. • Sous-ensemble du Product Backlog que l’équipe s’engage à produire durant le Sprint o Chaque Story est découpée en tâches par l’équipe o Les tâches sont suivies dans un Task Board o Un Burndown Chart permet de piloter la progression Le Sprint Backlog
    • 53. Task Board – Jour 1 D’après Erik Kniberg, Scrum & XP from the Trenches
    • 54. Task Board – Jour N D’après Erik Kniberg, Scrum & XP from the Trenches
    • 55. Burndown Chart D’après Erik Kniberg, Scrum & XP from the Trenches
    • 56. Kan Ban et contrôle visuel D’après Erik Kniberg, Scrum & XP from the Trenches
    • 57. Kan Ban et contrôle visuel (2) D’après Erik Kniberg, Scrum & XP from the Trenches
    • 58. Task Board électronique 58 Rally Enterprise Rally Software Trichord ChangeVision Mingle Thoughtworks VersionOne Enterprise VersionOne
    • 59. L’Incrément
    • 60. La définition de DONE Tests unitaires Codage Conception Analyse Intégration Tests utilisateurs Tests performance Beta Production
    • 61. 61 Les cérémonies de Scrum
    • 62. Le Sprint Planning
    • 63. • L'équipe choisit les Stories qu’elle estime pouvoir terminer • Le backlog de sprint est créé o Les tâches sont identifiées et estimées (1-16 heures) o Par toute l’équipe • La conception de haut niveau est abordée Planification du sprint www.xebia.fr En tant que touriste potentiel, je veux voir des photos des hôtels afin de me faire une idée des services et facilités. Coder la couche métier (8 heures) Coder l'IHM (4) Écrire les tests (4) Refactorer la classe foo (6) Exécuter les tests de performance (4)
    • 64. Périmètre • Analyser et évaluer le backlog de produit • Définir le but du sprint Plan • Décider comment s'y prendre (conception) • Créer la liste des tâches à partir des éléments du backlog de produit • Estimer les tâches en heures But du sprint Backlog du sprint Contexte métier Capacité de l'équipe Backlog de produit Technos Produit actuel Planification du sprint
    • 65. But du Sprint • Un bref énoncé de ce sur quoi le travail va essentiellement porter pendant le sprint Database Application Services financiers Sciences de la vie Offrir les fonctions pour les études génétiques. Offrir plus d'indicateurs que le produit ABC sur les données de streaming. Faire tourner l'application sur une base MySQL en plus d'Oracle.
    • 66. Sprint Planning
    • 67. • Revue de la vélocité et de la capacité du Sprint o Identifier tout ce qui est unique pour le Sprint à veinr (jours fériés, vacances, absence, etc..) • Déterminer le But du Sprint (Optionnel) • Sélectionner les User Stories les plus prioritaires du Product Backlog o En prendre sensiblement plus que la capacité, en s’assurant qu’elles sont alignées avec le But du Sprint • Discuter des User Stories pour créer les tâches et les critères d’acceptance • Estimer les tâches en heure o Limiter la taille des tâches à < 16 heures • S’engager sur les User Stories o A concurrence de la capacité • Alimenter le Task Board Exemple d’agenda pour un Sprint Planning
    • 68. Task Board D’après Erik Kniberg, Scrum & XP from the Trenches
    • 69. Le Daily Scrum
    • 70. • Paramètres o Quotidien o Maximum 15 minutes o Debout • Pas fait pour résoudre les problèmes o Tout le monde est invité o Seuls les membres de l'équipe peuvent parler • Permet notamment d'éviter l'organisation d'autres réunions Daily Scrum www.xebia.fr
    • 71. • Il ne s'agit pas d’un compte-rendu au ScrumMaster o Mais d’engagements devant des pairs 3 questions www.xebia.fr Qu'as tu fait hier ? 1 Que vas-tu faire aujourd'hui ? 2 Rencontres-tu des obstacles ? 3
    • 72. Le Sprint Review
    • 73. • L'équipe présente ce qu'elle a fait pendant le sprint o Toute personne intéressée par le produit est invitée • Implique une démonstration des nouvelles fonctionnalités ou de l'architecture • Informel o Préparation < 2h o Pas de slides • Toute l'équipe participe • Les intervenants du projets sont invités Revue de Sprint www.xebia.fr
    • 74. La Rétrospective
    • 75. • Réfléchir régulièrement à ce qui marche et ce qui ne marche pas • Conduite à la fin de chaque sprint • Toute l'équipe participe o ScrumMaster o Product Owner o Équipe o Éventuellement d’autres intervenants • Aboutit à un plan d’actions sur lequel l’équipe s’engage o Le Scrum Master en assure le suivi Rétrospective www.xebia.fr
    • 76. • Toute l'équipe collecte du feedback et discute sur ce qu'elle aimerait Start / Stop / Continue ww.xebia.fr Commencer à faire Arrêter de faire Continuer à faire Juste une façon parmi d'autres de mener une rétrospective.
    • 77. 77 Fin de la 2ème session Questions ? www.xebia.fr
    • 78. 78 3ème session Introduction à eXtreme Programming
    • 79. • L’autre méthodologie dont on parle beaucoup • Comme la plupart des autres méthodes XP est recommandé pour… o Des équipes de tailles petites ou moyennes o Des projets avec de nombreuses zones d’incertitude (risques) o Lorsque les besoins sont vagues ou évoluent rapidement • Adopte des processus issus d’autres méthodologies o E.g. SCRUM, Crystal • A été utilisé ou expérimenté chez… o Daimler-Chrysler, Ford, Capital One, IBM, et beaucoup d’autres Extreme Programming (XP) www.xebia.fr
    • 80. Les valeurs www.xebia.fr Communication leads to valuable feedback which encourages simplicity which allows for courage to change communication courage simplicité feedback respect
    • 81. • Les pratiques découlent des 4 valeurs o Communication, Simplicité, Feedback, Courage o Considérez les comme des « des fonctions de maximisation » • Pratique = Étude o En musique classique, une étude est, à l’origine, une pièce destinée à améliorer certains aspects techniques d’un élève ou d’un interprète o Il arrive de ne pas appliquer toutes les pratiques tout le temps en fonction des projets o Mais l’utilisation répétée des pratiques XP améliore incontestablement les compétences des développeurs et leur capacité à proposer des solutions plus rapidement • Les pratiques procurent les meilleurs résultats lorsqu’elles sont utilisées de façon conjuguée (SYNERGIE) Les pratiques www.xebia.fr
    • 82. Les « cercles de vie » www.xebia.fr On-site Customer Release Planning Small Releases Acceptance Tests Coding Standards Collective Ownership Continuous Integration Metaphor Sustainable Pace Pair Programming Unit Tests Refactoring Simple Design Le client L’équipe Le code L’équipe Le client
    • 83. • Définit les besoins, les fonctionnalités, définit les priorités et de répond aux questions des développeurs • Une interaction quotidienne de vis-à-vis o Réduit la quantité de documentation écrite o Et le coût élevé de sa création et de sa maintenance Client sur site www.xebia.fr
    • 84. • Où « jeu du planning » • Le « client » XP de doit définir la valeur métier des fonctionnalités o User Stories • Les développeurs (pas seulement un CP) estiment les fonctionnalités • A partir de ces informations, le client et les développeurs effectuent une sélection en fonction du ration coût / bénéfice o Permet une priorisation optimale des fonctionnalités Planification de Release www.xebia.fr
    • 85. • Mettre en production un système simple le plus rapidement possible puis appliquer des cycles de livraisons très courts • Exemple o Releaser tous les 2 ou 3 mois o Chaque release contient plusieurs itérations • Établir un « rythme » o Feedback régulier pour le client et l’équipe • Permet d’évaluer la véritable valeur du produit dans son environnement réel Livraisons courtes www.xebia.fr
    • 86. • Où « Test First », « Test Infected » o TESTS D’ACCEPTANCE : on demande aux clients de fournir des tests d’acceptance avant les développements (idéalement automatisés) o TESTS UNITAIRES : les développeurs écrivent d’abord des tests puis créent le logiciel qui répond aux exigences capturées dans les tests • Automatisation, Automatisation, Automatisation, (JUnit, XUnit) [5] o Un développement piloté par les exigences garantit que les fonctionnalités essentielles seront fournies TDD www.xebia.fr
    • 87. • Les développeurs restructurent le système sans en modifier le comportement pour supprimer les duplications, faciliter la communication, simplifier ou améliorer la flexibilité • Petites étapes • Coder, tester, refactorer, tester, coder, refactorer o Beck suggère [1] des cycles de (10 minutes) • Un alignement sur un pattern de conception est un refactoring typique • Basé sur le travail de Martin Fowler [6,7] Refactoring www.xebia.fr
    • 88. • Le code est écrit par 2 développeurs sur 1 seule machine o L’un la tactique, l’autre la stratégie • Le binôme devrait être « dynamique » o Les membres en binôme changent de rôle toutes les 30 à 60 minutes o Et sur tous les types de tâches • L’expérimentation montre une réelle efficacité [8] Programmation en binôme www.xebia.fr
    • 89. • Les bénéfices o Revue de code continue o Partage continu du métier o Amélioration continue des compétences techniques (Java, Design Patterns, Refactoring, IDE…) • Les développeurs on parfois plus de mal avec cette pratique que les managers o Tester pour voir si cela fonctionne o Peut nécessiter un temps d’acclimatation o Expérience du développement plus intense Programmation en binôme www.xebia.fr
    • 90. • Basé sur le principe que la plus haute valeur métier dérive du programme répondant aux besoins courants le plus simple • Pas d’over-engineering ! • K.I.S.S (un concept difficile à appliquer) • 2 philosophies communes d’équipes XP o DTSTTCPW – Do The Simpliest Thing That Could Possibly Work o YAGNI – You Aren’t Gonna Need IT Conception Simple www.xebia.fr
    • 91. • Les développeurs produisent du code en conformité avec des règles favorisant la communication au niveau du code • L’objectif : produire un code auto documenté • La raison : le langage comment est le code • Plus que de la Javadoc; de la bonne Javadoc et des commentaires appropriés Standards de développement www.xebia.fr
    • 92. • La vision de « l’architecture » selon XP • Guide les développements en fournissant une vision commune et unique de la façon dont le système fonctionne • Définit un vocabulaire et guide l’équipe dans les développements et la communication Métaphore www.xebia.fr
    • 93. • Intégrer et construire le système aussi souvent que possible • Intégrer à chaque fois qu’une tâche est finie • Permet de connaître à tout instant le « statut » du système Intégration Continue www.xebia.fr
    • 94. • Tout développeur peut modifier toute portion de code à n’importe quel moment • Ceci est facilité par l’utilisation de Standards de développement, de TDD et de Pair Programming (Synergie) • Sécurise l’équipe en terme de vacances, congés, maladie, turn-over o Les progrès ne s’arrêtent pas sur un composant parce qu’un membre de l’équipe est absent Propriété collective www.xebia.fr
    • 95. • Des développeurs fatigués produisent la plupart du temps un code de moindre qualité • Minimiser les « heures supplémentaires » et conserver une équipe fraîche produit un code de meilleur qualité en moins de temps • 40 – 45 devrait être la règle o Selon les préférences des équipes • Corollaire : ne jamais faire des heures supplémentaires une seconde semaine d’affilée o Éviter le burnout Rythme soutenable www.xebia.fr
    • 96. Synergie www.xebia.fr
    • 97. Cycles de feedback www.xebia.fr
    • 98. • Extrême = continuellement o Revue de code (pair programming) o Tests unitaires o Tests d’intégration o Tests d’acceptance utilisateurs • Pouvez vous satisfaire votre client avec du feedback, de la communication et de la simplicité constante ? • Le feedback procuré par les estimations, les tests, les livraisons fréquentes o Donne confiance aux utilisateurs o Donne confiance à l’équipe o Donne confiance au management Avantages d’XP www.xebia.fr
    • 99. • XP n’est pas une « silver bullet » ! • XP peut ne pas fonctionner pour o Des grosses équipes o Des équipes distribuées o Des systèmes trop complexes o Des projets d’intégration avec du code existant o Des organisations où la méthodologie est particulièrement rigide o Des organisation ou règne la culture du burn-out • Où la valeur d’une personne dépend du temps passé au travail o Des ego sur dimensionnés o Des environnements physiques inappropriés • Mais XP peut être adapté Limitations www.xebia.fr
    • 100. • Le changement culturel peut être difficile pour les développeurs et les managers o Mineurs : rythme soutenable, standards de développement, tests, refactoring o Majeurs : client sur site, jeu de planification, livraisons fréquentes, conception simple o Extrêmes : propriété collective, programmation en binôme, métaphore • Requiert des développeurs expérimentés (mais pas des gurus) • Disposer d’un client sur site n’est pas toujours possible o Manque de disponibilité o Niveau de prise de décision o En rupture avec la culture interne Inconvénients d’XP www.xebia.fr
    • 101. XP mal compris www.xebia.fr
    • 102. Scrum & XP Sprint Planning meeting Daily Scrum Sprint Review Sprint backlog Product backlog TDD Pair programming Refactoring Simple design Coding standard Sustainable Pace Metaphor Continuous Integration Collective ownership Whole team Planning game Small releases Customer tests Burndown chart Product owner Team ScrumMaster Scrum XP
    • 103. Cycles de feedback www.xebia.fr
    • 104. • Ce jeu est appelé le jeu de vélocité. Y avez-vous déjà joué ? o Changez de casquettes 3 fois o Développeurs – estiment o Propriétaires de produit – priorisent en fonction de la valeur métier et du temps o Développeurs – exécutent • Vélocité (1-6, complexité impossible) • Trouvez la story la plus facile et donnez lui la valeur 2 o Vous devriez trouver plus simple dans le futur • Estimez les autres stories relativement à 2 o Pensez complexité ET temps (une story simple peut prendre longtemps) • Il y aura 3 itérations, chacune de 3 minutes o Le temps ne sera décompté que lorsque vous exécuterez les stories. • VOUS NE RÉALISEZ QU’UNE STORY À LA FOIS (ensemble) XP Game www.xebia.fr
    • 105. 105 Fin de la 3ème session Questions ? www.xebia.fr
    • 106. 106 4ème session Piloter un projet Agile
    • 107. Vue d’ensemble Goals Feature Sets Stories Tasks Discovery Planning Release Planning Sprint Planning Daily Standup Define Value. Decide when & how to Deliver Value. Build Value.
    • 108. 108 Gestion des exigences
    • 109. • Le travail est organisé par valeur, pas par couche d’architecture Organisation du travail
    • 110. • Les spécifications complètes : o Assument que tout est connaissable à l’avance o Sont chronophages à rédiger, pénibles à lire o Considèrent l’accumulation de connaissance comme « un changement de périmètre » o Ne distinguent pas l’essentiel du superflu Spécifications détaillées ?
    • 111. • Une User Story, c’est : o Une description de haut niveau d’un but ou d’une fonctionnalité o Une tranche verticale du système • Doit avoir une valeur intrinsèque o Un point de départ pour discuter • Pas une spécification exhaustive Introduction aux User Stories
    • 112. De la User Story aux tâches User Story #023 En tant que nouvel utilisateur, je peux saisir mes informations personnelles Priorité : 1 Estimation : 2 Critères d’acceptance L’adresse est valide dans le référentiel Le numéro de téléphone contient 10 chiffres Le nom et l’adresse email sont obligatoires Tâches Prototyper l’UI Développer le code HTML/CSS Créer les champs dans la base Développer les contrôle métier Ecrire les cas de test Coder les fixtures Tests d’acceptance Tests ergonomiques Rédiger l’aide en ligne
    • 113. • En tant que <acteur>, • je peux <fonctionnalité> • afin de <résultat obtenu> Modèle de User Story Qui, Quoi, Pourquoi… que manque-t-il?
    • 114. • Les critère de validation (acceptance) permettent o de circonscrire le périmètre o de préciser la définition de DONE pour une Story • Focalisez-vous sur l’objectif, pas sur le moyen de l’atteindre Critères de validation En tant qu’abonné, je peux annuler une réservation Un abonné Premium peu annuler le jour même sans frais Un abonné non Premium doit payer des frais de 10% pour une annulation le jour même Un email de confirmation est envoyé à l’abonné L’hôtel est informé de l’annulation
    • 115. Ce qui fait une bonne User Story Bill Wake’s INVEST Independent Negotiable Valuable Estimatable Small Testable Ron Jeffries’ 3 Cs Card Conversation Confirmation
    • 116. • Éviter l’introduction de dépendances o Rendent la priorisation et la planification difficiles Indépendant www.xebia.fr Une entreprise peut payer pour une offre d’emploi avec une carte Visa Une entreprise peut payer pour une offre d’emploi avec une MasterCard Une entreprise peut payer pour une offre d’emploi avec une AmEx
    • 117. Rendre les stories indépendantes www.xebia.fr Combiner les stories Décomposer dans des dimensions différentes Effectuer 2 estimations et passer à autre chose • Un client peut payer avec une carte de crédit. • Un client peut payer avec 1 type de carte de crédit. • Un client peut payer avec 2 autres types de cartes de crédit. • 3 jours si initial; 1 sinon.
    • 118. • Les stories ne sont pas o Des contrats signés, elles peuvent changer o Des exigences auxquelles le logiciel doit répondre • Doivent capturer l’essence, pas les détails • Trop de détails donnent l’impression de o Fausse précision ou complétude o Qu’il n’est plus utile d’en parler • Rester flexible afin de permettre d’ajuster les parties d’une story qui seront implémentées o Si la story est un contrat, alors il faut l’estimer comme un contrat Négociable www.xebia.fr
    • 119. Valorisable www.xebia.fr • Un utilisateur peut effectuer une recherche d’emploi par titre et plage de salaire. • Sur l’intégralité du projet, l’équipe de développement produira de la documentation appropriée pour un audit ISO 9001. • L’équipe de développement produira l’application en accord avec CMM niveau 3 • Toutes les informations de configuration sont lues à partir d’un emplacement central. Utilisateurs Commanditaire
    • 120. • Devraient être réécrites pour exposer leurs bénéfices métiers Stories identifiées par des développeurs www.xebia.fr Toutes les connexions à la base doivent passer par un pool de connexion L’application doit supporter jusqu’à 50 utilisateurs simultanés avec une licence base de données 5 utilisateurs Toutes les erreurs sont présentées à l’utilisateur et loguées d’une façon consistante. Toute la gestion d’erreur et de traces est effectuée au travers un jeu de classes communes.
    • 121. • De nombreux projets assument à tort qu’il n’y a qu’un seul utilisateur o « L’utilisateur » • Rédigent toutes les user stories d’une seule perspective • Assument que tous les utilisateurs ont les mêmes buts • Vous raterez des besoins ! « Embarquez » l’utilisateur dans le backlog www.xebia.fr « En tant que <rôle>, je veux <action> afin que <bénéfices> »
    • 122. • Élargir le point de vue • Permettre aux utilisateurs de varier o Pourquoi ils utilisent le logiciel o Comment ils utilisent le logiciel o Background o Familiarité avec les logiciels / ordinateurs • Définition o Un rôle utilisateur est une collection de définitions d’attributs qui caractérisent une population d’utilisateur et leurs intentions d’interactions avec le système o Technique des Persona Les rôles de l’utilisateur www.xebia.fr
    • 123. • Parce que les stories sont utilisées dans les plannings • Une story peut ne pas être estimable si Estimables www.xebia.fr Les développeurs manquent de connaissances métier Les développeurs manquent de connaissances techniques La story est trop grosse
    • 124. • Les grosses stories (ou épiques) sont o Difficiles à estimer o Difficiles à planifier • Ne rentrent pas facilement dans un unique sprint • Story composée o Une story qui comprend de multiples stories plus courtes • Story complexes o Une story qui est large et ne peut pas être désagrégée facilement Small www.xebia.fr
    • 125. • Cachent souvent un grand nombre de suppositions Stories composées • Un CV inclut des sections séparées pour les diplômes, les emplois précédents, publications,… • Les utilisateurs peuvent désactiver leur CV • Les utilisateurs peuvent avoir de multiples CV • Les utilisateurs peuvent éditer leurs CV • Les utilisateurs peuvent supprimer des CV Un utilisateur peut poster son CV
    • 126. Décomposer une story composée • Un utilisateur peut créer des CV qui incluent diplômes, emplois précédents, historique de salaires, publications, présentations et un objectif • Les utilisateurs peuvent éditer leurs CV • Les utilisateurs peuvent supprimer des CV • Les utilisateurs peuvent avoir de multiples CV • Les utilisateurs peuvent avoir des CV actifs et d’autres inactifs Décomposition suivant les opérations (CRUD)
    • 127. Décomposer une story composée www.xebia.fr • Un utilisateur peut ajouter et éditer ses diplômes sur un CV • Un utilisateur peut ajouter et éditer ses emplois précédents sur un CV • Un utilisateur peut ajouter et éditer ses historiques de salaires sur un CV • Les utilisateurs peuvent supprimer des CV • Les utilisateurs peuvent avoir de multiples CV • Les utilisateurs peuvent avoir des CV actifs et d’autres inactifs Décomposition suivant les données
    • 128. • Les tests démontrent qu’une story répond aux attentes du propriétaire de produit • Essayer des les automatiser à 90+% Testable www.xebia.fr Un utilisateur doit trouver le logiciel simple à utiliser Un utilisateur débutant est capable de terminer un workflow courant sans formation Un nouvel écran est affiché dans les 2s dans 95% des cas Un utilisateur ne doit jamais avoir à attendre longtemps avant l’apparition d’un écran
    • 129. • Vision o The Fantastic Food Finder (FFF) permet aux utilisateurs d’obtenir sur leur téléphone mobile les informations sur les restaurants à proximité, grâce à une interface élégante et performante • Business Case o Les restaurants paieront une petite redevance chaque fois qu’un utilisateur clique sur leur lien o Ils paient également pour être mis en valeur Exercice – Fantastic Food Finder
    • 130. • Rédigez les Users Stories pour FFF o Trouvez-en au moins 12 o Ecrivez les critères de validation pour au moins l’une d’entre elles o Rappelez-vous : • En tant que <acteur> je peux <but immédiat> afin <d’obtenir quelque chose de valable> • Qui sont les acteurs du système ? • Quels sont les workflows ? • Temps total : 20 minutes Exercice
    • 131. • Les User Stories ne sont pas l’unique moyen de gérer les exigences dans un projet agile. D’autres approches : o Essential Use Cases o Low-fidelity prototyping o High-fidelity prototyping • La bonne façon de faire est souvent le résultat de plusieurs essais… Au-delà des User Stories
    • 132. • Comment gérez et communiquez-vous les besoins des utilisateurs sur vos projets? • Quelles méthodes utilisez-vous pour gérer les exigences ? • Les équipes comprennent-elles généralement la valeur de ce qu’elles développent ? Discussion – Vos exigences
    • 133. 133 Estimations Agiles
    • 134. Estimations et probabilités
    • 135. • 2 approches populaires • Story Points o Mesure strictement relative de la complexité o La variabilité est compensée sur le nombre de stories o Ne varie pas dans le temps • Jour de développement Idéal o Autour de 4-5 heures o Lien direct avec le temps idéal Unités d’estimation agiles
    • 136. • Des échelles non linéaires sont généralement préférées: o Fibonacci: 1, 2, 3, 5, 8 o Doubles: 1/2, 1, 2, 4, 8 o “T-Shirt Sizes:” S, M, L, XL • Permet d’être exact sans être trop précis Echelles d’estimations
    • 137. Exercice – Temps de consommation Fruit à consommer Complexité relative Pomme Banane Grappe de raisin Melon Mûre Mangue Framboise Ananas Lychee Pêche
    • 138. • Planning Poker est issu d’une technique d’estimation appelée « Wideband Delphi » • Déroulement : o Chaque estimateur (personne qui devra éventuellement faire le boulot) reçoit un jeu de carte, chaque carte stipulant un poids o Le Product Owner lit la story ; on en discute brièvement o Chaque estimateur choisit un carte (face cachée) o Toutes les cartes sont retournées simultanément o Les différences sont argumentées (extrêmes) o Ré-estimer jusqu’à ce que les estimations convergent (ou abandonner !) Le planning poker
    • 139. Planning Poker - Exemple 5 55Bill 52Ann 58Vijay 33Susan Round 2Round 1Estimateur
    • 140. 140 Planification
    • 141. • « Plans are nothing, planning is everything » • Connaître la contrainte et asservir les décisions à cette contrainte • Utiliser des techniques d'estimation honnêtes o Précision vs exactitude o Fiabilité vs quantité Planifier vs. Suivre un plan
    • 142. Plusieurs niveaux de planification
    • 143. Calculer la vélocité SBPB 8 3 5 5 5 5 8 3 5 5 5 8 3 5 5 Vélocité Estimée = 26 SB 5 8 3 5 5 Fin de sprintDébut de sprint Vélocité actuelle = 18Done! Done! Done! Pas commencé Presque Done!
    • 144. Suivi de la vélocité Velocity over Last Eight Sprints 0 2 4 6 8 10 12 14 16 1 2 3 4 5 6 7 8 Sprint Number Velocity
    • 145. Suivi de la vélocité 40 30 20 10 0 21 3 4 5 6 7 8 9 Moyenne (3 meilleures) = 37 Moyenne (8 dernières) = 33 Moyenne (3 pires) = 28
    • 146. Planification dynamique
    • 147. Intégration du Product backlog et du Burndown chart
    • 148. Release Planning
    • 149. • Description o Session de planning initiale, permettant de passer en revue le backlog initial, et de déterminer les dates des release • Durée o 2-4 heures • Participants o Team, Product Owner, ScrumMaster Release Planning - Aperçu Goals Features Stories Tasks
    • 150. Utiliser les Story Maps Workflow Sequence Priority Access record Review history Provide Nurse ID Provide Patient ID Update record View history Add comment Enter updates Search records Sort records Filter records Search history Reference validation Notify of updatesRELEASE 1 RELEASE 2 • Choisir des groupes cohérents de fonctionnalités couvrant toutes les activités des utilisateurs • Implémenter idéalement toutes les activités dès la première release • Améliorer la couverture de chacune des activités dans les releases suivantes
    • 151. • Une road map permet de communiquer clairement les objectifs business de chacune des releases o Une road map doit être respectée o Utiliser des buffers pour piloter la road map • Buffer de fonctionnalités (70% - 30%) • Buffer de temps (50%) Road Map PB 400 500
    • 152. Investissement incrémental - ROI
    • 153. 153 Fin de la 4ème session Questions ? www.xebia.fr
    • 154. 154 5ème session Sujets avancés
    • 155. 155 Product Owner L’homme orchestre
    • 156. Le proxy Product Owner
    • 157. 157 Montée en charge Gros projets
    • 158. Scalabilité avec un Scrum de Scrums www.xebia.fr
    • 159. Scrum de Scrums de Scrums www.xebia.fr
    • 160. 160 Stratégies de test
    • 161. Tests – Cas idéal www.xebia.fr Sprint 1 Sprint 2 v1.0.0 v1.1.0 Temps Les tests sont réalisés pendant l’itération ! L’objectif est de prévenir l’apparition de défauts
    • 162. Tests – Alternative commune www.xebia.fr Sprint 1 Sprint 2 v1.0.1 v1.1.0 Temps Tests de la 1.0 v1.0.1 Équipe de tests v1.0.0 Bug!
    • 163. 163 Merci www.xebia.fr

    ×