L’agilité ne suffit pas pour
être un bon
développeur
Houssam Fakih
@houssamfakih
@gonnot
Boris Gonnot
Agile Grenoble’15
C’est quoi un
bon développeur ?
Il n’y a pas de
référentiel commun
Subjectif
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
Plein d’autres exemples
Musique / Chanteur
Leçons tirées
Deux aspects à noter
L’épreuve peut varier
d’une discipline à
l’autre
#1
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é,
Grammaire, Mémoire…
Maintenant retour
au développement
Evaluation = Métrique
Métrique pour
un DEV
#MauvaiseUtilisation
#Manager
Former
le manager
#1
Sa responsabilité :
Training de l’équipe
Manager = Coach
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”
#NonValide
Tout bug est de
notre responsabilité
Objectif de tout
bon développeur
Bug
Valeur apportée
au client
#2
#Expérimental
Comment l’évaluer
“Google Analytics”
une piste intéressante
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
Localisation
des définitions
#2
Pas de mélange
Pas de dispersion
Refactoring
Compétence/Skill
Capacité de changer le
code sans changer le
comportement
Identifier
bad smell
Identifier les
commonalités
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
Challenger
les stories
Travail en équipe
Compétence/Skill
Coordination
Capacité d’écoute
Positivisme
Adaptabilité
Compétence/Skill
La routine est
notre ennemi
Toujours Apprendre
des nouveaux outils
Toujours Apprendre
des nouveaux
paradigmes
Simplifier
Compétence/Skill
Abstraction &
Decomposition
Détecter la complexité
de l’existant
A expérimenter
Code Maat
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”
développer
ses compétences
Sortir de sa
zone de confort
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 ?
Et avant la fin
Penser à vous reposer
@ArollaFr
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

820 vues

Publié le

Agile Grenoble 2015

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

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

×