Ich bin sehr neu in der agilen Softwareentwicklung und versuche, die Größenregel zu verstehen, die beim Schreiben wertvoller User Stories zu befolgen ist
Szenario
Ich bin derzeit an einem Portfolio-Datenimportprojekt beteiligt. Dazu gehört die Einrichtung einer Import- und Exportfunktionalität zwischen Anwendung und Adaptern. Die Import/Export-Funktionalität ist jedoch für einige Adapter implementiert. Wie wird die User Story eines neuen Adapters behandelt - Import-/Exporteinstellung. Die Funktionalität ist für alle Adapter gleich. Ich möchte die folgenden Zweifel klären 1. Sollten wir den Inhalt der User Stories wiederholen, wenn die Funktionalität gleich ist 2. Sollten wir ausführlichere oder kürzere Stories schreiben
Es gibt keine "richtige" Antwort. Es gibt jedoch einige Punkte zu User Stories, die Sie bei Ihrer Entscheidung möglicherweise als hilfreich empfinden:
1) User Stories wurden ursprünglich auf 3x5-Karten geschrieben. Dies wurde absichtlich ausgewählt, weil es unmöglich war, alle Details auf eine Karte dieser Größe zu bringen, sodass die Entwickler mit dem Benutzer oder PO sprechen und ihre eigenen Notizen aus dem Gespräch schreiben müssten.
2) User Stories sollten den zu lösenden Bedarf ausdrücken, nicht die Implementierung. Das bedeutet, dass der Beginn Ihrer User Story für so etwas wie Import wahrscheinlich so einfach ist wie:
Als neuer Benutzer möchte ich meine Daten aus einer flachen Datei importieren, damit ich nicht alles von Hand eingeben muss.
und vielleicht eine Kopie einer Importdatei als Beispiel beifügen.
Im Allgemeinen ist eine User Story eine Arbeit, die in einem Sprint abgeschlossen werden kann.
Wenn Ihre länger dauert, wird sie als Epic angesehen , das zusätzliche User Storys enthält . Wenn diese zusätzlichen Storys ähnlich erscheinen, aber unterschiedliche Akzeptanzkriterien haben , sollten sie als separate User Storys geschrieben werden .
Von dieser Seite des Bildschirms fühlt es sich an, als ob Sie diese Geschichte auflösen sollten. Viel Glück!
Das Entwicklungsteam und der Product Owner sollten zusammenarbeiten, um Akzeptanzkriterien für jede neue Funktionalität zusammenzufassen. Wenn sich der Wert, der von anderen erledigten Arbeiten geliefert wird, überschneidet, kann auf diese abgeschlossene Arbeit in allen neuen Arbeitsaufgaben verwiesen werden, die für das Produkt generiert werden. Dies bietet Kontext und einen Rahmen für die Herangehensweise an neue Arbeiten, wobei die vorhandene Funktionalität im Auge behalten wird. Wenn die neue Arbeit, die generiert wird, groß genug ist, sollte das Entwicklungsteam befugt sein, die Arbeit nach eigenem Ermessen zu verwalten/aufzuteilen, bevor sie sie in ihren Sprint einbringt.
Todd A. Jacobs
Jithin Antonius
Todd A. Jacobs
Shawn Adams