ユーザーストーリーを使用して複雑なビジネスルールを定義する方法

ユーザーストーリーの迅速で汚い定義：

"As a <role>, I want <goal/desire> so that <benefit>"

この一般に受け入れられている定義では、ビジネスルール、制約、またはユーザー入力を定義するためのスペースがほとんどありません。

説明のための簡単な例：

"As a <librarian>, I want to <register new books> so that
<students can find their availability online>"

このばかげた例では、本を登録するときに必要なフィールドをどこで定義しますか？どこにでも書かれるべきですか？または、必要なビジネスルールをプロダクトオーナーから口コミとして渡す必要がありますか？

フィールドは、会話の一部である必要があります。それが有用な場合、それらは書き留められるかもしれませんが、それは判断の呼び出しです。ドキュメントを最新の状態に保つのは難しいかもしれませんが、動作しているソフトウェアはある程度ドキュメントとして見ることができます。

ユーザーストーリー-会話を交わすという約束は、これに関するブログエントリになります。

あなたの些細な例には、あなたがこれにどれほど気づいているかわからないいくつかの点があります。「新しい本を登録する」とはどういう意味ですか？「オンラインで在庫を見つける」とは何ですか？これらは会話の始まりであり、ストーリーが完了すると、おそらくそれらの登録をファイルに保存するか、レポートを定期的に生成する必要があるため、新しいストーリーが存在する可能性があります。

これまでの回答は、特にユーザーストーリーが会話を思い出させるものであることに関して、有効なポイントを提供します。考慮すべきその他の事項：

1. ストーリーが複雑すぎる場合は、おそらく叙事詩です。エピックを今すぐ小さなストーリーに分割したり、製品のバックログで優先順位を付けたりすることができます

2. テストケースを暗示する詳細は、ストーリー自体から分離されています。[ マイク・コーン ]

   ストーリーカードの裏面に追加したり、重要な場合は小さなメモを作成したり、受け入れテストのドキュメントに追加したりできます。

ユーザーストーリーが良いかどうかを評価するためのガイドラインとして、Bill Wakeの提案に従うことができます。

• 私は（他の物語から）独立しています
• N egotiable
• Vの（ユーザーまたは顧客へ）aluable
• E stimable（適切な近似値まで）
• Sモール（推定可能）
• T ESTABLE

Mike Cohn著のUser Stories Applied本の第2章「Writing Stories」を読むことをお勧めします。

通常、多くのファセットを含む幅広いユーザーストーリーで、ストーリーの最も一般的な例を取得しようとします。次に、詳細を継承する子ユーザーストーリーを作成します。RallyDevのような多くのアジャイルプロジェクト管理ツールを使用すると、これを簡単に行うことができます。

新しい本の登録は広範であるため、おそらく<role>本をどのように登録するかについての10の子ユーザーストーリーがあります。

これらの事柄の極端な詳細または奇妙なフリンジの詳細は、通常、そのユーザーストーリーの1つ以上のタスクで定義します。タスクは、ユーザーストーリーを満たすために（一般的なレベルで）行うべき開発および設計作業を定義するのに役立ちます（たとえば、説明フィールドへの入力が50文字未満であることを確認するためのバリデーターを作成します...） 編集： 追加したいだけですユーザーのストーリーに極端な詳細を含めない方がおそらく良いでしょう。なぜなら、ユーザーが本当に気にかけていることではないからです。ユーザーはソフトウェアを一般的な用語で説明したいと考えており、ソフトウェア開発者に頼って詳細を把握し、隠します。

これは私が問題に取り組む方法ですが、多くの異なる方法があると確信しています。

答えは簡単です。ビジネスルールを受け入れ基準に組み込みます。

説明のための簡単な例：

図書館員として、新しい本を登録して、学生がオンラインで入手できるようにします。

次の場合に満足します：*次のフィールドを登録できます：-ISDN-著者-Dewey Decimal blah blah *本がシステムによって登録されたことの確認が表示されます*本をシステムで表示できます

ユーザーストーリーを使用して複雑なビジネスルールを定義する方法

それはユーザーストーリーの目的ではありません。これらは、実装の作成に必要なすべての詳細またはビジネスルールをキャプチャするソフトウェア要件ではありません。それらは、アプリケーションがユーザーの観点から何をすべきかについての単なる説明です。

重要なことを忘れないでください：適切なソフトウェアを構築します。そのために必要なものは何でも使用します。ユーザーストーリーは、アプリケーションに必要な機能を収集したことを確認するためのものです。物語（...として…）は、ソフトウェアの構築に関わる人々の間のコミュニケーションに関するものです。

詳細を受け入れ基準、サブストーリー、ユーザーストーリーに添付された技術タスク、仕様書などに記載することは、ユーザーストーリーが役立つことを超えています。ユーザーの悩みは、ソフトウェアの構築方法を決定するときの会話の「対象」にすぎません。

示されている例では、デューイやその他の分類システム、ISBN、取得番号、コピー/タイトル/著者の複製、他のエディションなど、開発者がほとんど知らない書籍登録の詳細が多数あります。 新しいシステムの場合、そのような詳細は顧客が提供する必要があります（そして、すべての人々の司書は確かにそれらを気にします）。

Steve O'Connellの言葉を引用すると、「仕様に必要な詳細が欠けている開発者が自分で作成したビジネスポリシーがどれだけ作成されるかを考えるのは恐ろしいことです。」