session mons 22 mars

AgileCampusTour

@mlainez

@mlainez

@cimm

@jbpros

julien@agilecampustour.org

simon@agilecampustour.org

marc@agilecampustour.org

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?