Über die richtige Formulierung von User-Stories wurde schon sehr viel geschrieben. Vielleicht zu viel? Alle Bemühungen User-Stories gut und richtig zu formulieren täuschen darüber hinweg, dass das eigentliche Problem Anforderungen zu erfahren, zu analysieren und zu verstehen nicht trivial ist.
Die Story lautet:
Ich als Klemmbausteinfigur möchte mit einem Klemmbaustein-Auto eine Lücke überwinden.
Offensichtlich fehlt in der Story eine Angabe zur Größe der Lücke. Im unten verlinkten Video „Making Lego Car CROSS Gaps“ ist zu sehen wie sich das Fahrzeug mit der Änderung der Lückengröße verändert. Im Video wird deutlich, dass sich das implizite Konzept eines „car“ signifikant mit der Änderung eines Parameters ändert. Einfach nur größer machen funktioniert leider nicht. Im Video wird zudem deutlich, dass Iteration der Weg zum Erfolg ist. Es wird aber auch offensichtlich, dass die anfänglichen Vermutungen zum Aufwand nicht viel wert sind. Ich empfehle beim Anschauen des Videos die User-Story in Gedanken zu aktualisieren, dass sie zu dem passt was am Ende raus kommt.
Der Brick Experiment Channel ist darüber hinaus in vielerlei Hinsicht zu empfehlen. Anschautipps: ein U-Boot aus Klemmbausteinen oder eine 1:gogol Übersetzung aus Klemmbaustein-Getrieben.
Hallo Wolfram, ich stimme Dir in weiten Teilen zu. Mir begegnet aber leider viel zu oft der Irrglaube, dass mit dem Schreiben einer User-Story alles erledigt sei was vor der Implementierung zu tun ist. Am Schluss würde ich aber etwas widersprechen. Eines der Kernelemente von agilem Arbeiten ist die Iteration und die ist meiner Erfahrung nach sehr hilfreich.
LG Eberhard
Da zeigt sich mal der Unterschied zwischen user Story und Requirements-Engineering. Requirements müssen vollständig und widerspruchsfrei sein, das wird von user Story IMHO nicht erwartet. Hinzu kommt, dass User Stories immer aus Sicht des Endbenutzers verfasst sind und damit den Prozess und die dazugehörige Physik und ander Zusammenhänge ausser Acht lassen. User Stories sind gut, um Overengineering zu vermeiden, im Beispielfall hilft das aber nicht wirklich, weil alle späten Evolutionen ganz deutlich in diese Richtung gehen ohne jedoch eine brauchbare Lösung zu erzeugen. Für diesen fall hilft eben agile nicht wirklich.