ユースケースは単なる複数のユーザーストーリーですか?
ユースケースよりもユーザーストーリーを使用することの利点は何ですか..およびその逆...どちらか一方を使用する場合...すべてのアジャイル手法はユーザーストーリーを使用しますか?
ユースケースは単なる複数のユーザーストーリーですか?
ユースケースよりもユーザーストーリーを使用することの利点は何ですか..およびその逆...どちらか一方を使用する場合...すべてのアジャイル手法はユーザーストーリーを使用しますか?
実際、元のユース ケース ( Jacobson の OOSEを参照) は、現在のユーザー ストーリーと同様にかなり軽量でした。時間の経過とともに、「ユースケース」の一般的な形式が、入力、出力、継承、使用関係、疑似コードなどを含む複雑なドキュメントになるまで進化しました。一般に、プログラマーはすべてをプログラミングに変換しようとします。
いずれにせよ、「ユースケース」と「シナリオ」の「ユーザーストーリー」を区別するものを定義しようとする試みは、同意する2つの権威を見つけるのが難しいため、かなり無駄です.\
個人的には、「[アクター] [動詞] [名詞] to get [ビジネス価値]」というパターンが役に立ちます。1 段落程度のテキストを超える場合は、大きすぎる可能性があります。
結局のところ、「アジャイル」は単なるラベルであり、人々はそれが何を意味するのかについて正確に意見が分かれています。同様に、人々は非常に異なるものを「ユースケース」と呼びます。
私の経験では、この2つの主な違いは、ユーザーストーリーがユーザーに焦点を当てており、通常は短く、形式的ではないことです。理想的には、はがきに簡単に収まるはずです。おそらく、エラー処理などの詳細は提供されていません。
ユースケースは、はるかに正式なものにすることができます(ただし、非公式に書く人もいます)。システムとのすべての相互作用に焦点を当て、同じユースケース内のいくつかの異なるシステム/アクターなどについて詳しく説明する場合があります。
それは私の経験ですが、おそらく誰もがこれらのツールをさまざまな方法で使用しているでしょう。ラベルにこだわる必要はありません。プロジェクトに適したものを使用してください。
ユースケースは、ユーザーストーリーをまとめたものではありません。
ユーザーストーリーは通常、ユースケースよりもはるかに単純です。ユースケースは、システムのある側面の動作に関係するすべてを完全にカバーしようとしていると思います。つまり、すべての動作、すべてのエラーパス、およびすべての例外処理です。
ユーザーに推奨されるテンプレートは次のとおりです。
(役割)として私は(何か)欲しいので(利益)
(この単純なテンプレートを提供してくれたMike Cohnに感謝します)
このように表現された動作の記述は、より機敏です。
この種のテンプレートを使用すると、さまざまな詳細レベルを使用して動作を説明できます。例えば:
IMHOのユースケースははるかに石に刻まれています!したがって、初期バージョンの後に更新するのは問題になる可能性があります。
HTH
乾杯、
ロブ
一言で言えば、いいえ。
ユースケースは通常、特定の機能がどのように機能するか、または特定のユーザーがシステムをどのように利用するかを示す詳細な仕様です。これは通常、特定のユーザー (またはアクター) の声であり、自己完結型です。
一方、ユーザーストーリーは「議論への誘い」です。通常は 1 文または 2 文です。そのための 1 つの優れたリソースを次に示します。また、Mike Cohn のUser Stories Appliedは、それだけの価値があります。
典型的な構文は、「<ユーザー> として <ビジネス価値> を達成するために <機能性> が必要です」または「<ユーザー> として <ビジネス価値> を達成するには <機能性> が必要です」であり、ストーリーの価値を強調します。 .
ユーザー ストーリーは独立したものではなく、開発者と顧客 (または顧客の代理人) の間でストーリーについてのディスカッションを行うことを目的としています。
ユースケースはユーザーストーリーと考えることができますが、その逆はできません。ユースケースは、ストーリーの複数の「エンディング」、特別な要件をカバーします(たとえば、フォームフィールドはxyz形式で入力する必要があり、ユーザーが間違った形式でフィールドを入力した場合はエラーメッセージ123を表示します)。また、ユースケースには、セキュリティガイドラインなどの外部ドキュメントへの追加の参照を含めることができます。