atdd

Documentation contractuelle et Scrum

La transition à Scrum dans un contexte de gouvernance et de modèle économique imposant habituellement une production abondante de documents. J’accompagne une équipe Scrum dans un contexte où de la documentation est exigée lors de jalons contractuels. Au départ, il s’agit d’un appel d’offres dans un domaine industriel. L’appel d’offres est classique -pas agile- et la réponse a proposé un développement avec une méthode agile. Le développement se fait avec Scrum, mais en plein accord avec l’émetteur de l’appel d’offres, ce qui laisse, heureusement, une marge de manœuvre par rapport aux jalons et à la documentation à fournir.

Les tests, un moyen d'améliorer la communication

Les tests d’acceptation (au sens agile) remplacent une spécification fonctionnelle détaillée. Avec un bénéfice essentiel : la communication est facilitée entre le métier et le développement. Vendredi dernier, à la conférence agile de Toulouse, il y avait un retour d’expérience sur les tests dans un projet agile. Il y a été question essentiellement des tests d’acceptation. Et de pilotage par les tests d’acceptation (ATDD). D’abord une précision : le terme acceptation ne doit pas être compris comme dans acceptance test ou UAT, phase à la fin d’un projet pour obtenir la signature du client, comme confirmation qu’il accepte le produit livré.
Pilotage par les tests d'acceptation

Pilotage par les tests d'acceptation

Méta-modèle

Après le TDD, voici l’ATDD. Dans l’épisode précédent, nous avions vu qu’une story était un élément du backlog de produit. Un principe, dans toutes les méthodes agiles, est qu’une story soit réalisée en une itération. Mais comment savoir si elle est vraiment finie à la fin de l’itération ? C’est la responsabilité du product owner d’accepter ou pas une story. Pour cela, le moins qu’il puisse faire est de définir ses conditions de satisfaction.