Given-When-Then comme pratique agile

Certains frameworks de test fonctionnel orientés vers BDD (Behaviour-Driven Development) implémentent nativement la séparation des étapes d'un test selon ce schéma :

Given / Étant donné [un contexte]

When / Quand [certains événements surviennent]

Then / Alors [on obtient les résultats attendus]

Par exemple, JBehave le propose dans son système d'annotations (@Given, @When, @Then), afin de composer l'écriture d'un "story test" en Java.

Mais ces mots-clés peuvent servir également à bien identifier les étapes à l'intérieur d'autres types de tests : unitaires ou d'intégration, avec JUnit par exemple. En effet, les annotations de JUnit ne sont pas toujours suffisantes : @Before (préparation), @Test (exécution + vérification) et @After (nettoyage) correspondent au cycle ci-dessous.

Tester en 4 étapes

Or, dans un test JUnit, rien ne distingue les étapes "Quand" et "Alors", sinon l'ordre d'écriture. De plus, quand une classe de test comporte plusieurs méthodes @Test, il est souvent nécessaire d'y ajouter quelques lignes supplémentaires pour finir la préparation du contexte ("Étant donné").

En tant que pratique, Given-When-Then a l'avantage de donner un guide pour mieux structurer son cas de test, d'inciter à n'écrire qu'un cas par méthode de test, ainsi que d'améliorer la lisibilité du code.

De manière à en généraliser l'usage, quoi de mieux que de l'intégrer directement dans son IDE ?

Avec Eclipse IDE, dans le menu "Windows / Preferences" :

• accéder au sujet "Java / Editor / Templates",
• créer un nouveau template en cliquant sur "New",
• configurer le template comme ci-dessous :
  
• dans votre méthode de test, taper tout ou partie de "givenwhenthen" et laisser l’auto-complétion faire le reste.

Il est aussi possible d'importer un template, en cliquant sur le bouton "Import" et en sélectionnant ce fichier.

Liens :

• Given - When - Then, Référentiel de l'Institut Agile

[Scrum] Casting du Product Owner

Dans un projet en mode Scrum, un bon PO, hors la définition du rôle et les aptitudes requises, doit tendre à satisfaire quelques critères que voici :

1. Être un visionnaire : Le PO porte le projet, c'est-à-dire que sa contribution devrait aider le projet à devenir un succès et guider l'équipe vers les objectifs à atteindre. Pour cela, il se sent directement concerné par la réussite ou l'échec du projet. En cas de difficultés rencontrées, il devrait agir et prendre des décisions qui relèvent de son périmètre. C'est donc l'opposition entre engagement et implication qui revient : "Engagé, je me sens concerné et je réagis ; alors qu'impliqué seulement, je me contente d'observer."
2. Maîtriser les aspects financiers du projet : Le PO connait bien les aspects financiers du projet, et devrait être capable de prioriser entre délai, périmètre et coûts. Par exemple, si le délai et le périmètre sont fortement contraints tandis que le budget est plus souple, l'équipe pourrait avoir besoin de faire intervenir ou de consulter des experts ponctuellement pour asseoir ou parvenir à une dynamique gagnante.
3. Voir Scrum aussi comme un état d'esprit, pas simplement comme une méthode alternative, en adhérant aux valeurs et aux principes véhiculés par l'Agilité.

Liens :

• Manifeste agile
• The Classic Story of the Pig and Chicken

Techniques pour amener les équipes à l’excellence

Introduction

J'ai assisté mardi soir à la conférence du même nom animée à Paris par Michel Goldenberg. Le sujet principal était la maîtrise du degré de motivation d'une équipe de développement au cours du cycle de vie d'un produit logiciel. Si Scrum propose un cadre pour gérer le suivi d'un projet, il ne répond pas à la question des moyens dont peuvent disposer un Scrum Master et une équipe pour agir sur la motivation et les performances.

A l'opposé d'une attitude managériale du type "Command & Control", le manifeste agile privilégie l'auto-organisation des équipes et la responsabilisation de leurs membres : l'objectif commun est de fournir un logiciel qui fonctionne et utile pour les utilisateurs en respectant les délais. Cela part d'un bon sentiment, l'objectif est lui-même louable, malheureusement peut-on dire que le concept tiendra en haleine la motivation des développeurs, après des mois, voire des années à suivre le cérémonial de Scrum ? En pratique, que constate-on ? Et si la démotivation doit à terme gagner les esprits comme c'est le cas dans toutes les équipes de par le monde, comment peut-on y remédier ?

Je vais donc essayer de répondre à ces questions en quelques articles, en reprenant les informations échangées lors de cette conférence.