Was haben ein Chirurg und eine Softwerker:in gemeinsam: Sie schneiden gerne. Tatsächlich ist für beide Berufe schneiden essentiell. Der Unterschied: Chirurgen schneiden gerne, weil dann so schön viel Blut fließt; Softwerker:innen schneiden, damit kein Blut fließt. User Stories schneiden ist wichtig für gute Software.

Schneiden ist ein Werkzeug, welches Software-Entwickler:innen in verschiedenen Kontexten durchführen: Bei den Anforderungen, im Architekturentwurf, im Implementierungsentwurf, bei der Implementierung und …. vorher …. bei den Tests. Und tatsächlich habe ich meine Meinung geändert. Während ich früher noch sagte: „Schneiden, schneiden, schneiden … bis nur noch eine Zeile Code übrig ist – die ist dann gut testbar“ bin ich heute der Meinung: Manchmal ist klein auch zu klein, insbesondere im Bereich der Software-Architektur.

Ich beginne meinen neuen Blog mit dem Schneiden. Warum? Weil dieses Thema mein ganzes Softwareleben geprägt hat. Ich habe mich schon immer gefragt, warum Software-Entwickler und Software-Entwicklerinnen nicht nur noch mit Verhaltensmuster wie Command, Chain of Responsibility, Strategy und anderen Pattern arbeiten. Zusammen mit Dependency Injection sind diese Muster sehr stark, vor allem in der Produktentwicklung, wie ich am Beispiel SAP Commerce zeigen will, wenn es um das Schneiden während der Implementierung geht.

Bei der Software-Entwicklung gibt es verschiedene Aspekte des Schneidens die ich in verschiedenen Blog-Einträgen beschreiben will.

• Bei den Anforderungen, also den User Stories.
• In der Architektur.
• Während es Entwurfs vor allem mit Verhaltensmuster.
• Im Laufe der Implementierung

Schneiden bei User Stories

Kriterien beim Schneiden von User Stories geben uns die INVEST-Kriterien:

• Independent: Eine User Story soll unabhängig von anderen Stories sein. Ist sie dieses nicht, gehört sie zu einer anderen Story.
• Negotiable: Hier geht es um eine Einladung zur Konversation. Solange Das Team die Story nicht in den Sprint gezogen hat, kann sie mit dem PO verhandelt und geändert werden.
• Valuable: Jede Story sollte einen Nutzen für einen Nutzer oder Stakeholder haben. Sie sollte aber auch wirklich der Software Mehrwert hinzufügen.
• Estimable: Da Schätzen im agilen Umfang keinen Mehrwert hat, ist mir diese Forderung zu platt. Sie korrespondiert mit der nächsten Forderung.
• Small: Was klein ist, ist auch schätzbar. Die Frage ist was ist klein? Aus meiner Sicht ist alles klein, was möglichst an einen Tag von dem gesamten Team umgesetzt werden kann.
• Testable: Was klein ist, ist auch testbar.

Schnittmuster für User Stories

Ich möchte nicht allgemein auf das Schneiden von Stories eingehen. Einen sehr schönen Artikel gibt es hier von Richard Lawrence. Lawrence beschreibt Patterns, von denen ich einige hier kurz erläutern möchte. Inspiriert hat mich mein letztes Projekt, in dem ich den PO (Product Owner) bei der Erstellung der User Stories geholfen habe.

Workflow Steps

Beim E-Commerce gibt es den klassischen Checkout. Die User Story mag heißen:

Als Kunde möchte ich meinen Warenkorb auschecken, damit ich die Waren geliefert bekomme.

Was liegt hinter dem Checkout?

• Falls der Kunde noch nicht eingelogt ist, muss er sich einloggen
• Er oder sie muss eine Adresse eingeben, wer die Waren bezahlt (payment address oder bill to).
• Die Kunden und Kundinnen müssen eine Adresse eingeben, wohin die Daten verschickt werden sollen (ship to).
• Am Ende wird dem Kunden eine Summary-Seite angezeigt, auf der er oder sie noch einige Dinge ändern kann.

Wenn man sich jetzt die einzelnen Schritte anguckt sieht man, sie sind immer noch nicht „klein genug“. Das liegt daran, dass es verschiedene Personas oder Status von Personas gibt. Das bedeutet auch nachdem ich nach einem bestimmten Muster geschnitten habe, müssen ggf. noch weitere Schnittmuster angewendet werden.

Business Rule Variation

Nehmen wir uns den ersten Schritt des Checkouts – das Einloggen, dann gibt es bestimmte Fälle aufgrund von Kundendaten:

Als registrierter Kunde möchte ich mich mit meinen Credentials (z.B. Username, Passwort) einloggen können, damit ich auf meine gespeicherten Adressen zugreifen kann.

Als nicht registrierter Kunde möchte ich mich registrieren, damit ich Seiten besuchen kann, die nur für registrierte Kunden freigeschaltet sind.

Als Gast möchte ich nur meine Daten für den Bestellvorgang eingeben können, damit ich nicht registriert werde.

Hier muss der PO also aufgrund des Status eines Kunden (registriert, nicht registriert, Gast) die Story in drei weitere Stories schneiden.

Operations (e.g. CRUD)

Wenn ich mir die Bezahl-Adresse und die Lieferadresse angucke, dann gibt es verschiedene Operationen, die ich im Bereich des E-Commerce mit den Adressen machen kann. Gespeicherte Adressen können nur registrierte Kunden haben.

Read

Als registrierter Kunde möchte ich aus einer Liste der Lieferadressen eine auswählen, damit ich nicht immer meiner Lieferadressen neu eingeben muss.

Create

Als registrierter Kunde möchte ich eine neue Lieferadresse erzeugen können, damit ich mehrere Lieferadressen verwalten kann.

Update

Als registrierter Kunde möchte ich eine Lieferadresse ändern, damit ich meinen Umzug anzeigen kann.

Delete

Als registrierter Kunde möchte ich eine Lieferadresse löschen, damit veraltete Lieferadressen nicht mehr im System vorhanden sind.

Ich möchte hier fachlich nicht darauf eingehen, ob diese Operationen überhaupt zulässig sind. Oft müssen Adressen im CRM geändert werden oder aus rechtlichen Gründen darf der User eine Adresse nicht löschen.

tl;dr

Schneiden im Bereich von User Stories ist notwendig, um den INVEST Kriterien für Stories zu genügen. Small und Independent sind hier die beiden wichtigen Dinge, die oft zu anderen Kriterien führen. Manchmal ist es notwendig mehrere Schnittmuster anzulegen um zum gewünschten Ergebnis zu kommen.