機能は、ビジネスに機能を提供できる機能の個別の要素です。
ストーリーは、利害関係者からフィードバックを得て、何か間違っているかどうかを確認するために使用できる機能の小さな側面です。
たとえば、「ユーザーが記事にコメントできるようにする」という機能があります。その機能に関連するストーリーは次のようになります。
- コメントを保存
- 失礼な言葉のコメントをフィルタリングする
- コメントを400文字に制限し、ユーザーにフィードバックする
- ボットがサイトにスパムを送信するのを防ぐためにキャプチャを追加する
- ユーザーがGoogle ID経由でログインできるようにする
等.
その後、各段階で、方向性が有用かどうかについてフィードバックを得ることができます。
一部のチームは、機能をストーリーに分割しません。それで大丈夫です。
機能==ユーザーストーリー。
言い回しは、与えられたアジャイル 方法論 が採用されていることによって決まります。
異なる方法では、機能を指すために異なる用語を使用します。使用する方法論や用語を決定するのはチームの責任です。エクストリームプログラミング（XP）では、ユーザーストーリーまたはストーリーという用語を使用して機能を表しています。スクラムは、製品バックログを使用して機能リストを記述します。機能駆動開発は機能を使用します。 DSDMは要件を使用します。同様に、要件やユースケースを使用して段階的に提供される機能を定義する統合プロセスのさまざまな軽量バージョン、つまりアジャイルUPがあります。結局のところ、目標は同じです。ビジネスの価値を定期的に、少しずつ、または少しずつ早く提供することです。
A ユーザーストーリーは、顧客の言語での非公式な声明であり、顧客が達成したい何かの意図を捉えています。 ser Storyは、非公式の要件ステートメントと考えることができます。
A ソフトウェア機能は、ソフトウェアの全体的な設計と機能に寄与するソフトウェアの明確な特性です。
いくつかの重要な考慮事項：
- ストーリーは機能を説明しますが、機能はストーリーを説明しません。
- ストーリーは機能を直接説明しない場合があります。
- ストーリーは、多数の機能を含めることを意味する場合があります。
- Feature-単独で、またはFeaturesのコレクションのメンバーとしてStoryの意図をキャプチャできます。
これらすべてを念頭に置いて、私はストーリーを説明として考える傾向があります。基本的に、顧客が何を望んでいるかを示す非公式の要件。一方、機能は、お客様の要件を満たすためにシステムがどのように機能するかを示す仕様であると考える傾向があります。
2つの用語は密接に関連していますが、いくつかの違いがあります。
まず、それらは異なるドメインから来ています。 「機能」という用語は、ソフトウェアの機能の一部を表すかなり一般的な用語ですが、「ユーザーストーリー」は、アジャイルソフトウェア開発のコンテキストでのみ開発されたものです。
実際には、1つのユーザーストーリーが特定の機能の実装で構成されているという点で、それらはしばしば一致します。
ただし、状況によっては異なる場合があります。
- 多くの場合、機能は1人のユーザーストーリーにはあまりにも多くの作業です。ユーザーストーリーは大きすぎてはいけません（通常、数日以内、最大1〜2週間の作業）。明らかに、多くの機能ははるかに大きいです。その場合、機能は多くのユーザーストーリーに実装されます。 「エピック」を使用してユーザーストーリーをグループ化する人もいます。その場合、その機能はエピックであると言えます。
- 非機能要件（パフォーマンス、セキュリティ、互換性など）は、ユーザーストーリーとして扱うこともできます（これは広く受け入れられていません）。その場合、ユーザーストーリーの結果は通常、機能とは呼ばれません（ "アプリケーションがめったにクラッシュしない"と呼ばない限り）。