« LeSS - Spécifications par l'exemple » : différence entre les versions

* ''“Pouvez-vous me donner un exemple ?”''

<br />  Cette question peut soudainement transformer une discussion vague et abstraite en une question claire et concrète. Lors de la discussion sur de nouveaux produits, les gens ont tendance à parler en termes abstraits et conceptuels. Ils débattent les uns avec les autres sans se comprendre - ils restent bloqués. Demander des exemples ramène la discussion à la réalité.<br /> <br />  Par exemple, nous entendons des affirmations telles que “Le système doit se remettre des situations d’erreurs”. C’est plutôt vague, nous demandons donc des exemples qui vont modifier la discussion. Cela pourrait être “Lorsque nous débranchons le câble, le système ne devrait pas tomber en panne” - ce qui est plus concret et plus compréhensible. Les exemples sont aussi utilisés pour avoir davantage de clarifications, tels que, “Comment le système devra t’il se remettre si nous enlevons une unité du système lorsque celui-ci est en train de marcher ?”.<br /> <br />  Examples are not just useful for clarifying requirements but also for clarifying ways of working. “We could never automate all our tests!” is something we would follow up with “Can you give me an example of a non-automatable test?” and that moves the discussion away from principle and into practice.<br /> <br />  Les exemples ne sont pas seulement utiles pour clarifier les exigences mais aussi pour clarifier les manières de travailler. “Nous ne pourrons jamais automatiser tous nos tests !” est une phrase à laquelle nous devrions répondre par “Pouvez-vous me donner un exemple d’un test non-automatisable ?” et ainsi progressivement déplacer le sujet de la discussion du principe vers la pratique.<br /> <br /> [[Image:a-tdd%20examples-fr.png|a-tdd examples-fr.png]]<br /> <br />  L’illustration ci-dessus montre les relations entre les exemples, les exigences et les tests. Lors des ateliers sur les exigences, l’utilisation des exemples pour élaborer les exigences et les transformer en tests.<br />  

==="N'optimisez" pas l’atelier sur les exigences===

<br />  Alors que nous étions en train de discuter d’A-TDD avec un groupe produit important, ce dernier a noté, “Nous avons amélioré l’atelier d’A-TDD. Seules trois personnes y participent : le Product Owner, le Scrum Master, et un spécialiste de l’équipe”. Nous leur avons demandé comment les autres membres de l’équipe pourraient être en mesure comprendre les exigences afin de pouvoir les implémenter et la réponse fut “Le spécialiste leur dira”. Ils ont ‘optimisé’ l’atelier en réintroduisant le traditionnel transfert de connaissance analyste-équipe comme avant.<br /> <br />  

===Éviter d’utiliser des ordinateurs et des projecteurs lors d’un atelier===

<br />  Les ordinateurs pompent l’énergie vitale des ateliers. Ils deviennent le centre de la discussion. À part pour vérifier certaines informations, éviter donc d’avoir le besoin d’‘optimiser l’atelier en travaillant directement sur ordinateur. À la place …<br />  

===Condenser le flux de travail en règles métiers===

<br />  La clarification des exigences lors des ateliers commence souvent avec des concepts abstraits, et puis lorsque des exemples sont mis sur la table, la focale de la discussion se déplace vers des discussions sur le flux de travail - “Lorsque j’utilise le système, je fais l’étape un, puis l’étape deux, et je m’attends à obtenir comme résultat X.”.<br /> <br />  Il peut arriver que ces exemples de flux de travail soient similaires à l’exception de quelques variations sur une ou deux étapes. Les tests des flux de travail contiennent des règles métiers cachées, qui peuvent être extraites et insérées dans un test orienté données. Cela recentre la discussion sur la clarification du domaine et permet de réduire la complexité en supprimant des détails superflus.<br />  

===Des tests sur les murs===

<br />  L’endroit idéal pour les tests c’est sur le mur - euh, du moins avec un tableau blanc entre les tests et le mur. Ce qui est écrit ou dessiné sur le tableau blanc sont enregistrés à l’aide de photos. Après l’atelier, les tests peuvent être distillés et retranscrits dans un outil.<br /> <br /> [[Image:a-tdd%20testwall1.jpg|a-tdd testwall1.jpg]]<br /> <br /> [[Image:a-tdd%20test-wall2.jpg|a-tdd test-wall2.jpg]]<br />  

===De l’utilisation du format table===

<br />  Exprimer des règles métiers sous la forme de tables permet de les rendre plus compréhensibles et aident à trouver des cas manquants. Les tables encouragent la clarté de la réflexion. [http://link.springer.com/chapter/10.1007/978-3-7091-6510-2_12#page-1 David Parnas, expert en informatique est un promoteur de longue date] de l’utilisation des tables dans la documentation des exigences.<br />  

===De l’utilisation des tests de flux de travail===

<br />  Récupérer les règles métiers et faire des tests pilotés par les données ne peut pas toujours se faire ni même s’avérer souhaitable. Certaines exigences s’avèrent tout simplement bien mieux exprimées sous la forme de l’exemple d’un flux de travail (un scénario comportant plusieurs étapes). Les tests des règles métiers pilotés par les données peuvent souvent être complétés par des exemples de flux de travail qui, en un certain sens, permettent de les relier.<br /> <br />  Attention : lorsque la plupart de vos tests sont des tests de flux de travail, alors il est très probable que vous ayez manqué certaines règles métiers<br />  

===Agenda type d’atelier===

<br />  Comment se structure un atelier A-TDD sur les exigences ? Nous suivons fréquemment l’agenda suivant :<br />  

==Développer de manière concurrente==

<br />  Après que les exigences aient été éclaircies, elles doivent être implémentées. Les différentes activités nécessaires à l’implémentation sont faites de manière concurrente. En même temps, l’équipe étoffe les tests tout en implémentant le code, en écrivant la documentation, en mettant à jour la description de la conception, et ainsi de suite.<br />  

===Distiller les tests===

<br />  De nombreux exemples sont créés pendant l’atelier sur les exigences. Tous les exemples ne deviennent pas des tests - seuls les éléments essentiels des exigences sont distillés sous la forme de tests. Les éléments non essentiels ou en doublons sont écartés - ils ont rempli leurs rôles pendant l’atelier d’accroissement des connaissances.<br /> <br />  Comment à partir des exemples en distiller des tests ? Voici quelques techniques :<br /> <br />  

* '''Classe d’équivalence''' — Certains exemples font partie de la même classe d’équivalence et donc un seul test peut s’avérer suffisant. La présence de testeurs spécialisés est tout spécialement bienvenue, étant donné que le partitionnement par classe d’équivalence est une technique de tests classique.

* '''Acceptation''' - Étant donné que tous les exemples ne sont pas d’égale importance, il convient de demander au Product Owner “Quels sont les exemples que vous voulez voir fonctionner à la fin de l’itération ?”

===Faites-vous accompagner de facilitateurs et de coachs spécialisées en A-TDD===

<br />  L’A-TDD est facile à faire, et difficile à adopter. Cela exige de remettre en question des postulats ancrés profondément et des changements d’habitudes. Un coach (externe) ayant de l’expérience en A-TDD et en changements organisationnels s’avèrent souvent nécessaire pour l’adopter. Trouvez un coach.<br /> <br />  Il est important de réaliser que les compétences d’un bon coach en A-TDD sont différentes de celles d’un bon coach en TDD. Le coaching en TDD est davantage technique, et davantage focalisé sur les développeurs, alors que l’A-TDD concerne toute l’équipe. En plus d’avoir des compétences techniques, un bon coach en A-TDD possède aussi d’excellentes compétences en facilitation d’ateliers.<br />  

===Utiliser un outil d’A-TDD===

<br />  

===N’utilisez pas les outils conventionnels pour faire du développement piloté par les tests d’acceptation===

<br />  Some product groups we worked with try to use their conventional test tools such as Lisp-based scripts or TTCN for A-TDD. This invariably fails. Why? A-TDD-style tests are created so that the Product Owner or user can read and understand the tests. But the test format—scripts—of these conventional tools are created for testers and are thus unsuitable for documenting requirements. It is nearly impossible to involve the Product Owner in writing examples using such tools.<br /> <br />  Certains des groupes de produits avec lesquels nous travaillons essayent d’utiliser des outils de tests conventionnels tels que des scripts en Lisp ou des notations de tests et de contrôle de tests (NdT : pour plus d’informations sur ces notations consultez https://fr.wikipedia.org/wiki/TTCN) adapté à l’A-TDD. Tout cela échoue invariablement. Pourquoi ? Le style des tests pour l’A-TDD est fait afin que le Product Owner ou que l’utilisateur puisse lire et comprendre les tests. Mais le format de type des scripts des tests de ces outils conventionnels sont faits pour un testeur professionnel et s’avère donc inapproprié pour la documentation d’exigences. Il est presque impossible d’impliquer le Product Owner dans la rédaction d’exemples avec de tels outils.<br />  

===Mais à la place utilisez un outil dédié à l’A-TDD qui servira d’intermédiaire aux outils de tests conventionnels===

<br />  Devez-vous abandonner tous les outils conventionnels de tests lorsque vous adoptez l’A-TDD ? Peut-être pas.<br /> <br />  Un groupe de produits, dédié aux graphismes, avec lequel nous avons travaillé avait passé plusieurs années à mettre en place un langage de scripts afin d’automatiser leurs tests. Cela devrait leur prendre quelques années de plus pour développer du code permettant de faire le liant (bibliothèques de tests ou fixtures) entre le framework A-TDD et leur système en tests - d’ailleurs la majeure partie de ce code sera du même acabit que ce qu’ils ont pu faire avec leur langage de scripts.<br /> <br />  Une alternative est de laisser le code faisant le liant d’englober leur langage de scripts et ainsi de réutiliser le travail déjà fait. Les outils conventionnels de tests ne sont pas nécessairement de mauvais outils, mais simplement ils fournissent le mauvais format - le mauvais langage - permettant d’avoir des spécifications exécutables.<br /> <br />  

==Livrer pour acceptation==

<br />  Le code est implémenté et tous les tests passent. Et ensuite ? Le cycle d’A-TDD, comme celui de Scrum, renferme un cycle d’inspection-adaptation dans lequel les résultats sont livrés aux parties prenantes, qui en inspectent les effets à travers les tests et qui décident comment procéder - quelles exigences seront implémentées par la suite.<br />  

===Montrer les tests lors de la Revue de Sprint===

<br />  Lors d’une Revue de Sprint, l’équipe démontre des progrès visibles au Product Owner en montrant ce qui a été produit lors de l’itération.<br /> <br />  Nous avons travaillé avec certains groupes pour définir les étapes de la démo pendant la Planification du Sprint. Une équipe passait un temps disproportionné en préparation de démo. Un gaspillage total.<br /> <br />  Lors de la Planification du Sprint, une alternative possible est de définir les exemples qui doivent passer et montrer les progrès en utilisant les tests lors de la Revue de Sprint.<br />  

==Ouvrages recommandés==

<br />