機能を共有するストーリーに対処する方法

私は2つの物語を持っています（私は彼らが利益部分を欠いていることを知っています）

1. 与信管理ユーザーとして、Officeの現在と以前の給与の差異を表示できます。
2. 与信管理ユーザーとして、Officeの現在と以前の給与の差異のPDFを含む電子メールを受信できます。

2つは、同じクエリ/フィルター基準を持つという点で関連しています。唯一の違いは、「表示」ストーリーでは結果がユーザーに表示され、「メール」ストーリーでは結果がPDFに書き込まれ、ユーザーにメールで送信されることです。

これらの2つのストーリーの共通の側面の分離に苦労しています。

たとえば、どちらも同じクエリを使用しますが、結果に対する処理は異なります。

クエリを純粋に技術的な別のストーリーに分離する必要がありますか？

PDFの作成と電子メールの送信はオフラインで行う必要がありますが、それは技術的な話になりますか？

これらの2つのストーリーを2つの機能的なストーリーと2つの技術的なストーリーに分けることができました。

1. システムとして、Officeの現在の給与と以前の給与の差を計算できます。

2. 与信管理ユーザーとして、Officeの現在の給与と以前の給与の違いを確認できます。

3. システムとして、Officeの現在の給与と以前の給与の違いのPDFドキュメントを作成できます。

4. 与信管理ユーザーとして、Officeの現在の給与と以前の給与の違いのPDFを含む電子メールの受信をリクエストできます。

私が戻ってくる問題は、4つのストーリーが独立しておらず、「ケーキをスライス」しないことです。

したがって、これら2つをどのように扱うかはよくわかりません。

ユーザーストーリーは、システム仕様でも機能要件でもありません。むしろ、それらはそのような仕様や要件につながる会話の始まりです。

したがって、システムの実装に重複があると予想されます。ユーザーストーリーは、このような機能の重複を説明したり、排除したりするものではありません。ユーザーストーリーの目的は、実装の詳細を説明することではなく、ユーザーの観点から機能的な期待を収集することです。

してはいけないこと：ストーリーを分割してみてください。

実施：開発チームが2番目のストーリーを認識していることを確認します。

詳細なタスクを計画し、両方をエレガントな方法で処理できる汎用モデルを作成しようとすることの問題は、難しいことです。

ユーザーストーリーの目的は、作業を完了することです。エレガントは副次的な目的であり、リファクタリングに任せるべきです。

これを最大限に活用し、実行する必要がある他の10個の同様のタスクについて誰にも話さないと、明らかに非常に迷惑ですが、2番目または3番目のタスクは最初のタスクが完了するまで考えられないことも完全に考えられます。あなたがそれをすべて計画したいなら、滝で行ってください。

ロバートハーヴェイとの暴力的な合意において、ユーザーストーリーの目的は、ユーザーができることを理解することです。グルーミングを行うと、顧客はユーザーストーリーを理解し、気になりますが、開発者はもう少し気になります。作業を理解して見積もるために十分な質問をしたら、それらをサポートするタスクを作成できます。

この特定のケースでは、最初に取り組む方と一緒に行われる両方のユーザーストーリーのコアを有効にするタスクを作成できます。

ユーザーストーリーに追加する重要なことは次のとおりです。

• 合否基準
• 仮定

厳密に言えば、ユーザーストーリーは、必要な結果を理解するための会話の約束です。

たとえば、2番目のユーザーストーリーを取り上げる

与信管理ユーザーとして、Officeの現在と以前の給与の差異のPDFを含む電子メールを受信できます。

以下について考えてください。

• この要件を推進しているユーザーの「ニーズ」は何ですか？（ソリューションとしてPDFをメールで送信していますか？これはニーズに対応していない可能性があり、チームはより良いソリューションを考え出すことができます）
• このユーザーに対処し、ソリューションを検証できる最小のスライスは何ですか？短いフィードバックループは貴重です。

ストーリーの分割に近づくときは、可能な限り投資基準を覚えておいてください。

1. 私は独立しています
2. N egotiable
3. V aluable
4. 電子制御可能
5. Sモール
6. T ESTABLE

自然な順序付けのストーリーを持つことは問題ありません。それを考慮に入れてください-通常、最初のストーリーは必要な機能をもたらし、2番目のストーリーはそれに基づいて構築されるため、より大きくなります。

「技術的な」ストーリーに挑戦します。一般的に、それらはユーザー結果に焦点を当てたストーリーの実装をサポートするためのタスクである可能性が最も高いためです。

TL; DR

両方のユーザーストーリーが同じイテレーション内でスコープに取り込まれると仮定すると、ストーリーを実装計画とそれに付随するタスクに分解するのがチームの仕事です。ユーザーストーリーはコンテキストと範囲を提供します。実装、仕様、またはパンチリスト項目ではありません。

ストーリーは反復タスクに分解されるべき

スクラムや他のアジャイル手法を使用している場合、反復の計画段階をスキップすることはよくある間違いです。スクラムでは、製品バックログアイテム（厳密に言えばユーザーストーリーである必要はありません）が現在のスプリントに取り込まれると、チームはスプリントプランニングの一部を使用して、ワークアイテム間の共通性を抽出し、依存関係を特定し、次に、タスクレベルの作業を記録するためにスプリントバックログを作成します。

投稿で指摘したように、アジャイルイテレーションに密接に関連するユーザーストーリーを含めることは珍しくありません（実際、望ましいことです）。スクラムでは、これはスプリントゴールの使用を通じて明らかになります。スクラムフレームワークの外では、目的が共有されているか依存関係が共有されているため、関連するストーリーを取り込むことが依然として理にかなっています。単一のイテレーション内で共有依存関係を抽出して作業することにより、チームは多くの場合、将来は類似しているが同一ではない機能のコードをリファクタリングまたは反復する必要を回避できます。

ストーリーを実装するタスク

次に、ユーザーストーリーの依存関係の計画について考える別の方法を示します。一般に：

1. エピック/テーマは、長期計画またはバックログのグループ化に使用されます。
2. ユーザーストーリーは、目的、コンテキスト、範囲を伝えるために使用されます。
3. ジャストインタイム計画を使用して、単一の反復に適合する実装を開発します。
4. タスクは、1つ以上のユーザーストーリーの完了の定義を満たすジャストインタイムプランを実装します。

ユーザーストーリーを実装計画またはタスクリストとして扱うことは、ほとんどの実務家によってアジャイルなアンチパターンと見なされています。どのような呼び出しを選択しても、アジャイルフレームワークのジャストインタイムの計画段階をスキップせず、チームのプロセス内のどこかで依存関係と共有実装の詳細を追跡してください。