Wie können User Stories keine Anforderungen enthalten (wenn sie auf einer Karte geschrieben sind) und dennoch umsetzbar sein?

Mir wurde gesagt, dass "User Stories keine Anforderungen sind, sondern nur eine Erinnerung daran, was der Kunde wünscht. Sie können Anforderungen nicht in eine Story einfügen." Nehmen wir als Beispiel, dass ein Kunde eine andere Verarbeitung für verschiedene Kreditkarten wünscht. Es gibt strenge Anforderungen, die implementiert und bekannt sein müssen, damit Testfälle geschrieben werden können. Wohin sollten Anforderungen gehen, wenn nicht in der User Story?

Wie können sich Entwickler aus einer Story entwickeln, wenn es keine geringeren Anforderungen gibt? Wie können Tester Testfälle (detaillierte) basierend auf einer User Story schreiben? Wohin gehen Anforderungen wie DB-Einschränkungen, Feldvalidierung usw. außerhalb der User Story?

Diese Antwort konzentriert sich auf die Arbeit mit User Stories und Anforderungen auf niedrigerer Ebene. Ich werde nicht über die Tugenden oder das Fehlen von Scrum oder Agile sprechen. Ich werde auch nicht über Gurus sprechen.

In dieser Antwort wird davon ausgegangen, dass Sie an Bord von Scrum sind, aber noch keinen Weg gefunden haben, dies für Sie zum Laufen zu bringen.

Wie bereits erwähnt, sollen User Stories beschreiben, wie die Benutzer die Software haben möchten. Da sich die Benutzer nicht um Implementierungsmaterial auf niedriger Ebene wie Datenbanktabellen, Einschränkungen, Architekturmuster usw. kümmern, finden Sie solche Details nicht in einer User Story.

Dies bedeutet jedoch nicht, dass diese Details nirgendwo aufgezeichnet werden sollten.

Wenn Entwickler User Stories implementieren, müssen sie Details auf niedrigerer Ebene kennen, die typische Benutzer nicht kennen. Diese Informationen können von KMU, BAs, dem Product Owner, Ihrem Architekten oder einer anderen sachkundigen oder technisch versierten Person stammen.

Bedeutet dies, dass Details auf niedriger Ebene in User Stories aufgezeichnet werden sollten? Nein und Ja).

Irgendwann zwischen der Erstellung und Implementierung der Story muss jemand herausfinden, wie sie implementiert werden soll. Dies geschieht normalerweise in Form von Gesprächen mit den an der Story beteiligten Personen (Benutzer, Architekt, Entwickler usw.). Diese Gespräche sollten zu eindeutigen Akzeptanzkriterien führen, die den Umfang der Implementierung der User Story klar umreißen. Diese Details müssen irgendwo aufgezeichnet werden und wo das wirklich liegt, liegt bei Ihnen. Der Schlüssel hierbei ist, dass diese Details nach der Erstellung der User Story ermittelt werden. Ich denke, das ist es, was dein Guru zu betonen versucht.

Als Entwickler ist klar, dass Sie eine Möglichkeit benötigen, Ihre User Story mit spezifischeren Anforderungen zu verknüpfen. Genau wie Sie das tun, ganz bei Ihrem Team ist.

Wenn die Leute in Ihrem Team diese Details nicht in den User Stories sehen möchten, müssen Sie dies möglicherweise respektieren. Es hat Vorteile, wenn Sie Ihre hochrangigen User Stories frei von Implementierungsdetails halten. Es hält sie schlank und Ihr Rückstand kann als Verlauf dessen gelesen werden, was Ihre Benutzer und Product Owner wollten. Machen Sie einfach auch Ihre Bedürfnisse als Entwickler bekannt. Sie sollten in der Lage sein, einen Kompromiss zu finden, bei dem eine einfache Verknüpfung mit der User Story alle glücklich macht.

Ja, es ist BS. Und Scrum ist nicht agil.

Ich hasse die Starrheit sogenannter agiler Praktiker, die Ihnen mitteilen, dass es eine Möglichkeit gibt, agil zu handeln, und dass Sie alle Regeln befolgen müssen, die in den heiligen Schriften der von ihnen verwendeten „agilen“ Methodik festgelegt sind. Es ist alles BS.

Bei Agile geht es darum, agil zu sein.

Bei Agile geht es darum, Dinge mit einem Minimum an Aufwand zu erledigen. Dies bedeutet nicht "keine Dokumentation", da Sie in der Regel mehr in einer agilen Rolle dokumentieren. Sie können einfach mit der Dokumentation fortfahren, ohne einen Prozess für die Dokumentation planen zu müssen. Ähnliches gilt für das Codieren, Testen und Erfassen von Anforderungen. Die einzigen Dinge, die in einem agilen Prozess wichtig sind, sind diejenigen, die Ihnen helfen, Ihre Arbeit schnell und effizient ohne BS zu erledigen.

Wenn Sie also in diesem Fall die Benutzeranforderungen in die Karten aufnehmen, können Sie den erforderlichen Code schreiben, testen, dokumentieren und demonstrieren. Stellen Sie die Anforderungen auf die Karte und sagen Sie den Gurus, dass das Team immer Recht hat.

Was denkt der Rest Ihres Entwicklerteams? In einer wirklich agilen Methodik sollten Sie das tun, was das Team für sie am besten hält, wenn sie der Meinung sind, dass Anforderungen ohne „Benutzerkonversationen“ von vornherein geschrieben werden sollten. Wenn das Team der Meinung ist, dass die Benutzergespräche eine gute Sache sind, hören Sie ihnen zu und verstehen Sie, warum sie dies denken, und bringen Sie sich in ihre Arbeitsweise ein.

Nenn dies einfach keine User Story und alle werden glücklich sein.

Ich denke, die Antwort ist, Sie können dies aufschreiben, wo immer Sie wollen.

Im Allgemeinen sind bestimmte Implementierungen aus folgenden Gründen nicht in einer User Story enthalten:

1. Sie wissen, was der Kunde will, aber Sie wissen nicht, wie es umgesetzt werden soll.
2. Der Kunde ist sich bewusst, dass es sich um spezifischere Anforderungen handelt, kümmert sich jedoch nicht wirklich darum und / oder versteht sie auch nicht.
3. Jeder glaubt, dass er sich der konkreten Implementierungen zu diesem Zeitpunkt voll bewusst ist, aber niemand möchte sie aufschreiben, da sich ihrer Erfahrung nach sowieso alles ändern wird und niemand es umschreiben möchte.

Es gibt keine Regeln, die bei Bedarf zusätzliche Dokumente weglassen. Vielleicht braucht der Kunde Zugriff darauf und vielleicht auch nicht. Wenn Sie hoffen, eine Art Vertrag zwischen Ihnen und dem Kunden über die spezifische Implementierung zu schließen, als könnten Sie ihm folgen, und wenn der Kunde nicht dafür verantwortlich ist, dass er dem zustimmt, täuschen Sie sich. Wenn der Kunde die technischen Details der Kreditkartenabwicklung versteht, sollten Sie diese Dokumente mit ihm teilen und sie möglicherweise in das Gespräch einbeziehen.

Ich denke, wenn Ihre Scrum-Berater Ihnen sagen, dass Scrum keine Anforderungen stellt, dann haben Sie einige sehr schlechte Berater. Sie sagen sogar zu Unrecht, dass eine User Story überhaupt keine Anforderung ist, sondern nur eine Art von Anforderung.

Was sind die verschiedenen Arten von Softwareanforderungen?

Geschäftsanforderungen

Hierbei handelt es sich im Allgemeinen um ein Geschäftsbedürfnis auf hohem Niveau, das im Allgemeinen einer Art Aussage über ein System im Executive-Stil gleichkommt. Es ist absichtlich auf hohem Niveau und breit angelegt und kann nicht ohne viel mehr Details implementiert werden.

Benutzeranforderungen

Dies sind die Ihnen bekannten User Story-Anforderungen. Sie können in der Regel auf eine Haftnotiz passen.

• Schauspieler - In der Regel ein Benutzer oder Stakeholder.
• Need - Einige Elemente oder allgemeine Funktionen, die vom Benutzer benötigt werden
• Grund - Der Grund oder Kontext, aus dem dieser Bedarf besteht
• Akzeptanzkriterien - Dies ist der Rahmen für das Testen der Benutzerakzeptanz und während der Sprint-Demo, in dem der Product Owner entscheiden kann, ob eine User Story akzeptiert wird oder nicht.

Funktions- oder Systemanforderungen

Dies scheint das fehlende Teil in Ihrem Puzzle zu sein. Ausgehend von den Anforderungen auf Benutzerebene definiert eine funktionale Anforderung die Akteure und Eigenschaften eines Systems auf Systemebene sowie das Verhalten und die Funktionen eines Systems. Dies kann auch in einem Story-Format erfolgen und in Ihrem Backlog enthalten sein. Diese Elemente sollten eigenständig sein und können unabhängig von den Anforderungen eines Benutzers implementiert werden.

• Schauspieler - Ein System oder eine Komponente.
• Bedarf - Ein Bedarf, eine Eigenschaft oder eine Verhaltensangabe eines Systems, das vorhanden sein sollte.
• Begründung - Ein Kontext, der dahintersteckt, warum dies im System benötigt wird
• Akzeptanzkriterien - Szenarien, Verhaltensweisen, Funktionen und Abläufe, die erforderlich sind, um zu kommunizieren, wie System- und Integrationstests durchgeführt werden sollen. Wenn diese Arten von Tests für die Anforderung bestanden werden, wissen wir, dass diese Funktionsanforderung abgeschlossen wurde. Diese können in der externen Dokumentation Ihrer User Storys vorhanden sein, sollten jedoch abgeschlossen sein, bevor diese Storys in einem Sprint zugewiesen werden.

Die funktionalen Anforderungen definieren Ihre Lösung, die sich nach der von Ihnen beschriebenen Lücke in Ihrem Prozess anhört.

Bemerkenswerte Anforderungstypen, die erwähnt werden müssen, für Ihre Frage jedoch keine Rolle spielen: Nichtfunktionale Anforderungen, technische Anforderungen usw.

Eine User Story ist eine bestimmte Art von Artefakt mit dem Ziel, die Schnittstelle zu beschreiben, die der Benutzer vom System erwartet, und aus diesem Grund gehören Details auf niedriger Ebene einfach nicht dazu. Wenn Sie sie dort ablegen, ändern Sie die Absicht des Artefakts und es entspricht nicht mehr der Definition einer US.

Verwenden Sie andere Arten von Spezifikationen, um Anforderungen auf niedrigerer Ebene zu erfassen und Entwurfsentscheidungen zu treffen. Was genau diese anderen Formulare sein sollten, muss in Ihrer Organisation gelöst und an Ihre spezifische Umgebung angepasst werden.

Ihre Frage klingt so ähnlich wie

Ich habe diese CarFactory und ich muss auch Fahrräder herstellen, aber unser OOD "Guru" sagt, dass ich das nicht darf. Was ist das BS!?!

Respektieren Sie die Trennung von Anliegen und Zusammenhalt Ihrer Artefakte, sowohl die in Ihrem Code als auch die in Ihren Prozessen.

Ich denke, der Zweck dieses Ansatzes ist nicht, User Stories einzuschränken, sondern schlechte Anforderungen zu verhindern.

Nach meiner Erfahrung sind Benutzer im Allgemeinen nicht in der Lage, Anforderungen zu schreiben. Entwickler sind im Allgemeinen nicht in der Lage, Anforderungen zu schreiben. Zum Teufel, lassen Sie es uns einfach zugeben: Anforderungen sind schwer zu schreiben!

Ich denke, es wäre für einen Benutzer gültig, im Rahmen einer Verwendungsgeschichte etwas in Anforderungssprache zu schreiben. Dies sollte jedoch nicht automatisch zur Anforderung werden. Zwei widersprüchliche Nutzungsgeschichten zu haben ist ein kleines Problem. Zwei widersprüchliche Anforderungen zu haben, ist ein Hauptproblem bei der Vertragsunterbrechung. Es hat keinen Sinn, das eine vor seiner Zeit in das andere zu befördern.

Ich denke, der drakonische Standpunkt beruht auf der Erkenntnis der menschlichen Natur. Wenn die Leute anfangen, User Stories als einen Ort zu betrachten, an dem sie Anforderungen stellen, werden sie dies auch tun. Der wirkliche Vorteil der Verwendung von Geschichten gegenüber anderen Mitteln zum Sammeln von Anforderungen wie Informationen besteht darin, dass sie in natürlichen Formulierungen und Notationen des Benutzers abgefasst sind. Dadurch ist es wahrscheinlicher, dass die Entwickler aus der Perspektive des Kunden denken. In einer perfekten Welt könnten dort auch kalte Jargons vorkommen. In der Realität neigen solche Wörter dazu, Entwickler dazu zu bringen, sich an die leicht verständlichen Anforderungen zu halten und die subtilen Formulierungen und Nuancen zu verpassen, die die agile Entwicklung mithilfe von Use Stories aufdecken möchte.

Treffen Sie Ihre eigenen Entscheidungen

Die Antwort auf die Frage: Wie können Entwickler überhaupt eine Story entwickeln, wenn es keine geringeren Anforderungen gibt? ist sehr einfach - die detaillierten Anforderungen, die orthogonal zu den Anforderungen des Endbenutzers sind (z. B. DB-Einschränkungen, Feldvalidierung usw.), sind für den Benutzer eigentlich unerheblich. Wenn die Benutzeranforderungen durch sehr unterschiedliche Feldvalidierung, sehr unterschiedliche DB-Strukturen oder möglicherweise gar keine herkömmliche DB erfüllt werden können, wäre es kontraproduktiv, wenn die Benutzer solche Informationen mit Blick auf eine bestimmte Implementierung zusammenstellen, was sehr wahrscheinlich ist unterscheidet sich davon, wie das System am Ende implementiert wird.

Sie sind professionelle Entwickler, also treffen Sie professionelle Entscheidungen nach besten Kräften in Bezug auf Implementierungsdetails. Ein Benutzer, der einen Tisch haben möchte, kann einem Tischler mitteilen, welche Art von Holz er haben möchte. Es wird jedoch vom Tischler erwartet, dass er entscheidet, wie dick die Tischbeine sein sollen, um angemessene Lasten aufnehmen zu können. Wenn Ihnen einige Informationen fehlen, um eine aussagekräftige Entscheidung zu treffen, muss dies mit dem Benutzer besprochen werden. Für etwa 90% des Inhalts eines detaillierten Anforderungsdokuments sind jedoch abgesehen von den vagen Anwenderberichten und den Best Practices der Branche keine Informationen erforderlich .

All diese Details sind nicht willkürlich - es gibt schlechte Entscheidungen und bessere Entscheidungen, und sie sollten dokumentiert werden, da sie sich auf andere Teile der Implementierung auswirken. Letztendlich handelt es sich jedoch immer noch um Implementierungsdetails, über die das Implementierungsteam entscheiden kann und sollte an die Bedürfnisse und Best Practices der Benutzer anpassen.

Eine Standardauto-Analogie - wenn ein Kunde das Auto rot lackieren möchte, wäre eine angemessene Klarstellung für die User Story, zu fragen, welcher Rotton besser wäre, aber nicht die chemische Zusammensetzung des Lackes; Es wäre jedoch zu erwarten, dass sie das Auto nicht mit Wasserfarben lackieren würden, die sich im Regen auswaschen würden, da es die beste Vorgehensweise ist, dies nicht zu tun.

TL; DR

User Stories dienen dazu zu dokumentieren, welcher Wert dem Produkt hinzugefügt werden soll und warum. Implementierungsdetails (z. B. wie der Wert hinzugefügt, getestet, gemessen oder validiert werden soll) werden durch die Story eingeschränkt, sind jedoch nicht in ihnen enthalten. Sie werden bewusst als separate Artefakte belassen, um Flexibilität und Beweglichkeit innerhalb des Frameworks zu gewährleisten.

Die Spezifikationen und Implementierungsdetails werden am häufigsten in anderen Artefakten erfasst, z. B. in Skripten und Szenarien für Acceptance-Test Driven Development (ATDD), Test Driven Development (TDD) und Behavior-Driven Development (BDD). Diese speziellen Artefakte werden vom Scrum-Framework nicht vorgeschrieben, aber sie bieten Ihnen sicherlich einen guten Ausgangspunkt, wenn Sie nicht bereits über andere effektive Prozesssteuerungen verfügen.

Anwenderberichte sind keine Spezifikationen

Das Originalplakat (OP) stellte folgende Frage :

[A] Kunde möchte eine unterschiedliche Verarbeitung für unterschiedliche Kreditkarten, es gibt strenge Anforderungen, die implementiert und bekannt sein müssen, damit Testfälle geschrieben werden können ... WO SOLLTE ICH ES SETZEN, WENN ES NICHT IN DER GESCHICHTE STEHT?

Eine User Story ist ein Feature , das Wert liefert , einen Kontext für die Gespräche über die Implementierung bietet und eine Sichtweise, die an einen Value Consumer gebunden ist, der von dem Wert profitiert, den das Feature liefert.

Der springende Punkt einer User Story ist, dass die Implementierungsdetails keine Vorgabe sind. Dem Team steht es frei, die Funktion so zu implementieren, dass der identifizierte Wert im entsprechenden Kontext an den Wertkonsumenten geliefert wird.

Ein gelungenes Beispiel

Eine Beispiel-User Story

Dies lässt sich leichter erklären, wenn Sie mit weniger mehrdeutigen User Stories beginnen. Da das OP keine verwertbare User Story zur Verfügung stellte, die der INVEST-Mnemonik folgt , werde ich eine zum Zwecke eines Beispiels erfinden. Betrachten Sie die folgende Geschichte:

Als Benutzer, der es vorzieht, mit Discover-Karte zu bezahlen,
möchte ich die Option, meine Einkäufe mit der Discover-Karte zu tätigen,
damit ich nicht auf Visa, Mastercard oder American Express beschränkt bin.

Dies bietet ein konkretes Feature, bietet einen Kontext, der die Implementierungsentscheidungen des Teams leiten kann, und identifiziert den Value Consumer als Discover-Card-Kunden. Das ist kein Pflichtenheft, aber es ist das, was Sie brauchen, um mit dem Kunden und dem Team die richtigen Gespräche darüber zu führen, wie die Story während einer Entwicklungsiteration am besten umgesetzt werden kann.

Analyse und Implementierung

Die tatsächliche Umsetzung liegt beim Team. Das Team muss einige Analysen durchführen, um Folgendes zu bestimmen:

• Der einfachste Weg, eine neue Funktion zu implementieren.
• Welche der verschiedenen Implementierungsoptionen lässt sich in Zukunft am einfachsten unterstützen, ohne dass technische Schulden anfallen.
• So wenden Sie die Open-Closed- und YAGNI-Prinzipien an, um sicherzustellen, dass Ihre neue Funktion robust ist, ohne überarbeitet zu werden.

Eines der Kernprinzipien des Agilen Manifests ist die Zusammenarbeit mit Kunden. Von einem funktionsübergreifenden, selbstorganisierenden Team wird erwartet , dass es in der Lage ist, mit dem Kunden zusammenzuarbeiten, um die Implementierungsdetails innerhalb der von der User Story bereitgestellten Richtlinien zu erarbeiten.

Wenn Ihre User Stories nicht gut geschrieben sind oder wenn das Team nicht über die Fähigkeiten oder die Prozessreife verfügt, um die für das agile Framework erforderliche Analyse durchzuführen, ist dies offensichtlich viel schwieriger als erforderlich. Es wurden ganze Bücher zum Thema geschrieben, wie man gute User Stories auf der richtigen Granularitätsebene erstellt. Es gibt leider keine Silberkugel, aber es ist eine erlernbare Fähigkeit für agile Teams.

Testgetriebenes und verhaltensgetriebenes Design

Der beste Weg, um sicherzustellen, dass die Analyse solide ist und die Implementierung sowohl vernünftig als auch unterstützbar ist, ist die Verwendung von TDD- und BDD-Praktiken. In Anbetracht der obigen Geschichte sollte das Team die geplante Implementierung beispielsweise durch Artefakte erfassen:

• Gurken-Features mit testbaren Szenarien.

  Dies ist am nützlichsten, um die Entwicklung von Abnahmetests voranzutreiben und die Benutzererwartungen hinsichtlich des Anwendungsverhaltens zu dokumentieren . Zum Beispiel sollte die User Story eine oder mehrere verwandte Cucumber-Funktionen enthalten, die beschreiben, wie der Benutzer mit einer Discover-Karte auschecken kann und wie dieser Vorgang für den Benutzer aussieht.

• RSpec-Tests, die das Verhalten (nicht die internen Implementierungsdetails) neuer Codefunktionen überprüfen .

  Dies ist am nützlichsten, um das beabsichtigte Verhalten der Funktion in der Anwendung zu dokumentieren und zu validieren. In der User Story werden beispielsweise Unit- und Integrationstests erstellt, die sicherstellen, dass die Verwendung einer Discover-Karte das kartenspezifische Verhalten hervorruft, das die Anwendung benötigt, um einen Verkauf über das Payment Gateway zu autorisieren.

Die spezifischen Tools spielen keine Rolle. Wenn Sie Cucumber oder RSpec nicht mögen, verwenden Sie die Tools oder Methoden, die für Ihr Team am besten geeignet sind. Der Punkt ist jedoch, dass die Implementierungsdetails auf der User Story basieren , aber nicht von dieser vorgegeben werden . Stattdessen handelt es sich bei der Implementierung (oder bei den Spezifikationen, wenn Sie dies vorziehen) um Details, die während der Entwicklung des Features auf kollaborative Weise ausgearbeitet werden.

Viele gute Antworten hier. Hoffentlich kann ich mit einem anderen einen Mehrwert schaffen ...

Ich denke, ein Problem, das Ihr Team möglicherweise hat, ist die Migration von einer nicht agilen Methodik.

In der Regel handelt es sich dabei um eine Art Wasserfall-Methode, bei der in der Praxis in der Regel versucht wird, alle technischen Anforderungen zu dokumentieren, bevor eine Codezeile geschrieben wird.

Das funktioniert aber nicht immer. Oft klappt es nicht. Der Grund? Denn die Anforderungen stimmen selten mit der Realität überein. Dinge ändern sich. Daher der Schritt in Richtung Agile.

Mit Agile ist die User Story alles, was den Benutzer interessiert. Sie möchten von Punkt A nach Punkt B gelangen. Wie Sie dies in Bezug auf die Implementierung erreichen, liegt in Ihren Händen. Wenn Sie darauf warten, dass Ihnen jemand die technischen Anforderungen mitteilt, ist das nicht wirklich Agil. Wenn Sie Fragen haben, fragen Sie. Wenn Sie Dokumentation benötigen, dokumentieren Sie, aber Sie möchten nicht, dass der Kunde all diese Entscheidungen für Sie trifft. Sie mögen Meinungen haben, aber in einem agilen Umfeld sollten diese Meinungen (wie Ihr Guru vorschlägt) in einem Gespräch diskutiert werden.

Es mag das Gefühl haben, dass dies eine Belastung für Ihr Team ist, aber betrachten Sie es als Luxus. Ihr Team hat jetzt viel Einfluss auf die Lösung - was beim Wasserfallmodell nicht unbedingt der Fall war.