ユーザーストーリー、機能、および叙事詩の関係？

まだアジャイルに慣れていない人として、ユーザーのストーリー、機能、叙事詩の関係や違いを完全に理解しているとは思いません。

この質問によると、機能はストーリーのコレクションです。答えの1つは、機能が実際には叙事詩であることを示唆しています。機能とエピックは同じものと見なされますか？それは基本的には関連するユーザーストーリーのコレクションですか？

プロジェクトマネージャーは、階層構造があると主張しています。

Epic->機能->ユーザーストーリー

基本的に、すべてのユーザーストーリーはこの構造内に含まれている必要があります。したがって、すべてのユーザーストーリーはアンブレラ機能に該当し、すべての機能はエピックに該当する必要があります。

私には、それは厄介に聞こえます。ユーザーストーリー、機能、および叙事詩がどのように関連しているかを誰かが明確にできますか？または、違いを明確に概説する記事はありますか？

実際には非常に一般的な用語です。それらを解釈する多くの方法があり、文献や人々の見方は異なります。私が言うすべてを塩の大きな粒で取りなさい。

通常、Epicは、ソフトウェアの非常にグローバルで、あまり明確に定義されていない機能で構成されています。とても広いです。通常、それを理解し、それらをアジャイルな反復に適合するようにしようとすると、小さなユーザーストーリーまたは機能に分割されます。例：

Epic-
顧客がWeb経由で自分のアカウントを管理できるようにする

機能とユーザーストーリーはより具体的な機能であり、受け入れテストで簡単にテストできます。多くの場合、単一の反復に収まるように十分な粒度にすることをお勧めします。

機能は通常、ソフトウェアの動作を説明する傾向があります。

機能
-Webポータルを介した顧客情報の編集

ユーザーストーリーは、ユーザーがやりたいことを表現する傾向があります。

ユーザーストーリー
銀行員として
、顧客情報を変更
して最新の状態に保つことができるようにしたいと考えています。

この2つの間に実際に階層があるとは思いませんが、必要に応じて、または作業方法に合っていれば、階層を設定できます。ユーザーストーリーは、機能に対する特定の正当化、またはそれを行う特定の方法になります。または、逆の場合もあります。機能は、ユーザーストーリーを実現する方法です。または、同じことを示すことができます。両方を使用することができます：ユーザーストーリーは、ソフトウェアの制約を説明するためにビジネス価値と機能をもたらすものを定義します。

ユーザーストーリー：顧客として、私はカードは最も人気のあるクレジットで支払いをしたい
フィーチャー政府のGOV-TAX-02のXML APIをサポートしています。

シナリオの問題もあります。これは通常、機能/ユーザーストーリーが実行される方法です。通常、特定の受け入れテストに明確にマッピングされます。例えば

シナリオ：お金 を引き出す
銀行口座に2000ドルある 100ドルを引き出す と、現金で100ドルを受け取り、残高は1900ドルです

それが私が働いているそれらの用語を定義する方法です。これらの定義は、数学的な定義や標準化された用語とはほど遠いものです。右翼の政治家と左翼の政治家の違いに似ています。どこに住んでいるかによります。カナダでは、右翼と見なされるものは、米国では左翼と見なされる場合があります。それは非常に変数です。

真剣に、私はそれについてあまり心配しません。重要なことは、チームの全員が定義に同意して、お互いを理解できるようにすることです。スクラムのようないくつかの方法は、それらをより正式に定義する傾向がありますが、あなたに合ったものを選び、残りは残します。結局のところ、プロセスとツールを介した個人と相互作用、および包括的なドキュメントを介した作業ソフトウェアについては機敏ではありませんか？

Epic：最終的に小さなストーリーに分解される非常に大きなユーザーストーリー。

ユーザーストーリー：開発者がそれを実装するための労力の合理的な見積もりを作成できるように、十分な情報を含む、要件の非常に高いレベルの定義。

http://www.telerik.com/agile-project-management-tools/agile-resources/vocabulary.aspx

機能：ソフトウェアアプリケーションまたはライブラリの際立った特性または機能（パフォーマンス、移植性、機能など）。

http://en.wikipedia.org/wiki/Software_feature

これらの用語にあまりにも厳格な階層を適用しないように注意します。以前の仕事でそれを試みました。二回。両方の試みは異なっており、どちらの場合も不必要に自分自身を制限していることがわかりました。唯一の定数は、ユーザーストーリーの定義でした。計画の観点から見ると、ストーリーはプロジェクトの基本的な構成要素です。より大きな用語（エピック、機能など）は事実上単なるタグです。タグは、ストーリーを複数のエピックと複数の機能の一部として同時に存在させるための簡単な方法です。それよりも厳格であることは精神的な努力の価値はありません。

タグはStack Exchangeで機能し、あなたにとっても機能します。

Epics、Stories、Featuresの使用方法は次のとおりです。

プロジェクトサイクルの初期に、Epicsを作成します。これらは非常に高レベルで、ほとんどマーケティング中心の機能の弾丸です。次のようなエグゼクティブサマリーで使用できるもの

新しいWebサイトにより、顧客は製品を閲覧したり、在庫状況や価格を表示したり、注文したり、過去の注文履歴を確認したりできます。

これは次のようなエピックにつながります

• 製品カタログを閲覧する
• 可用性を表示
• 価格を見る
• 注文する
• 注文履歴を見る

これらはユーザーストーリーとして書かれています（たとえば、顧客として製品カタログを参照して、情報に基づいて購入を決定できるようにします）が、実際に開発およびリリースされる10のスターターとしてのみ機能します。

これらのエピックは、さらにユーザーストーリーに分解されます。これらは実際のエンドツーエンドのユーザージャーニーであり、範囲が非常に限定され、1つのリリースサイクルで独立して推定および計画でき、開発、テスト、およびリリースできる方法で定義されます。

ユーザーストーリーは配信の単位です。ユーザーストーリーは、完全であるか完全ではないか、公開されるか、公開されないかです。

Epicは、多数のユーザーストーリーをもたらす可能性がありますが、すべてが同時に開発またはリリースされるわけではありません。

例として、製品カタログの閲覧の叙事詩は、

• カテゴリ階層をナビゲートする
• キーワードで探す
• 製品属性によるフィルタリング（価格帯、ブランド、色、サイズなど）

繰り返しになりますが、これらはそれぞれ、たとえば顧客としてカテゴリ階層をナビゲートし、製品を参照して、自分のニーズに最も適した製品にドリルダウンできる形式で作成されます。

一般的に、ほとんどのプロジェクトでは、数十の叙事詩と数百の物語があります。

次に、ストーリーのライフサイクルを進めながら、これらのストーリーにFeatureのタグを付けます。たとえば、すべての参照と検索、在庫と価格設定のストーリーには、たとえば「製品カタログ」のタグが付けられます。クレジットカードによる支払いに関連するプレイスストーリーには「クレジットカード」ラベルが付けられ、PayPalによる支払いに関連するストーリーには「ペイパル」ラベルが付けられます。

これらのラベルは、同じアクティビティを実行する異なるタイプであるためではなく、一緒にリリースする必要があるため、一緒に属するストーリーをグループ化するのに役立ちます。

たとえば、「クレジットカードによる注文の支払い」ストーリーは「PayPalによる注文の支払い」ストーリーと同じ叙事詩に属しますが、一緒にリリースする必要はありません。

一方、「クレジットカードによる注文の支払い」ストーリー、「クレジットカードへの返品返金の処理」ストーリー、および「顧客が自分のアカウントで保存したクレジットカードを管理できるようにする」ストーリーは、互いに属しているようです。 。それらはすべて、「クレジットカード」機能ラベルでタグ付けされていました。つまり、それらはすべて「クレジットカード」機能に属します。PayPalへの返品払い戻しを処理できない場合、またはアカウントで保存したクレジットカードを管理できない場合は、クレジットカードで支払いを行う機能をリリースすることはあまり役に立ちません。

注：一般的なルールとして、つまり。これは、最終的にはビジネス上の決定です。市場投入までの時間が重要な場合は、これらのいずれかを使用してライブを開始する正当な理由があるかもしれません。

したがって、Epicsは、独立して開発できる（関連するが別々の）ストーリーに分解するのに役立ち、Featuresは一緒にリリースする必要があるストーリーをグループ化するのに役立ちます。

Epicsはユーザーストーリーに分解され、ユーザーストーリーはフィーチャーに合成されると言えます。機能に属するストーリーは通常、Epics全体にあります。したがって、エピックと機能は、厳密な階層ではなく、直交しています。

私たちの働き方では、エピックスがストーリーに分解されると、目的が失われます。Epicsを推定または計画しません。Epicsの進行状況を追跡しません。Epicsはリリースしません。ユーザーストーリーを推定、計画、追跡します。そして、機能をリリースします。

これらはあなたが基づいているアジャイルキャンプに応じて変えることができる用語であり、外部の利害関係者を含むあなたのチームの全員が間違いなくあなた自身のキャンプを作ることができるため、本当に正しい答えはないという多くの回答のように私は同意しますそれらの意味を理解します。これは、要件を整理する方法にすぎません。

私が好きな答えはマイク・コーンのキャンプからのものであり、それはかなり簡単です。

http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes

• Epicは単なる大きなストーリーです（階層的）
• テーマは単なるストーリーのグループです（タグによく似ています）

彼は実際には「機能」という用語を避けています。これは主に、伝統的な滝の世界で一般的な用語だったためだと思います。多くのアジャイルキャンプでは、違いを強調するために異なる用語を使用する傾向があります。

PMの定義では、FeatureはEpic-Story階層の中央のどこかにあります。

これは、InfoQの記事http://www.infoq.com/articles/visualize-big-picture-agileからのこの定義の情報グラフィックです;-)

機能とエピックは同じものではありません。

• 機能はユーザーストーリーではありません。
• Epicはユーザーストーリーです。
• ユーザーストーリーは叙事詩かもしれません。
• ユーザーストーリーには多くの機能を含めることができます。
• フィーチャーは、1から多数のユーザーストーリーを満たすことができます。

計画段階では、議論がにつながるユーザーストーリー typicalyとして識別されている叙事詩彼らのためにソリューションを実装するための努力が、数日で達成するにはあまりにも大きいため。製品の機能は、このフェーズで特定されます。しかし、それは議論の副産物にすぎません。次に、機能を使用して製品ロードマップを計画しますが、これは別の議論です。

エピックを採取し、その結果、さらに議論されているユーザーストーリー各エピックため。特長と叙事詩はでの議論駆動するために使用されているバックログ洗練とスプリント計画セッションを。その時点で、それらの議論から出てくるユーザーストーリーは洗練され、優先順位が付けられ、スプリント計画では、実装のためにスプリントに受け入れられます。

これは単なる問題の分解です。サイズが異なる場合を除き、それらは単なるストーリーです。

私は個人的にはサイズにラベルを付けないことを好んでいますが、もしそうするならそれでも問題ありません。PMにワークスペースの定義を尋ねてください。

私たちの組織には2,000人以上の開発者がいるため、この質問に対する答えは、共通の製品で一緒に作業している数百のアジャイルチーム間の流かつ明確なコミュニケーションにとって重要です。非常に小さな組織の場合、階層構造である必要さえない非常に単純な構造にすることができます（他の人が答えたように）。ただし、大規模な組織の場合、組織化され、スケーリングされた一貫性のある階層が必ず必要です。その中には、厳密に階層ではないものから階層を作成しようとする問題があります。

ちなみに、これらの異なるレベルのそれぞれを「作業項目」と呼びます。一部の組織（上記の回答者の一部を含む）は、異なるレベルをStoriesまたはUser Stories（および過去にもあります）と呼んでいますが、これはあいまいすぎるため、これらを総称してWork Itemと呼びます。

これまでに「公式に」行った最善の方法は、階層の最上位（最上位から2番目）にある投資テーマとビジネスエピックのDean LeffingwellのSAFe構造、その下のフィーチャー、最後にフィーチャーの下のストーリーに従うことです。アジャイルによると、タスクは常にストーリーの下にあるため、その用語をそれ以上再利用しないように注意しています。少なくとも、すべてのチームで一貫性を保つために、SAFeに従うことにしました。

しかし、これは私たちのニーズにはまだ不十分です。フィーチャーは、ソフトウェア製品の消費者に明らかに価値のある成果物として定義されます（つまり、これらのフィーチャーを今後のリリースの発表に記載します）。また、ストーリーを、単一のアジャイル開発チームが単一のスプリントで提供できる、より少ない範囲と作業として定義します。また、SAFeのポートフォリオレベル（およびこのレベルを下回らないレベル）での投資テーマとビジネスエピックの定義に従うことを開始しています。そして、「テーマ」と「叙事詩」の古い定義を使用しないようにしています。

私たちは今、この方向にゆっくりと進化していますが、進歩の車輪はゆっくりと研ぎます。作業を一口サイズのチャンクに分割して、作業を定義し、複数のチームでスムーズに実行できるようにする方法については、まだ苦労しています。これを行うには、フィーチャーよりも小さいがストーリーよりも大きい「サブフィーチャー」が必要であることがわかります。サブ機能は、個々のチームがフィーチャー上で行った作業のチャンク、または単一のチームが異なる時間に（異なるスプリント、または異なるリリースでも）行った作業のチャンクに使用できます。

FeatureとBusiness Epicの間に複数の階層レベルも必要ですが、SAFE Investment Themesと混同されやすいため、「テーマ」と呼ぶ以外は、これを解決していません。いくつかの大きなプロジェクト（リリース）では、5〜8もの異なる階層レベルがあり、それぞれが作業をより小さなチャンクに分割しています。これらのテーマは「機能グループ」と考えることができますが、それは必ずしも正しい用語ではありません。

あいまいさではなく、明快さを提供する用語を使用することが重要だと思います。したがって、ストーリーを参照する人は、1つのスプリントで実行できる作業の最小単位（ストーリーの下のタスクを除く）を意味し、サブ機能は、単一のスプリントで実行できる作業の最小単位を意味しますチーム。同様に、機能グループは機能の1つ上の階層レベルです。その上、少しあいまいになるので、通常は単にテーマと呼び、テーマを他のテーマの親および子として許可します。機能、サブ機能、およびストーリーレベルをそれぞれ1つのレベルに制限しようとしています（機能は他の機能の子であってはなりません）。

「タグ」を使用してこれを整理することはできますが、タグは、すべてのチーム間の作業を分類するために必要な組織的な作業内訳構造を提供しません。定義では、タグはあいまいです（多対多の関係）が、階層は厳密に1対多です。

結論としては、これはまだ進行中の作業であり、私たちはまだそれに取り組んでいるということです。しかし、テーマ、叙事詩、特集、ストーリーのSAFe定義を順守することで、正しい方向に進むことができます！

製品バックログ階層は、製品のサイズとそのモジュール性（定義されている製品領域の数）に大きく依存しています。

小さなプロジェクトの場合：Epic> Storyで十分です。どちらかを「機能」と呼びます。
大規模プロジェクトは、小説>テーマ>叙事詩>特集>ストーリーのようになります。

最良の例は次のとおりです。
小説 = MS Office
テーマ = MS Word / MS Excel ...
Epic = Tables / Font Directory ...
Features = Basic Table / Table Color Scheme / Operations with Cells ...
Stories（for ' 「テーブル」エピック内の基本テーブル機能）=テーブルの追加/テーブルの描画/未加工の挿入/列の挿入...

バックログの独自のスケーリングを定義する際に留意しておくと有益なことは次のとおり
です。1.ストーリー： a）1つのスプリント内で常に実行可能。b）エンドユーザーに対して常にテスト可能とは限らない
2.叙事詩 /特徴：a）1つのスプリント期間に適合せず、分解する必要がある。b）エンドユーザーに対して常にテスト可能であるべきである; c）常に出荷可能、収益化可能-ROIを計算する
3. Epic> Featureセクションを追加するかどうかを検討する場合、またはEpic> Storyに固執する場合：EpicとStoryの間にFeatureを挿入するのは、次の場合のみです。tは1リリースにも適合します。そのため、1リリース期間に適合する出荷可能な要素を定義する必要があります。

これが役に立てば幸いです。

私たちの組織には次のものがあります。

テーマ=ストーリーのコレクションをグループ化するために使用

Epic =ユーザーストーリーに分解する必要がある大規模なユーザーストーリー（実際には要件）を説明します

機能=ブリキに書かれていることを行い、必要な製品の機能を説明する

ユーザーストーリー=これは、タスクの派生元である最低レベルの詳細です。