AT Marseille 2011 - Réduisons les gaspillages
•Als PPTX, PDF herunterladen•
1 gefällt mir•1,206 views
Session donnée lors de l'Agile Tour Marseille, le 13 octobre 2011, sur la réduction des gaspillages Pour lutter contre les facteurs de coûts, deux grandes tendances ont émergé du monde de l’industrie : le taylorisme et le lean. Dans le premier cas, on cherche à réduire le cout de main d’oeuvre de la tache, en s’intéressant au TJM le plus bas. Dans l’apporche Lean, on recherche d’abord à réduire les gaspillages tells que la surproduction, l'attente, les pertes de temps dans les tâches sans valeur ajoutée, les développements mal faits, les défauts, et le plus intéressant d'entre eux, les stocks. Nous voyons donc lors de cette conference en quoi ces gaspillages se retrouvent dans le monde de l’informatique, et comment les démarches et pratiques agiles permettent de les réduire.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie AT Marseille 2011 - Réduisons les gaspillages
Ähnlich wie AT Marseille 2011 - Réduisons les gaspillages (20)
AT Marseille 2011 - Réduisons les gaspillages
- 1. Réduisons les gaspillages ! Comment réduire ses coûts de développement grâce aux pratiques agiles ?
- 2. Moi… Jérôme Avoustin .NET, Agilité, Performance @JeromeAvoustin http://blog.avoustin.com Agilité, AMOA, .NET, SharePoint http://www.smartview.fr
- 3. Attention…! Cette session ne parle pas directement du Lean Software Developement 3
- 4. Nos objectifs 1. « Nous voulons délivrer des applications de qualité durablement » 2. « Nous recherchons continuellement la maximisation du ratio Satisfaction utilisateur / Coût » Attaquons-nous aux COÛTS 4
- 5. Comment réduire les coûts ? Le Lean 5
- 6. Comment réduire les coûts ? Le Lean 6
- 7. Les piliers du Lean Qualité++, Sécurité ++, Temps d’écoulement --, Moral ++, Coûts -- JUSTE- A-TEMPS KAIZEN JIDOKA Philosophie, Hommes, Standards, Management visuel 7
- 8. Les piliers du Lean KAIZEN 2 forces : Employés et travail d’équipe Réduction des gaspillages 8
- 9. Qu’est-ce qu’un gaspillage ? • Wikipedia : « Le gaspillage est l'action qui consiste à utiliser une ressource de manière non rationnelle ou à mauvais escient » • Objectifs du Lean o Les identifier o Les réduire, voire les supprimer 9
- 10. Les types de gaspillage dans le Lean • La surproduction • L’attente • Le transport inutile • Le actions inutiles ou répétées • La complexité • Les défauts • Les stocks 10
- 11. Les types de gaspillage dans le Lean • La surproduction • L’attente • Le transport inutile • Le actions inutiles ou répétées • La complexité • Les défauts • Les stocks • La dette 11
- 12. La chasse aux gaspillages Partons à la chasse aux gaspillages ! 12
- 13. La surproduction 60% des fonctionnalités peu ou pas du tout utilisées Conséquence(s) : le ROI tend vers zéro Quels progrès dans l’Agile ? B D E A C YAGNI Prioriser Itérations Kanban 13
- 14. Surproduction et priorisation Priorité + B Changement possible D A Porte de sortie C E I J U R Maximisation M de la valeur produite L Priorité - H sous contrainte 14
- 15. L’attente et les retards MOA DEV TEST CLIENT Conséquences : • Le changement coûte très cher • La rentabilité est elle-même retardée Quels progrès dans l’Agile ? Equipes Itérations Kanban auto-organisées Obeya15
- 16. Attente et Kanban FLUX CONTINU Mesure du temps TAKT Time Henrik Kniberg – Kanban and Scrum 16
- 17. Les actions inutiles ou répétées 17
- 18. Les actions inutiles ou répétées 18
- 19. Les actions inutiles ou répétées Autres actions répétées : • Compilations manuelles • Tests manuels Conséquences : • La rentabilité est également retardée et/ou diminuée • Perte d’informations et apparition de défauts Quels progrès dans l’Agile ? Pilotage par les tests Interactions Intégration Rétrospective directes continue 19
- 20. Les défauts Bugs Fonctionnalités Ergonomie non conformes inadaptée Conséquences : • Augmentation des coûts • Baisse de la qualité Quels progrès dans l’Agile ? Intégration Définition Pilotage par les tests continue Feedback de fini 20
- 21. Les stocks - Les types de stock Stock Stock d’idées de besoins CDC MOA Fonctionnels Stock de conception Stock DSD de spécifications Stock DCT, DAT,... de développements Développeurs Architectes Testeurs Stock Stock de défauts Stock Manuels de documentation Cahier de tests de tests 21
- 22. Histoire d’un projet 10j 8j 20j Temps : J + 0 jours 145 138 123 113 53 38 18 jours 10 jours J+0 J+10 J+18 CDC DSD J+38 15j 10j 60j DCT, DAT,… J+53 J+113 J+123 15j 7j J+138 J+145 22
- 23. Histoire d’une fonctionnalité 10j 8j 20j Temps : J + 0 jours 145 138 123 113 53 38 18 jours 10 jours J+0 J+10 J+18 CDC DSD 2h J+38 15j 2h 0,5j 10j 60j DCT, DAT,… J+53 0,5j J+113 J+123 0,5j 3j 15j 6,5j 1j 7j J+138 0,5j J+145 23
- 24. Histoire d’une fonctionnalité 10j 8j 20j Temps : J + 0 jours 145 138 123 113 53 38 18 jours 10 jours J+0 J+10 J+18 CDC DSD 2h 9,75j 19,5j J+38 15j 2h 7,25j 0,5j 10j 60j DCT, DAT,… J+53 14,5j 0,5j J+113 J+123 0,5j 9,5j 3j 57j 15j 6,5j 1j 7j 14j J+138 138,5j 0,5j 6,5j J+145 24
- 25. Bilan de l’histoire En définitive, le temps passé dans le stock est important Temps utile : 4,5% Temps de Stock : 95,5% • Pour quelle raison ? o Parce que la fonctionnalité est réalisée en même temps que toutes les autres 25
- 26. Pour quelles conséquences ? • Time to Market >= 145 j • La valeur de la fonctionnalité diminue • Les défauts se dissimulent dans les stocks • Ils ne sont souvent découverts que trop tard 26
- 27. Pour quelles conséquences ? • Time to Market >= 145 j • La valeur de la fonctionnalité diminue • Les défauts se dissimulent dans les stocks • Ils ne sont souvent découverts que trop tard 27
- 28. Pour quelles conséquences ? • Time to Market >= 145 j • La valeur de la fonctionnalité diminue • Les défauts se dissimulent dans les stocks • Ils ne sont souvent découverts que trop tard • Le stock engendre un risque important de dépassement de coûts 28
- 29. Les contre-mesures Quels progrès dans l’Agile ? B D E A C Itérations Kanban Prioriser Intégration Pilotage par les tests Feedback continue 29
- 30. La dette – les types de dette Obsolescence Besoins Code Tests
- 31. Exemple : la dette de tests Principal = pas de tests automatisés Intérêts payés : • Temps de correction des bugs • Répétition des tests manuels de non régression • Bugs encore présents en production • Peur du changement, et de la régression ! 31
- 32. Exemple : la dette de tests Principal = pas de tests automatisés Intérêts payés : • Temps de correction des bugs • Répétition des tests manuels de non régression • Bugs encore présents en production • Peur du changement, et de la régression ! Si on ne rembourse pas, on court vers le défaut : C’est la refonte ! Il faut maitriser sa dette ! 32
- 33. Quelles contre-mesures ? Quels progrès dans l’Agile ? Pilotage par les tests Intégration Définition continue de fini Code Review Refactoring Feedback 33
- 34. Conclusion L’Agile permet de réduire les coûts ! 34
- 35. Comment ? B D E A C Itérations Kanban Prioriser 35
- 36. Comment ? Définition Pilotage par les tests Intégration de fini continue Feedback Code Review Refactoring 36
- 37. Comment ? Equipes Interactions auto-organisées Obeya directes Rétrospective 37
- 38. Finalement, 3 conseils Adoptez les Favorisez le Multipliez les cycles itératifs feedback régulier interactions 2 recommandations Réduisez vos Maitrisez gaspillages votre dette 1 mot de la fin MERCI de votre attention ! 38
Hinweis der Redaktion
- Juste à temps : le flux continu en pièce à pièce, le flux tiré, le lissage, etc.Jidoka : « autonomation » : Capacité d’une machine à contrôler automatiquement son bon fonctionnement,arrêt de production au premier défaut
- Juste à temps : le flux continu en pièce à pièce, le flux tiré, le lissage, etc.Jidoka : « autonomation » : Capacité d’une machine à contrôler automatiquement son bon fonctionnement,arrêt de production au premier défaut
- Le plus fondamental des gaspillagesOn investit dans la spécification, la conception, le développement, la recette, la correction de bugs, la maintenance, etc.YAGNI : Ce que l’on ne développe pas ne coûte rienPrioriser par la valeur d’affaire, la satisfaction utilisateur, etc.Développer par itérationPour pouvoir réviser les prioritésPour supprimer les fonctionnalités devenues inutilesPour s’arrêter quand la valeur produite est suffisante
- Le développement a démarré 4 mois après la prise de décisionLes spécifications sont en cours de validationLes testeurs sont en attente d’une version en recetteLes utilisateurs attendent 9 mois qu’une première version de l’application soit disponible
- A chaque étape : REFORMULATION, et donc INTERPRETATION, et donc ERREUREst-ce toujours utile de reformuler autant de fois ?Oui dans certains cas : traçabilité de la fabrication d’un avion
- A chaque étape : REFORMULATION, et donc INTERPRETATION, et donc ERREUREst-ce toujours utile de reformuler autant de fois ?Oui dans certains cas : traçabilité de la fabrication d’un avion
- Coût lié à la détection du défaut, à la correction, à la vérification de la non-régression, au passage en productionFeedback continu : review
- Cycle en V : vérification qui a le + de valeur, faites par le client, le plus tard possible !!
- Cycle en V : vérification qui a le + de valeur, faites par le client, le plus tard possible !!
- Cycle en V : vérification qui a le + de valeur, faites par le client, le plus tard possible !!
- Les cycles itératifsEviter la surproductionDiminuer les impacts des attentes et des retardsRepérer et éliminer les défauts au plus tôt, en réduisant les stocksFavoriser la prise en compte du changement et l’apprentissageLa priorisationNe pas investir dans ce qui n’a pas de valeur
- Le pilotage par les tests, les démonstrations, la notion de « Terminé »Eviter les erreurs d’interprétationApprocher le zéro défautMaitriser sa dette technique en éliminant la peur du changement
- Les équipes auto-organisées, le regroupement géographique, les échanges directsLimiter les attentes et les retardsFavoriser l’apprentissageLes rétrospectives Marginaliser les coûts liées aux tâches répétées