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