Story Splitting Revisited

Vor kurzem habe ich an dieser Stelle das Story Splitting Flowchart von Richard Lawrence vorgestellt, eine gute, praktische Hilfe zum Schneiden von Use Stories.

Heute möchte ich die darin enthaltenen Pattern um zwei weitere ergänzen, die sich schon in mehreren Projekten als sehr hilfreich erwiesen haben.

Stub Pattern

Entwickeln Sie Stubs für abhängige Elemente, deren Fertigstellung Sie nicht beeinflussen können.

Dieses Pattern adressiert das Risiko bei abhängigen Elementen, seien es Hardwarekomponenten oder entfernte Services. Die Entkopplung von Abhängigkeiten durch die Entwicklung von Stubs verschafft uns die Möglichkeit, unseren Teil der Lösung zu entwickeln und zu testen, ohne auf die Zulieferung warten zu müssen. Und dabei muss ein Stub keine perfekte Simulation der tatsächlichen Komponente sein.

Aber: die Benutzung von Stubs sollte auf keinen Fall die Integration der tatsächlichen Komponente verzögern, sobald diese verfügbar ist. Formulieren und priorisieren Sie deshalb immer gleich das Pendant zur „Stub“-Story, also:

… möchte ich die aktuellen Werte von Globex (stubbed) beziehen …

und:

… möchte ich die aktuellen Werte von Globex beziehen …

Abhängigkeiten sind meist risiko-behaftet. Adressieren Sie Risiken schnell, mit Stubs. Verzögerte Integration ist schlecht, verlieren Sie sie deshalb nicht aus den Augen. Integrieren Sie so schnell wie möglich. Es entstehen durch die Anwendung dieses Patterns zwar zwei Storien, die nicht unabhängig voneinander sind; unter dem Risiko-Aspekt ist das aber gut vertretbar.

API before GUI Pattern

Wenn eine Story die Benutzungsoberfläche (GUI) involviert, entwickeln Sie zuerst eine Lösung auf der API-Ebene ohne Berücksichtigung der GUI.

Dies zwingt die Entwicklung dazu, die Applikationslogik aus der GUI-Schicht herauszulassen und führt damit zu einem klareren und leichter wartbaren Design. Zudem wird die Testautomatisierung erleichtert, da Funktionalität nicht durch die GUI-Schicht hindurch getestet werden muss.

Auch hier gilt: wenn Sie dieses Splitting-Pattern benutzen, schreiben Sie auch immer gleich die ergänzende Story auf, nämlich die Implementierung über die GUI. Auch hier werden zwei Stories erzeugt, die nicht unabhängig voneinander sind. Und wenn die Ausgangsstory schon klein genug ist, wird man sicher versucht sein, dieses Pattern nicht anzuwenden. Zumal dadurch auch der „Value“ für den Kunden verzögert wird. Auf der anderen Seite ist dieses Pattern ein wirksames Mittel, um technische Schuld bei GUI-lastigen Applikationen zu vermeiden.

Wenn Sie mehr über das Schneiden von User Stories wissen wollen, besuchen Sie unsere Trainingsseite.

Uwe Valentini

Kontaktieren Sie Uwe Valentini

Uwe Valentini arbeitet bei Agile-by-HOOD als Berater und Coach mit viel persönlichem Engagement mit Menschen, Teams und Organisationen auf ihrem Weg zu mehr Agilität. Uwe ist leidenschaftlicher Agilist, er lernt jeden Tag etwas Neues und hat viel Spaß daran. Sein Motto: Agilität beginnt im Kopf.