L'agilité ne suffit pas pour être un bon développeur

Agile Grenoble 2015

Transcript

1. L’agilité ne suffit pas pour être un bon développeur Houssam Fakih @houssamfakih @gonnot Boris Gonnot Agile Grenoble’15
2. C’est quoi un bon développeur ?
3. Il n’y a pas de référentiel commun
4. Subjectif
5. Apprenons de ce qui se passe ailleurs
6. Sport
7. Athlétisme
8. Quelle mesure ? Le temps/distance
9. Usain Bolt - Record du monde 100m Temps : 9”58
10. Haltérophilie Lu Xiaojun 176 Kg à l’arraché (record mondial)
11. Quelle mesure ? La charge / Temps
12. Trois choses à noter
13. Attention aux stéréotypes #1
14. Le plus dur est l’entraînement et non pas la compétition #2
15. la belle posture malgré la charge #3
16. Concours national de Dictée
18. Plein d’autres exemples Musique / Chanteur
19. Leçons tirées
20. Deux aspects à noter
21. L’épreuve peut varier d’une discipline à l’autre #1
22. l’évaluation est faite sur la compétition #2
23. et non pas lors de l’entraînement
24. L’entraînement est pour gagner en compétences
25. Compétences variées
26. Foulée, Explosivité, Grammaire, Mémoire…
27. Maintenant retour au développement
28. Evaluation = Métrique
29. Métrique pour un DEV
30. #MauvaiseUtilisation #Manager
31. Former le manager #1
32. Sa responsabilité : Training de l’équipe
33. Manager = Coach
34. Ne pas communiquer #2
35. c’est votre outil
36. Mesurer c’est la base… élément de feedback
37. Quelle mesure ? Quantifiable et Simple
38. Deux mesures
39. Nombre de bugs #1
40. “C’est la faute du fonctionnel”
41. #NonValide
42. Tout bug est de notre responsabilité
43. Objectif de tout bon développeur
44. Bug
45. Valeur apportée au client #2 #Expérimental
46. Comment l’évaluer
47. “Google Analytics” une piste intéressante
48. Review sur le produit
49. Compétences (Skills)
50. Clean Code Compétence/Skill
51. Nommage #1
52. Le lecteur a toujours raison
53. Partage du même langage
54. Avec tous les acteurs du projet
55. Localisation des définitions #2
56. Pas de mélange
57. Pas de dispersion
58. Refactoring Compétence/Skill
59. Capacité de changer le code sans changer le comportement
60. Identifier bad smell
61. Identifier les commonalités
62. Connaître le catalogue de refacto de son IDE
63. Clean Tests Compétence/Skill
64. Un test est une documentation
65. Un test utile
66. Ne pas sur-tester
67. Refactoriser vos tests
68. Même Qualité pour le code et le test
69. Connaître son utilisateur Compétence/Skill
70. S’intéresser à l’utilisateur final
71. Résoudre ses problèmes
72. Challenger les stories
73. Travail en équipe Compétence/Skill
74. Coordination
75. Capacité d’écoute
76. Positivisme
77. Adaptabilité Compétence/Skill
78. La routine est notre ennemi
79. Toujours Apprendre des nouveaux outils
80. Toujours Apprendre des nouveaux paradigmes
81. Simplifier Compétence/Skill
82. Abstraction & Decomposition
83. Détecter la complexité de l’existant
84. A expérimenter Code Maat
85. Etre toujours à la recherche de feedback
86. Respecter les jalons Compétence/Skill
87. Bien estimer
88. Gérer son rythme
89. Comment développer ces compétences ?
90. Il faut s’entraîner
91. Mais comment ?
92. En développant ?
93. Peut-être…
94. En course à pieds, courir ne fait pas progresser
95. Fractionné Fractionné - 30/30”
97. développer ses compétences
98. Sortir de sa zone de confort
99. Fixer des objectifs…
100. …liés aux compétences que l’on veut travailler
101. Quels Outils ?
102. Katas, Dojo, etc.
103. Exercices connus String Calculator Diamond Bowling Game Tic Tac Toe Gilded Rose etc.
104. Les entraînements doivent être
105. En groupe (meetup, pairing, soirées, etc.)
106. Réguliers (pour ajuster)
107. Maîtrisés (Plan d’entraînement)
108. Matrice de compétences
110. On en tire 3 événements
111. Regression Consolidation Progression
112. Regression Temporaire ou chronique ?
113. Et avant la fin
114. Penser à vous reposer
115. @ArollaFr