Recommandé
Recommandé
Contenu connexe
Similaire à Radical Quality From Toyota to Tech - Devoxx France.pptx
Similaire à Radical Quality From Toyota to Tech - Devoxx France.pptx (20)
Radical Quality From Toyota to Tech - Devoxx France.pptx
- 1. DEVOXX FRANCE 2023 QUALITÉ RADICALE DE TOYOTA À LA TECH
- 2. Les bugs : la norme dans notre industrie 2 70 bugs 1000 lignes de code Sources - The Economics of Software Quality (Capers Jones and Olivier Bonsignour), Carogalix study 7 to 25% des bug fixes introduisent un nouveau bug…
- 3. Pourtant, ces bugs ont parfois des conséquences désastreuses 3 Sources - Medical Devices: The Therac 25 http://sunnyday.mit.edu/papers/therac.pdf Datent: if mode/energy specified then begin calculate table index repeat fetch parameter output parameter point to next parameter until all parameters set call Magnet if mode/energy changed then return end if data entry is complete then set Tphase to 3 if data entry is not complete then if reset command entered then set Tphase to 0 return
- 4. La raison : une idée fausse que la qualité est plus chère que la non-qualité 4 sources : The economics of software quality
- 5. défaut 0
- 6. pas une fin en soi 0
- 7. 0 mais la meilleure stratégie pour créer des équipes tech extraordinaires
- 8. Woody Rousseau CTO & Cofondateur @ Sipios 8 Qui nous-sommes Flavian Hautbois Co-author of the upcoming "Build to Sell" book Lean coach in Tech & Product - Enthousiaste de Lean management et de pensée système - Passionné d’APIs et d’Open Finance @WoodyRoussea u /in/woodyrousseau
- 9. Woody Rousseau CTO & Cofounder @ Sipios Flavian Hautbois Co-auteur du futur livre "Build to Sell" Coach lean en Tech & Produit Qui nous-sommes 9 @flavianhautbois /in/flavianhautbois https://buildtosell.org - Un geek de la technologie - Passionné par le fait de créer des produits digitaux excellents avec l’aide de la pensée lean
- 10. Agenda L’HISTOIRE DE SADAO NOMURA 01 QUALITÉ RADICALE DANS LE SOFTWARE 02 RETEX CHEZ SIPIOS, OCUS, AND AUTORABIT 03 UN FRAMEWORK LÉGER POUR DÉMARRER 04 10
- 12. Faites connaissance avec Sadao Nomura : M. Qualité chez Toyota 1. SADAO NOMURA 12 2006-2015
- 13. Son programme “Dantotsu” réduit de 88% les défauts en 3 ans 1. SADAO NOMURA 13 -50% -50% -50% -88%
- 14. Il classifie aussi les défauts en 4 types 1. SADAO NOMURA 14 A B C D
- 15. Ses résultats s’obtiennent avec le processus en 8 étapes 1. SADAO NOMURA 15 Inspecter la pièce défectueuse Vérifier dans le stock Identifier la cause racine Implémenter des contre mesures Retex en daily meeting Créer / améliorer les standards et déployer Former les personnes Vérifier avec des go & sees
- 16. La vitesse… est clé 1. SADAO NOMURA 16 in 24h
- 17. et ça se voit à chaque étape 1. SADAO NOMURA 17 Inspecter la pièce défectueuse Vérifier dans le stock Identifier la cause racine Implémenter des contre mesures Retex en daily meeting Créer / améliorer les standards et déployer Former les personnes Vérifier avec des go & sees jour même jour même jour même jour même jour suivant jour suivant jour suivant jour suivant
- 18. ET DANS LA TECH?
- 19. 2. Qualité radicale dans le software 19
- 20. On ne ship pas des voitures mais on peut se fixer des objectifs ! 2. QUALITÉ SOFTWARE -50% -50% -50% -88% Défauts
- 21. C’est d’ailleurs ce que prône Accelerate avec ses DORA metrics 2. QUALITÉ SOFTWARE -50% -50% -50% -88% Change Failure Rate (% de déploiements introduisant un incident)
- 22. Les types A à D peuvent être définis dans un flux de développement software 2. QUALITÉ SOFTWARE
- 23. Pourtant, la gestion des défauts est assez différente du processus en 8 étapes 23 Vérifier le défaut Évaluer la criticité Prioriser le fix Fixer le défaut Écrire un postmortem (optionnel) Ajouter des vérifications (optionnel) 2. QUALITÉ SOFTWARE
- 24. Vérifier le défaut Évaluer la criticité Prioriser le fix Fixer le défaut Écrire un postmortem (optionnel) Ajouter des vérifications (optionnel) avec des délais encore qui n’ont pas le même niveau d’ambition… 24 2. QUALITÉ SOFTWARE 1er jour 1er jour 1er jour <= quelques semaines encore + tard… encore + tard…
- 25. Le // des pratiques Dantotsu dans la tech est passionnant : Management Visuel 2. QUALITÉ SOFTWARE
- 26. Le // des pratiques Dantotsu dans la tech est passionnant : Standards 2. QUALITÉ SOFTWARE
- 27. Le // des pratiques Dantotsu dans la tech est passionnant : Formation 2. QUALITÉ SOFTWARE Tutorials Katas Pair/mob programming Code review
- 28. Le // des pratiques Dantotsu dans la tech est passionnant : “Weak Point” 2. QUALITÉ SOFTWARE
- 29. Le // des pratiques Dantotsu dans la tech est passionnant : Environment de Travail 2. QUALITÉ SOFTWARE Lint / Codestyle Structure du code Portail développeur Système de gestion de connaissances
- 30. Le // des pratiques Dantotsu dans la tech est passionnant : Rituels 2. QUALITÉ SOFTWARE
- 31. 3. Retex @ Ocus, AutoRABIT & Sipios
- 32. 32 3. RETEX
- 33. 33 Nous lançons un point hebdomadaire sur la qualité autour de QRQC 3. RETEX
- 34. Ocus : un problème de backlog de bugs clients 34 3. RETEX
- 35. Regardons un QRQC. D’abord le problème à résoudre… 35 3. RETEX
- 36. … sa correction immédiate, puis une analyse de cause sur son introduction 36 3. RETEX
- 37. Le développeur décrit ce qu’il a essayé, ce qui a marché et pas marché 37 3. RETEX
- 39. Nous avons fait un atelier de 3j avec l’équipe CodeScan pour créer les indicateurs 39 3. RETEX
- 40. L’équipe CodeScan définit ses types A, B, C et D 40 3. RETEX
- 41. Et choisir de se focaliser d’abord sur les types D 41 3. RETEX
- 42. 42 Un point sur la qualité quotidien permet de discuter des problèmes entre équipes 3. RETEX
- 43. Chaque jour, l’équipe CodeScan résout un problème de bout en bout 43 3. RETEX
- 44. Ce qui fait émerger des weak points précis qui auront un effet de levier important 44 CodeScan engineering How to deploy the infrastructure (SRO) Reinforce error handling to fix seemingly random test failures (Engineering) Important change from SRO not communicated to CodeScan (SRO / Engineer) about the SES keys – but unclear why it had to be shared Quality test plan Have a test plan that covers most of the actual user cases (Engineering) How QA tests SAML QA plan to handle on-prem version 3. RETEX
- 45. Les résultats sont là : 1 type D dans la dernière semaine et plus de backlog 45 3. RETEX (en réalité ils n’ont pas eu de nouveau type D jusqu’au 7 avril)
- 46. 46 3. RETEX
- 47. Il était une fois : un scale de 9 à plus de 100 personnes… 47 3. RETEX
- 48. Patatra : voilà les défauts… 48 3. RETEX
- 49. … et les clients pas contents ! 😡 49 Les features sont shippées : c’est cool. Par contre, ça ship des bugs aussi. Ça fait flipper les personnes avec qui on travaille. Sur les tests auto, j’en parle depuis 2 ans : ma frustration ne pourrait pas être plus grande. Je n’arrive pas à comprendre pourquoi ça n’avance pas… 3. RETEX
- 50. Je trouve un bouquin hallucinant que je lis pendant un trek éprouvant au Maroc 50 moi, plus intéressé par le Lean dans des usines en Afrique du sud que par la montagne 3. RETEX
- 51. Mes premières tentatives donnent des résultats encourageants 51 On construit en équipe une factory API pour centraliser tous nos défauts Les défauts sont vus comme des sources de discussions intéressantes plutôt que de blâmes 3. RETEX
- 52. Mais on fait aussi face à plusieurs difficultés… Remote Trouble management visuel à la vie dure depuis l’ère Covid 52 3. RETEX
- 53. Mais on fait aussi face à plusieurs difficultés… Remote Trouble Stock First management visuel à la vie dure depuis l’ère Covid pas évident de mettre l’attention sur le “in” quand il y a un stock de défauts 53 3. RETEX
- 54. Mais on fait aussi face à plusieurs difficultés… Remote Trouble Stock First Archéologie management visuel à la vie dure depuis l’ère Covid pas évident de mettre l’attention sur le “in” quand il y a un stock de défauts certains bugs datent d’un autre temps et sont difficiles à analyser 54 3. RETEX
- 55. Mais on fait aussi face à plusieurs difficultés… Remote Trouble Stock First Archéologie Charge management visuel à la vie dure depuis l’ère Covid pas évident de mettre l’attention sur le “in” quand il y a un stock de défauts certains bugs datent d’un autre temps et sont difficiles à analyser Une analyse profonde prend ~2h pour quelqu’un d'expérimenté… 55 3. RETEX
- 56. Mais on fait aussi face à plusieurs difficultés… Remote Trouble Stock First Archéologie Charge Conditions management visuel à la vie dure depuis l’ère Covid pas évident de mettre l’attention sur le “in” quand il y a un stock de défauts certains bugs datent d’un autre temps et sont difficiles à analyser Une analyse profonde prend ~2h pour quelqu’un d'expérimenté… Le teamwork ou la pression du delivery sont les usual suspects pour les causes racines… 56 3. RETEX
- 57. Le format abouti tient sur une feuille A4! 57 3. RETEX la ligne de code responsable est clairement identifiée afin d’éviter une idée fausse sur la cause réelle Une seule cause est choisie par le développeur pour que l’analyse soit rapide (30mn) La cause d'occurrence fait apparaître clairement qui doit apprendre quoi et porte sur un geste technique afin de cibler des apprentissages sur le craftsmanship de l’équipe Le comportement inattendu est exprimé du point de vue de l’utilisateur pour renforcer l’empathie et le sens client Les contremesures sont locales et actionnables par l’équipe pour créer une dynamique positive La cause d’outflow cible l’étape la plus proche possible de l’introduction du défaut afin de minimiser le rework dans le futur https://www.gitlab.com/… Sur la page de récap du prêt, le dirigeantvoit un montant prêté 1000x inférieur au montant réel Françoisn’a pas transformé le montant envoyé par la dépendance API car nous n’avons pas de standard sur comment stocker/typerdes montants - Jean créé un standard avec le client, en donnant en input les standards des meilleurs (Stripe…) - 17.09 - Jean forme l’équipe sur le standard établi - 16.09 Nous n’avons pas de manière de détecter de manière statique une primitive obsession (bad smell) - Jean créé une fitness functionexploitant ArchUnit pour détecter des primitifs sur des objets métiers “classiques” (montants, dates, emails…) - 20/09
- 58. L’équipe pilote de Thibault a diminué de 81% ses défauts en prod en 1 an ! 58 3. RETEX
- 59. Au niveau Sipios en revanche… pas encore de tendance ! 59 3. RETEX
- 60. 3. RETEX 60 J’ai aussi détecté nos “weak points” et nous avons lancé une académie de formation
- 62. 62 Conclusion Buy-in du top management S’entraîner aux résolutions de problème
- 63. 63 Conclusion Buy-in du top management S’entraîner aux résolutions de problème Se concentrer sur les apprentissages craft
- 64. 64 Conclusion Buy-in du top management Mesurer et se fixer des objectifs S’entraîner aux résolutions de problème Se concentrer sur les apprentissages craft
- 65. 65 Un template pour démarrer : la version Ocus
- 66. 66 Un template pour démarrer : la version Sipios
- 67. Merci ! 67 Woody Rousseau CTO & Cofondateur @ Sipios, part of Theodo Group @WoodyRoussea u /in/woodyrousseau Flavian Hautbois Co-auteur du futur livre "Build to Sell" Coach lean en Tech & Produit @flavianhautbois /in/flavianhautbois https://buildtosell.org http://tiny.cc/dantotsu