ユーザーストーリーとアジャイル用語の機能の違いは何ですか？
機能は「クレジットカード認証」のようなものかもしれませんが、ユーザーストーリーは「Paypalのクレジットカード認証」かもしれません。
では、ユーザーストーリーは機能のサブセットですか？
はい、サブセットのようなもの。この記事は読みやすいです：
機能とストーリー
抜粋：
今日、私は自分の心の特徴と物語の違いを明確にしておらず、それが重要な違いであることに気付きました。基本的に、機能とは、エンドユーザーが通常一度にすべてを取得することを期待する機能のパッケージを関連付けて配信するストーリーのグループです。たとえば、インラインテーブルのサイズ変更は機能です（注：これは、テーブル、行、および列のサイズを変更するためのドラッグ機能です。Wordで試してください）。最初のパスでは、おそらくテーブルのインラインサイズ変更のための単一のストーリーがありますが、推定するには大きすぎます。したがって、3つのストーリーに分割し、列のサイズを変更し、行のサイズを変更して、テーブル自体のサイズを変更します。
Kent Beck and Martin Fowlerstoriesおよびfeaturesは同義語によると：
ユーザーストーリーは、顧客にとって価値のある機能の塊（Wordfeatureを使用する人もいます）です。
通常、機能と呼ばれるものは、テーマまたはepicと呼ばれます。テーマとエピックは、ユーザーストーリーをより大きな機能セットにグループ化するために使用されます。
より意味的な観点から：機能は構築しようとしているシステムの一部であり、ユーザーストーリーはその部分を説明する方法です。
補正：
パスカルが指摘したように-その引用で「機能」の本当の意味を見逃したのかもしれません（「機能」は明らかに機能を指します） Pascalが言ったように、ユーザーストーリーは機能をキャプチャする方法であるため、多くのコンテキスト（「この機能に取り組んでいます」と「この機能に取り組んでいます」）。つまり、これら2つの間に1対1の関係があります。そして、セマンティクスに関する私の発言からわかるように、これは私が本当にそれを理解する方法です。
どういたしまして..
ユーザーストーリーは、ビジネス価値の小さな部分を表します。そのため、ユーザーストーリーが機能のサブセットであるか、機能がユーザーストーリーのサブセットであると言うのは本当に困難です（ユーザーストーリーは通常、正確に何を知らない傾向がある利害関係者によって書かれていることにも留意してください）彼らが欲しい... :)）
したがって、ストーリーを短くするためにアジャイルの推奨事項に従う場合、ユーザーストーリーが機能のサブセットである「最良の」シナリオに該当します。
ただし、利害関係者が長いストーリーを書く場合、各ストーリーにはいくつかの機能があります（チームと利害関係者との間に良好なコミュニケーションがある場合、チームはストーリーを小さなものに分割するため、これは起こりません）
機能は、システムが行っていることです。ユーザーストーリーは、機能を取り込むための手段の1つにすぎません。
「類似の要件に複数のロールを使用する」ことについてさまざまなアイデアを探していたときに、このトピックに出会いました。
関係者は通常、ニーズを依存ストーリーとして伝えるため、関連ストーリーのコンテナとしての機能は、要件の優先順位付けに役立つと思います。最近のプロジェクトで、顧客から次のように言われました
メンバーは管理者にメッセージを送信できます管理者はすべてのメンバーにメッセージを送信できますメンバーは互いにメッセージを送信できます
これらの要件を確認したら、人々がメッセージを送信できるようにするシステムを実装し、誰が何をするかを許可するためのチェックを追加する必要があることを知っています。
また、これらの要件には、着信したメッセージの読み取り、配置、スパムなどの設定などの他の暗黙的な要件がある場合があることも知っています。
だから私はこれらの要件を次のように言い換えようとします
メンバーまたは管理者として、他の人にメッセージを送信できます。メンバーまたは管理者として、自分に送信されたメッセージを読むことができます。
そして、受け入れ基準として、誰が誰に送ることができるかを詳細に述べます。
その後、これらすべてを「プライベートメッセージング」機能と呼びます。そのため、しばらくして、クライアントが追加費用であると判断した場合、「プライベートメッセージングのものをドロップするだけ」と言うことができ、すべて削除できます。バックログから。