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


27

私は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つをどのように扱うかはよくわかりません。


4
「技術的なユーザーストーリー」を使用する場合は、ここには4つではなく3つのことがあることに気付きます。モデルと2種類のビュー(PDFビューとGUIビュー)から計算した違い。レポートの表示方法が異なるだけです。
candied_orange

1
それらの1つに取り組む。次に、もう一方に取り組みます。とても簡単です。
Ant P

なぜ2つのストーリーがあるのですか?
ジェフ

回答:


55

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

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


3
実際に非常によく似たものを書き始めていましたが、この答えはすでに私のすべての側面をカバーしているので、+ 1。
Doc Brown

ここでも同じように、実装は避けてください。
candied_orange

1
@JoeYoung:実装の詳細は-実装に入りますか?また、この別の開発者にどのように伝えるかは、チームのコミュニケーション構造によって異なります。もちろん、「給与の差異をオンラインで表示するとき、またはそれらをPDFとして取得するとき、両方の場合にまったく同じコンテンツを取得することが重要です」などの機能要件が含まれる場合があります。その場合は、少なくとも1つの(より良い)ユーザーストーリーへのメモとしてこれを追加します。ただし、この要件がどのように実装されるかについての説明はストーリーに入れないでください。
ドク・ブラウン

3
デザインとは、開発者に問題の解決方法を伝えることではありません。開発者にどの問題を解決するかを伝えています。
candied_orange

1
これらのストーリーの時間コストを評価するとき、それらをどのように評価しますか?一般的なクエリ部分に5時間、Webビュー部分に6時間、PDFビュー部分に7時間かかるとします。時間を推定しますか、1つは11時間(5 + 6)、もう1つは7時間(またはその逆:12と6)を任意に言いますか、または6と7に推定しますが、両方の5時間のオーバーヘッドを組み合わせてどうですか?11と12(両方に5を追加)?「このモデルは、このようなケースを処理するためのものではありません。話してください。」それはまだストーリーボードに記録されているかもしれませんが、どのように?
アーロン

15

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

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

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

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

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


4

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

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

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

  • 合否基準
  • 仮定

必ずしもストーリー以上のドキュメントを作成する必要はないことに注意してください。このストーリーは、ビジネスレベルのコンテキストを提供します。より詳細な追跡が必要なのはあなた次第です(そして、主に組織の制約に依存します)。ただし、それを最小限に抑えることを目指してください(プロセスを超えた人など)。
Ant P

@AntPは同意しましたが、これは定義の完了(DoD)に向けられており、ユーザーストーリーのある3x5カードの裏面に収まるはずです。
ベリンロリチュ

2

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

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

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

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

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

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

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

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

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


2

TL; DR

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

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

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

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

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

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

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

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

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.