Réduisons les gaspillages !<br />Comment réduire ses coûts de développement<br />grâce aux pratiques agiles ?<br />
Notre objectif<br />« Nous voulons délivrer des applications de qualité durablement »<br />« Nous définissons la qualité c...
Comment réduire les coûts ?<br />Le Lean<br />3<br />
Comment réduire les coûts ?<br />Le Lean<br />4<br />
Les 3 piliers du Lean<br />Le Juste à Temps : « Conserver les stocks nécessaires à chaque étape de la fabrication au plus ...
Qu’est-ce qu’un gaspillage ?<br />Wikipedia : « Le gaspillage est l'action qui consiste à utiliser<br />une ressource de m...
Quels sont les objectifs affichés ?<br />Industrialiser pour marginaliser certains coûts<br />Augmenter l’efficacité opéra...
Les types de gaspillage dans le Lean<br />La surproduction<br />L’attente<br />Le transport<br />Le travail mal exécuté ou...
La chasse aux gaspillages<br />Partons à la chasse aux gaspillages !<br />9<br />
La surproduction<br />Le plus fondamental des gaspillages<br />Constat dans le développement<br />60% des fonctionnalités ...
L’attente et les retards<br />Comment cela se caractérise-t-il ?<br />Les spécifications sont en cours de validation<br />...
Les actions inutiles ou répétées<br />12<br />
Les actions inutiles ou répétées<br />13<br />
Les actions inutiles ou répétées<br />Autres types d’actions inutiles ou répétées<br />Les compilations manuelles,<br />Le...
Les défauts<br />Peuvent être de tout type, et intervenir à tout moment<br />Bugs (de fonctionnement, de sécurité, etc.)<b...
Les stocks – Les types de stock dans le développement<br />Stock<br />d’idées<br />Stock<br />de besoins<br />CDC<br />MOA...
Les stocks – Les types de stock dans le développement<br />Stock<br />d’idées<br />Stock<br />de besoins<br />MOA<br />Fon...
Les stocks – Histoire d’un projet<br />Temps : J +<br />0 jours<br />10 jours<br />18 jours<br />38 jours<br />53 jours<br...
Les stocks – Histoire d’une fonctionnalité<br />Temps : J +<br />0 jours<br />10 jours<br />18 jours<br />38 jours<br />53...
Les stocks – Bilan de l’histoire<br />En définitive, le temps passé dans le stock est important<br />Pour quelle raison ?<...
Les stocks – Pour quelles conséquences ?<br />L’investissement consacré n’est potentiellement rentable qu’au bout de 145 j...
Les stocks – Les pistes d’amélioration<br />Quelles pistes d’amélioration apporte l’Agile ?<br />L’itération, associée à l...
La dette – Principes d’une dette<br />Ce que contient un stock induit un coût de possession<br />Ce coût s’apparente à une...
La dette – Les types de dette technique<br />La dette d’obsolescence<br />Utilisation d’anciennes versions de technologies...
La dette – Exemple : la dette de tests<br />Au fur et à mesure qu’on ajoute des fonctionnalités sans<br />tests automatiqu...
La dette – Exemple : la dette de tests<br />Au fur et à mesure qu’on ajoute des fonctionnalités sans<br />tests automatiqu...
Conclusion<br />L’Agile permet de réduire les coûts !<br />Comment ?<br />27<br />
Comment ?<br />Les cycles itératifs<br />Eviter la surproduction<br />Diminuer les impacts des attentes et des retards<br ...
Comment ?<br />Les équipes auto-organisées, le regroupement<br />	géographique<br />Favoriser les échanges directs<br />Li...
Finalement,<br />3conseils<br />Adoptez les cycles itératifs<br />Favorisez l’apprentissage<br />Multipliez les interactio...
Prochain SlideShare
Chargement dans…5
×

Réduisons les gaspillages

2 388 vues

Publié le

Slides de la conférence donnée lors de l'Agile Tour 2010 à Vannes.
L'objectif de la conférence est d'expliquer en quoi les pratiques agiles permettent de réduire les coûts de développement.

Publié dans : Business, Technologie
0 commentaire
3 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
2 388
Sur SlideShare
0
Issues des intégrations
0
Intégrations
45
Actions
Partages
0
Téléchargements
1
Commentaires
0
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • A chaque étape : REFORMULATION, et donc INTERPRETATION, et donc ERREUREst-ce toujours utile de reformuler autant de fois ?Oui dans certains cas : fabrication d’un avion, en cas de crash
  • A chaque étape : REFORMULATION, et donc INTERPRETATION, et donc ERREUREst-ce toujours utile de reformuler autant de fois ?Oui dans certains cas : fabrication d’un avion, en cas de crash
  • Réduisons les gaspillages

    1. 1. Réduisons les gaspillages !<br />Comment réduire ses coûts de développement<br />grâce aux pratiques agiles ?<br />
    2. 2. Notre objectif<br />« Nous voulons délivrer des applications de qualité durablement »<br />« Nous définissons la qualité comme la maximisation du ratio<br />Satisfaction utilisateur / Coût<br />Attaquons-nous aux<br />COÛTS<br />2<br />
    3. 3. Comment réduire les coûts ?<br />Le Lean<br />3<br />
    4. 4. Comment réduire les coûts ?<br />Le Lean<br />4<br />
    5. 5. Les 3 piliers du Lean<br />Le Juste à Temps : « Conserver les stocks nécessaires à chaque étape de la fabrication au plus faible niveau possible, idéalement nul »<br />Les stocks coutent de l’argent<br />Les stocks diminuent la valeur de l’élément stocké <br />Les stocks dissimulent les défauts : la ligne de flottaison<br />L’« Autonomation » (Jidoka) : Autonome + Automatisation<br />Capacité d’une machine à contrôler automatiquement son bon fonctionnement <br />Permet de construire la qualité intrinsèque<br />Ne pas reléguer le test à la fin<br />La chasse aux gaspillages (Muda)<br />5<br />
    6. 6. Qu’est-ce qu’un gaspillage ?<br />Wikipedia : « Le gaspillage est l'action qui consiste à utiliser<br />une ressource de manière non rationnelle ou à mauvais escient »<br />Objectifs du Lean<br />Les identifier<br />Diminuer leur impact<br />Les supprimer<br />Qualité totale<br />Réduisons les gaspillages !<br />6<br />
    7. 7. Quels sont les objectifs affichés ?<br />Industrialiser pour marginaliser certains coûts<br />Augmenter l’efficacité opérationnelle des équipes<br />Réduire de manière drastique les coûts<br />7<br />
    8. 8. Les types de gaspillage dans le Lean<br />La surproduction<br />L’attente<br />Le transport<br />Le travail mal exécuté ou inadapté<br />La complexité<br />Les défauts<br />Les stocks<br />8<br />
    9. 9. La chasse aux gaspillages<br />Partons à la chasse aux gaspillages !<br />9<br />
    10. 10. La surproduction<br />Le plus fondamental des gaspillages<br />Constat dans le développement<br />60% des fonctionnalités sont très rarement ou pas du tout utilisées<br />Quel pourcentage chez vous ?<br />Quelles conséquences ?<br />On investit dans des fonctionnalités inutiles<br />La spécification, la conception, le développement, la recette, la correction de bugs, la maintenance, etc.<br />Pour un bénéfice nul !<br />Quels progrès offrent l’Agile ?<br />Ce que l’on ne développe pas ne coûte rien : YAGNI<br />Prioriser<br />Par la valeur d’affaire, la satisfaction utilisateur, etc.<br />Développer par itération<br />Pour pouvoir réviser les priorités<br />Pour supprimer les fonctionnalités devenues inutiles<br />Pour s’arrêter quand la valeur produite est suffisante<br />10<br />
    11. 11. L’attente et les retards<br />Comment cela se caractérise-t-il ?<br />Les spécifications sont en cours de validation<br />Les testeurs sont en attente d’une version en recette<br />Le développement a démarré 4 mois après la prise de décision<br />Les utilisateurs attendent 9 mois qu’une première version de l’application soit disponible<br />Quelles conséquences ?<br />Le changement est pris en compte difficilement et à un coût élevé<br />La rentabilité de l’investissement est retardée, voire annulée<br />Quels progrès dans l’Agile ?<br />Travailler par itération :<br />Réduction de l’attente<br />Obeya : salle de guerre<br />Regroupement géographique<br />Equipes auto-organisées<br />11<br />
    12. 12. Les actions inutiles ou répétées<br />12<br />
    13. 13. Les actions inutiles ou répétées<br />13<br />
    14. 14. Les actions inutiles ou répétées<br />Autres types d’actions inutiles ou répétées<br />Les compilations manuelles,<br />Les tests manuels (unitaires, non régression,…), etc.<br />Quelles conséquences ?<br />Perte évidente de temps, et donc retard dans la rentabilité de l’investissement<br />Perte de l’information et apparition de défauts<br />Le papier élu « pire moyen de communication »<br />Quels progrès trouve-t-on dans l’Agile ?<br />Le pilotage par les tests<br />Favoriser les interactions directes<br />L’intégration continue<br />Les rétrospectives<br />Composante essentielle du cycle d’amélioration continue <br />PDCA : Roue de Deming<br />14<br />
    15. 15. Les défauts<br />Peuvent être de tout type, et intervenir à tout moment<br />Bugs (de fonctionnement, de sécurité, etc.)<br />Fonctionnalités non conformes<br />Ergonomie non adaptée (nombre de clic, performance, messages inadaptés etc.)<br />Quelles conséquences ?<br />Coût lié à la détection du défaut, à la correction, à la vérification de la non-régression, au passage en production<br />Diminution de la rentabilité de l’investissement<br />Quels progrès apporte l’Agile ?<br />Le pilotage par les tests (TDD, User Stories, spécifications exécutables)<br />La notion de « Terminé »<br />Garde-fou de la qualité dans l’Agile<br />Les démonstrations fréquentes<br />L’intégration continue<br />15<br />
    16. 16. Les stocks – Les types de stock dans le développement<br />Stock<br />d’idées<br />Stock<br />de besoins<br />CDC<br />MOA<br />Fonctionnels<br />Stock<br />de conception<br />Stock<br />de spécifications<br />DSD<br />DCT, DAT,...<br />Développeurs<br />Architectes<br />Stock<br />de développements<br />Testeurs<br />Manuels<br />Stock<br />de tests<br />Stock<br />de défauts<br />Stock<br />de documentation<br />Cahier de tests<br />16<br />
    17. 17. Les stocks – Les types de stock dans le développement<br />Stock<br />d’idées<br />Stock<br />de besoins<br />MOA<br />Fonctionnels<br />Stock<br />de conception<br />Stock<br />de spécifications<br />Développeurs<br />Architectes<br />Stock<br />de développements<br />Testeurs<br />Stock<br />de tests<br />Stock<br />de défauts<br />Stock<br />de documentation<br />17<br />
    18. 18. Les stocks – Histoire d’un projet<br />Temps : J +<br />0 jours<br />10 jours<br />18 jours<br />38 jours<br />53 jours<br />113 jours<br />123 jours<br />138 jours<br />145 jours<br />8j<br />20j<br />10j<br />15j<br />60j<br />10j<br />15j<br />7j<br />J+0<br />J+10<br />J+18<br />J+38<br />CDC<br />DSD<br />DCT, DAT,…<br />J+53<br />J+113<br />J+123<br />J+138<br />J+145<br />18<br />
    19. 19. Les stocks – Histoire d’une fonctionnalité<br />Temps : J +<br />0 jours<br />10 jours<br />18 jours<br />38 jours<br />53 jours<br />113 jours<br />123 jours<br />138 jours<br />145 jours<br />8j<br />20j<br />10j<br />15j<br />60j<br />10j<br />15j<br />7j<br />J+0<br />J+10<br />J+18<br />2h<br />2h<br />0,5j<br />0,5j<br />3j<br />0,5j<br />1j<br />0,5j<br />19,5j<br />14,5j<br />57j<br />9,5j<br />14j<br />6,5j<br />J+38<br />7,25j<br />9,75j<br />6,5j<br />138,5j<br />CDC<br />DSD<br />DCT, DAT,…<br />J+53<br />J+113<br />J+123<br />J+138<br />J+145<br />19<br />
    20. 20. Les stocks – Bilan de l’histoire<br />En définitive, le temps passé dans le stock est important<br />Pour quelle raison ?<br />Parce que la fonctionnalité est réalisée en même temps que toutes les autres, formant ainsi<br />un lot,<br />un palier,<br />une version…<br />Temps utile : 4,5%<br />Temps de Stock : 95,5%<br />20<br />
    21. 21. Les stocks – Pour quelles conséquences ?<br />L’investissement consacré n’est potentiellement rentable qu’au bout de 145 jours<br />Pendant toute la durée du temps de stock, la valeur de la fonctionnalité a diminué<br />Les défauts ne sont détectés qu’à la fin !...<br />… Et se sont potentiellement dissimulés dans la plupart de stocks !<br />Le stock engendre un risque très important de dépassement des coûts<br />Défauts<br />Inadéquation de l’application au besoin<br />21<br />
    22. 22. Les stocks – Les pistes d’amélioration<br />Quelles pistes d’amélioration apporte l’Agile ?<br />L’itération, associée à la priorisation<br />Le pilotage par les tests, associée aux démonstrations<br />Le design incrémental : KISS<br />Principes de l’itération<br />C’est une durée fixe<br />Par Exemple : 2 semaines<br />C’est une durée fixe !!<br />En anglais : une Timebox<br />Ce que livre l’équipe peut potentiellement être mis en production<br />L’équipe s’engage<br />En début d’itération,…<br />Sur les fonctionnalités à livrer au bout de l’itération,…<br />Mais…<br />…C’est une durée fixe !!!!<br />Une itération n’est pas un lot<br />22<br />
    23. 23. La dette – Principes d’une dette<br />Ce que contient un stock induit un coût de possession<br />Ce coût s’apparente à une dette<br />Principes d’une dette :<br />Un capital est emprunté : c’est le principal<br />Tout au long de la période d’emprunt, des intérêts sont payés<br />Si on veut éviter le surendettement, il faut aussi rembourser du principal<br />Deux types de dettes :<br />La mauvaise dette<br />Le capital emprunté sert à financer ce qui ne présente aucune valeur<br />La bonne dette<br />L’investissement est utilisé pour créer de la valeur<br />Avoir de la dette n’est pas une mauvaise chose…<br />…Mais il faut maîtriser sa dette<br />Eliminer la mauvaise dette au profit de la bonne dette<br />Rembourser continuellement le principal, et limiter les intérêts à payer<br />23<br />
    24. 24. La dette – Les types de dette technique<br />La dette d’obsolescence<br />Utilisation d’anciennes versions de technologies<br /> ou de frameworks<br />La dette de qualité de code<br />Qualité de code médiocre, dont l’amélioration est remise au lendemain<br />La dette de tests<br />Ensemble des tests unitaires et de non régression non automatisés<br />La dette de fonctionnalités<br />Ensemble des fonctionnalités encore non implémentées et non prioritaire<br />24<br />
    25. 25. La dette – Exemple : la dette de tests<br />Au fur et à mesure qu’on ajoute des fonctionnalités sans<br />tests automatiques, on augmente le principal<br />On contracte ainsi une dette de tests<br />Tout au long du développement, on paye les intérêts suivants :<br />Temps de correction de bugs<br />Tests manuels répétés (non régression)<br />Bugs encore présents après la mise en production<br />25<br />
    26. 26. La dette – Exemple : la dette de tests<br />Au fur et à mesure qu’on ajoute des fonctionnalités sans<br />tests automatiques, on augmente le principal<br />On contracte ainsi une dette de tests<br />Tout au long du développement, on paye les intérêts suivants :<br />Temps de correction de bugs<br />Tests manuels répétés (non régression)<br />Bugs encore présents après la mise en production<br />Peur du changement à cause de la peur de la régression<br />On contracte d’autres types de dette : obsolescence et qualité de code<br />Si on ne rembourse pas progressivement le principal, le poids des intérêts s’accentue<br />Lorsque les intérêts deviennent trop lourds, on est obligé de faire défaut : c’est la refonte !<br />26<br />
    27. 27. Conclusion<br />L’Agile permet de réduire les coûts !<br />Comment ?<br />27<br />
    28. 28. Comment ?<br />Les cycles itératifs<br />Eviter la surproduction<br />Diminuer les impacts des attentes et des retards<br />Repérer et éliminer les défauts au plus tôt, en réduisant les stocks<br />Favoriser la prise en compte du changement et l’apprentissage<br />La priorisation<br />Ne pas investir dans ce qui n’a pas de valeur<br />Le pilotage par les tests, les démonstrations, la notion de « Terminé »<br />Eviter les erreurs d’interprétation<br />Approcher le zéro défaut<br />Maitriser sa dette technique en éliminant la peur du changement<br />Les rétrospectives <br />Favoriser l’apprentissage et la standardisation des pratiques<br />Marginaliser les coûts liées aux tâches répétées<br />28<br />
    29. 29. Comment ?<br />Les équipes auto-organisées, le regroupement<br /> géographique<br />Favoriser les échanges directs<br />Limiter les attentes et les retards<br />Favoriser l’apprentissage<br />Les principes et les pratiques de développement, issues d’XP<br />L’intégration continue, le TDD, le design incrémental, le pair-programming, etc.<br />YAGNI, KISS, Fail-fast, SoC, etc.<br />Améliorer la qualité et marginaliser le coût de maintenance (évolutive ou corrective)<br />29<br />
    30. 30. Finalement,<br />3conseils<br />Adoptez les cycles itératifs<br />Favorisez l’apprentissage<br />Multipliez les interactions<br />2recommandations<br />Réduisez vos gaspillages<br />Maitrisez<br />votre dette<br />1 mot de la fin<br />MERCI de votre attention !<br />30<br />

    ×