AgileCampusTour
La fine équipe             Julien Biezemans                julien@agilecampustour.org                @jbpros             Si...
Souvenez-vous de Bob
Le projet sur lequel il travaille
Et sa vision du déroulement d’un tel                projet                                             Blu              We...
Et sa vision du déroulement d’un tel                projet                                             Blu              We...
Comment se passe le développement        au jour le jour ?
Chaque matin, Bob et son équipe se   réunissent en daily standup                                         Blue Team        ...
“Non, on ne s’assied pas durant un            standup”
Bob insiste sur la qualité du code             produit
Pourquoi ?NewGuy
Bob veut simplement éviterd’accumuler de la ‘dette technique’
Quand on code au plus vite et de manière non optimale, on contracte unedette technique que lon rembourse tout au long de l...
C’est un peu comme un prêt pour          une maison...
Comment apparaît-elle ?
Comment la rembourser ?
Comment la rembourser ?En “refactorant” le code !
Mais pas n’importe comment !
Bob insiste aussi sur la pratique du        pair programming
Quelle que soit la formule
1 clavier 1 souris
2 claviers 2 souris
2 claviers 2 souris 2 écrans (mirroring)
Bob insiste également sur l’importance des tests
A différents niveaux de l’application
Le test unitaire est un procédé permettant de sassurer du fonctionnementcorrect dune partie déterminée dun logiciel ou dun...
Les tests dintégration ont pour but de valider le fait que toutes les partiesdéveloppées indépendamment fonctionnent bien ...
Mais au fond, à quoi ca peut bien       servir, ces tests...
Identifier une régression
Vérifier des critères d’acceptance
Protéger une application existante
“Oui mais les tests ça prend du           temps...”
C’est un investissement
Et une source de documentation
Et si on écrit ces tests avant le code, on développe différement, c’est du TDD
Après avoir écrit un test, on l’exécute...
On écrit le code minimal pour qu’il passe
On “refactore” le code
Si une régression apparaît on le voit tout                de suite !
Exemple : les “specs” de Carcassonne
On peut aussi aller plus loin et faireintervenir la valeur métier du client
Les paires recoivent les sénarios                                     “Lorsque je remplis le champ et“Lorsque je suis sur ...
Et écrivent leurs tests dans un langage         lisible par leur client
Ils font du BDD
Avec Cucumber ou JBehave
Exemple : un “feature” de carcassonne
Dès que la fonctionnalité répond à la       notion de “terminé”
Elle est envoyée au “système de           versioning”
Pourquoi ?                                  I  Conflicts                  Back to last   did               commit please   ...
La fonctionnalité envoyée, le serveurd’intégration continue prend le relais
Il va exécuter la suite de tests
Vérifier qu’on a pas de régression
Si tout passe, on déploie en “staging”
Afin que le client puisse tester
Si c’est accepté, on peut déployer en              production
BluWeek   Day             Sto TO WI D              ~          Na             rie D P O              ~              s O (4)...
Ce n’est pas une recette miracle, et ça ne     convient pas à tout le monde...
Et comment on fait sur un projet         existant ?
Adapter le processus progressivement
En organisant des rétrospectives
S’attaquer à la dette technique       progressivement
Grâce à des “smoke tests”
Et la méthode mikado
Un peu de lecture ?
Encore une petite rétrospective ?
Questions?@agilecampustour   http://agilecampustour.org
Session mons 22 mars
Session mons 22 mars
Session mons 22 mars
Prochain SlideShare
Chargement dans…5
×

Session mons 22 mars

706 vues

Publié le

Deuxième session théorique de l'AgileCampusTour à Mons, sur les techniques de développement

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

  • Soyez le premier à aimer ceci

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

Aucune remarque pour cette diapositive

Session mons 22 mars

  1. 1. AgileCampusTour
  2. 2. La fine équipe Julien Biezemans julien@agilecampustour.org @jbpros Simon Schoeters simon@agilecampustour.org @cimm Marc Lainez marc@agilecampustour.org @mlainez Si vous voulez tweeter utilisez le hashtag #actbe
  3. 3. Souvenez-vous de Bob
  4. 4. Le projet sur lequel il travaille
  5. 5. Et sa vision du déroulement d’un tel projet Blu Week Day Sto TO WI D ~ Na rie D P O ~ s O (4) NE Mi ~ ~ ~
  6. 6. Et sa vision du déroulement d’un tel projet Blu Week Day Sto TO WI D ~ Na rie D P O ~ s O (4) NE Mi ~ ~ ~
  7. 7. Comment se passe le développement au jour le jour ?
  8. 8. Chaque matin, Bob et son équipe se réunissent en daily standup Blue Team Stories TODO WIP(4) DONE ~~~~~ 3 Name tags ~~~~~ 5 ~~~~~ 2 Misc. ~~~~~ 3 ~~~~~ 5
  9. 9. “Non, on ne s’assied pas durant un standup”
  10. 10. Bob insiste sur la qualité du code produit
  11. 11. Pourquoi ?NewGuy
  12. 12. Bob veut simplement éviterd’accumuler de la ‘dette technique’
  13. 13. Quand on code au plus vite et de manière non optimale, on contracte unedette technique que lon rembourse tout au long de la vie du projet sousforme de temps de développement de plus en plus long et de bugs de plusen plus réguliers Wikipedia
  14. 14. C’est un peu comme un prêt pour une maison...
  15. 15. Comment apparaît-elle ?
  16. 16. Comment la rembourser ?
  17. 17. Comment la rembourser ?En “refactorant” le code !
  18. 18. Mais pas n’importe comment !
  19. 19. Bob insiste aussi sur la pratique du pair programming
  20. 20. Quelle que soit la formule
  21. 21. 1 clavier 1 souris
  22. 22. 2 claviers 2 souris
  23. 23. 2 claviers 2 souris 2 écrans (mirroring)
  24. 24. Bob insiste également sur l’importance des tests
  25. 25. A différents niveaux de l’application
  26. 26. Le test unitaire est un procédé permettant de sassurer du fonctionnementcorrect dune partie déterminée dun logiciel ou dune portion dunprogramme. Wikipedia
  27. 27. Les tests dintégration ont pour but de valider le fait que toutes les partiesdéveloppées indépendamment fonctionnent bien ensemble de façoncohérente. Wikipedia
  28. 28. Mais au fond, à quoi ca peut bien servir, ces tests...
  29. 29. Identifier une régression
  30. 30. Vérifier des critères d’acceptance
  31. 31. Protéger une application existante
  32. 32. “Oui mais les tests ça prend du temps...”
  33. 33. C’est un investissement
  34. 34. Et une source de documentation
  35. 35. Et si on écrit ces tests avant le code, on développe différement, c’est du TDD
  36. 36. Après avoir écrit un test, on l’exécute...
  37. 37. On écrit le code minimal pour qu’il passe
  38. 38. On “refactore” le code
  39. 39. Si une régression apparaît on le voit tout de suite !
  40. 40. Exemple : les “specs” de Carcassonne
  41. 41. On peut aussi aller plus loin et faireintervenir la valeur métier du client
  42. 42. Les paires recoivent les sénarios “Lorsque je remplis le champ et“Lorsque je suis sur le menu que j’appuie sur le boutton, alorsprincipal, je dois voir l’image du le nom doit apparaître dans lajeu” liste”
  43. 43. Et écrivent leurs tests dans un langage lisible par leur client
  44. 44. Ils font du BDD
  45. 45. Avec Cucumber ou JBehave
  46. 46. Exemple : un “feature” de carcassonne
  47. 47. Dès que la fonctionnalité répond à la notion de “terminé”
  48. 48. Elle est envoyée au “système de versioning”
  49. 49. Pourquoi ? I Conflicts Back to last did commit please ! thisConflicts
  50. 50. La fonctionnalité envoyée, le serveurd’intégration continue prend le relais
  51. 51. Il va exécuter la suite de tests
  52. 52. Vérifier qu’on a pas de régression
  53. 53. Si tout passe, on déploie en “staging”
  54. 54. Afin que le client puisse tester
  55. 55. Si c’est accepté, on peut déployer en production
  56. 56. BluWeek Day Sto TO WI D ~ Na rie D P O ~ s O (4) NE Mi ~ ~ ~
  57. 57. Ce n’est pas une recette miracle, et ça ne convient pas à tout le monde...
  58. 58. Et comment on fait sur un projet existant ?
  59. 59. Adapter le processus progressivement
  60. 60. En organisant des rétrospectives
  61. 61. S’attaquer à la dette technique progressivement
  62. 62. Grâce à des “smoke tests”
  63. 63. Et la méthode mikado
  64. 64. Un peu de lecture ?
  65. 65. Encore une petite rétrospective ?
  66. 66. Questions?@agilecampustour http://agilecampustour.org

×