Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Les Bases des Méthodes Lean/Agile

12,978 views

Published on

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

Published in: Business, Technology
  • Be the first to comment

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 />

×