L’agilité ne suffit pas pour
être un bon
développeur
Houssam Fakih & Boris Gonnot
@houssamfakih @gonnot
Et pour vous, c’est quoi
un bon développeur ?
Il n’y a pas de
référentiel commun
Subjectif
Pourquoi on s’est
posé cette question?
parce que
c’est motivant
Progresser
Devenir Meilleur
Conquérir nos
faiblesses
En parler ça nous
responsabilise
Apprenons de ce qui
se passe ailleurs
Sport
Athlétisme
Quelle mesure ?
Le temps/distance
Usain Bolt - Record du monde 100m
Temps : 9”58
Haltérophilie
Lu Xiaojun
176 Kg à l’arraché
(record mondial)
Quelle mesure ?
La charge / Temps
Trois choses à noter
Attention aux stéréotypes
#1
Le plus dur est l’entraînement
et non pas la compétition
#2
la belle
posture
malgré la
charge
#3
Concours national de Dictée
Les règles
d’Orthographe
Connaître la grammaire
et la conjugaison
Plein d’autres exemples
Musique / Chanteur
Leçons tirées du
sport
Deux aspects à noter
L’épreuve peut varier
d’une discipline à l’autre
#1
En athlétisme, c’est la
même distance
En Haltérophilie c’est
la même charge
Pour la dictée, le texte
n’est pas le même
l’évaluation est faite
sur la compétition
#2
et non pas lors de
l’entraînement
L’entraînement est pour
gagner en compétences
Compétences variées
Foulée, Explosivité,
Puissance, etc.
Règles de Grammaire,
d’orthographe, de
conjugaison, de Mémoire, etc.
Maintenant revenons
dans le monde du
développement
Evaluation = Métrique
Métrique pour un DEV
DANGER
#MauvaiseUtilisation
#Manager
Il faut former le
manager
#1
sa responsabilité
Training de l’équipe
manager = coach
simplement ne pas
communiquer
#2
c’est votre outil
Mesurer c’est la base…
élément de feedback
Quelle mesure ?
Quantifiable et Simple
Deux mesures
Nombre de bugs
#1
“C’est la faute
du fonctionnel”
#ExcuseBidon
Tout bug est de
notre responsabilité
Objectif de tout
bon développeur
Zero Bug
Valeur apportée
au client
#2
#Expérimental
Comment l’évaluer
Google Analytics : une
piste intéressante
Attention si non utilisé,
il faut comprendre
pourquoi
review sur le produit
Compétences
(Skills)
Clean Code
Compétence/Skill
Nommage
#1
Le lecteur a
toujours raison
Partage du
même langage
avec tous les
acteurs du projet
Ubiquituous
Language
Localisation
des définitions
#2
Pas de mélange
Pas de dispersion
Refactoring
Compétence/Skill
Identifier bad smell
Identifier les
commonalités
capacité de changer le
code sans changer le
comportement
Connaître le catalogue
de refacto de son IDE
Clean Tests
Compétence/Skill
Un test est une
documentation
un test utile
Ne pas
sur-tester
Refactoriser
vos tests
Même Qualité pour
le code et le test
Connaître son
utilisateur
Compétence/Skill
S’intéresser à
l’utilisateur final
Résoudre ses
problèmes
Comprendre ses
problématiques
Challenger les story
Travail en équipe
Compétence/Skill
Coordination
Capacité d’écoute
Positivisme
Adaptabilité
Compétence/Skill
Routine est
notre ennemi
Toujours Apprendre
des nouveaux outils
Toujours Apprendre
des nouveaux paradigmes
Critère : capacité à
simplifier
Simplifier
Compétence/Skill
Abstraction &
Decomposition
détecter la complexité
de l’existant
Mesurer le dev d’une
nouvelle modification
Si ça prend beaucoup du
temps il y a forcément
une complexité cachée
des outils à expérimenter
Code Maat (couplage
temporel & statique)
Etre toujours à la
recherche de feedback
Respecter les jalons
Compétence/Skill
Bien estimer
Gérer son rythme
Comment développer
ces compétences
Il faut s’entraîner
Mais comment ?
En développant ?
Peut-être…
En course à pieds, courir
ne fait pas progresser
FractionnéFractionné - 30/30”
Il faut challenger
le corps
développer
ses compétences
Sortir de sa
zone de confort
et il faut fixer
des objectifs
liés aux compétences
que l’on veut travailler
Quels Outils ?
Katas, Dojo, etc.
Exercices connus
String Calculator
Diamond
Bowling Game
Tic Tac Toe
Gilded Rose
etc.
Les entraînements
doivent être
en groupe (meetup,
pairing, soirées, etc.)
Réguliers
(pour ajuster)
Maîtrisés (Plan
d’entraînement)
Matrice de
compétences
On en tire 3
événements
Regression
Consolidation
Progression
Regression Temporaire
ou chronique ?
Penser à
vous reposer
Et avant la fin
@arolla
L’agilité ne suffit pas pour être un bon développeur
L’agilité ne suffit pas pour être un bon développeur
L’agilité ne suffit pas pour être un bon développeur
L’agilité ne suffit pas pour être un bon développeur
Prochain SlideShare
Chargement dans…5
×

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

411 vues

Publié le

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.

Publié dans : Ingénierie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
411
Sur SlideShare
0
Issues des intégrations
0
Intégrations
4
Actions
Partages
0
Téléchargements
13
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

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

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

×