AgileCampusTour
@mlainez
@mlainez
@cimm
@jbpros
Julien Biezemans
Simon Schoeters
Marc Lainez
La fine équipe
Si vous voulez tweeter utilisez le hashtag #actbe
Souvenez-vous de Bob
Le projet sur lequel il travaille
Week DayStories
TODO
WIP
(4)
DONE
~~~~~
Na
Mi
Blu
Et sa vision du déroulement d’un tel projet
Week DayStories
TODO
WIP
(4)
DONE
~~~~~
Na
Mi
Blu
Et sa vision du déroulement d’un tel projet
Comment se passe le développement au jour le jour ?
Chaque matin, Bob et son équipe se réunissent en daily standup
Stories TODO WIP(4) DONE
~~~~~3
~~~~~5
~~~~~ 2
~~~~~3
~~~~~5
Name tags
Misc.
Blue Team
“Non, on ne s’assied pas durant un standup”
Bob insiste sur la qualité du code produit
Pourquoi ?
New Guy
Bob veut simplement éviter d’accumuler de la ‘dette technique’
Quand on code au plus vite et de manière non optimale, on contracte une dette technique que l'on rembourse tout au long de la vie du projet sous forme de temps de développement de plus en plus long et de bugs de plus en plus réguliers
Wikipedia
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 s'assurer du fonctionnement correct d'une partie déterminée d'un logiciel ou d'une portion d'un programme.
Wikipedia
Les tests d'intégration ont pour but de valider le fait que toutes les parties développées indépendamment fonctionnent bien ensemble de façon cohérente.
Wikipedia
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 faire intervenir la valeur métier du client
“Lorsque je suis sur le menu principal, je dois voir l’image du jeu”
“Lorsque je remplis le champ et que j’appuie sur le boutton, alors le nom doit apparaître dans la liste”
Les paires recoivent les sénarios
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 ?
Conflicts
Conflicts
Back to last commit please !
I did
this
La fonctionnalité envoyée, le serveur d’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
Week DayStories
TODO
WIP
(4)
DONE
~~~~~
Na
Mi
Blu
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 ?
http://agilecampustour.org@agilecampustour
Questions?