Skip to content

Blogs de Développeurs: Aggrégateur de Blogs d'Informatique sur .NET, Java, PHP, Ruby, Agile, Gestion de Projet

Forum Logiciel

Forum Logiciel : diffusion de connaissance et d’informations sur toutes les activités liées au développement d’applications informatiques en entreprise.

Architecture, Agilité, C++ "in the mix" - Le blog de Mathieu Cans
Syndiquer le contenu
Le blog de Mathieu Cans
Mis à jour : il y a 6 heures 21 min

Specification by example et documentation vivante

dim, 09/11/2016 - 20:22

Specification by example & documentation vivanteEn 2015,  avec Brice nous avons prĂ©sentĂ© une session Ă  Agile Grenoble intitulĂ©e “Specification by example : venez assister Ă  la naissance d’une documentation vivante”. Depuis nous avons prĂ©sentĂ© Ă  plusieurs reprises cette session qui est Ă  chaque fois accueillie avec enthousiasme. Elle se compose en 3 parties : prĂ©sentation de la thĂ©orie, un exemple concret interactif et un retour d’expĂ©rience. La collaboration Ă©tant ag15_logo_speaker_blancau cĹ“ur de ce processus, cette mĂ©thode implique tous les intervenants d’un projet : analystes mĂ©tier, dĂ©veloppeurs, testeurs et managers.

Des exemples utiles à différentes phases du projet

Comme l’explique le livre de Gojko Adzic, travailler avec des exemples est intéressant lors des différentes phases du projet :

  • ComprĂ©hension partagĂ©e : en amont du dĂ©veloppement, travailler avec des exemples permet de lever des ambiguĂŻtĂ©s et de s’assurer que l’on parle bien des mĂŞmes choses. De plus si tous les intervenants sont impliquĂ©s Ă  cette phase, cela joue aussi sur la dynamique d’équipe.
  • Acceptance test : dès le dĂ©but du dĂ©veloppement, l’exemple est entrĂ© dans l’outil d’automatisation. Il devient un « acceptance test » de la double boucle TDD. Il prend alors un  rĂ´le de pense bĂŞte : il reste rouge tout le long du dĂ©veloppement et passe vert lorsque le logiciel satisfait toutes les exigences.
  • Regression test: une fois vert l’exemple change encore d’objectif. Il sert maintenant Ă  dĂ©tecter les rĂ©gressions. Un bon exemple nous indique dans quelle fonctionnalitĂ© s’est glissĂ© le bug.
  • Documentation vivante: un autre aspect est maintenant de jouer un rĂ´le  documentaire de l’application. Cette documentation Ă©volue en mĂŞme temps que le logiciel et est vĂ©rifiĂ©e en continu.  Il arrive parfois que l’ajout d’une fonctionnalitĂ© rende obsolète certaines contraintes qui avaient Ă©tĂ© ajoutĂ©es prĂ©cĂ©demment. En passant rouge, les exemples nous indiquent l’impact du changement.
Où se trouve la poule aux œufs d’or ?

8218-FX-6-0-13-6-9-0-90-5-5-95-95Cette mĂ©thode n’est pas magique. Son implĂ©mentation demande des efforts et un changement culturel. Aussi j’insiste rĂ©gulièrement sur le fait que cette mĂ©thode apporte Ă©normĂ©ment de valeur sur l’Ă©tape de comprĂ©hension partagĂ©e et de documentation vivante.

A mon sens, il n’y a pas d’autres mĂ©thodes qui challengent autant l’expression du besoin et la documentation. Aussi comme trop d’information tue l’information, quand je suis face Ă  des questions sur l’exhaustivitĂ© oĂą la qualitĂ© des exemples, j’essaye d’identifier Ă  quelle phase profite l’exemple. Si j’investis sur la documentation, l’exemple a certainement de la valeur. Par contre si je rajoute des exemples uniquement pour me protĂ©ger de la rĂ©gression, j’essaye de voir si je ne peux pas les rajouter dans d’autres tests (robustesse, intĂ©gration, etc…)

La phase de compréhension partagée porte en elle même beaucoup de valeur. A cette étape c’est le besoin qui est challengé. Les « product owners » doivent illustrer le besoin par des exemples concrets. En ayant des représentants de l’équipe métier, développement et test, l’interaction des différents points de vue va enrichir l’idée initiale.

Dans l’exemple pratique de la présentation, nous tentons d’illustrer l’impact du changement en ajoutant une règle qui est incohérente avec une autre. Sur cette simulation cela semble simpliste, mais nous avons récemment vécu cette illustration :

Nous voulions légèrement modifier un calcul affiché à l’écran. Il était difficile, tant le système était complexe, de détecter que cela rendait obsolète une autre fonctionnalité.

Pour moi l’efficacitĂ© de cette mĂ©thode est Ă  rapprocher du principe « Mutal Benefit » de eXtrem Programming : une mĂŞme activitĂ© (la rĂ©daction d’un exemple) apporte de la valeur dès l’instant prĂ©sent. Le principe est d’Ă©crire un exemple parce que cela est utile maintenant pour dĂ©finir ce que doit faire l’application. Pas uniquement parce qu’un jour il va potentiellement servir. En automatisant la vĂ©rification de l’exemple on rĂ©cupère les fruits de cet investissement tout au long de la vie du projet.

Emblem-question.svgLes questions qui reviennent souvent

Lors de nos diverses présentations certaines questions sont récurrentes. En voici quelques-unes :

  • Vous parlez de pyramide des tests, n’êtes-vous pas en train de faire une pyramide inversĂ©s ?
    • Effectivement, le nombre d’exemples augmente avec le temps et le besoin de documentation. Cependant ce n’est qu’une partie des tests. Nous nous en servons comme test d’acceptance et de nombreux tests unitaires sont Ă©crits en mĂŞme temps que le code. Notez que cette documentation est très utile pour les testeurs pendant les recettes lors des phases de livraison.
  • Est-ce que l’approche est similaire Ă  celle du TDD ? C’est-Ă -dire que si on n’arrive pas Ă  tester c’est qu’il y a un problème de design ?
    • Par le fait d’automatiser des exemples, il y a forcĂ©ment une influence sur le design. Cependant ce n’est pas son objectif, le besoin est beaucoup plus chahutĂ© par cette approche. Si le besoin n’est pas très clair, on a une opportunitĂ© de s’en rendre compte dès la phase de comprĂ©hension partagĂ©e. A ce stade le changement coĂ»te moins cher.
  • A propos de l’impact au changement, n’y a-t-il pas moyen de l’identifier avant le dĂ©veloppement ?
    • Effectivement si une incohĂ©rence n’a pas Ă©tĂ© levĂ©e lors de la 1ère phase, ce n’est que lorsque le code va ĂŞtre modifiĂ© que l’on va savoir quel est l’impact du changement. Cependant comme cette incohĂ©rence est connue, cela permet de statuer et de mettre Ă  jour la documentation. On a alors une nouvelle source de vĂ©ritĂ© sur ce que fait l’application (l’autre Ă©tant le code).
  • Quel est le coĂ»t pour la mise en place de cette mĂ©thode ?
    • Ce n’est pas facile de rĂ©pondre Ă  cette question quantitativement. Cela dĂ©pend de l’organisation mise en place. Sur notre projet, les dĂ©veloppeurs ont pris en charge une bonne partie (~20-30% temps de dĂ©veloppement). Cependant tout le monde s’accorde pour dire que cela vaut le coup : l’application a peu de bug, il y a moins d’incomprĂ©hension. C’est aussi l’unique documentation utilisĂ©e par le mĂ©tier, les dĂ©veloppeurs et les testeurs.

J’espère vous avoir donné envie de tenter l’aventure Specification by example. La présentation est disponible sous SlideShare et le code sous GitHub.

The post Specification by example et documentation vivante appeared first on Agilité, Architecture, C++ "in the mix".

Catégories: Blog Individuel

Partagez la connaissance

Partagez BlogsdeDeveloppeurs.com sur les réseaux sociaux