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

408 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
408
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

×