アジャイル開発におけるユーザーストーリーの分離
私が読んだ内容に基づいて、ユーザーストーリーは多くの場合、「誰が」「何を」「なぜ」という形式でキャストされます。 「誰」「何」がわかりやすい。 ATMの例：
顧客として
入金できるようになりたい
[なぜ]
「なぜ」の行は、ソフトウェアの範囲に大きな影響を与える可能性があるようです。たとえば、次のすべては機能の正当な正当化のように見えます。ただし、1つ目はセキュリティ、保険、データの冗長性などを意味します。 2番目と3番目は、完全に別個のシステムの存在を意味します。 3つすべてがデータの永続性を意味します。
銀行によって保護されるように
オンラインで自分の財政を管理できるようにするため
それで、私のデビットカードで支払いをする
簡単に言えば、アジャイルソフトウェア開発のコンテキスト内で、複雑な/結合された機能要件をどのように処理して、正しく開発できるようにしますか？
たとえば、開発チームは、このような高レベルのユーザーストーリーから一連のユースケースを導き出しますか？または、ユーザーストーリーを書き直して、範囲を限定しましたか？
うーん、これらの理由がユーザーストーリーに役立つとは思いません。
この形式の理由は、開発者が仕様の精神ではなく仕様の文字に従わないように、開発者に洞察を与えるためです。
ユーザータイプ「顧客」を追加しても役に立たない可能性があります。一緒に行きます.
As a: _BankAccountOwner_
I want to: pay money into my bank account,
from another banks debit card,
by filling in a form online
So that: I can later withdraw it.
これで開発者は、これを行っているのがBankAccountOwnerタイプの顧客であることを知っているので、他のストーリーと合わせることができます。
彼らは私たちが達成しようとしていることの一般的な仕様を知っています、「ウェブページ経由でお金を入金する」
そして、彼らは「彼らは後でお金を引き出すことができるだろう」というユーザーの期待を知っているので、必要となる技術的な詳細を含めます（この限られた例では少し難しいですが...）。
- それは他人ではなくユーザーの銀行口座に行くべきです
- それは自動的にローンや何かを完済するべきではありません
- 銀行が破綻している場合はお金を受け入れないでください
- なんらかの理由でX日間引き出しできない場合は、お客様に警告する
Whyは、より簡潔な仕様を可能にし、必要な場合に開発者からの質問を促すことができます。 「他のストーリーYは、最初にローンを返済する必要があると言っていますか？」等
2番目のポイントについては、「このような高レベルのストーリーからどのように処理しますか？」まああなたの例はかなり高いレベルです。私はそれにいくつかの詳細とその他の変更を加えなければならなかったことに気づくでしょう。しかし、一般的にはそれらを実行してさらに追加するだけです。例えば
as a _BankAccountOwner_
I want to : pay money into my account
with a credit card... etc
as a _BankAccountOwner_
when paying money into my account
I want to : be told my current balance
銀行のような場合、よく知られているため、前もって100万と1つの要件があるはずです。ただし、通常は、既存のシステムを追加しているか、本当に基本的な「スプリントゼロ」のものから始めます。
As a: _Bank_
I want to : have a website
so that : I can provide services to _BankAccountOwner_
As a: _Bank_
I want to : have an ssl cert for my website
so that : I comply with laws X, Y and Z
等
ユーザーストーリーの1文の表現は、機能要件のキャリアを意味するものではありません。あくまでも概要です。このユーザーストーリーの詳細は、スプリントの直前（スプリント計画会議、またはバックロググルーミング会議の直前）に、製品の所有者とチームが双方向で会話することで明らかになります。これらの要件を正式に記録する必要はありませんが、必要に応じて、製品の所有者はこの会話の最も重要な結論を受け入れ基準の形式で記録できます。
ユーザーストーリーが最初はあいまいすぎる場合は、製品の所有者は、より多くの情報を提供し、チームからの質問に答えるだけです。チームが1つのスプリントには大きすぎると結論付けた場合にのみ、製品の所有者はストーリーを分割する必要があります。複数のユーザーストーリーに置き換えてください（多くの場合、チームの助けを借りて）。
だからあなたの質問に戻るには：
複雑な機能要件はどのように処理されますか？
- それらは、1つのスプリントで飲み込むのに十分なほど小さいユーザーストーリーに分類されます。
- これらのユーザーストーリーは、スプリントの直前に、会話を通じて明確にされます
「なぜ」の行は、ソフトウェアの範囲に大きな影響を与える可能性があるようです。
いいえ、whyはソフトウェアのスコープにまったく影響しません。これはストーリーの正当化であり、ストーリーが満たさなければならない要件ではありません。これは、開発者がストーリーの重要性を理解するために存在し、ストーリーが全体像にどのように適合するかを示しています。
他にもいくつか回答がありますが、他の回答では見逃されていると思います。
ここに理由があるのは、（マットレスではなく）銀行口座にお金を預けたい理由ではありません。なぜATMでやりたいのか。これに対する答えは、機能に影響を与える可能性があります。
たとえば、「銀行が閉鎖された後でも預金してお金を使うことができる」という理由の場合、銀行口座に預金取引を適用せずにお金や小切手を受け取るだけでは、ユーザーのニーズを満たしません。