Wie entwerfe ich als Entwickler User Stories?

Ich schreibe ein System, in dem sowohl der Systembesitzer als auch ich Entwickler sind, und wir sind derzeit die einzige Quelle für 'Anfragen' oder Anforderungen an das System, die ich in User Stories erfassen möchte, die an Features {1} gebunden sind. Meine dringende Priorität ist es jetzt, einen überschaubaren Rückstand zu erfassen. Wie soll ich vorgehen, um das Niveau der technischen Daten zu erfassen, mit denen ich es gewohnt bin, in Benutzergeschichten zu arbeiten, die nicht zu technisch sein sollen?

{1} Ich evaluiere den agilen Projektmanagementdienst TargetProcess , und jede User Story muss an eine übergeordnete Funktion gebunden sein. Das System scheint gut zu passen, daher würde ich lieber mit dieser kleinen Einschränkung arbeiten, als sie zu umgehen.

Die typische Story-Vorlage ist sehr einfach zu visualisieren:

As a [ROLE] I need to [WHAT] so that/because [WHY].

Das Interessante ist, dass die Bedeutung der Komponenten umgekehrt ist.

WARUM ist wichtiger als WAS und das ist wichtiger als ROLLE

Beispiel mit dieser Frage

Als Softwareentwickler muss ich lernen, wie man User Stories schreibt, damit ich das Backlog mit Entwürfen füllen kann, um Diskussionen über die Funktionen zu starten und ihnen Punkte zuzuweisen.

Alles andere ist über die Komplikation der Absicht und der Implementierung von User Stories hinaus.

Zusätzliche Tools (Integration ist am besten)

Werkzeuge können verwendet werden , um zusätzliche zu erfassen Detail Informationen über die Geschichten , die erfasst wird , wenn sie zu assign Punkte / Schätzung diskutieren, aber das Detail sollte nicht Teil der Geschichte selbst sein. Etwas so Einfaches wie ein Wiki mit 1 Seite pro Geschichte, um Details / Abschriften von Diskussionen zu erstellen, ist eine ausreichend gute Lösung. Excel-Tabelle ist eine schreckliche Lösung.

Konzentrieren Sie sich beim Schreiben der User Stories auf das Was und Warum und vermeiden Sie das Wie .

Was Sie konfrontiert sind, ist eigentlich eine sehr gute Übung für alle Entwickler. Die Anforderung in einfachen, geschäftlichen Begriffen ausdrücken zu können, ist eine wichtige Fähigkeit.

Sie sollten sich auf die allgemeine Anforderung konzentrieren, z. B. "Sie müssen in der Lage sein, eine einzelne Auswahl aus einer Dropdown-Liste von Objekten zu treffen, damit der Benutzer die Foo-Aktion aktivieren kann", anstatt eine Combobox oder Listbox oder was auch immer anzugeben, das eine bestimmte Routine auslöst .

Eine andere Möglichkeit, dies zu erreichen, besteht darin, so zu tun, als wäre die zugrunde liegende Codebasis / das zugrunde liegende Framework eine fast vollständige Black Box. Jedes Mal, wenn Sie "Objekt XYZ verwenden" sagen, können Sie sich selbst überprüfen, indem Sie fragen, ob Sie dies in einem Black-Box-System wissen würden.

Update:
IMO, es ist in Ordnung, Details in einen Anwendungsfall einzufügen, die den für Informationen erforderlichen Detaillierungsgrad angeben. Bei einem Registrierungssystem ist es beispielsweise fair, Folgendes anzugeben
: Nachname; Erforderliches Feld
- Vorname; Erforderliches Feld
- Konto-ID; System erzeugt keine Eingabe notwendig
- Sternzeichen; optionales Feld - (Vorschlag) Suche nach Eingabe des Geburtsdatums?
- usw....

Der Schlüssel ist, dass Sie nicht das technische Wie für diese Informationen angeben. Wenn Sie feststellen, dass Sie für den Nachnamen "String-Klasse / Zeichen-Array / oder Varchar-Feld verwenden" sagen, wissen Sie, dass Sie zu viel angeben.

Wenn Sie mehrsprachig sind, verwenden Sie zwei unterschiedliche Sprachen als Lackmustest. Zum Beispiel sind Strings in C im Allgemeinen char (acter) Arrays, während C ++, Java und C # (okay, und fast alle anderen ...) ein tatsächliches String-ähnliches Objekt haben. Wenn Sie feststellen, dass Ihre Spezifikation durch die Verwendung einer dieser Sprachen ungültig ist, wissen Sie, dass Sie zu viel angegeben haben.

Es ist erwähnenswert, dass ich im Gegensatz zu User Story speziell den Begriff Use Case verwende , obwohl die Variante, die ich am Ende verwende, eine Mischung aus beiden ist. Mein Ziel eines Anwendungsfalls ist es, einen Überblick über die Vorgänge zu geben (eine User Story im engeren Sinne), dann aber die erforderlichen Akteure, Systeme und allgemeinen Funktionen durchzuarbeiten. Mein Ansatz ist näher an dem, was Fowler in diesem Wikipedia-Artikel vorschlägt, als an Cockburns Ansatz.

Ich habe also einen einzigen Anwendungsfall (oder so) für das Registrierungsszenario oder das Arbeitselement. Wenn es wirklich komplex ist, würde ich es in Vielfache aufteilen, aber das ist keine große Sache. Der Anwendungsfall kann dann bei Bedarf in einzelne Aufgaben unterteilt werden. Was in ein bestimmtes Scrum geworfen wird, hängt von vielen Variablen ab, aber nichts in diesem Ansatz hindert Sie daran, am Ende des Scrums eine nachweisbare Komponente zu haben.