“Specifications by examples” avec Gojko Adzic

“Specifications by examples” avec Gojko Adzic

Dans le cadre de notre amélioration continue chez Agile Partner, nous avons organisé un workshop “Specifications by exemples”. L’objectif de cet atelier, dirigé par Gojko ADZIC est de mettre en avant des compétences et techniques de communication qui permettent de combler le fossé entre les parties prenantes (Business, utilisateurs…) et les équipes de développement. Des méthodes et des modèles pour nous aider à créer des systèmes (dans notre cas, logiciels) de qualité, adaptés aux objectifs ont également été présentés durant cet atelier.

 

Qui est Gojko Adzic ?

Agojkouteur de “Specification by Example“, parmi d’autres livres influents sur les méthodologies agiles, Gojko Adzic se spécialise dans l’agilité et le Lean Quality. Il travaille avec des équipes ambitieuses pour améliorer la qualité de leurs produits logiciels et des processus, en se spécialisant dans l’agile testing, la specification par l’exemple, et le “Behavior Driven Development”.

 

La spécification par l’exemple ?

La spécification par l’exemple est une approche collaborative pour définir les besoins et les tests fonctionnels axés sur le business. Cette approche permet d’exprimer le besoin et les exigences en utilisant des exemples réalistes au lieu de déclarations abstraites. Elle est appliquée dans le cadre des P1040329méthodes de développement Agile, en particulier le “Behavior Driven Development”. C’est particulièrement efficace pour la gestion des exigences et des tests fonctionnels sur les projets de grande envergure, dans des domaines exigeants et/ou dans lesquels l’organisation (entreprise, département, business unit) est complexe.

 

Don’t trust me, I’m an engineer

Un des points les plus marquant, sûrement parce qu’il entrait en résonance avec des situations que beaucoup des participants avaient vécues, est la redéfinition des responsabilités des équipes de développement. Il est extrêmement courant que l’équipe fasse des suppositions sur le but, le périmètre, le besoin et même régulièrement sur les intentions non exprimées du client. C’est généralement le cas pour pallier à des “trous” dans la spécification, à des cas aux limites ou à un périmètre non couvert par la spécification. Or, un point qui a été répété, répété et répété est :

Il n’est pas de la responsabilité de l’équipe de présupposer les besoins du business

Un focus important a été mis sur le fait que les équipes et le business doivent travailler régulièrement et de manière collaborative à écrire les exemples permettantP1040341 d’exprimer le besoin client et aussi le non-besoin client. Le concept sous-jacent à cette notion de non-besoin est qu’il est particulièrement difficile de savoir ce que l’on veut (“une glace à quoi ?”) mais qu’il est relativement aisé de savoir ce qu’on ne veut pas (“Pas une glace au chocolat”). Pour aider le business à affiner et exprimer son besoin, le but est de lui fournir rapidement des exemples afin qu’il puisse formuler ses “plaintes” sur ce qu’il ne veut pas.

Le principe tend à rejoindre l’objectif des itérations courtes de Scrum et XP: avoir un feedback rapide du business pour pouvoir affiner la vision du produit le plus rapidement possible. Le principe est ici poussé encore un peu plus, car au lieu d’avoir un énorme pic de feedbacks (coïncidant souvent avec un gros pic de stress) à la livraison (en waterfall), ou même un pic modéré de feedbacks à la fin de l’itération, le feedback (et le stress associé) est lissé tout le long du cycle et tend, en principe, à décroître avec le temps.


Evolution du stress selon les méthodes

Spécification par l’exemple, apprentissage par la pratiqueP1040331

Plusieurs ateliers nous ont permis d’appréhender les problématiques pouvant surgir d’une spécification même dans le cas où tout le monde la trouvait simple et limpide. Gojko a fourni, expliqué et fait expérimenter plusieurs outils facilitant l’émergence de besoins clairs et également des zones d’ombres dans le périmètre d’un projet. Ces serious games ont permis de convaincre les plus sceptiques que la spécification la plus claire et la plus complète sur un besoin a priori extrêmement simple (le Blackjack) peut être remise en cause et montrer des limites et des trous énormes en moins de 30 minutes même par quelqu’un qui ne connait pas le domaine.

 

Pour plus de ressources sur les spécifications par l’exemple :

Le site de Gojko Azdic : http://specificationbyexample.com/
Le livre de Gojko : http://www.amazon.fr/Specification-Example-Gojko-Adzic/dp/1617290084
Un google group de discussion sur le sujet : https://groups.google.com/forum/#!forum/specificationbyexample
Une vidéo (en anglais) de présentation du sujet : http://gojko.net/2009/12/10/challenging-requirements/

Greg Nguyen
2 Comments

Post a Comment

Comment
Name
Email
Website