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

11. 1.L’histoire de
Sadao Nomura
11

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

38. 38
3. RETEX
AutoRABIT

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

61. 61
Conclusion
Buy-in du top
management

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