ユーザーストーリーと機能の違いは何ですか？

icescrumで遊んで、ユーザーストーリーとユーザー機能の違いを理解していないことに気付きました。

誰かが違いを説明できますか？

機能は、ビジネスに機能を提供できる機能の明確な要素です。

ストーリーは機能の小さな側面であり、これを使用して利害関係者からフィードバックを得たり、何か間違ったことをしているかどうかを調べることができます。

たとえば、機能は「ユーザーが記事にコメントできるようにする」かもしれません。その機能に関連するストーリーは次のようになります。

• コメントを保存
• 失礼な言葉のコメントをフィルター
• コメントを400文字に制限し、ユーザーにフィードバックする
• サイトにスパムするボットを阻止するためにキャプチャを追加
• ユーザーがGoogle ID経由でログインできるようにします

等

その後、各段階で、私たちが取っている方向が有用かどうかについてフィードバックを得ることができます。

一部のチームは、機能をストーリーに分割しません。それで大丈夫です。

機能==ユーザーストーリー。

言い回しは、採用されている特定のアジャイル手法によって決定されます。

異なる方法論では、異なる用語を使用して機能を参照します。どの方法論または用語を使用するかを決定するのはチーム次第です。エクストリームプログラミング（XP）は、ユーザーストーリーまたはストーリーという用語を使用して機能を表します。スクラムは、製品バックログを使用して機能リストを記述します。機能駆動開発では機能を使用します。DSDMは要件を使用します。同様に、要件および/またはユースケースを使用して段階的に配信可能な機能を定義する統合プロセス、またはアジャイルUPのさまざまな軽量バージョンがあります。最終的には、目標は同じです。ビジネス価値を少しずつ定期的に、より早くより早く提供することです。

ユーザーストーリーは、顧客の願いが実現することを何かの意図を捉え、顧客の言語で非公式文です。ユーザーストーリーは、非公式の要件ステートメントと考えることができます。

ソフトウェア機能は、ソフトウェアの明確な特徴ソフトウェアの全体的なデザインと機能性に寄与していることです。

いくつかの重要な考慮事項：

• A ストーリーは記述することができる機能を、しかし、機能が説明したことがないストーリーを。
• A ストーリーは直接記述しない可能性があります機能を。
• A ストーリーの数の包含を意味するものでもよい機能。
• 機能 -単独またはコレクションのメンバーとして機能 -の意図取り込むことができるストーリー。

このすべてを念頭に置いて、私はストーリーを説明として考える傾向があります。基本的に非公式の要件で、顧客が何を望んでいるかを教えてくれます。一方、機能は、顧客の要件を満たすためにシステムがどのように機能するかを示す仕様と考える傾向があります。

2つの用語は密接に関連していますが、いくつかの違いがあります。

まず、それらは異なるドメインから来ています。「機能」という用語はソフトウェアの機能の一部を表すかなり一般的な用語ですが、「ユーザーストーリー」はアジャイルソフトウェア開発のコンテキストでのみ考案され、実際に使用されています。

実際には、1つのユーザーストーリーが特定の機能を実装することで構成されるという点で、非常に頻繁に一致します。

ただし、状況によっては異なる場合があります。

• 多くの場合、機能は1人のユーザーストーリーには多すぎる作業です。ユーザーストーリーは大きすぎてはなりません（通常は数日以内、最大1〜2週間の作業）。明らかに多くの機能ははるかに大きいです。その場合、多くのユーザーストーリーに機能が実装されます。一部の人々は「エピックス」を使用してユーザーストーリーをグループ化します。その場合、この機能は叙事詩であると言えます。
• 機能以外の要件（パフォーマンス、セキュリティ、互換性など）もユーザーストーリーとして扱うことができます（ただし、これは広く受け入れられているわけではありません）。その場合、ユーザーストーリーの結果は通常、機能と呼ばれません（「アプリケーションがめったにクラッシュしない」と呼ばない限り）。