Les Bases des Méthodes Lean/Agile

12 664 vues

Publié le

Six éléments à mettre en place avant de parler agilité ou lean

Publié dans : Business, Technologie
  • Soyez le premier à commenter

Les Bases des Méthodes Lean/Agile

  1. 1. Les Bases des méthodesAgiles<br />Bonne nouvelle: on saitque ca marche en on saitpourquoi.<br />Mauvaise nouvelle: c’est pas facile<br />
  2. 2. Consultant. <br />Project Manager. <br />Games Maker.<br />His Blog: blog.nayima.be<br />NAYIMA<br />We make play work<br />
  3. 3. Les buts<br />Voirquelquesidéesfondamentales des méthodes Agile et Lean<br />Comprendrepourquoicelamarche<br />Comprendrepourquoipeud’équipesréussissent à mettrecela en place<br />
  4. 4. Les Tests<br /> J’aidécouvertune nouvelle idée<br /> Je comprendsmieuxpourquoicelamarche/ne marche pas dansmonéquipe<br /> Je veux en savoir plus<br />
  5. 5. 1<br />
  6. 6. Théorie des Contraintes<br />Des actions locales pour<br />des améliorationsglobales<br />
  7. 7. 9<br />8<br />5<br />7<br />??<br />7<br />7<br />Le maillon faibleLe Goulot d’étranglement<br />
  8. 8. Il ne faut pas courir plus vitequesesutilisateur<br />Backlog<br />Le Goulot<br />The Business<br />Operations<br />Dev team<br />
  9. 9. Il ne faut pas courir plus vitequesesutilisateur<br />Le Goulot<br />Dev team<br />The Business<br />Operations<br />Backlog<br />6 releases <br />per year<br />2 releases <br />per year<br />
  10. 10. Quatre clients vont plus vitequ’un<br />Le Goulot<br />Dev team<br />Backlog<br />Sales<br />Operations<br />Production<br />Finance<br />Audit<br />Customers<br />6 releases <br />per year<br />2 major releases <br />per year per group<br />
  11. 11. I’ln’y a pas de “Business”Il n’y a que “Nous”<br />Dev team<br />Backlog<br />Sales<br />Operations<br />Production<br />Finance<br />Audit<br />Customers<br />6 releases <br />per year<br />2 releases <br />per year per group<br />
  12. 12. DEVOPS<br />
  13. 13. Le Goulot bouge<br />Analyse<br />Design<br />Code<br />Test<br />
  14. 14. Le Goulot bouge<br />Design<br />Analyse<br />Code<br />Test<br />
  15. 15. Le Goulot bouge<br />Code<br />Analyse<br />Design<br />Test<br />
  16. 16. Le Goulot bouge<br />Test<br />Analyse<br />Design<br />Code<br />
  17. 17.
  18. 18.
  19. 19. The Bottleneck Game<br />
  20. 20.
  21. 21.
  22. 22. Oui, mais…<br />
  23. 23. Oui, mais…<br />On estorganisé en départements<br />Chaquedépartement a sespropresobjectifs<br />Les projetssonttellement complexes qu’iln’y a personne qui a la vueglobale<br />
  24. 24. 2<br />
  25. 25. Real Options<br />Déciderquandilfautdécider<br />
  26. 26. Des décisions comme des options<br />Un coût<br />Une valeur<br />Une date d’expiration<br />On prend les décisions difficiles à défaire tard<br />On prend les décisions faciles à défaire tôt<br />
  27. 27. Planification Real Options<br />Option<br />Option<br />On attend...<br />Option<br />Décision 2<br />Deadline<br />Décision 3<br />Décision 1<br />
  28. 28. Repousser les décisions<br />Option<br />Option<br />On attend...<br />Option<br />Décision 2<br />Deadline<br />Décision 3<br />Décision 1<br />
  29. 29. Repousser les décisions<br />Option<br />Option<br />On attend...<br />Option<br />Décision 2<br />Deadline<br />Décision 3<br />Décision 1<br />
  30. 30. Repousser les décisions<br />Option<br />Option<br />On attend...<br />ET on cherche plus d’info<br />Option<br />Décision 2<br />Deadline<br />Décision 3<br />
  31. 31. Une histoire belge<br />Redesign du site d’une chaine télé<br />
  32. 32. Redesign du site télé<br />Date de livraison fixe: Site web doit être prêt avant Novembre<br />On a un design/style existant<br />“Il y aura un re-design de la chaine”<br />Donc, il faudra un re-design de tous les sites<br />
  33. 33.
  34. 34. Q: qu’est-ce qu’on fait?<br />A: Continuer avec ancien design, puis retravaillerB: Attendre le nouveau design<br />
  35. 35.
  36. 36. Appliquons Real Options<br />Implementation Ancien Design<br />Site sans design<br />Implementation Nouveau Design<br />1 Octobre<br />1 Septembre<br />1 Aout<br />
  37. 37. Réduction du temps d’implementation<br />Implementation Ancien Design<br />Site sans design<br />Implementation Nouveau Design<br />1 Octobre<br />1 Septembre<br />1 Aout<br />
  38. 38. Résultat<br />Plein de discussion sur le design (plusieurs mois)<br />Un équipier suit le progrès<br />Décision du 1er Septembre: ancien design<br />Site et application livré à temps<br />“On a jamais vécu un projet avec si peu de stress”<br />On a séparé la partie connue de la partie sous discussion<br />“Ceci sera notre approche pour tous les projects suivants”<br />
  39. 39. Excellence technique<br />Réduit le temps d’implementation et retarde les dates de décision<br />Rend plus de décisions faciles à défaire <br />
  40. 40. Oui, mais…<br />
  41. 41. Oui, mais…<br />“Je préfèreunemauvaisedécisionplutôtque pas de décision”<br />“Je n’aime pas l’incertitude”<br />“J’aiappris à prendre les décisionsarchitecturales le plus tôt possible”<br />“On ne réussit plus à changer notre code ou architecture”<br />
  42. 42. 3<br />
  43. 43. Valeur<br />Réduire les coûtsc’est facile,<br />maisça ne dure pas<br />
  44. 44. Project Economic Framework<br />
  45. 45. PDCA cycle<br />
  46. 46. Business Value Modelling<br />
  47. 47.
  48. 48.
  49. 49. Prioritisation par Valeur<br />TODO<br />BUSY<br />RFT<br />DONE<br />Iteration<br />Release<br />Value<br />
  50. 50. Compagnie de téléphonie<br />Situation<br />2 mois d’analyse<br />“Il faut 60 features”<br />“Il faut une application web self-service avec architecture SOA”<br />Ca va prendre +/- 2 ans<br />Résultat<br />3 jours d’analyse Agile<br />Seulement 10 des 60 features apportent de la valeur<br />On a identifié 4 features qu’ils avaient oubliés<br />25% de la valeur pouvait être livrée dans deux mois (sans application web...)<br />
  51. 51. Oui, mais…<br />
  52. 52. Oui, mais…<br />“On n’a pas le temps”<br />“Impliquertoutel’équipeest un gachis de temps”<br />“Il n’y a pas moyen de définir la valeur”<br />“Notre but est de réduire les coûts”<br />
  53. 53. 4<br />
  54. 54. Autonomie<br />
  55. 55.
  56. 56.
  57. 57.
  58. 58. Et moi? <br />Je fais quoi?<br />
  59. 59. Challenge Respectueux<br />Buts et stratégie<br />Aider / Coacher / Former<br />Challenger<br />
  60. 60.
  61. 61. Oui, mais…<br />
  62. 62. Oui, mais…<br />“Ilsvontprendre les tâchesfaciles”<br />“Ils ne vontrien faire si je ne leurdis pas quoi faire”<br />“Il n’y a pas de managers dans Agile”<br />“On varien demander aux managers, car ilsvontprendre la mauvaisedécision”<br />“Les développeurssurestimenttoujours, donc je diviseleurs estimations par 4”<br />
  63. 63. 5<br />
  64. 64. L’excellence technique<br />Difficile d’être agile dans un marais<br />
  65. 65.
  66. 66. Pratiques de Qualité<br />Tests d’acceptanceavant le code<br />Tests unitairesavant le code<br />Refactoring continu<br />Conception Simple<br />Binomage<br />Design/code Guidelines<br />
  67. 67.
  68. 68.
  69. 69. Un experiment<br />Même équipe<br />Même application<br />Même langage<br />Même client<br />Sans TDD => 2/3 de la vitesse de développement<br />
  70. 70. Oui, mais…<br />
  71. 71. Oui, mais…<br />“On n’a pas le temps d’écrire du bon code, car on passe tout notre temps à corriger des bugs”<br />“Les testeursn’ont pas fait leurboulot”<br />“C’estdevenutropcompliqué, faudraréécrire”<br />“Ecrire des tests prendtrop de temps”<br />“Il faut de la discipline”<br />
  72. 72. 6<br />
  73. 73.
  74. 74.
  75. 75. The Logical Thinking Process<br />
  76. 76. The Logical Thinking Process<br />Intermediate Objectives Map<br />Prerequisite/<br />Transition Tree<br />Comment y arriver?<br />Par petits pas<br />Quel est notre but?<br />Qu’est-ce qu’on manque?<br />Future Reality Tree<br />Current Reality Tree<br />Est-ce que cela marchera?<br />Quels nouveau problèmes<br />Est-ce qu’on va créer?<br />Pourquoi est-ce qu’on manque quelque chose?<br />Conflict Resolution Diagram<br />Qu’est-ce qu’on pourrait faire<br />pour résoudre le conflit sous-jacent?<br />
  77. 77. Et moi? <br />Je peux jouer?<br />
  78. 78.
  79. 79. “Amélioration Continue”?<br />
  80. 80. Amélioration Continue<br />
  81. 81.
  82. 82. Challenge Respectueux<br />Buts et stratégie<br />Aider / Coacher / Former<br />Challenger<br />
  83. 83. Oui, mais…<br />
  84. 84. Oui, mais…<br />“On va pas changer la documentation du processus”<br />“On n’ose pas faire les changementsqu’ilfaut”<br />“On n’a pas le temps d’implementer les actions de la retrospective”<br />“On n’ose pas parler des vraisproblèmes”<br />“On a peur des conflits”<br />
  85. 85. En résumé<br />
  86. 86. En résumé<br />Théorie des Contraintes<br />Real Options<br />Définir la Valeur économique<br />Autonomie de l’équipe et du management<br />Excellence Technique<br />Systems Thinking<br />
  87. 87. Les Tests<br /> J’aidécouvertune nouvelle idée<br /> Je comprendsmieuxpourquoicelamarche/ne marche pas dansmonéquipe<br /> Je veux en savoir plus<br />
  88. 88. Si vousvoulez en savoir plus<br />
  89. 89. Merci<br />Thank You<br />Dank u<br />

×