Agile - Que le choc commence !

1,365 views
1,250 views

Published on

Introduction à l’Agilité

Scrum, ScrumMaster, User Stories, Backlog… Ces mots vous sont peut-être familiers ? En vogue depuis plusieurs années, l’Agilité est en expansion rapide sur les projets informatiques.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,365
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Agile - Que le choc commence !

  1. 1. Martin Lapointe, PMP, ScrumMaster 1
  2. 2. Martin Lapointe 12 ans d’expérience en gestion de projets (PMBOK et Agiles) 2
  3. 3. 2009 Certification ScrumMaster complétée2008 Certification PMP complétée2003 Maîtrise courte en Technologie de l’informationExpériences:  e-learning (Pharmaceutiques Américaines)  Site Web de médias  Sites e-commerce  Plateformes SOA et géo-positionnement  Applications bancaires  Portail télécom avec portion BI  Responsable Assurance Qualité Processus - Banque 3
  4. 4.  Agilité, un peu d’histoire Une définition Les valeurs Agiles Le jargon de cette nouvelle organisation La logique Scrum L’ingénierie logicielle Ce que l’on en dit… Les objections Etapes suivantes 4
  5. 5. Mais c’est quoi l’Agilité ?Quelques synonymes : alerte, habile, léger, rapide, souple, vif…C’est un contenant de valeurs ! Agile (Valeurs)Avec entre autre : Scrum pour le pilotage Scrum (Pilotage XP pour l’ingénierie logicielle Projet) XP (Ingénierie) 5
  6. 6. Les 4 valeurs du développement Agile : Individus et échanges plus que processus et outils. Produit fonctionnel plus que documentation. Collaboration du client plus que négociation du contrat. Réactivité au changement plus que suivi dun plan.+ Les 12 principes du développement Agile 6
  7. 7. Un résumé : Un client à satisfaire Basé sur l’humain et la communication verbale Focus sur une partie limitée et maîtrisable Périodes de durées fixes Livraison dun produit fonctionnel Qualité implicite et non-négociable Adaptation rapide au changement 7
  8. 8. Fixe Charge Délai Coût Développement logiciel AgileNégociable Développement logiciel traditionnel Délai Coût Charge 8
  9. 9. 9
  10. 10.  Le terme Scrum :  Est emprunté au rugby et signifie mêlée. Il représente :  Une équipe soudée, qui cherche à atteindre un but, pour faire avancer le ballon pendant une mêlée. 10
  11. 11. 11
  12. 12. Le travail à réaliser est découpé en incréments appelés « User Stories »Le format : En tant que <rôle> Je veux <faire quelque chose> Dans le but de <obtenir de la valeur> 12
  13. 13.  Une User Story représente:  Le besoin d’un usager  La description d’une fonctionnalité  Un item de planification  Un élément de conversation Point de vue adopté non technique pour identifier la valeur métier (Business value). Aspect narratif (voici ce qui se passe). 13
  14. 14.  Une bonne User Story respecte le principe "INVEST":  I – Independent (Indépendant)  N – Negotiable (Négociable)  V – Valuable (Apporte de la valeur)  E – Estimable (Estimable)  S – Small (Petit)  T –Testable (Testable) 14
  15. 15. Un Product Backlog c’est : Le regroupement des fonctionnalités à réaliser. La compilation de toutes les User Stories par Epic. Une priorisation par la Business value. 15
  16. 16. Le Sprint Backlog c’est : Une sélection de User Stories, priorisée par le client, qui seront à réaliser dans un Sprint. Les éléments les plus importants qui représentent une valeur ajoutée. Des Users Stories découpées en tâches et estimées par l’équipe. 16
  17. 17. Le burndown c’est : Un affichage graphique de la consommation des tâches du projet pour piloter la santé du Sprint. 17
  18. 18. Un Scrum Board avec beaucoup de Post-it 18
  19. 19. 19
  20. 20. Product Owner (PO) Le Product Owner est le représentant des clients et des utilisateurs. Son objectif est de maximiser la valeur du produit développé.  Il rédige les User Stories et prépare le Backlog.  Il définit lordre dans lequel les fonctionnalités seront développées.  Il prend les décisions importantes.  Il valide les développements. 20
  21. 21. ScrumMaster Le ScrumMaster est responsable de la méthode. Ce nest pas un Chef de projets, c’est un facilitateur. Parmi ses attributions :  Fait disparaître les obstacles !  Communiquer la vision et les objectifs à léquipe.  Apprendre au PO à rédiger le Backlog.  Faciliter les rituels de Scrum.  Coacher léquipe de développement.  Aider à ladoption de l’Agilité au niveau de lentreprise. 21
  22. 22. Membres de l’équipe Léquipe est auto-gérée et pluridisciplinaire.  Il ny a pas de notion de hiérarchie interne : toutes les décisions sont prises ensemble.  Léquipe sadresse directement au PO.  Une équipe agile est composée de 7+/- 2, donc entre 5 et 9 personnes max.  Une équipe pluridisciplinaire comporte toutes les compétences suivantes: ▪ Développeurs logiciel et progiciel ▪ Testeur ▪ Intégrateur Frontend ▪ Architecte technique et de solution ▪ Architecte de l’information ▪ DBA 22
  23. 23. 23
  24. 24. Sprint Planning Requis :  Toute l’équipe 100% disponibles  le Backlog priorisé  les User Stories « Ready » à expliquer à l’équipe  Les scénarios de tests Léquipe négocie le Sprint avec le PO, estime les User Stories du Sprint et planifie les tâches en équipe. 24
  25. 25. Daily Scrum – Stand-up  Au quotidien, le stand-up, permet à l’équipe de faire un point sur les tâches en cours et sur les difficultés. Cette réunion dure 15 minutes maximum. Cette réunion a pour but la synchronisation de léquipe.  A tour de rôle, chaque membre répond à 3 questions : ▪ Quest-ce que jai fait hier ? ▪ Quest-ce que je compte faire aujourdhui ? ▪ Quelles sont les difficultés que je rencontre ? 25
  26. 26. La DémoTout le monde participe Objectif : valider le logiciel développé pendant le Sprint. Léquipe effectue une démo à son auditoire. Feedback des participants. 26
  27. 27. Rétrospective du Sprint Faite en interne avec léquipe par le ScrumMaster. Objectif :  Comprendre ce qui s’est passé dans le Sprint ▪ les gains, succès ▪ les erreurs, problèmes  Prendre des décisions pour saméliorer au prochain Sprint. 27
  28. 28.  Une équipe Agile planifie un produit par couches. Les couches sont les caractéristiques ou des fonctionnalités du produit. Les couches seront ajoutées de façon itérative. Rérérence: Jeff Patton, www.AgileProductDesign.com 28
  29. 29.  L’évolution itérative en Scrum. Un produit complet intégrant le changement à chaque itération. L’approche incrémentale demande de formaliser l’idée avec des estimés et exigences.Rérérence: Jeff Patton, www.AgileProductDesign.com 29
  30. 30. Développement d’un site d’emploi Source: Pyxis - http://fr.slideshare.net/p yxistech/iiba-story- mapping-jscv2-12286011 30
  31. 31.  Estimation : durant le Sprint planning l’équipe va utiliser le Poker Planning. Consiste à attribuer des points de complexité. Une valeur de référence sera attribuée à une User Story. L’équipe vote avec des cartes spéciales. http://www.mountaingoatsoftware.com/topics/planning-poker 31
  32. 32.  User Stories complétées = points Evaluer une vélocité sur plusieurs Sprints. Sur le long terme la vélocité va se stabiliser : Sprint 0 Sprint 1 Sprint 2 Sprint 3 10 points 20 points 25 points 26 points 32
  33. 33.  Prochaine étape = Release Planning à grande échelle  Technique : Story mapping tempsnécessaire première releasePlus ou deuxième release optionnalité moins optionel troisième release Rérérence: Jeff Patton, www.AgileProductDesign.com 33
  34. 34.  Le Scrum est avant tout dédié à la gestion de projets. L’équipe de développement doit s’organiser autour des principes de développement XP. 34
  35. 35. Les principes XP1. Client sur site2. Jeu du Planning ou Planning poker3. Intégration continue4. Petites livraisons5. Rythme soutenable6. Tests de recette (ou tests fonctionnels)7. Tests unitaires8. Conception simple9. Utilisation de métaphores10. Refactoring (ou remaniement du code)11. Appropriation collective du code12. Convention de nommage13. Programmation en binôme 35
  36. 36.  Trop souvent, l’Agilité fait face à la pensée magique mais…  Non, ça ne va pas coûter moins cher pour la même chose  Non, ça ne va pas prendre moins de temps pour la même chose  Non, on ne parle plus d’exigences 36
  37. 37. Avantages du Scrum Entièrement développé et testé pour de courtes itérations Simplicité des processus Règles définies clairement Augmentation de productivité Organisation personnelle Chaque équipe a son lot de responsabilités Amélioration de la communication 37
  38. 38. Difficultés reliées au Scrum Changement, Changement, Changement. Change les habitudes, peut déstabiliser plusieurs. Rend visible les maillons faibles très rapidement, ce qui crée de la résistance au changement. Trouver un équilibre entre anticipation et adaptation. Pas de garanties au delà du Sprint. L’incompréhension de la disparition des specs traditionnelles pour des User Stories. 38
  39. 39. Pourquoi une entreprise passerait au Scrum ? Time to market ! Livrer des itérations de produits plus rapidement et devancer la compétition. Eviter le développement de fonctionnalité inutiles ($$). Elimine les périodes de stabilisations ($$) puisque chaque Sprint livre en Production. 39
  40. 40. 40
  41. 41.  Nous travaillons sur un système complexe, nous devons faire l’architecture en premier.  En scrum, le focus est mis sur une architecture émergeante mais rien n’empêche de mettre en place une base en place et trouver un équilibre entre anticipation et adaptation. Ecrire les tests en premier prend plus de temps et je n’ai pas de temps à perdre.  Il est évalué que faire les tests en premier prend environ 15% plus de temps. Par contre des études faites chez Microsoft ont aussi démontrés que les bugs étaient en déclin de 24 à 38%. Scrum, c’est trop de réunions !  En effet la pratique de Scrum engendre un certain nombre de réunions, et que ces dernières mobilisent toute l’équipe. Toutes les réunions sensibilisent et responsabilisent au projet l’équipe. De plus elles sont structurées, timeboxées (limitées dans le temps), et ont un but précis connus de tous les participants. C’est mon code, je ne veux pas fixer les bugs des autres.  Personne ne veut mal paraître en face des autres. Il est reconnu que les équipes qui pratique les « collective ownership » écrivent du code plus propre et avec moins de bugs. 41
  42. 42. Mike Cohn mountaingoatsoftware.com/scrumKen Schwaber controlchaos.comManifeste Agile agilemanifesto.orgAgile Alliance agilealliance.comScrum Alliance scrumalliance.org 42

×