SlideShare une entreprise Scribd logo
DEVOXX FRANCE 2023
QUALITÉ RADICALE
DE TOYOTA
À LA TECH
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…
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
La raison : une idée fausse que la qualité est plus chère que la non-qualité
4 sources : The economics of software quality
défaut
0
pas une
fin en soi
0
0
mais la meilleure
stratégie
pour créer des
équipes tech
extraordinaires
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
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
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
1.L’histoire de
Sadao Nomura
11
Faites connaissance avec Sadao Nomura : M. Qualité chez Toyota
1. SADAO NOMURA
12
2006-2015
Son programme “Dantotsu” réduit de 88% les défauts en 3 ans
1. SADAO NOMURA
13
-50%
-50% -50% -88%
Il classifie aussi les défauts en 4 types
1. SADAO NOMURA
14
A B C D
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
La vitesse… est clé
1. SADAO NOMURA
16
in 24h
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
ET DANS LA
TECH?
2. Qualité radicale
dans le software
19
On ne ship pas des voitures mais on peut se fixer des objectifs !
2. QUALITÉ SOFTWARE
-50%
-50% -50% -88%
Défauts
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)
Les types A à D peuvent être définis dans un flux de développement software
2. QUALITÉ SOFTWARE
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
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…
Le // des pratiques Dantotsu dans la tech est passionnant : Management Visuel
2. QUALITÉ SOFTWARE
Le // des pratiques Dantotsu dans la tech est passionnant : Standards
2. QUALITÉ SOFTWARE
Le // des pratiques Dantotsu dans la tech est passionnant : Formation
2. QUALITÉ SOFTWARE
Tutorials Katas
Pair/mob
programming
Code review
Le // des pratiques Dantotsu dans la tech est passionnant : “Weak Point”
2. QUALITÉ SOFTWARE
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
Le // des pratiques Dantotsu dans la tech est passionnant : Rituels
2. QUALITÉ SOFTWARE
3. Retex
@ Ocus, AutoRABIT
& Sipios
32
3. RETEX
33
Nous lançons un point hebdomadaire sur la qualité autour de QRQC
3. RETEX
Ocus : un problème de backlog de bugs clients
34
3. RETEX
Regardons un QRQC. D’abord le problème à résoudre…
35
3. RETEX
… sa correction immédiate, puis une analyse de cause sur son introduction
36
3. RETEX
Le développeur décrit ce qu’il a essayé, ce qui a marché et pas marché
37
3. RETEX
38
3. RETEX
AutoRABIT
Nous avons fait un atelier de 3j avec l’équipe CodeScan pour créer les indicateurs
39
3. RETEX
L’équipe CodeScan définit ses types A, B, C et D
40
3. RETEX
Et choisir de se focaliser d’abord sur les types D
41
3. RETEX
42
Un point sur la qualité quotidien permet de discuter des problèmes entre équipes
3. RETEX
Chaque jour, l’équipe CodeScan résout un problème de bout en bout
43
3. RETEX
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
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
3. RETEX
Il était une fois : un scale de 9 à plus de 100 personnes…
47
3. RETEX
Patatra : voilà les défauts…
48
3. RETEX
… 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
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
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
Mais on fait aussi face à plusieurs difficultés…
Remote Trouble
management visuel à
la vie dure depuis
l’ère Covid
52
3. RETEX
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
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
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
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
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
L’équipe pilote de Thibault a diminué de 81% ses défauts en prod en 1 an !
58
3. RETEX
Au niveau Sipios en revanche… pas encore de tendance !
59
3. RETEX
3. RETEX
60
J’ai aussi détecté nos “weak points” et nous avons lancé une académie de formation
61
Conclusion
Buy-in du top
management
62
Conclusion
Buy-in du top
management
S’entraîner aux
résolutions de
problème
63
Conclusion
Buy-in du top
management
S’entraîner aux
résolutions de
problème
Se concentrer sur
les
apprentissages
craft
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
Un template pour démarrer : la version Ocus
66
Un template pour démarrer : la version Sipios
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

Contenu connexe

Tendances

T620.0046 Q7 _Anexo.pptx
T620.0046 Q7 _Anexo.pptxT620.0046 Q7 _Anexo.pptx
T620.0046 Q7 _Anexo.pptx
AnaRamos874831
 
Hsqldb操作指南
Hsqldb操作指南Hsqldb操作指南
Hsqldb操作指南
allen dong
 
خرائط التدفق
خرائط التدفقخرائط التدفق
خرائط التدفق
iraniakhaled
 
Sifir Darab 1.docx
Sifir Darab 1.docxSifir Darab 1.docx
Sifir Darab 1.docx
Mohd Huzairi Abenoh
 
تمرين تقييم مستوي المؤسسية في منظمتك د.طارق السويدان
تمرين تقييم مستوي المؤسسية في منظمتك د.طارق السويدانتمرين تقييم مستوي المؤسسية في منظمتك د.طارق السويدان
تمرين تقييم مستوي المؤسسية في منظمتك د.طارق السويدان
sadek younis
 
Mining Software Repositories
Mining Software RepositoriesMining Software Repositories
Mining Software Repositories
Israel Herraiz
 
Model Compression
Model CompressionModel Compression
Model Compression
DarshanG13
 

Tendances (7)

T620.0046 Q7 _Anexo.pptx
T620.0046 Q7 _Anexo.pptxT620.0046 Q7 _Anexo.pptx
T620.0046 Q7 _Anexo.pptx
 
Hsqldb操作指南
Hsqldb操作指南Hsqldb操作指南
Hsqldb操作指南
 
خرائط التدفق
خرائط التدفقخرائط التدفق
خرائط التدفق
 
Sifir Darab 1.docx
Sifir Darab 1.docxSifir Darab 1.docx
Sifir Darab 1.docx
 
تمرين تقييم مستوي المؤسسية في منظمتك د.طارق السويدان
تمرين تقييم مستوي المؤسسية في منظمتك د.طارق السويدانتمرين تقييم مستوي المؤسسية في منظمتك د.طارق السويدان
تمرين تقييم مستوي المؤسسية في منظمتك د.طارق السويدان
 
Mining Software Repositories
Mining Software RepositoriesMining Software Repositories
Mining Software Repositories
 
Model Compression
Model CompressionModel Compression
Model Compression
 

Similaire à Radical Quality From Toyota to Tech - Devoxx France.pptx

Paris Chaos Engineering Meetup #6
Paris Chaos Engineering Meetup #6Paris Chaos Engineering Meetup #6
Paris Chaos Engineering Meetup #6
Christophe Rochefolle
 
Meetup aws user group lille 2018 chaos engineering
Meetup aws user group lille 2018   chaos engineeringMeetup aws user group lille 2018   chaos engineering
Meetup aws user group lille 2018 chaos engineering
Benjamin Gakic
 
L'ADN d'un développement produit réussi
L'ADN d'un développement produit réussiL'ADN d'un développement produit réussi
L'ADN d'un développement produit réussi
OCTO Technology Suisse
 
Afterwork OCTO Delivery - L'ADN d'un développement produit réussi
Afterwork OCTO Delivery - L'ADN d'un développement produit réussiAfterwork OCTO Delivery - L'ADN d'un développement produit réussi
Afterwork OCTO Delivery - L'ADN d'un développement produit réussi
cyrilpicat
 
La gestion des actifs logiciels : enjeux et opportunités
La gestion des actifs logiciels : enjeux et opportunitésLa gestion des actifs logiciels : enjeux et opportunités
La gestion des actifs logiciels : enjeux et opportunités
Microsoft Ideas
 
Agile tour 2015 alliés contre les défauts
Agile tour 2015   alliés contre les défautsAgile tour 2015   alliés contre les défauts
Agile tour 2015 alliés contre les défauts
Julien Jakubowski
 
Agile tour Lille 2015 allies ensemble contre les defauts
Agile tour Lille 2015 allies ensemble contre les defautsAgile tour Lille 2015 allies ensemble contre les defauts
Agile tour Lille 2015 allies ensemble contre les defauts
Antoine Blk
 
Introduction à la qualité logicielle (1/5)
Introduction à la qualité logicielle (1/5)Introduction à la qualité logicielle (1/5)
Introduction à la qualité logicielle (1/5)
Sylvain Leroy
 
Scrum Day 2014 - Êtes-vous prêts pour le modèle Spotify ?
Scrum Day 2014 - Êtes-vous prêts pour le modèle Spotify ?Scrum Day 2014 - Êtes-vous prêts pour le modèle Spotify ?
Scrum Day 2014 - Êtes-vous prêts pour le modèle Spotify ?Publicis Sapient Engineering
 
Cloud Expo Europe 2018 - "Et si on testait en production ?"
Cloud Expo Europe 2018 - "Et si on testait en production ?"Cloud Expo Europe 2018 - "Et si on testait en production ?"
Cloud Expo Europe 2018 - "Et si on testait en production ?"
Christophe Rochefolle
 
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie TrudelHa zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Agile Montréal
 
Soubki projet
Soubki projetSoubki projet
Soubki projet
s1kor
 
Introduction au test_logiciel-fr
Introduction au test_logiciel-frIntroduction au test_logiciel-fr
Introduction au test_logiciel-fr
EmanBali
 
Pour passer la crise, remboursez votre dette technique !
Pour passer la crise, remboursez votre dette technique !Pour passer la crise, remboursez votre dette technique !
Pour passer la crise, remboursez votre dette technique !
Agile Tour Genève
 
Amélioration Continue - Des faits & des effets
Amélioration Continue - Des faits & des effetsAmélioration Continue - Des faits & des effets
Amélioration Continue - Des faits & des effets
Philippe Launay
 
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013
Xavier NOPRE
 
Retour d'expérience TAA - 2011/03/29
Retour d'expérience TAA - 2011/03/29Retour d'expérience TAA - 2011/03/29
Retour d'expérience TAA - 2011/03/29
Elapse Technologies
 
Analyse des besoins et gestion des projets besoin.pdf
Analyse des besoins et gestion des projets besoin.pdfAnalyse des besoins et gestion des projets besoin.pdf
Analyse des besoins et gestion des projets besoin.pdf
JordaniMike
 
coursABGP-miage-1112-4p1.pdf
coursABGP-miage-1112-4p1.pdfcoursABGP-miage-1112-4p1.pdf
coursABGP-miage-1112-4p1.pdf
HervKoya
 
Supervision d'un réseau informatique avec Nagios
Supervision d'un réseau informatique avec NagiosSupervision d'un réseau informatique avec Nagios
Supervision d'un réseau informatique avec Nagios
christedy keihouad
 

Similaire à Radical Quality From Toyota to Tech - Devoxx France.pptx (20)

Paris Chaos Engineering Meetup #6
Paris Chaos Engineering Meetup #6Paris Chaos Engineering Meetup #6
Paris Chaos Engineering Meetup #6
 
Meetup aws user group lille 2018 chaos engineering
Meetup aws user group lille 2018   chaos engineeringMeetup aws user group lille 2018   chaos engineering
Meetup aws user group lille 2018 chaos engineering
 
L'ADN d'un développement produit réussi
L'ADN d'un développement produit réussiL'ADN d'un développement produit réussi
L'ADN d'un développement produit réussi
 
Afterwork OCTO Delivery - L'ADN d'un développement produit réussi
Afterwork OCTO Delivery - L'ADN d'un développement produit réussiAfterwork OCTO Delivery - L'ADN d'un développement produit réussi
Afterwork OCTO Delivery - L'ADN d'un développement produit réussi
 
La gestion des actifs logiciels : enjeux et opportunités
La gestion des actifs logiciels : enjeux et opportunitésLa gestion des actifs logiciels : enjeux et opportunités
La gestion des actifs logiciels : enjeux et opportunités
 
Agile tour 2015 alliés contre les défauts
Agile tour 2015   alliés contre les défautsAgile tour 2015   alliés contre les défauts
Agile tour 2015 alliés contre les défauts
 
Agile tour Lille 2015 allies ensemble contre les defauts
Agile tour Lille 2015 allies ensemble contre les defautsAgile tour Lille 2015 allies ensemble contre les defauts
Agile tour Lille 2015 allies ensemble contre les defauts
 
Introduction à la qualité logicielle (1/5)
Introduction à la qualité logicielle (1/5)Introduction à la qualité logicielle (1/5)
Introduction à la qualité logicielle (1/5)
 
Scrum Day 2014 - Êtes-vous prêts pour le modèle Spotify ?
Scrum Day 2014 - Êtes-vous prêts pour le modèle Spotify ?Scrum Day 2014 - Êtes-vous prêts pour le modèle Spotify ?
Scrum Day 2014 - Êtes-vous prêts pour le modèle Spotify ?
 
Cloud Expo Europe 2018 - "Et si on testait en production ?"
Cloud Expo Europe 2018 - "Et si on testait en production ?"Cloud Expo Europe 2018 - "Et si on testait en production ?"
Cloud Expo Europe 2018 - "Et si on testait en production ?"
 
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie TrudelHa zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
 
Soubki projet
Soubki projetSoubki projet
Soubki projet
 
Introduction au test_logiciel-fr
Introduction au test_logiciel-frIntroduction au test_logiciel-fr
Introduction au test_logiciel-fr
 
Pour passer la crise, remboursez votre dette technique !
Pour passer la crise, remboursez votre dette technique !Pour passer la crise, remboursez votre dette technique !
Pour passer la crise, remboursez votre dette technique !
 
Amélioration Continue - Des faits & des effets
Amélioration Continue - Des faits & des effetsAmélioration Continue - Des faits & des effets
Amélioration Continue - Des faits & des effets
 
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013
 
Retour d'expérience TAA - 2011/03/29
Retour d'expérience TAA - 2011/03/29Retour d'expérience TAA - 2011/03/29
Retour d'expérience TAA - 2011/03/29
 
Analyse des besoins et gestion des projets besoin.pdf
Analyse des besoins et gestion des projets besoin.pdfAnalyse des besoins et gestion des projets besoin.pdf
Analyse des besoins et gestion des projets besoin.pdf
 
coursABGP-miage-1112-4p1.pdf
coursABGP-miage-1112-4p1.pdfcoursABGP-miage-1112-4p1.pdf
coursABGP-miage-1112-4p1.pdf
 
Supervision d'un réseau informatique avec Nagios
Supervision d'un réseau informatique avec NagiosSupervision d'un réseau informatique avec Nagios
Supervision d'un réseau informatique avec Nagios
 

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
  • 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
  • 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
  • 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)
  • 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
  • 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