ユーザーストーリー、機能、叙事詩の関係？
まだアジャイルに不慣れな人なので、ユーザーのストーリー、機能、叙事詩の関係や違いを完全に理解しているとは思えません。
これによると question 、フィーチャーはストーリーのコレクションです。答えの1つは、機能が実際には叙事詩であることを示唆しています。機能とエピックは同じものと見なされますか？それは基本的に関連するユーザーストーリーのコレクションですか？
プロジェクトマネージャーは、階層構造があると主張しています。
エピック->機能->ユーザーストーリー
そして、基本的には、すべてのユーザーストーリーがこの構造に収まる必要があります。したがって、すべてのユーザーストーリーは包括的な機能に属し、すべての機能はエピックに属している必要があります。
私には、それは厄介に聞こえます。ユーザーストーリー、機能、叙事詩がどのように関連しているかを誰かが明確にできますか？または、違いを明確に概説する記事はありますか？
彼らは実際には非常に一般的な用語です。それらを解釈するには多くの方法があり、文学や人々の見方はさまざまです。私が言うすべてのことを巨大な塩の粒で取りなさい。
通常、エピックは非常にグローバルであり、ソフトウェアの機能があまり明確に定義されていません。それは非常に広いです。通常、それを理解してアジャイルなイテレーションに適合させると、小さなユーザーストーリーまたは機能に分解されます。例：
エピック
-お客様がWeb経由で自分のアカウントを管理できるようにします
機能とユーザーストーリーはより具体的な機能であり、受け入れテストで簡単にテストできます。多くの場合、1回の反復に収まるように十分に細かくすることが推奨されます。
機能は通常、ソフトウェアの機能を説明する傾向があります。
機能
-Webポータルを介した顧客情報の編集
ユーザーストーリーは、ユーザーが何をしたいかを表現する傾向があります。
ユーザーストーリー
銀行員として、
顧客情報を変更できるようにしたい
最新に保つことができるようにします。
私は実際には2つの間に階層があるとは思わないが、必要に応じて、またはそれがあなたの作業方法に適合している場合は、1つを持つことができる。ユーザーストーリーは、機能の特定の正当化、または特定の方法で行うことができます。または、逆の場合もあります。機能は、ユーザーストーリーを実現する方法の1つです。または、同じことを表すこともできます。両方を使用できます。ユーザーストーリーは、ビジネスの価値をもたらすものを定義し、ソフトウェアの制約を説明する機能を定義します。
ユーザーストーリー：顧客として、最も人気のあるクレジットカードで支払いたい
機能政府のGOV-TAX-02 XML APIをサポートします。
シナリオの問題もあります。これは通常、機能/ユーザーストーリーが実行される方法です。それらは通常、明確に特定の受け入れテストにマッピングされます。例えば
シナリオ：お金を引き出す
銀行口座に2000ドルある
100ドル引き出すと
その後、100ドルの現金を受け取ります
そして、私の残高は1900 $です
それが私たちがこれらの用語を定義する方法です私が働く場所。これらの定義は、数学的な定義や標準化された用語とはかけ離れています。右翼の政治家と左翼の政治家の違いに似ています。どこに住んでいるかによります。カナダでは、右翼と見なされるものは、米国では左翼と見なされる場合があります。それは非常に可変です。
真剣に、私はそれについてあまり心配しません。重要なのは、チームの全員が定義に同意して、お互いを理解できるようにすることです。スクラムのようないくつかの方法は、それらをより正式に定義する傾向がありますが、何がうまくいくかを選び、残りは残します。結局のところ、個人とプロセスとツールの相互作用と包括的なドキュメント上の作業ソフトウェアについては俊敏ではありませんか？
Epic：非常に大きなユーザーストーリーで、最終的には小さなストーリーに分解されます。
ユーザーストーリー：開発者がそれを実装するための努力の合理的な見積もりを生成できるように十分な情報を含む、要件の非常に高レベルの定義。
http://www.telerik.com/agile-project-management-tools/agile-resources/vocabulary.aspx
機能：ソフトウェアアプリケーションまたはライブラリの特徴または機能（パフォーマンス、移植性、機能など）。
これらの用語に厳格すぎる階層を適用しないように注意してください。私は以前の仕事でそれを試みました。二回。どちらの試みも異なり、どちらの場合も、不必要に自分自身を制限していたことがわかりました。唯一の定数は ユーザーストーリー の定義でした。計画の観点から見ると、ストーリーはプロジェクトの基本的なビルディングブロックです。より大きな用語（エピック、機能など）は、事実上tagsです。タグは、ストーリーを複数のエピックおよび複数の機能の一部として同時に存在させる簡単な方法です。それよりも厳格であることは精神的な努力の価値はありません。
タグはStack Exchangeで機能し、タグも機能します。
Epics、Stories、Featuresの操作方法は次のとおりです
プロジェクトサイクルの早い段階で、Epicsを作成します。これらは非常に高レベルで、ほぼマーケティング中心の機能の要点です。次のようなエグゼクティブサマリーで使用できるものです。
私たちの新しいウェブサイトでは、顧客が製品を閲覧し、在庫と価格を確認し、注文し、過去の注文履歴を見ることができます
これは次のようなエピックにつながります
- 製品カタログを閲覧
- 可用性を表示
- 価格を見る
- 注文する
- 注文履歴を見る
これらはユーザーストーリーとして記述されます（たとえば、顧客として、製品カタログを参照して、情報に基づいた購入の決定を下したい）。しかし、実際に開発およびリリースされるものの10のスターターとしてのみ機能します。
これらのエピックは、さらにユーザーストーリーに分解されます。これらは実際のエンドツーエンドのユーザージャーニーであり、範囲が非常に限定されており、推定および計画済み独立して、開発済み、テスト済み、およびreleased1つのリリースサイクル。
ユーザーストーリーは配信の単位です。これは、完了したか、完了していないか、ライブになるか、ライブにならないユーザーストーリーです。
エピックは、多数のユーザーストーリーをもたらす可能性があり、すべてが同時に開発またはリリースされるわけではありません。
例として、ブラウズ製品カタログの叙事詩は、
- カテゴリ階層をナビゲートする
- キーワードで探す
- 製品属性（価格帯、ブランド、色、サイズなど）でフィルターします。
繰り返しになりますが、これらはそれぞれ次のような形式で記述されます。顧客として、カテゴリー階層をナビゲートして、製品を閲覧し、自分のニーズに最も適した製品にドリルダウンできるようにしたいと考えています。
一般に、ほとんどのプロジェクトでは、数十のエピックと数百のストーリーがあります。
ここで、ストーリーのライフサイクルを進めるときに、これらのストーリーにFeature sのタグを付けます。たとえば、すべての閲覧と検索、株価と価格の記事には、たとえば「製品カタログ」というタグが付けられます。クレジットカードによる支払いに関連する注文注文ストーリーには「クレジットカード」ラベルが付けられ、Paypalによる支払いに関連するストーリーには「Paypal」ラベルが付けられます。
これらのラベルは、同じアクティビティを実行するさまざまなタイプ（すべての注文注文ストーリーなど）ではなく、一緒にリリースする必要があるため、一緒に属するストーリーをグループ化するのに役立ちます。
たとえば、「クレジットカードで支払う注文」ストーリーは、「Paypalで支払う注文」ストーリーと同じエピックに属しますが、一緒にリリースする必要はありません。
一方、「クレジットカードで支払う注文」ストーリー、「クレジットカードへの返品払い戻しの処理」ストーリー、および「顧客が保存したクレジットカードをアカウントで管理できるようにする」ストーリーは、互いに属しているようです。 。それらはすべて「クレジットカード」機能ラベルでタグ付けされていました。つまり、すべて「クレジットカード」機能に属します。 Paypalへの返品の払い戻しを処理できない場合、または保存したクレジットカードをアカウントで管理できない場合は、クレジットカードで支払う注文を発行する機能を解放することはあまり役に立ちません
注：原則として。これは最終的にはビジネス上の決定です。市場投入までの時間が重要な場合は、これらのどちらか一方を使用し、もう一方を使用しない正当な理由がある可能性があります。
したがって、Epicsは、個別に開発できる（関連するが個別の）ストーリーに分解するのに役立ち、フィーチャーは、一緒にリリースする必要があるストーリーをグループ化するのに役立ちます。
Epicsはユーザーストーリーに分解され、ユーザーストーリーはフィーチャーに組み立てられると言えます。機能に属するストーリーは通常、エピック全体に渡ります。したがって、エピックとフィーチャは直交しており、厳密な階層ではありません。
私たちの仕事のやり方では、エピックが物語に分解されると、彼らは目的を失います。 Epicsの見積もりや計画は行いません。 Epicsの進捗状況は追跡しません。 Epicsはリリースされません。ユーザーストーリーを見積もり、計画し、追跡します。そして、機能をリリースします。
多くの回答のように、これらはあなたがどのアジャイルキャンプに基づいているかによって異なり、あなた自身のキャンプを間違いなく構成できるため、実際には正しい回答がないということに同意します外部の利害関係者を含むチームの全員が彼らの意味を理解している限り。これは、要件を整理する方法の1つにすぎません。
私が好きな答えはマイク・コーンのキャンプからのもので、それはかなり簡単です。
http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes
- エピックは大きなストーリーです（階層的）
- テーマは単なるストーリーのグループです（タグに非常によく似ています）
彼は実際には「機能」という用語を避けています。それは主に伝統的な滝の世界では一般的な用語だったからだと思います。多くのアジャイルキャンプは、違いを強調するために異なる用語を使用する傾向があります。
したがって、PMの定義では、フィーチャーはエピックストーリー階層の中間のどこかにあります。
これが私のInfoQ記事からのこの定義の私の情報グラフィックです http://www.infoq.com/articles/visualize-big-picture-agile ;-)
機能とエピックは同じものではありません。
- フィーチャーはユーザーストーリーではありません。
- エピックはユーザーストーリーです。
- ユーザーストーリーはエピックかもしれません。
- ユーザーストーリーには多くの機能を含めることができます。
- 機能は、1〜多くのユーザーストーリーを実行できます。
計画段階では、ディスカッションの結果、ユーザーストーリーとなります。これは通常、Epicsとして識別されます。これらのソリューションを実装するための労力が多すぎて数日で達成できないためです。製品機能は、このフェーズで識別されます。しかし、それは議論の副産物にすぎません。 機能は、製品のロードマップを計画するために使用されます。これは、個別の説明です。
Epicsが使用され、さらに議論され、各エピックに対してser Storiesが生成されます。 FeaturesおよびEpicsは、Backlog RefinementおよびSprint Planningセッションでの議論を促進するために使用されます。そのとき、それらのディスカッションから出てくるユーザーストーリーは洗練された、優先順位が付けられた、そしてスプリントプランニングです。 、実装のためにスプリントに受け入れられました。
それは単なる問題の分解です。サイズが異なる以外は、単なるストーリーです。
私は個人的にそれらのサイズにラベルを付けないことを好みますが、そうする場合もそれで問題ありません。あなたに尋ねるPMワークスペースの定義は何か。
私たちの組織には2,000人を超える開発者がいるため、この質問への答えは、私たちが共通の製品に取り組んでいる何百ものアジャイルチーム間の流暢で明確なコミュニケーションにとって重要です。非常に小規模な組織の場合、（他の人が答えたように）階層的である必要さえない非常に単純な構造を持つことができます。ただし、大規模な組織では、組織化され、スケーリングされた、一貫性のある階層が明らかに必要です。厳密に階層化されていないものから階層を作成しようとする際の問題があります。
ちなみに、これらの異なるレベルのそれぞれを「ワークアイテム」と呼びます。一部の組織（上記の回答者の一部を含む）では、さまざまなレベルをストーリーまたはユーザーストーリーと呼んでいます（これまでにもありました）が、あいまいすぎるため、これらを総称してワークアイテムと呼んでいます。
これまでに「公式」に行った最善の方法は、ディーンレフィンウェルのSAFeの投資テーマとビジネスエピックの階層構造の最上部（および上から2番目）、次にその下のフィーチャー、最後にフィーチャーの下のストーリーに従っていることです。アジャイルによれば、タスクは常にストーリーの下にあるので、その用語を上位に再利用しないように注意しています。私たちはSAFeをフォローして、少なくともすべてのチームである程度の一貫性を保つことを選択しました。
しかし、これはまだ私たちのニーズには不十分です。私たちは、機能をソフトウェア製品の消費者への明確に価値のある成果物として定義します（つまり、今後のリリースの発表にこれらの機能をリストします）。また、ストーリーとは、単一のアジャイル開発チームが単一のスプリントで提供できる、より少量のスコープと作業であると定義しています。また、ポートフォリオレベル（このレベルより下ではない）での投資テーマとビジネスエピックのSAFeの定義に従っています。また、「テーマ」と「エピック」の古い定義を使用しないようにしています。
私たちは今、ゆっくりとこの方向に進化していますが、進歩の車輪はゆっくりと挽きます。作業を定義して複数のチームでスムーズに実行できるように、作業を一口サイズのチャンクに分割する方法については、まだ苦労しています。これを行うには、フィーチャーより小さく、ストーリーよりも大きい「サブフィーチャー」が必要であることがわかります。サブ機能は、各個々のチームが機能に対して行った作業のチャンク、またはSINGLEチームがさまざまな時点で行った作業のチャンク（異なるスプリント、または異なるリリースでも）に使用できます。
機能とビジネスエピックの間に複数の階層レベルも必要ですが、「テーマ」と呼ぶ以外に、まだこれを解決していません。これは、SAFe投資テーマと混同されやすいため、正しい用語ではないことがわかっています。いくつかの大きなプロジェクト（リリース）では、5から8もの異なる階層レベルがあり、それぞれが作業をますます小さなチャンクに分割しています。これらのテーマは「機能グループ」と考えることができますが、必ずしも正しい用語とは限りません。
あいまいさではなく、明確さを提供する用語を使用するように試みることが重要だと思います。したがって、ストーリーを参照する人は、1つのスプリントで実行できる作業の最小単位を意味します（ストーリーの下のタスクを除く）。サブ機能は、1つの機能で実行できる機能の最小作業単位を意味しますチーム。同様に、機能グループは機能の1つ上の階層レベルです。その上、少しぼやけてしまうので、通常は単にテーマと呼び、テーマを他のテーマの親と子として許可します。機能、サブ機能、ストーリーのレベルをそれぞれ1つのレベルに制限しようとしますが（機能は他の機能の子であってはなりません）、これを100％制限することはまだできていません。
「タグ」を使用してこの一部を整理できることはわかっていますが、タグでは、すべてのチーム間で作業を分類するために必要な組織的な作業分解構造は得られません。定義により、タグはあいまい（多対多の関係）ですが、階層は厳密に1対多です。
結論としては、これはまだ私たちにとって進行中の作業であり、私たちはまだそれに苦労しています。しかし、テーマ、エピック、フィーチャー、ストーリーのSAFe定義を順守することで、私たちは正しい方向に進んでいます！
製品バックログ階層は、製品サイズとそのモジュール性（定義された製品領域の数）にかなり依存しています。
小規模なプロジェクトの場合：Epic> Storyで十分です。どちらかを「機能」と呼びます。
大規模プロジェクトは次のようになる可能性があります：小説>テーマ>エピック>機能>ストーリー
最良の例は次のとおりです。
小説= MS Office
テーマ= MS Word/MS Excel ...
Epic=テーブル/フォントディレクトリ...
機能=基本的な表/表の色スキーム/セルを使用した操作...
Stories（「テーブル」エピック内の「基本テーブル」機能の場合）=テーブルの追加/テーブルの描画/ローの挿入/列の挿入。 ..
バックログの独自のスケーリングを定義するときに覚えておくと有益だと私が信じているのは次のとおりです。
1。ストーリー： a）1つのスプリント内で常に実行可能。 b）エンドユーザーが常にテストできるわけではない
2。エピック /機能：a）1つのスプリント期間に適合せず、分解する必要があります。 b）常にエンドユーザーがテストできる必要があります。 c）常に出荷可能で、収益化できる-ROIを計算する
。 Epicを追加するかどうかを検討するとき> FeatureセクションまたはEpicに固執する>ストーリー：Epicとストーリーの間にのみフィーチャーを挿入することをお勧めしますwhen：Epicは1つのリリースにも適合しないため、1つのリリース期間に適合する出荷可能な要素を定義する必要があります。
これがお役に立てば幸いです。