Wie behandle ich Anwendungsaspekte in Bezug auf Funktionen und User Stories?

8

Beim Erstellen eines Backlogs gelten verschiedene Anforderungen, die für eine Vielzahl von User Stories gelten, z. B. Aspekte der Anwendung wie Fehlerbehandlung und Feedback. Wie füge ich diese ein (ohne eine # include-Direktive in jeder User Story zu verwenden)? Sollte ich die Fehlerpräsentation als Feature behandeln und dann User Stories für dieses Feature wie "System fängt Ausnahmen ab und zeigt dem Benutzer Informationen an" haben?

project-management agile scrum

— ProfK
quelle

Gilt das für ALLE User Stories oder nur für wenige (aber immer noch viele)? Und "System fängt Ausnahmen ab und zeigt dem Benutzer Informationen an" ist zu spezifisch, um Teil der User Story zu sein.

— Euphoric

@Euphoric Sie würden für die große Mehrheit der Geschichten gelten; Alle Geschichten, die Benutzeroberfläche und Datenspeicher

— betreffen

3

Der Umgang mit Benutzerfeedback ist für die Benutzererfahrung von entscheidender Bedeutung, gilt jedoch auch für verschiedene Teile der Anwendung auf unterschiedliche Weise.

Nehmen Sie die folgenden zwei Beispiele:

Eine Geschichte könnte sich auf eine direkte Benutzerinteraktion konzentrieren, bei der ein schwerwiegender Fehler auftritt. Ein modaler Dialog wird verwendet, um den Benutzer über den Fehler zu informieren und ihn darüber zu informieren, dass eine Wiederherstellung nicht möglich ist. Die Geschichte hierfür wäre: „Als Benutzer ich über einen ungültigen Eintrag einiger Daten bilden , so informiert werden , dass ich diesen Fehler gehen sofort zurück und korrigieren“ . Diese User Story impliziert, dass dies ein schwerwiegender Blockierungsfehler ist, den der Benutzer sofort korrigieren muss.

In einer zweiten Geschichte vergisst der Benutzer, obligatorische Daten in ein Formular einzugeben. Die Geschichte wäre: "Als Benutzer möchte ich, dass fehlende Felder in einem Eintrag hervorgehoben werden, damit ich weiß, welche Felder erforderlich sind."

Diese subtile Benachrichtigung ist sehr unterschiedlich und kann nicht mit der ersten Story zu einer allgemeinen Fehlerbehandlungsgeschichte kombiniert werden. Beides kann sich jedoch aus internen Ausnahmen ergeben.

Denken Sie daran, dass es wichtig ist, das "Was" einer Geschichte zu vermitteln, beispielsweise das Fehlerszenario, das in einer bestimmten Situation behandelt werden sollte. Das Wie des Fehlers (dh eine Ausnahme wird irgendwo ausgelöst) ist für den Produktbesitzer fast irrelevant, da er keinen geschäftlichen Wert hat. Aus technischer Sicht würde ich eine Soundarchitektur in keiner Weise von meinem Produkt erwarten.

Am Ende gewinnen Sie Flexibilität und Erweiterbarkeit, indem Sie sich auf den Geschäftswert konzentrieren und gut getrennte und kleine User Stories haben.

— malte
quelle

2

Ich glaube, die Lösung ist eine gute Trennung der Bedenken. Dinge wie Fehlerbehandlung, Protokollierung, Feedback und dergleichen sollten global mit nur einem Code behandelt werden. Nur Anforderungen, die sich von diesem globalen Verhalten unterscheiden, sollten entweder als Teil von User Stories oder in der Diskussion über die Implementierung dieser User Storys notiert werden.

Auf der Seite des Projektmanagements sollte es also eine User Story geben, die besagt: "Als Benutzer möchte ich Fehler so sehen, dass ich sie dem Administrator melden kann." oder etwas ähnliches. Und diese User Story sollte in der Regel für alle Anwendungsfälle gelten.

— Euphorisch
quelle

Ich mag das, auch wenn es nicht nur zu einem aufgelöst wird, könnte ich es vielleicht gebrauchen. "Als Benutzer würde ich diese Fehler wie folgt sehen", "möchte per E-Mail über diese Fehler informiert werden" usw. Aber ich verwende ein Tool, bei dem die USA unter einer Funktion stehen müssen. Ich hätte dann eine Leistung für die wenigen Fehler User Stories?

— ProfK

1

Eine Idee (aus SCRUM): Dinge, die für jede User Story überprüft werden müssen, sind in der sogenannten "Definition von erledigt" enthalten .

Normalerweise umfasst "Definition von erledigt" technische Dinge wie:

Alle Tests sind grün
Code ist ziemlich sauber
Code verursacht keine Regressionen

Es kann aber auch für den Benutzer sichtbare Dinge enthalten:

Kein Benutzervorgang dauert länger als eine Sekunde
Alle GUI-Steuerelemente können nur mit der Tastatur verwendet werden

Das Team muss die "Definition von erledigt" für jede User Story überprüfen, bevor es für erledigt erklärt wird.

Eine Möglichkeit wäre, eine angemessene Fehlerbehandlung in diese "Definition von erledigt" aufzunehmen. Wie die anderen Antworten zeigen, sind die von Ihnen angeführten Beispiele (Fehlerbehandlung und Feedback) wahrscheinlich keine wirklich guten Beispiele für Anforderungen, die "überall" gelten:

Die richtige Fehlerbehandlung und Rückmeldung hängt normalerweise vom Kontext ab. Daher muss sie für die Orte, an denen sie benötigt wird, separat definiert werden. In diesem Fall ist es möglicherweise besser, die Fehlerbehandlung als separate User Stories zu formulieren, wie in der Antwort von malte erläutert.

— sleske
quelle