L’agilité est sans doute une des méthodes les plus efficaces pour simplifier la production logicielle. Derrière ce mot nous avons tendance à ranger toutes les compétences requises et attendues d’un(e) développeur(se) professionnel(le) dans le sens crafts(wo)man. Mais quelles sont donc toutes ces compétences ? Est-ce que l'agilité suffit pour faire des bons développeurs ? Pourrions-nous développer sans être agile tout en livrant des applications de grande qualité ? Cette session apporte des réponses pragmatiques sur ces questions en définissant une liste bien précise et concrète des différentes compétences attendues d’un “crafts(wo)man” performant(e). Nous parlons également de l’importance de mesurer ces compétences d’une manière continue pour suivre notre progression et devenir plus efficace. Nous abordons également les techniques qui permettent un apprentissage ciblé et maîtrisé pour mieux progresser sur chacune de ces différentes compétences.

1. L’agilité ne suffit pas pour
être un bon
développeur
Houssam Fakih & Boris Gonnot
@houssamfakih @gonnot

2. Et pour vous, c’est quoi
un bon développeur ?

3. Il n’y a pas de
référentiel commun

4. Subjectif

5. Pourquoi on s’est
posé cette question?

6. parce que
c’est motivant

7. Progresser

8. Devenir Meilleur

9. Conquérir nos
faiblesses

10. En parler ça nous
responsabilise

11. Apprenons de ce qui
se passe ailleurs

12. Sport

13. Athlétisme

14. Quelle mesure ?
Le temps/distance

15. Usain Bolt - Record du monde 100m
Temps : 9”58

16. Haltérophilie
Lu Xiaojun
176 Kg à l’arraché
(record mondial)

17. Quelle mesure ?
La charge / Temps

18. Trois choses à noter

19. Attention aux stéréotypes
#1

20. Le plus dur est l’entraînement
et non pas la compétition
#2

21. la belle
posture
malgré la
charge
#3

22. Concours national de Dictée

24. Les règles
d’Orthographe

25. Connaître la grammaire
et la conjugaison

26. Plein d’autres exemples
Musique / Chanteur

27. Leçons tirées du
sport

28. Deux aspects à noter

29. L’épreuve peut varier
d’une discipline à l’autre
#1

30. En athlétisme, c’est la
même distance

31. En Haltérophilie c’est
la même charge

32. Pour la dictée, le texte
n’est pas le même

33. l’évaluation est faite
sur la compétition
#2

34. et non pas lors de
l’entraînement

35. L’entraînement est pour
gagner en compétences

36. Compétences variées

37. Foulée, Explosivité,
Puissance, etc.

38. Règles de Grammaire,
d’orthographe, de
conjugaison, de Mémoire, etc.

39. Maintenant revenons
dans le monde du
développement

40. Evaluation = Métrique

41. Métrique pour un DEV

42. DANGER
#MauvaiseUtilisation
#Manager

43. Il faut former le
manager
#1

44. sa responsabilité
Training de l’équipe

45. manager = coach

46. simplement ne pas
communiquer
#2

47. c’est votre outil

48. Mesurer c’est la base…
élément de feedback

49. Quelle mesure ?
Quantifiable et Simple

50. Deux mesures

51. Nombre de bugs
#1

52. “C’est la faute
du fonctionnel”

53. #ExcuseBidon

54. Tout bug est de
notre responsabilité

55. Objectif de tout
bon développeur

56. Zero Bug

57. Valeur apportée
au client
#2
#Expérimental

58. Comment l’évaluer

59. Google Analytics : une
piste intéressante

60. Attention si non utilisé,
il faut comprendre
pourquoi

61. review sur le produit

62. Compétences
(Skills)

63. Clean Code
Compétence/Skill

64. Nommage
#1

65. Le lecteur a
toujours raison

66. Partage du
même langage

67. avec tous les
acteurs du projet

68. Ubiquituous
Language

69. Localisation
des définitions
#2

70. Pas de mélange

71. Pas de dispersion

72. Refactoring
Compétence/Skill

73. Identifier bad smell

74. Identifier les
commonalités

75. capacité de changer le
code sans changer le
comportement

76. Connaître le catalogue
de refacto de son IDE

77. Clean Tests
Compétence/Skill

78. Un test est une
documentation

79. un test utile

80. Ne pas
sur-tester

81. Refactoriser
vos tests

82. Même Qualité pour
le code et le test

83. Connaître son
utilisateur
Compétence/Skill

84. S’intéresser à
l’utilisateur final

85. Résoudre ses
problèmes

86. Comprendre ses
problématiques

87. Challenger les story

88. Travail en équipe
Compétence/Skill

89. Coordination

90. Capacité d’écoute

91. Positivisme

92. Adaptabilité
Compétence/Skill

93. Routine est
notre ennemi

94. Toujours Apprendre
des nouveaux outils

95. Toujours Apprendre
des nouveaux paradigmes

96. Critère : capacité à
simplifier

97. Simplifier
Compétence/Skill

98. Abstraction &
Decomposition

99. détecter la complexité
de l’existant

100. Mesurer le dev d’une
nouvelle modification

101. Si ça prend beaucoup du
temps il y a forcément
une complexité cachée

102. des outils à expérimenter
Code Maat (couplage
temporel & statique)

103. Etre toujours à la
recherche de feedback

104. Respecter les jalons
Compétence/Skill

105. Bien estimer

106. Gérer son rythme

107. Comment développer
ces compétences

108. Il faut s’entraîner

110. Mais comment ?

111. En développant ?

112. Peut-être…

113. En course à pieds, courir
ne fait pas progresser

114. FractionnéFractionné - 30/30”

116. Il faut challenger
le corps

117. développer
ses compétences

118. Sortir de sa
zone de confort

119. et il faut fixer
des objectifs

120. liés aux compétences
que l’on veut travailler

121. Quels Outils ?

122. Katas, Dojo, etc.

123. Exercices connus

124. String Calculator
Diamond
Bowling Game
Tic Tac Toe
Gilded Rose
etc.

125. Les entraînements
doivent être

126. en groupe (meetup,
pairing, soirées, etc.)

127. Réguliers
(pour ajuster)

128. Maîtrisés (Plan
d’entraînement)

129. Matrice de
compétences

131. On en tire 3
événements

132. Regression
Consolidation
Progression

133. Regression Temporaire
ou chronique ?

134. Penser à
vous reposer

135. Et avant la fin

136. @arolla