Retrospective de mes huit dernières années dans la création de logiciels. Je parle de mes débuts avec SCRUM, de la réécriture d'une app un nombre honteux de fois, de l'apprentissage de Clean Code et de l'Extreme Programming. Je tire les leçons de ces huit années et les partager avec l'audience. J'explique pourquoi je trouve important de tester son code et de laisser les développeurs parler avec toutes les parties prenantes des projets.

1. Du Code &
Des Humains

2. Du Code &
Des Humains
ryfacto.fr
Nicolas VERINAUD
@nverinaud

3. « Google The Error Message Algorithm »

6. Toile de Paillage Tissée

7. Développer un logiciel
Facile ?
🤔
Toyota
Chinook
Mars Climate Orbiter
Therac-25 911

8. https://en.wikipedia.org/wiki/List_of_software_bugs

12. Développeur
Professionnel

13. 🙂
Fonctionnalité
3 jours

14. 😕 Fonctionnalité
3 semaines

15. 😖
Fonctionnalité
Trop long

16. Productivité
0
25
50
75
100
Mois
0 1 2 3 4 5 6 7 8 9 10 11 12
Vélocité

18. Développeur : une espèce à
part ?
Réécrire : une fatalité ?

19. Développeur : une espèce à
part ?
Réécrire : une fatalité ?

21. Client Commercial
Directeur
Technique
Dev Scrum Master Mockups Master

22. Utilisateur Product Owner
Proxy Product
Owner
Dev Lead Dev Scrum Master

23. Utilisateur Product Owner
Proxy Product
Owner
Dev Lead Dev Scrum Master
Téléphone ArabeEnterprise Edition

24. • Les individus et leurs interactions plus que les processus et les outils
• Des logiciels opérationnels plus qu’une documentation exhaustive
• La collaboration avec les clients plus que la négociation contractuelle
• L’adaptation au changement plus que le suivi d’un plan

25. Discuter avec l’utilisateur
pour construire un logiciel qui
fait le boulot

26. Qu’est-ce que le code ?

27. Qu’est-ce que le code ?

28. Le code est la spécification la
plus détaillée du monde

31. - Alberto Brandolini
« C’est la compréhension du développeur, pas votre connaissance,
qui devient le logiciel. »

32. 01001010
11101111
01010101
UX

34. Comment comprendre
efficacement les besoins ?

35. Quel est le véritable problème ?
Les 5 « Pourquoi ? » et la
définition récursive

36. Quel est le véritable problème ?
Les 5 « Pourquoi ? » et la
définition récursive

37. définition récursive
« J’ai besoin d’une base de donnée générique
contenant tous les médicaments vendus et qui
peuvent être prescrit par les médecins. »

38. définition récursive
« J’ai besoin d’une base de donnée générique
contenant tous les médicaments vendus et qui
peuvent être prescrit par les médecins. »
Pourquoi ?

39. définition récursive
« Pour aider les médecins à faire leurs
ordonnances. »
Pourquoi ?

40. définition récursive
« Car les médecins font des erreurs en prescrivant
des médicaments. »
Pourquoi ?

41. définition récursive
« Car ils prescrivent des médicaments
incompatibles. »
Pourquoi ?

42. définition récursive
« Car les interactions entre les médicaments sont
complexes. »
Une interaction entre médicaments ?

43. Base de donnée générique de médicaments
définition récursive
« Et bien, par exemple : deux médicaments ne
doivent pas être pris ensemble car ils contiennent
tous les deux la molécule M et il y a un risque de
surdosage. »

44. Base de donnée générique de médicaments
Aider les médecins à prescrire les
bons médicaments

45. Quelles solutions ?
Impact Mapping

46. Impact Mapping
Quelles solutions ?
Créer le logiciel qui aura le
meilleur impact, le meilleur ROI

47. Impact Mapping
Quelles solutions ?
Créer le logiciel qui aura le
meilleur impact, le meilleur ROI

48. Créer le logiciel qui aura le
meilleur impact, le meilleur ROI
Gojko Adzic

49. Implémentation ? Métier ?
Event Storming

50. Implémentation ? Métier ?
Event Storming
Aligner Métier et Technique

51. Implémentation ? Métier ?
Event Storming
Aligner Métier et Technique
http://ziobrando.blogspot.fr/2013/11/introducing-event-storming.html

52. Vision d’ensemble ? Priorités ?
User Story Mapping

53. Vision d’ensemble ? Priorités ?
User Story Mapping
Créer un véritable MVP

54. User Story Mapping
Vision d’ensemble ? Priorités ?
Créer un véritable MVP

55. User Story Mapping
Créer un véritable MVP
Jeff Patton

56. User Story Mapping
Créer un véritable MVP

57. C’est la compréhension du
développeur qui devient le
logiciel, pas le cahier des
charges.

58. Projet complexe ?

59. Projet complexe ?
Mauvaise conception ?

60. Projet complexe ?
Mauvaise conception ?

61. Deux Formes de Complexité
Complexité Essentielle

62. Deux Formes de Complexité
Complexité Essentielle
Complexité Accidentelle

63. Comment s’en rendre compte ?
Deux Formes de Complexité
Complexité Essentielle
Complexité Accidentelle
≠
Dette Technique

64. Deux Formes de Complexité
Complexité Essentielle
Complexité Accidentelle
Comment s’en rendre compte ?

65. +
Deux Formes de Complexité
Complexité Essentielle
Complexité Accidentelle

66. Comment estimez-vous ?
Arrêtez d’estimer !

67. Comment estimez-vous ?
Arrêtez d’estimer !

68. - Un développeur qui fait une estimation fiable
« Je ne sais pas ! »

69. Comment éviter la complexité
accidentelle ?
En prenant soin du code !En prenant soin du code !

70. Comment éviter la complexité
accidentelle ?
En prenant soin du code !
Comment ?

71. Comment éviter la complexité
accidentelle ?
En prenant soin du code !
Comment ?
Refactoring régulier !

72. Comment éviter la complexité
accidentelle ?
En prenant soin du code !
Comment ?
Refactoring régulier !
Je risque de tout péter non ?

73. Comment éviter la complexité
accidentelle ?
En prenant soin du code !
Comment ?
Refactoring régulier !
Je risque de tout péter non ?
Non ! Grâce aux tests
automatisés !

74. accidentelle ?
En prenant soin du code !
Comment ?
Refactoring régulier !
Je risque de tout péter non ?
Non ! Grâce aux tests
automatisés !

75. Deux possibilités
Économiquement Mort

76. Comment s’en sortir ?
Deux possibilités
Économiquement Mort
Avant la 1ère mise en prod 😱

77. Deux possibilités
Économiquement Mort
Comment s’en sortir ?
Repartir de zéro avec des tests

78. Repartir de zéro avec des tests
Deux possibilités
Économiquement Mort
Comment s’en sortir ?

79. Deux possibilités
Économiquement Mort

80. Embaucher ?
Deux possibilités
Économiquement Viable
Tierce Maintenance Applicative 😱

81. Deux possibilités
Économiquement Viable
Embaucher ?

82. Économiquement Viable
Embaucher ?
Fred Brooks

83. Fred Brooks
« Adding manpower to a late project makes it later. »

84. Écrire des tests...
...pour pouvoir refactor...

85. Écrire des tests...
...pour pouvoir refactor...
...pour prospérer !

86. Écrire des tests...
...pour pouvoir refactor...
...pour prospérer !

87. Scrum

88. Scrum
+
Extreme Programming

89. Test Driven Development
Culture du Partage

90. Culture du Partage
Test Driven Development
Solidarité Technologique

91. Culture du Partage
Test Driven Development
Solidarité Technologique

92. Créer un logiciel pertinent
avec le meilleur ROI est difficile

93. Ne pas négliger le Code
Ni la compréhension du
Développeur

94. Ne pas négliger le Code
Ni la compréhension du
Développeur

95. Du Code

96. Du Code & Des Humains
Merci !

97. Du Code & Des Humains
Merci !
ryfacto.fr@nverinaud
Envie de travailler
avec nous ?