Intro to Specification By Example (Sebastian Heglmeier, improuv)
Transcrição
Intro to Specification By Example (Sebastian Heglmeier, improuv)
Word must Die Intro to Specification By Example Sebastian Heglmeier „Was macht die Software eigentlich im Fall xy?“ o o o o steht in der Doku keine Ahnung, vielleicht gibts nen Test dafür puh, mal im Code nachsehen da musst den Huber Franz fragen (aber der hat letztes Jahr gekündigt) Problem: mehrere Quellen der Wahrheit, Code als letzte Instanz Wie schnell gibts Feedback, ob das neue Feature richtig implementiert ist? o o o o o Automatisierte (Akzeptanz)Tests (Entwickler) Manuelle Tests (Tester) Review (PO, Stakeholder) QA (Biz, Orga) Bug in Produktion (Kunde) Probleme • • Zeitverluste durch zu spätes Feedback gemeinsames Verständnis zwischen Biz und Entwicklern Specification By Example • Erfunden von Gojko Adzic http://gojko.net/ • Prozesskette • Anfang: Spezifikation • Ende: Lebende Dokumentation • Löst die vorher beschriebenen Probleme © Gojko Adzic Deriving Scope from Goals [Aufgaben aus den Businesszielen ableiten] Projects fail since the requirements are bad (Jerry Weinberg) • Das Richtige machen • Impact Mapping • User Story Mapping • Feature Injection • Die Richtigen fragen • Entwickler kennen Produkt oft besser als das Biz. • Domain Expert und Decider sind unterschiedliche Leute • Zusammen den Scope erstellen! Gibb-Drexler-Weisboard Team Building Process Biz Goal <- Why <-> Who <-> What <-> How -> User Story / Epic http://de.slideshare.net/ek_artem/impact-mapping-for-startups# http://de.slideshare.net/ek_artem/impact-mapping-for-startups# Specifying Collaboratively We don‘t work with business enough (Ward Cunningham) Specification Workshop • PO(s), Stakeholder, Entwickler, Tester • Benefits: – Gemeinsame Sprache – Gemeinsames Verständnis entwickeln (Biz- und Tech-Modell angleichen) – Unnötiges Nochmal-Machen-Müssen vermeiden • Wichtig: gute Fragen stellen, um die BusinessModell-Entscheidungen herauszufinden Illustrate using Examples Small Diffferences in Understanding can have a huge cumulative effect (Gojko Adzic) • Bisher: Requirements interpretieren • Jetzt: Schlüsselbeispiele und Grenzfälle oder problematische Stellen im System • Ziel: Requirements mit Schlüsselbeispielen ersetzen Refining the Specification • Beispiele von Biz Users oft aus Interface Perspektive (What vs How) • Beispiele zu groß (Divide the Complexity) • Zu viele Beispiele (Find Hidden Concepts) • Spec & Beispiele wie Code refactoren – DRY, SRP, SLA, Principle of Least Surprise • Ziel: Beispiele als Acceptance Criteria • Zusätzliche Info zu den Beispielen macht sie leichter verständlich (erster Schritt Richtung Living Documentation) Schlechte Specs • • • • • Falscher Abstraktionsgrad / fehlende Konzepte Fehlender Kontext / kein guter Start / kein Fokus Zu technisch / Skript / zu viele Details / komplizierte Sätze Unnötige Beispiele / irrelevante Daten Inkonsistente Sprache Gute Specs • • • • • • Beschreiben klar ein Businessziel Sind leicht zu lesen Strukturierte Testdaten Klares Format Verstecken unnötige Komplexität Kurz und bündig Automating Validation without changing the specification • Problem: automatisierte Specs für Business User unzugänglich • Es gibt mehr als eine Version der Wahrheit • Ziel: Business Sprache & Konzepte genauso in Tests übernehmen • Frameworks: Cucumber, jbehave, jasmine, SpecFlow, Concordion, Fitnesse, ... Tests are Specs, Specs are Tests! Tests in „Gherkin“ Glue Code in e.g. Java Visualization for PO Feature: Kapazität des Ausgabefachs begrenzt Validate Frequently Vorher: • Funktionierts? Im Code gucken! • Entwickler: Orakel & Informationssenken Jetzt: • Verständliche Tests • Oft laufen lassen und Vertrauen aufbauen • Tests als „Single Source of Truth“ Evolving a Documentation System [...] this kind of tests is a good opportunity [...] not a two feet high pile of paper. This is something lighter [...] That‘s real documentation (André Brissette) Lebende Dokumentation ist • gut organisiert • leicht zu finden • konsistent --> „Replaces all the artifacts that teams need for delivering the right product (Gojko Adzic)“ Living Documentation Keine Zukunftsmusik... sondern es funktioniert schon! jasmine.gibhub.io Concordion