Im SAFe DevOps Health Radar ist Develop der Schritt, in dem wir die Features aus der Continuous Exploration in funktionierenden Code umwandeln. Wir teilen Features in User Stories auf, implementieren sie mit starkem Fokus auf eingebaute Qualität und committen alles in die Versionskontrolle. In diesem Video erkläre ich den Develop-Schritt und warum Qualitätspraktiken wie TDD und BDD so wichtig sind.
Wo Develop in die Pipeline passt#
In den vorherigen Videos haben wir Continuous Exploration betrachtet: Ideen von Business und Kunden sammeln, sie in Epics mit klaren Hypothesenaussagen transformieren, diese Hypothesen durch Kundeninterviews und Marktforschung in Collaborate and Research validieren, die minimale Architektur in Architect definieren und alles in Features für unser Backlog und unsere Roadmap zusammenführen.
Mit diesen Features gehen wir nun in den Develop-Schritt. Hier teilen wir Features in Stories auf, implementieren diese Stories und committen den Code in die Versionskontrolle.
Features in Stories aufteilen#
Ein Feature ist typischerweise grösser als eine einzelne Iteration oder ein Sprint. Deshalb müssen wir Features in kleinere User Stories herunterbrechen. Das Ziel ist es, das minimale Stück zu identifizieren, das dem Business oder dem Kunden Wert liefert und sofort gebaut werden kann.
Zum Beispiel: Wenn wir eine Website mit mehreren Eingabeformularen bauen müssen, könnte die kleinste wertvolle Story sein: das Website-Gerüst bauen, es mit dem Backend und einem externen System oder einer Datenbank verbinden und etwas auf dem Bildschirm anzeigen. Das beweist, dass wir integrieren können, und liefert bereits Wert.
Gute User Stories schreiben#
Features aufzuteilen allein reicht nicht aus. Wir müssen die Stories ordentlich schreiben. Eine User Story folgt einer klaren Vorlage:
- Titel, der die Story beschreibt
- Satz in der Form: “Als [Nutzer] möchte ich [Aktion], damit [Geschäftswert]”
- Akzeptanzkriterien im Given/When/Then-Format (Behavior Driven Development)
Zum Beispiel: “Als Fahrer möchte ich den Geldbetrag vor dem Tanken begrenzen, damit ich meine Ausgaben kontrollieren kann.” Die Akzeptanzkriterien spezifizieren dann: “Gegeben, dass der Fahrer einen Höchstbetrag angibt, wenn die Tankkosten den Betrag erreichen, dann stoppt der Tankvorgang automatisch.”
Mit BDD erhalten wir direkt aus den Akzeptanzkriterien eine ausführbare Spezifikation. Das gibt uns Testfälle, die wir sofort implementieren können.
Test Driven Development#
Für die Implementierung verwenden wir einen Test-First-Ansatz: Test Driven Development (TDD). Der Zyklus ist einfach:
- Einen Test schreiben. Ausführen. Er schlägt fehl (rot), weil die Implementierung fehlt.
- Gerade genug Code schreiben, um den Test zu bestehen (grün).
- Refactoring durchführen, da alle Tests weiterhin bestehen.
- Wiederholen mit dem nächsten Test.
Der Vorteil ist klar: Wir bekommen Tests für jeden Teil unserer Implementierung und wissen, dass die Implementierung genau das tut, was spezifiziert ist. Wenn die User Story bereits mit BDD-Akzeptanzkriterien im Given/When/Then-Format geschrieben ist, wird das Erstellen der Tests noch einfacher.
Eingebaute Qualität und der Shift-Left-Ansatz#
Wir wollen Qualität von Anfang an einbauen, anstatt sie nachträglich hineinzutesten. Das ist der Shift-Left-Ansatz: Statt des traditionellen V-Modells, bei dem Tests nach dem Coding stattfinden, verschieben wir das Testen nach links.
Mit Shift Left:
- Features werden direkt mit BDD geschrieben (Tests im Given/When/Then-Format)
- User Stories haben ausführbare Akzeptanzkriterien
- Code wird mit TDD geschrieben (Test First)
- Pair Work (z.B. Pair Programming) verbessert sowohl Qualität als auch Geschwindigkeit
Das bedeutet, dass Tests auf jeder Ebene direkt von Anfang an geschrieben werden. Qualität wird eingebaut, nicht nachträglich aufgesetzt.
Alles in die Versionskontrolle#
Sobald der Code geschrieben ist, committen wir ihn in die Versionskontrolle. Aber nicht nur den Code. Alles sollte in der Versionskontrolle sein: Code, Infrastrukturkonfiguration, Tests, Testdaten, Anforderungen und Architekturdokumentation.
Indem wir alles unter Versionskontrolle haben, gewinnen wir volle Rückverfolgbarkeit. Für jede gegebene Version können wir genau sehen, welcher Code, welche Konfiguration, welche Tests und welche Anforderungen Teil dieses Deployments waren.
Application Telemetry#
Im Architect-Schritt haben wir für Betriebsfähigkeit entworfen. Jetzt im Develop-Schritt implementieren wir dieses Design. Wir fügen Logging-Anweisungen und Application Telemetry hinzu, um die Informationen zu sammeln, die für den effizienten Betrieb des Systems in der Produktion nötig sind, ohne sich auf dem Produktionsserver einzuloggen und nach Fehlern zu suchen.
Application Telemetry dient zwei Zwecken:
- Betriebsdaten: Systemgesundheit überwachen und Probleme schnell diagnostizieren
- Geschäftsdaten: unsere Hypothese evaluieren und den gelieferten Wert messen
Sicherheitsanforderungen umsetzen#
Im Architect-Schritt haben wir Threat Modelling durchgeführt, um Bedrohungen, Angreifer und Angriffsvektoren zu identifizieren. Im Develop-Schritt schreiben wir den Code, der genau diese Sicherheitsanforderungen adressiert. Sicherheit ist kein nachträglicher Gedanke. Sie wird als Teil der Entwicklungsarbeit implementiert.
Die Reifegrade#
Der SAFe DevOps Health Radar bietet eine Reifegradbeurteilung für Develop:
- Sit: Das Team-Backlog existiert nicht oder wird nicht zur Steuerung der täglichen Arbeit verwendet.
- Crawl: Stories sind entweder unvollständig oder zu ausführlich. Unit Tests werden in der Regel nicht geschrieben. Peer Reviews werden nicht durchgeführt.
- Walk: Stories sind vollständig. Die meisten Änderungen haben Unit Tests. Peer Reviews werden meistens durchgeführt.
- Run: Code wird täglich eingecheckt. Die Unit-Test-Abdeckung liegt über 80%. Peer Reviews werden immer durchgeführt.
- Fly: Code wird mehrmals täglich eingecheckt. Tests werden vor dem Code geschrieben (TDD). Pair Work und andere Praktiken für eingebaute Qualität sind die Norm.
Eine Anmerkung zur Unit-Test-Abdeckung: Eine Abdeckungsmetrik ist als Indikator für das Entwicklungsteam nützlich. Sie kann Bereiche aufzeigen, die Verbesserung brauchen. Es ist jedoch eine Entscheidung des Entwicklers oder des Teams, wo hohe Abdeckung sinnvoll ist. Es gibt Bereiche im Code, in denen null Prozent Abdeckung völlig in Ordnung ist.
Was Develop produziert#
Das Ergebnis des Develop-Schritts ist:
- User Stories, die verfeinert und bereit für die Implementierung sind
- Code, der in das Source-Code-Repository committet wurde
- Tests (Unit Tests, Integrationstests, End-to-End-Tests), die den committeten Code verifizieren
Dieser Code geht dann zum nächsten Schritt in der Pipeline: Build. Dort wird der committete Quellcode kompiliert und in deploybare Artefakte verpackt.
Wichtige Erkenntnisse#
- Features in kleine, wertvolle Stories aufteilen. Jede Story sollte innerhalb einer einzelnen Iteration etwas Bedeutsames liefern.
- Stories mit BDD schreiben. Given/When/Then-Akzeptanzkriterien liefern ausführbare Spezifikationen und fertige Testfälle.
- TDD für die Implementierung nutzen. Zuerst Tests schreiben, dann Code. Das baut Qualität von Anfang an ein.
- Pair Work praktizieren. Zwei Personen, die gemeinsam an einer Story arbeiten, verbessern sowohl Qualität als auch Geschwindigkeit.
- Alles in die Versionskontrolle. Code, Konfiguration, Tests, Anforderungen, Architektur. Volle Rückverfolgbarkeit hängt davon ab.
- Application Telemetry implementieren. Im Architect-Schritt entwerfen, im Develop-Schritt einbauen. Sie wird für den Betrieb und die Hypothesenvalidierung benötigt.
- Sicherheitsanforderungen im Code umsetzen. Threat Modelling identifiziert die Risiken; Develop ist der Ort, an dem sie adressiert werden.