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

<br />  Les gens sont souvent préoccupés par avoir des livrables tangibles lors d’un atelier - les tests - et ils oublient les effets intangibles - la connaissance. La compréhension et la clarté des exigences sont les livrables clés d’un atelier sur les exigences ; les tests en sont l’expression.<br /> <br />  Il ne s’agit pas d’une fausse dichotomie. Les tests sont importants et cette technique s’appelle le développement piloté par les tests d’acceptations. Sans tests, il s’agirait juste d’un atelier sur les exigences - mais cela permet d’éviter de confondre la fin avec les moyens.<br /> <br />  

===Exemples d’utilisation===

* ''“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 />  

<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 />