Story-Splitting – b-agile

Es ist also mehr oder weniger Geschmackssache, ob Sie ein grafisches Use-Case-Diagramm oder eine Liste von (Text-)User Stories bevorzugen.

Lassen Sie mich die Diskussion über die Strukturierung von Anforderungen im Großen zusammenfassen: Unabhängig von der Notation ist eine Zerlegung eines großen Problems in einen extern ausgelösten Prozess der neutralste Weg, um diese Aufschlüsselung zu erreichen. Es basiert nicht auf einer internen Struktur der Systeme (nicht seine Funktionen, nicht seine Subsysteme, nicht seine Objekte, .,,) sondern rein auf Bedürfnisse aus der Umwelt.

Dies soll nicht heißen, dass die anderen oben genannten Zersetzungsstrategien nicht funktionieren, sondern nur ein Vorschlag, um nicht in internen Strukturdiskussionen stecken zu bleiben.

Das Aufteilen in das kleine

Wie Sie im einfachen Beispiel des Navigationssystems oben sehen können, scheint dieser Prozess (unabhängig von der von Ihnen bevorzugten Notation) immer noch zu komplex zu sein, um in einer Iteration implementiert zu werden. Sie müssen es auf jeden Fall in kleinere Stücke zerlegen. Lawrence (https://agileforall.com/resources/how-to-split-a-user-story/) schlug viele Möglichkeiten vor, größere Brocken anzugehen und sie in Geschichten zu unterteilen, die klein genug für eine Iteration sind.

Während klassische Methoden vor allem vorschlugen, einen komplexen Prozess besser zu verstehen, indem sie seine Abfolge von Schritten betrachten, stehen wir jetzt in der agilen Welt vor einem zusätzlichen Problem: Wir wollen in jeder Iteration Wert schaffen, d. H. Potenziell lieferbare Produktinkremente entwickeln. Es ist nicht gut genug, nur einen großen Prozess (einen Anwendungsfall oder eine große Geschichte) zu zerlegen, um ihn besser zu verstehen. Nach der Zerlegung sollte jedes Teil dem Benutzer unabhängig von den anderen Teilen noch einen gewissen Wert liefern.

Dies verhindert technische Splits wie das Aufteilen in seine technischen Ebenen wie Benutzeroberfläche, Domänenfunktionalität und Persistenzschicht, da die erste Implementierung der Persistenzschicht (dh das Erstellen einiger Datenbanktabellen) keinen Geschäftswert liefert, bis Sie sie füllen und anzeigen können. Das Gleiche gilt oft für die reine Zerlegung von Geschäftsprozessen in ihre Schritte: Die Implementierung nur des einzelnen Schritts 7 eines komplexen Prozesses kann keinen Wert liefern, solange Vorgänger- und Nachfolgeschritte nicht vorhanden sind.

(Nur eine interessante historische Randbemerkung über Terminologiekriege zwischen Methodologen: Mike Cohn beklagte sich, dass User Stories keine Anwendungsfälle sind, indem er einfach das Argument verwendete: Sie könnten zu groß sein, um sie in einer Iteration zu implementieren. Ivar Jacobson akzeptierte dieses Argument über die Größe, schlug jedoch zurück, indem er behauptete, die “Use Cases Slices” seien eine viel bessere Denkweise als die Arbeit mit ausreichend kleinen User Stories, da Use Case Slices einen End-to-End-Wert liefern.)