D1 - Un développeur est-il un numéro, un coût journalier ou un artiste ?

620 views

Published on

Le métier et le rôle du développeur ont fortement évolués au cours des 10 dernières années du fait notamment de l'adoption massive des méthodologies agiles. De manière ludique, cette session mettra en lumière cette évolution et ces enjeux.

Freddy Mallet

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
620
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

D1 - Un développeur est-il un numéro, un coût journalier ou un artiste ?

  1. 1. xpday.ch 2009 2010 Genève 2011 9 mai« Un développeur est-il un numéro,un coût journalier ou un artiste ? » Freddy Mallet - D1 -
  2. 2. XP Day Suisse Développeur : Artiste ou Numéro ? Par Freddy Mallet freddy.mallet@sonarsource.com
  3. 3. Il était une fois des autodidactes
  4. 4. Le savant génial
  5. 5. Le super héros
  6. 6. Lindividualiste Cest mon jouet !
  7. 7. Lhomme
  8. 8. Les technologies se complexifient COBOL Java, .Net, Web, Clouds, Ruby, Scala, NoSQL, SOAP, N tiers, Play, GWT, ...
  9. 9. Les attentes du métier augmentent
  10. 10. Loutillage évolue Makefile Gestionnaire Intégration Tests unitaires de projet technique ContinueVI / Emacs Gestionnaire Gestionnaire Refactoring Inspection de source de tickets depuis lIDE Continue
  11. 11. Les exigences évoluentGestionnaire de configuration Aucune modification ne passe en production sans avoir été préalablement placée sous contrôle de version Lensemble cohérent des sources dune version applicative doit pouvoir être retrouvé aisément dans le gestionnaire de source
  12. 12. Les exigences évoluentIntégration continue Le code contenu dans le gestionnaire de source doit pouvoir être compilé à tout moment et par nimporte qui Lexécution des tests unitaires fait pleinement parti du processus de construction La sortie du processus de construction est un livrable prêt à lemploi Si une des exigences ci dessus nest plus respectée, rien nest plus important que de la corriger
  13. 13. Les exigences évoluentInspection Continue Tout nouveau code doit être accompagné de tests unitaires Aucune méthode ne doit excéder un seuil de complexité Aucun code ne doit être dupliqué ...
  14. 14. Laventurier est perdu
  15. 15. La mission évolue« Get It Done » et « Do It Right »
  16. 16. Tout est maintenance évolutive ! Création dune application Maintenance Dune lapplication
  17. 17. Une application est vivante
  18. 18. Inspection Continue « A well-written program is a program  where the cost of implementing a feature is constant throughout the programs lifetime. » Itay Maman
  19. 19. La dette technique
  20. 20. Comment mesurer cette dette ?
  21. 21. Les 7 péchés capitauxDu développeur Péchés Dette technique
  22. 22. Exemple de dégradation structurelle
  23. 23. Développeur, aujourdhui et demain ?
  24. 24. Lentêtement est toujours possible
  25. 25. Développement : activité linéaire !Spécifications Code Source
  26. 26. Ce nest pas complexe
  27. 27. 9 femmes peuvent faire un enfant en 1 mois !
  28. 28. Les tests ça coutent chers !
  29. 29. On spécifie puis on ... développe externalise, outsource
  30. 30. Je nattends rien dudéveloppeur excepté du code source
  31. 31. Des aspirations naissent
  32. 32. Complexité
  33. 33. Passion
  34. 34. Expérience
  35. 35. IntuitionCréation
  36. 36. Une métaphore nest quune image
  37. 37. Le développeur est un artiste !
  38. 38. Le développeur est un jardinier !
  39. 39. Mais les choses sont plus simplesProfessionnalisation
  40. 40. Artisanat ou Industrie ? L’industrie est lensemble des activités humaines tournées vers la production en série de biens ; elle sous-entend :  une certaine division du travail, contrairement à lartisanat où la même personne assure théoriquement lensemble des processus : étude, fabrication, commercialisation, gestion  une notion déchelle, on parle de « quantités industrielles » lorsque le nombre de pièces identiques atteint un certain chiffre
  41. 41. Une démarche et des outils
  42. 42. Feedback Driven Development Revue « collégiale » de la fonctionnalité Détermination du plus petit incrément fonctionnel Revue « collégiale » du design Détermination du plus petit incrément technique Ecrire un test en échec Ecrire le code pour faire passer le test dans le vert Refactorer le code Pousser le changement Automatisation dun test dintégration
  43. 43. Coach, où es-tu ?
  44. 44. A chacun sa vision Intermittent AmateurArtisan Numéro Compagnon Professionnel Jardinier
  45. 45. Mais quel potentiel dévolution !
  46. 46. Questions & Réponses Merci http://www.sonarsource.org http://www.sonarsource.com

×