Einführung
Im Bereich der agilen Entwicklung dienen Benutzerstories als wesentliche Bausteine für die Kommunikation zwischen Entwicklerteams und Stakeholdern. Um sicherzustellen, dass diese Stories korrekt umgesetzt werden und die gewünschten Ziele erfüllen, sind Akzeptanzkriterien unverzichtbar. Akzeptanzkriterien legen die spezifischen Bedingungen und Erwartungen fest, die eine Benutzerstory erfüllen muss, um als abgeschlossen angesehen zu werden. Doch wie ist die beste Art, diese Kriterien zu strukturieren? In diesem Artikel untersuchen wir drei beliebte Vorlagen für Akzeptanzkriterien: Given-When-Then, Behavior-Outcome-Expectation und Role-Feature-Reason. Wir werden die Vor- und Nachteile jeder Vorlage beleuchten und diskutieren, wann und wie sie effektiv eingesetzt werden können.
Häufig verwendete Vorlagen für Akzeptanzkriterien
Akzeptanzkriterien sind entscheidend, um den Umfang einer Benutzerstory zu definieren und sicherzustellen, dass das Entwicklerteam versteht, was implementiert werden muss. Hier sind drei häufig verwendete Vorlagen:
- Given-When-Then (GWT):
- Gegeben: Eine Voraussetzung oder ein Kontext, der die Grundlage legt.
- Wenn: Die Aktion oder das Ereignis, das die Benutzerstory auslöst.
- Dann: Das erwartete Ergebnis oder die Folge.
Beispiel:
- Gegeben ein registrierter Benutzer ist angemeldet
- Wenn sie auf die Schaltfläche „Zum Warenkorb hinzufügen“ klicken
- Dann sollte das Produkt in ihren Warenkorb hinzugefügt werden
- Verhalten-Ergebnis-Erwartung (BOE):
- Verhalten: Die Aktion oder das Verhalten, das die Benutzerstory betrifft.
- Ergebnis: Das erwartete Ergebnis oder die Zustandsänderung, die aus diesem Verhalten resultieren soll.
- Erwartung: Jegliche zusätzlichen Details oder Bedingungen.
Beispiel:
- Verhalten: Der Benutzer sendet ein Kontaktformular
- Ergebnis: Eine E-Mail mit den Formulardaten wird an das Support-Team gesendet
- Erwartung: Die E-Mail enthält die Kontaktdaten des Benutzers und die Nachricht
- Rolle-Funktion-Grund (RFR):
- Rolle: Die Rolle oder Person, die in der Benutzerstory beteiligt ist.
- Funktion: Die spezifische Funktion oder Funktionalität, die beschrieben wird.
- Grund: Der Zweck oder die Begründung für die Funktion.
Beispiel:
- Rolle:Administrator
- Funktion: Möglichkeit, Benutzerkonten zu löschen
- Grund: Um die Integrität der Benutzerdatenbank aufrechtzuerhalten und inaktive Konten zu entfernen
Dies sind nur einige Beispiele für Akzeptanzkriterien-Vorlagen. Die Wahl der Vorlage hängt oft von der Vorliebe des Teams und der Komplexität der Benutzerstory ab. Es ist wichtig, dass Akzeptanzkriterien klar, spezifisch und überprüfbar sind, um sicherzustellen, dass die Benutzerstory korrekt umgesetzt wird. Zudem sollten Akzeptanzkriterien je nach Bedarf sowohl funktionale als auch nicht-funktionale Anforderungen abdecken.
Zusammenfassung der Akzeptanzkriterien-Vorlagen
Hier ist eine Tabelle, die die Vor- und Nachteile der drei Akzeptanzkriterien-Vorlagen (Gegeben-Wenn-Dann, Verhalten-Ergebnis-Erwartung und Rolle-Funktion-Grund) sowie ihre zugehörigen Aspekte vergleicht:
| Aspekt | Gegeben-Wenn-Dann (GWT) | Verhalten-Ergebnis-Erwartung (BOE) | Rolle-Funktion-Grund (RFR) |
|---|---|---|---|
| Vorteile | |||
| Klarheit | Bietet eine klare Struktur zur Darstellung der Anforderungen der Benutzerstory. | Trennt explizit Verhalten, Ergebnis und Erwartungen zur besseren Klarheit. | Betont Rolle, Funktion und Grund für ein besseres Verständnis. |
| Prüfbarkeit | Einfach in Testfälle umzuwandeln. | Ermutigt zur Angabe überprüfbarer Bedingungen zur Validierung. | Kann verwendet werden, um Testfälle zu ermitteln, indem auf Rollen und Funktionen fokussiert wird. |
| Flexibilität | Geeignet für eine breite Palette an Benutzerstories, von einfach bis komplex. | Ermöglicht Flexibilität bei der Beschreibung von Benutzerinteraktionen und erwarteten Ergebnissen. | Anpassungsfähig an verschiedene Szenarien und hilft bei der Begründung des Bedarfs an Funktionen. |
| Lesbarkeit | Lesbar und verständlich für technische und nicht-technische Teammitglieder. | Kurz und strukturiert, was die Überprüfung durch Stakeholder erleichtert. | Bietet Kontext dafür, warum eine Funktion benötigt wird, und unterstützt die Priorisierung. |
| Nachteile | |||
| Aufwand | Kann bei sehr komplexen Benutzerstories umständlich werden und zu langen Kriterien führen. | Kann bestimmte nicht-funktionale Anforderungen oder Einschränkungen nicht erfassen. | Erfordert zusätzliche Erklärungen, wenn Rolle, Funktion oder Grund nicht offensichtlich sind. |
| Mangel an Kontext | Kann den Gesamtkontext der Benutzerstory nicht effektiv erfassen. | Könnte über größere Geschäftsziele oder Motivationen hinter der Benutzerstory hinweggehen. | Beruht darauf, dass Stakeholder Rolle, Funktion und Grund implizit verstehen. |
| Nicht ideal für nicht-funktionale Anforderungen | Weniger geeignet für die Festlegung nicht-funktionaler Anforderungen (z. B. Leistungsfähigkeit, Sicherheit). | Kann nicht-funktionale Aspekte nicht betonen, es sei denn, sie werden explizit in die Erwartungen aufgenommen. | Nicht-funktionale Anforderungen können übersehen werden, wenn sie nicht explizit formuliert sind. |
Dies sind einige der wichtigsten Vor- und Nachteile, die mit jedem der Akzeptanzkriterien-Vorlagen verbunden sind. Die Auswahl der Vorlage sollte die spezifischen Anforderungen der Benutzerstory, des Projekts und die Vertrautheit des Teams mit der Vorlage berücksichtigen. In der Praxis verwenden Teams oft eine Kombination dieser Vorlagen, je nach Bedarf, um umfassende Akzeptanzkriterien für Benutzerstories zu erstellen.
Zusammenfassung
Akzeptanzkriterien für Benutzerstories spielen eine entscheidende Rolle im agilen Softwareentwicklung, indem sie die Grenzen und Erwartungen für jede Geschichte definieren. Um diesen Prozess zu optimieren, vergleicht dieser Artikel drei weit verbreitete Vorlagen für Akzeptanzkriterien: Given-When-Then, Behavior-Outcome-Expectation und Role-Feature-Reason. Wir untersuchen die Stärken und Schwächen jeder Vorlage und geben Einblicke, wann sie je nach Komplexität der Benutzerstory und den Bedürfnissen des Teams eingesetzt werden sollten. Am Ende haben Sie ein klares Verständnis dafür, wie Sie die passendste Vorlage auswählen, um effektive Akzeptanzkriterien für Ihre agilen Projekte zu erstellen.