Effektive Stories werden in geschrieben Agile Entwicklung 2.0

Gut geschriebene Stories sind für alle Entwickler und Teammitglieder leicht verständlich, z. B. Tests oder Dokumentation.

Mithilfe von Stories kann die Zuweisungsgruppe den Aufwand, der für die Implementierung der Arbeit gemäß der Definition von „Fertig“ erforderlich ist, genau schätzen. Die Definition von „Fertig“ ist die von der Gruppe vereinbarten Ausstiegskriterien, die bestimmen, wann eine Story abgeschlossen ist.

Eine Story hat die folgenden grundlegenden Bedingungen:

• Beschreibung: Die Story-Beschreibung bezieht sich auf eine Anwenderpersona, z. B. einen Administrator, und beschreibt entweder einen Geschäftswert oder behandelt eine technische Schuld.
• Akzeptanzkriterien: Die Story-Akzeptanzkriterien sind messbar und testbar.

Story-Beschreibungen

Eine gute Anwenderstory-Beschreibung identifiziert Folgendes für die Erfüllung der angegebenen Anforderung:

• Die Rolle der Anwenderpersona im System
• Der von der Anwenderpersona ausgedrückte Bedarf
• Der Vorteil für alle Stakeholder wie Entwickler, Anwender und andere

Normalerweise wird eine Story-Beschreibung folgendermaßen ausgedrückt: „Als <role> möchte ich <Ziel oder Bedürfnis>, damit <benefit>“.

Beispiele für eine gute Story-Beschreibung

• Beschreibung: Als Entwickler möchte ich den aktuellen Status meiner Anwendung in einem Update-Satz veröffentlichen, damit ich sie auf einem Produktionssystem bereitstellen kann.
• Beschreibung: Als Kunde möchte ich Benachrichtigungen erhalten, wenn Kommentare für einen Incident eingegeben werden, damit ich über den Status informiert werde.
• Beschreibung: Als Change-Manager möchte ich die Bewertung des Risikos für einen bestimmten Change ermöglichen, indem ich eine Liste von Fragen mit Multiple-Choice-Antworten erstelle.

Beispiel für eine schlechte Story-Beschreibung

Beschreibung: Benachrichtigungen werden gesendet, wenn Incidents erstellt werden.

Diese Beschreibung ist schlecht aus folgendem Grund:

• Die Beschreibung gibt nicht an, wer oder was die Benachrichtigungen sendet, nicht in welcher Form die Benachrichtigung angenommen wird, z. B. E-Mail.
• Die Beschreibung enthält keine Leistungsinformationen, daher ist der Geschäftsnutzen nicht klar.

Es könnte besser geschrieben werden als:

Beschreibung: Als Incident-Ersteller möchte ich, dass E-Mail-Benachrichtigungen an eine vordefinierte Gruppe von interessierten Parteien gesendet werden, wenn ich einen Incident erstelle, damit sie informiert werden können, wenn ein Incident erstellt wird, der sie betrifft.

Story-Akzeptanzkriterien

Akzeptanzkriterien definieren die Grenzen einer Anwenderstory und werden verwendet, um zu bestätigen, ob die Software wie beabsichtigt funktioniert, was bedeutet, dass die Story abgeschlossen ist. Akzeptanzkriterien sind ein wesentlicher Teil der „Definition von „Fertig“ für eine Story.

Kriterien für gute Akzeptanz

Kriterien für gute Akzeptanz sollten gegebenenfalls Folgendes umfassen:

• Nutzbarkeit: Stellen Sie sicher, dass Sie in die Akzeptanzkriterien Maß für die Nutzbarkeit aufnehmen. Geben Sie an, wie die Frage beantwortet werden soll: Ist sie einfach zu verwenden? Der Schlüssel besteht darin, die richtigen Messungen zu identifizieren und sicherzustellen, dass jede quantifizierbar ist.
• Funktionalität: Identifizieren Sie bestimmte Anwenderaufgaben, Geschäftsprozesse oder Funktionen, die am Ende des Projekts vorhanden sein müssen. Eine funktionale Anforderung kann sein: Der Anwender kann aus mehreren Größen auswählen.
• Fehlerbehandlung: Listet Fehlerfälle auf und wie sie behandelt werden sollen. Wenn ein Anwender beispielsweise die Schritte in der falschen Reihenfolge ausführt, wie behandelt die Software dies?
• Leistung: Testen Sie die Systemleistung aus der Perspektive eines einzelnen Anwenders. Beispiel: Ist die UI reaktionsfähig?
• Belastungstests: Beschreiben Sie, wie das System reagiert, wenn es unter Stress steht, da es viele Anwender, Transaktionen oder Abfragen gibt. Akzeptanzkriterien müssen zulässige Schwellenwerte für Belastungstests definieren. Beispiel: Antwortet das System innerhalb eines Schwellenwerts von 250 Millisekunden, wenn 100 Anwender gleichzeitig Abfragen übermitteln?

Beispiel für Kriterien für gute Akzeptanz

Beschreibung: Als Kunde möchte ich das Buch über ein sicheres webbasiertes Formular bestellen und bezahlen, damit meine Kreditkarteninformationen sicher sind.

Akzeptanzkriterien:

• Alle Pflichtfelder müssen ausgefüllt werden, bevor ein Kunde ein Formular übermitteln kann.
• Informationen aus dem Formular werden in der Kundenauftragsdatenbank gespeichert.
• Die Zahlung kann über Amex, Master Card oder Visa-Kreditkarte erfolgen.
• Das System muss die Umsatzsteuer genau berechnen und anwenden.
• Das System muss Versandkosten genau berechnen und anwenden.
• Der Kunde muss in der Lage sein, die Richtigkeit der Bestellung zu überprüfen.
• Eine Bestätigungs-E-Mail wird an den Kunden gesendet, der das Formular übermittelt.
• Schutz vor Spam funktioniert.

Beispiel für ungültige Akzeptanzkriterien

Beschreibung: Als Kunde möchte ich Benachrichtigungen erhalten, wenn ein Incident kommentiert wird, damit ich über den Status informiert werde.

Akzeptanzkriterien: Die entsprechenden Personen werden benachrichtigt, wenn Incidents kommentiert werden.

Die Akzeptanzkriterien sind schlecht, da sie nicht genügend Details zum Testen enthalten. Beispielsweise ist nicht klar, wer die entsprechenden Personen sind.

Die Akzeptanzkriterien könnten besser geschrieben werden als:

1. Erstellen Sie als ESS-Anwender einen Incident.
2. Wählen Sie Aus Benachrichtigen Sie interessierte Parteien .
3. Speichern Sie den Incident.
4. Melden Sie sich als interessierte Partei an.
5. Überprüfen Sie, ob Sie eine E-Mail für den protokollierten Incident erhalten haben.