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

18

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?

user144171
quelle
6
User Stories sind genau das - Anforderungen auf Benutzerebene. Niedrigere Softwareanforderungen (häufig Einschränkungen, die als akzeptabel angesehen werden) sollten immer separat erfasst und mit einem entsprechenden Verweis separat dokumentiert werden.
Gusdor
7
Der Sinn der User Storys ist, dass die meisten Benutzer Ihres Programms niemals wissen oder sich darum kümmern, wie es funktioniert . Sie kümmern sich nicht um die Datenbankstruktur, die Trennung von Interessen, Klassenstrukturen usw .; Sie legen Wert auf Stabilität, Geschwindigkeit und Benutzerfreundlichkeit. Deshalb halten Sie ihre Geschichten fest, um herauszufinden, wofür sie das Programm verwenden werden. Wie Sie es dann implementieren, ist eine ganz andere Ebene von Anforderungen, die Benutzer werden im Allgemeinen nicht in der Lage oder bereit sein, diesen Prozess zu informieren.
Jonrsharpe
2
Mücke: Eigentlich nicht. Ich habe gefragt, weil ich wirklich interessiert bin, wie das richtig gemacht werden kann, da ich mir sicher bin, dass SCRUM in vielen Teams ein Problem darstellt.
user144171
4
@maple_shaft das problem mit "rantish" -elementen ist, dass diese tendenziell rantish-antworten anziehen. Ich bin damit einverstanden , dass es ein vernünftiger Kern drin ist, fragt sich, ob es sein kann, bearbeitet ed nur , dass der Kern halten und auszulöschen Einladung zu Ranty Antworten
gnat
2
Hier gibt es eine gute Frage, die aber als Schimpfwort geschrieben ist. Ich habe versucht, etwas zu bearbeiten.
DA01

Antworten:

28

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.

MetaFight
quelle
3
+1 Akzeptanzkriterien fügt Detail
Fractional
3

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.

gbjbaanb
quelle
4
Würde es Ihnen bitte etwas ausmachen, dies in einer weniger (dh nicht) abfälligen Weise zu formulieren? Ich stimme Ihnen in diesem Punkt zu, aber die Leute sind anderer Meinung und das ist kein Grund, Ihre Manieren auf diese Weise zu verlieren.
Frank
Eigentlich kann ich mir keine Anforderungen vorstellen, die nicht im Voraus geschrieben wurden - selbst für die einfachsten Dinge wie numerische Felder muss man die Länge, den Datentyp und die Validierungen kennen. Diesen Gurus zufolge ist es nicht notwendig, dass diese Dinge in der Geschichte vorkommen. Aber wenn Sie den Code schreiben, ist High-Level-US nutzlos, Sie müssen die Einschränkungen, Abläufe usw. usw. kennen. Ich habe noch nie ein Projekt mit reinen Zwei-Satz-US gesehen, das für die Implementierung und das Testen effizient war.
user144171
3
Der Client hat einer 8-Bit-Ganzzahl zugestimmt, es ist also nicht meine Schuld.
JeffO
2
@gbjbaanb: Agil ist nur ein neues Modewort für "gesunden Menschenverstand", dh das Finden der richtigen Balance zwischen Vorausanalyse / Design und der schnellen Bereitstellung einer Teillösung, um Feedback zu sammeln. Ich finde den Begriff " agil" ziemlich irritierend, da diese Ideen außer dem Namen nur sehr wenig Neues enthalten. Das Schlimmste passiert, wenn ein eher unflexibles Framework wie SCRUM als agil auferlegt wird . IMO wirklich agil zu sein, würde bedeuten, die Worte agil und SCRUM fallen zu lassen und Ihren Prozess an Ihre Bedürfnisse anzupassen, wie wir es immer getan hatten, bevor die agile Welle begann.
Giorgio
1
@Alex er fragt sehr viel im Zusammenhang mit SCRUM und agilen Prozessen.
gbjbaanb
3

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.

JeffO
quelle
1
Aber hier ist das Problem, ein bisschen US ist alles, was Sie brauchen, aber ich sage, dass es nicht möglich ist, wenn es in der Geschichte um "was" und nicht um "wie" geht. Welche Länge hat das Feld, wenn ein Anmeldebildschirm angezeigt werden soll? Welche Zeichen sind erlaubt? usw ... den benutzern ist es egal, aber devs und tester werden und daher muss dies irgendwo geschrieben werden.
user144171
4
Also schreib es auf! An der ergänzenden Dokumentation ist nichts auszusetzen, wenn es darum geht, die Arbeit zu erledigen. Verstehen Sie nur, dass Sie dies in vielen Fällen nicht wie einen Kundenvertrag behandeln können. Der Client verwendet Ihren Anmeldebildschirm und teilt Ihnen dann mit, dass er unabhängig von den Angaben in Ihrer Dokumentation mehr Zeichen benötigt. Jetzt können Sie entscheiden, ob Sie Ihren Code, die Dokumentation oder beides ändern möchten.
JeffO
Und wenn es ein gewaltiges Unterfangen ist, die Länge einer Eingabe anzupassen, ist Ihr Code ohnehin nicht sehr beweglich, sodass wenig oder keine Dokumentation keinen großen Unterschied macht.
JeffO
2
@ user144171 Der Versuch, ALLE Anforderungen für ein Projekt oder eine Funktion im Voraus und so detailliert wie möglich bis zum letzten Bit aufzuschreiben, ist genauso schlimm wie überhaupt keine Anforderungen zu haben. Gleiches gilt für das Design.
AK_
@AK_ Ich glaube nicht, dass er angibt, dass dies alles im Voraus erledigt werden muss, aber sicherlich muss genug im Voraus erledigt werden, bevor man sprintet, wenn ein beträchtlicher Rückstand besteht.
maple_shaft
2

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.

maple_shaft
quelle
Ich bin mir nicht sicher, ob Sie zwischen Benutzeranforderungen und funktionalen Anforderungen unterscheiden. Die Benutzeranforderungen sollten, wie in den USA, funktionale Anforderungen sein, und die funktionalen Anforderungen unterscheiden sich deutlich von den Systemanforderungen.
Alex
@Alex: User Story / Anforderung => Geld vom Geldautomaten abheben möchten, Funktionsanforderung => Die Gesamtzeit für die Ausgabe von Rechnungen darf 30 Sekunden nicht überschreiten. Die Benutzeranforderung umfasst nicht die Funktionsanforderung.
Jmoreno
@jmoreno Diese "User Story" in Ihrem Beispiel ist keine User Story, sondern der Ausgangspunkt einer User Story. Und die "funktionale Anforderung" an die Ausführungszeit liegt in einer Grauzone, die wichtigste funktionale Anforderung besteht darin, Rechnungen auszugeben, die zeitliche Beschränkung könnte viele Ursachen haben.
Alex
2
@jmoreno Tatsächlich wird eine solche Leistungsmetrik als nichtfunktionale Anforderung betrachtet a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors . Das Verhalten selbst ist eine Funktion eines Systems . Die User Story stellt beides gegenüber, indem sie die Bedürfnisse eines Benutzers definiert. Die Funktion eines Benutzers ist vielmehr das, was wir als Anwendungsfall und nicht als funktionale Anforderung kennen.
maple_shaft
@ Alex Siehe meinen Kommentar oben. Ich denke, Sie sind beide verwirrt, was eine funktionale Anforderung ist.
maple_shaft
1

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.

Alex
quelle
1

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.

Cort Ammon - Setzen Sie Monica wieder ein
quelle
1
Das Problem bei dieser Denkweise ist, dass sie in einem kreativen Projekt gut funktioniert, in dem die Bedürfnisse des Benutzers klar sind, die genauen Spezifikationen jedoch begrenzt sind. Wenn es um komplexe Systeminteraktionen und insbesondere um behördliche Auflagen und die geschäftlichen Anforderungen an fest definierte Systemparameter geht, werden die wichtigen Details in User Stories oftmals nicht erfasst. Sie nehmen die Konversation auf, aber wenn ich 20 Seiten mit genauen Vorgaben und Regeln habe, ist das zu viel, um sie in eine "Konversation" aufzunehmen. Auch hier sind funktionale Anforderungen erforderlich.
maple_shaft
1
Ich bin damit einverstanden, dass Anforderungen benötigt werden. Ich denke nur, dass sie woanders hingehen sollten. Ich kann nicht für den Rest der Welt sprechen, aber ich habe festgestellt, dass es außerordentlich einfach ist, den Zweck von User Stories zu missbrauchen und sie in Broschüren voller Anforderungen zu verwandeln. Wenn das passiert, kann ich die User Stories nirgendwo hin. In einer perfekten Welt könnte man beides in User Stories einfügen, aber Entwickler sind menschlich und die Kultur ist launisch. Wenn sich ein Team daran gewöhnt, User Stories für Anforderungen zu verwenden, ist es möglicherweise kulturell unmöglich, zu dem zurückzukehren, von dem ich glaube, dass es das primäre Ziel ist.
Cort Ammon - Reinstate Monica
1

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.

Peter ist
quelle
1

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.

CodeGnome
quelle
0

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.

DA01
quelle