Menschenverständliche Spezifikationen sind der Schlüssel zu besserer Software

Liebe Führungskraft,

Seid ihr es leid, am Tag, an dem ihr ein IT-System oder einen Service für Endnutzer erwartet, Ausreden aus der IT- oder R&D-Abteilung zu hören wie „Da ist etwas dazwischengekommen“ oder „Das war unerwartet“?

Was ist passiert? Sagt euch die Delivery-Organisation, dass eure Anforderungen nicht ausreichend waren, obwohl ihr den Endkunden in die Planungsphase einbezogen habt?

Was wäre, wenn ihr die Ursache all dieser Probleme finden könntet?

Wir alle möchten wertvolle Software für Menschen entwickeln – in einer Welt voller fehleranfälliger Prozesse, Expertenvoreingenommenheit und organisatorischer Herausforderungen. Mein Kollege Tatu hat eine sehr gute Einführung in ATDD und TDD geschrieben, die erklärt, worum es dabei geht und wie diese Ansätze einer Organisation helfen, „nach links zu verschieben“.

Schauen wir uns die Probleme genauer an, die entstehen, wenn zu spät geplant wird und eure geschäftlichen Anforderungen (Spezifikationen) nicht mit der Definition of Done verknüpft sind.

Die Definition of Done ist die treibende Kraft von Agile

Selbst mit Agile-Methoden kann es äußerst schwierig sein, sich auf echten Kundennutzen zu konzentrieren.

Wenn Softwareorganisationen aus Business und IT/R&D ihre agile Transformation beginnen und wirklich Agile arbeiten, ist die Unklarheit rund um den Begriff Definition of Done (DoD) in Bezug auf die Anforderungen der Endnutzer ein sehr häufiges Problem. Anders gesagt: Wie stellt ihr sicher, dass ihr aus Sicht der Anforderungen das Richtige umsetzt?

Eine minderwertige DoD kann ein Symptom vieler Probleme sein. Meist bedeutet sie, dass ihr keine gute Methode habt, um eure Akzeptanzkriterien für Endnutzer präzise zu formulieren.

Ich würde sagen: Wenn eure UX-Designer, Entwickler, Betriebsteams und Tester im Demo-Meeting über die Korrektheit der Features streiten, habt ihr jede Menge unnötigen Code und technische Schulden in eurem Softwareentwicklungsprozess. Diese Schulden werden in Softwareprojekten häufig als „Verschwendung“ bezeichnet.

Ein Demo-Meeting sollte als Review-Schritt genutzt werden, um die DoD eurer Arbeitselemente zu prüfen. Außerdem könnt ihr Endnutzern das Ergebnis zeigen und Feedback für kommende Sprints einholen.

Planung ist tot – und doch nicht

Als Entwickler und Ingenieur für automatisierte Tests habe ich agile Transformationen auf die harte Tour erlebt. Nachdem die Agile-Evangelisten „das Gebäude verlassen“ und erklärt haben, es gebe „keine technische und spezifikationsorientierte Vorplanung“ (das haben wir alle schon gehört ...), bleibt ihr ziemlich hilflos zurück. Wie richtet ihr eure täglichen Aktivitäten aus und kommuniziert klar, was aus Business-Sicht erledigt werden muss, damit Features und Epics bereit für die Demo sind?

Und denkt daran: Eine User Story ist keine Spezifikation!

Die Probleme werden noch deutlicher, wenn ihr den eigentlichen Release vorantreiben wollt. Die Kommunikation dreht sich plötzlich um End-to-End-Anwendungsfälle, obwohl ihr euren Release abschließen solltet – und zu diesem Zeitpunkt sind solche Überlegungen meist zu spät.

Natürlich ist die Kommunikation einfacher, wenn weniger als zwanzig Personen an eurem Service oder Produkt für Endnutzer arbeiten – einschließlich aller Stakeholder. Aber wenn es mehr Personen sind, gilt: Mehr ist nicht unbedingt besser.

Ohne eine klare Vision – die DoD für Endnutzer – für eure Agile-Methode (Scrum oder Kanban) fehlt euch der nötige Fokus für die Entwicklung. Außerdem fehlt euren Teams eine klare Richtung.

Das Chaos ohne ein klares, systemweites Ziel

Wenn euch das bekannt vorkommt, gibt es wahrscheinlich Verbesserungspotenzial in eurer Planung. Unzureichende Spezifikationen und fehlende geeignete Tools, um diese Spezifikationen auf Agile Weise zu verifizieren – also ohne Testautomatisierung auf Business-Ebene mit Fokus auf Endnutzer –, behindern euch, obwohl das heute nicht mehr nötig sein sollte.

Ich möchte es noch einmal betonen: Wenn eure Planung chaotisch ist, gebt ihr Menschen Raum für Annahmen – und das ist gelinde gesagt riskant. Technische Probleme sind meist nicht das eigentliche Problem. Es sind die geschäftlichen Anforderungen und deren Tests.

Ein klares Zeichen dafür, dass ihr „Mini-Waterfall“ oder „Scrum, But“ betreibt, ist, wenn Implementierung und Tests in unterschiedlichen Sprints stattfinden – ohne klare funktionale Spezifikationen, die über Stichpunkte in einem Word-Dokument hinausgehen.

Niemand möchte die dadurch verursachte Verschwendung und technischen Schulden. Ihr könnt euer Projekt eine Zeit lang so betreiben, aber weitere Änderungen darauf aufzubauen, führt letztlich zu einem System, das weder nutzbar noch wartbar ist.

Denn DevOps möchte Verschwendung vermeiden

Ein Thema, das in der DevOps-Literatur immer wieder auftaucht, ist die Beseitigung von Verschwendung. Etwas völlig Falsches zu tun, ist die größte Quelle für Verschwendung – und liegt in niemandes Interesse!

Bei schlechter Planung braucht ihr Methoden und Tools, um den Mehrwert für Endnutzer zu validieren und diese Werte so schnell wie möglich zu testen.

Specification by Example mit Gherkin und Robot Framework

Wenn Softwareentwickler nicht genug Aufwand in die Spezifikationsarbeit investieren, führt das letztlich zu enormer Verschwendung von Zeit und Geld.

Spezifikationen braucht ihr auch in der Agile-Welt! Entscheidend ist jedoch: Ihr müsst sie so erstellen, dass ein Mensch sie verstehen kann. Denn technische Spezifikationen für Endnutzer verständlich zu machen und mit ihnen zusammenzuarbeiten, steht im Mittelpunkt agiler Methoden. Besonders in großen und komplexen Organisationen, in denen nicht jeder Softwareentwickler ist.

Mit Specification By Example (SBE) könnt ihr ein klares Verständnis des Problems und einer passenden Lösung dafür entwickeln.

1. Kombiniert SBE und Design Thinking, um eine gute Lösung für das validierte Geschäftsproblem zu erkunden und auszuwählen.

2. Als Ergebnis habt ihr das Verhalten der Endnutzer im Gherkin-Syntaxformat (Given, When, Then) dokumentiert – beginnt zunächst mit einigen „Sunny Cases“.

3. Nach gemeinsamen Workshops zu diesen Anwendungsfällen im Gherkin-Format habt ihr einen klaren User Flow, den ihr implementieren und testen könnt.

Als Nächstes kommt die Stärke und Eleganz eines keyword-gesteuerten Test-Frameworks wie Robot Framework ins Spiel. Ihr könnt die Automatisierung direkt hinter diesen Schritten implementieren. So entsteht ein systemweiter E2E-Testfall, der gleichzeitig eure Spezifikation der Geschäftsanforderungen ist.

Jetzt nutzt ihr Acceptance Test Driven Development (Abbildung 2)! Davon profitieren nicht nur Test- und QA-Teams: Das gesamte Projekt verfolgt nun ein klares Ziel.

Ein gemeinsames Verständnis sorgt für Effizienz und Fokus im Entwicklungsprozess.

Eine klare Definition of Done schafft Fokus

Meiner Erfahrung nach können Sprint-Planung und -Umsetzung kaum reibungsloser laufen, wenn ihr eure funktionalen und technischen Spezifikationen so handhabt.

Besonders während des Sprints wird die nötige Ruhe und Konzentration möglich, wenn ihr die DoD vor der Demo/Review erreicht. Damit dieser Workflow für euer Team funktioniert, braucht es viel Disziplin von allen Beteiligten – ja, besonders vom Business Owner und den Product Owners. Alle Beteiligten benötigen Schulungen. Gerade am Anfang sollten die Stakeholder die ersten Workshops persönlich vor Ort durchführen.

Wie immer sind wir für euch da. Meldet euch, wenn ihr Unterstützung dabei braucht, Verschwendung zu vermeiden.