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

<div id="content_view" class="wiki" style="display: block"><span style="background-color: #ffffff">Auteur : The LeSS Company B.V.</span><br /> <span style="background-color: #ffffff">Source : [http://less.works/less/structure/teams.html Specification by Example - Large Scale Scrum (LeSS)]</span><br />

<br /> '''Les tests en tant qu'exigences, les exigences en tant que tests''' : Dans l'ouvrage [http://www.amazon.fr/Exploring-Requirements-Quality-Before-Design/dp/0932633137 Exploring Requirements: Quality before Design], les auteurs Gause et Weinberg creusent le lien entre exigences et tests, “l’une des manières les plus efficaces pour tester les exigences est d’avoir des cas de tests ressemblant à ceux servant à tester un système complet”. [http://gmelnik.com/papers/Melnik-Martin-Tests-and-Requirements-The-Moebius-Strip-IEEE-Software-2008.pdf Melnik et Martin] étendent cette théorie plus loin en proclamant : “Au fur et à mesure de la montée en puissance du formalisme, les tests et les exigences deviennent impossible à distinguer l’un de l’autre. À la limite, les tests et les exigences sont équivalents”. Les tests doivent être précis afin d’être automatisables. Le développement piloté par les tests d’acceptation exploite ce formalisme et reformule les exigences à travers l’écriture de tests automatisables.<br /> <br />  L'''es ateliers pour clarifier les exigences''' : Le sixième principe agile nous rappelle que “La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.” Les ateliers de clarifications des exigences en face-à-face sont utilisés depuis l’invention du [http://www.amazon.fr/Joint-Application-Development-Jane-Wood/dp/0471042994 Joint Application Design (JAD)]. Ils sont aussi utilisés en [http://www.amazon.fr/Rapid-Application-Development-James-Martin/dp/0023767758 Rapid Application Development (RAD)] ainsi que dans la méthode agile [http://www.amazon.fr/DSDM-Dynamic-Systems-Development-Practice/dp/0201178893 DSDM]. Le développement piloté par les tests d’acceptation exploite de manière similaire les conversations en face-à-face dans les ateliers pour formaliser les exigences sous la forme de tests.<br /> <br /> '''L’ingénierie concurrente''' : Les auteurs de [http://www.amazon.com/Concurrent-Engineering-Effectiveness-Integrating-Organizations/dp/1569902313 Concurrent Engineering Effectiveness] définissent l’ingénierie concurrente ainsi : “Il existe un tel lien étroit entre les participants lors du processus de développement d’un produit, qu’ils accomplissent leur travail à peu près en même temps.” Le moteur principal de l’ingénierie concurrente est le raccourcissement du temps de développement. Avoir des itérations de deux semaines c’est court, l’équipe doit trouver par conséquent une manière de travailler de façon concurrente - développer de façon séquentielle sur une itération aussi courte ne marche pas. Nous avons vu des équipes inventer des spécifications par l’exemple encore et encore, simplement parce qu’elles devaient répondre à la question “Comment pouvons-nous accomplir notre travail en même temps.”<br /> <br /> '''Plutôt prévenir que détecter''' : Dans l’une des toutes premières études sur Toyota, [http://www.amazon.fr/Study-Toyota-Production-System-Engineering/dp/0915299178 A Study of the Toyota Production System], Singeo Shingo écrit : “L’objectif de l’inspection doit être la prévention ; toutefois, pour que l’inspection puisse avoir ce rôle, nous devons changer notre manière de penser.” De manière similaire, dans [http://www.clearspecs.com/downloads/ClearSpecs16V01_GrowthOfSoftwareTest.pdf “The Growth of Software Testing,”], les auteurs identifient cinq périodes distinctes dans l’évolution du test logiciel. Ils nomment la dernière période “La période orientée prévention” et affirme “Poser des questions relatives aux tests … le plus tôt possible est souvent plus important pour la qualité logicielle et la réduction des coûts de développement que le passage des tests proprement dit.” C’est exactement ce que s’efforce de faire les spécifications par l’exemple. Lorsque des testeurs sont présents lors d’ateliers sur les exigences, ils peuvent poser des questions relatives aux tests, et de cette manière améliorer les exigences et prévenir les anomalies. Le mouvement Qualité Totale - influencé par Toyota et le développement du lean - promeut aussi la prévention plutôt que la détection.<br /> <br />  Comment fonctionne l’A-TDD ? L’illustration ci-dessous permet d’en avoir un aperçu :<br /> [[Image:a-tdd%20overview-fr.png|a-tdd overview-fr.png]]<br /> <br /> <br /> <br />  

<br />  La liste exacte dépend du produit, du contexte, des conventions de travail et de la [[LeSS%20-%20La%20D%C3%A9finition%20du%20Fini|Définition du Fini (fr)]].<br /> <br /> '''Livrer''' : Lors du passage des tests, les exigences sont revues avec le Product Owner et d’autres parties prenantes. De nouvelles exigences peuvent ainsi naître ou amener à des changements au niveau des tests existants.<br /> <br />  L’illustration ci-dessous décrit plus en détails le développement piloté par les tests d’acceptation<br /> <br /> [[Image:a-tdd%20in%20more%20details-fr.png|a-tdd in more details-fr.png]]<br /> <br /> <br />  Les étapes pour que les développements pilotés par les tests d’acceptation s’intègrent harmonieusement dans le cycle LeSS :<br /> <br /> [[Image:a-tdd%20steps-fr.png|a-tdd steps-fr.png]]<br /> <br />  Intégration des étapes du développement piloté par les tests d’acceptation dans le cycle itératif Scrum.<br /> <br /> ''Discuter en atelier'' : Avant de faire une Planification du Sprint détaillée, l’équipe, le Product Owner, et les autres parties prenantes clarifient les exigences de manière collaborative lors d’un atelier.<br /> <br /> ''Développer de manière concurrente'' : Les tâches permettant d’implémenter les tests/exigences sont créées lors de la Planification du Sprint détaillée et implémentées lors de l’itération. Toutes les activités se déroulent “à peu près en même temps”.<br /> <br /> ''Livrer pour acceptation'' : L’incrément opérationnel du produit — les tests d’acceptation passants — sont livrés pour acceptation aux parties prenantes et discutés avec tous lors de la Revue de Sprint.<br /> <br />  

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