共有される前任者に依存するユーザーストーリーの独立性と推定
ショップでの製品カタログの使用に関するユーザーストーリーがあるとは言わないでください。
- 管理者として、カタログアイテムを追加/変更/削除できます（1つ以上のユーザーストーリー、ここでは関係ありません）
- お客様として商品カタログを検索できます
- 顧客として私は製品の詳細を見ることができます
この各ストーリーは前作に依存しています。製品情報を格納するデータベースを設計および作成します。
データベースの作成は次のように表現できます。
- 別の話：ショップのオーナーとして、販売する製品に関する情報を保存したい
- 最初に選択されるストーリーで実行されるタスク
最初のケースではストーリーの依存関係を作成し、2番目のケースではこの追加のタスクをどこで見積もるか疑問に思います。さらに2つのストーリーポイントを追加するとします。どのストーリーにこのポイントを追加する必要がありますか？すべて（および将来の残りのストーリーを再推定）、なし？ 2番目のオプションも見積もりを妨げる可能性があると思います。このストーリーポイントを依存ストーリーに追加してから、場合によっては削除することを忘れないでください。
そのような状況にどのように対処するのですか？
正しい解決策は2番です。
アジャイル推定は設計によるウォーターフォールよりもはるかに正確ではありません：
- ストーリーは「会話をするためのリマインダー」そしてそれらは不完全であり、定義上交渉可能です
- ストーリーを推定する唯一の目的は、反復を使用している場合、反復で達成できることを多かれ少なかれ決定することです
- ストーリーが十分に小さい限り、かんばんなどのアジャイル手法では推定は基本的に役に立ちません。
- 一連のストーリーがいつになるかを見積もる意味はありません正確に実行される：ストーリーは変わるため、長期的な目標の場合、詳細な見積もりは避けなければなりません。
特に、データベースの作成は、最初にプレイするストーリーでは、実装の詳細であるtaskです。タスクは（選択した場合）時間ではなくポイントでは見積もられ、スプリント計画ではなくスプリント中に見積もられます。
ポイントはストーリーの複雑さを測定します-作業量ではなく、それよりも短い時間です-そして私の経験では、ポイントはチームがストーリーを完了したときに勝つ「賞」として最もよく見られます。データベーステーブルを追加しても、全体的な複雑さは実際には増加しません。データベーステーブルの追加は、ストーリーが再生される特定の時点のために表示される詳細です。
「2つのポイントはどこに行くの？」と尋ねる無意味です。どこへ行くにも「2ポイント」はありません。テーブルを作成する必要があるかどうかにかかわらず、ストーリーは同じであり、ストーリーを完了するために実行する必要があるすべてのタスクがどれであるかを知らないことは完全に正常であり、不可避です。
推定するとき、ストーリーがいつ再生されるのか、また再生時にデータベースのどの部分が配置されるのかわからないため、この精度の欠如から抜け出す方法はありません。繰り返しますが、これは正常であり、避けられないことです。
具体的には、次のように言います。
- 管理者として、カタログアイテムを追加/変更/削除できます（1つ以上のユーザーストーリー、ここでは関係ありません）
- 顧客として製品カタログを検索できます
- 顧客として、製品の詳細を表示できます
この各ストーリーは前作に依存しています。製品情報を格納するデータベースを設計および作成します。
しかし、これは一般的に真実ではありません。 必要データベースはまったく必要ありません。たとえば、サービスを使用できます。あなたはそれを処理するオープンソースコンポーネントをインストールすることができます。テーブルの作成を必要としないドキュメントデータベースを使用することもできます。あらかじめパッケージ化された検索サービスなどを使用できます。
あなたがしていることは、実装の詳細をストーリーと融合させることです。ストーリーは必須ではありません。彼らはそれよりも高いレベルでなければなりません！顧客は製品カタログを検索することで利益を得ることができ、チームはストーリー（および設定した完了の定義）を満たす最も単純なソリューションを提供することが期待されます。製品データベースを含めます。
データベースを設定すること自体には顧客の価値がないため、できればそれ自体のストーリーではありません。データベースの実装は、それを必要とする最初のストーリーの一部である必要があります。または、理想的には、データベースは段階的に実装されます：すべてのストーリーで実装ストーリーを機能させるために必要な部分。
（これは、事前にdesignを実行できないという意味ではありません。おそらくそうする必要があります）
一般に、ユーザーストーリー間の依存関係は非常に一般的です。チームは、他のストーリーがすでに行われているという前提で、特定のストーリーを推定します。 （これらの種類の前提条件に注意するのが最善です）。これは常に起こります。計画が変更され、ストーリーの前提条件が適用されなくなった場合、チームは再見積もりの機会を得る必要があります。
私はこの問題に何度も遭遇しましたが、完璧な解決策を見つけることはできませんでした。
しかし、私は、最も不完全な解決策は別の話をすることであることを発見しました。難しいのは、それをどのように表現するかです。このストーリーが目に見えるものを何も生成しないことをユーザーが理解できるように、ユーザーと一緒にこれを行う必要がありますが、プログラマーは他の有用なストーリーを提供することができます。
「店主として、自分が売っている商品の情報を保存したい」というのは、その点がよく伝わらない。これは、エンドユーザーがそれらの詳細を保存できることを意味します。
開発者が製品の利害関係者でもあることを利害関係者がよく理解している場合は、「プログラマーとして、顧客が販売する製品に関する情報を保存および取得したいので、次のことができるようになります。 ＃132、＃133、＃134を完了してください。」
ユーザーが現在のイテレーションでこれを確認し、タスク132、133、または134を確認しない場合、ユーザーは、これがイテレーションの最後に示すことができるものではないことを知ることになります彼らに彼らは、次の反復で、それらのタスクを安価に実行できるようになることに満足するでしょう。通常はこれで十分です。
当然のことながら、あなたはタスクの主要な利害関係者であるため、反復の最後に、そのようなタスクを互いに示す必要があります。
おまけとして、この考え方は、「プログラマーとして、XYZサービスのAPIを改善して、サービスに対してより迅速に開発できるようにする必要がある」などの技術的な負債の話についてうまく説明します。
各ストーリーの例に「so that」節を追加したことに注意してください。これは、説明している例よりも明確なストーリーであっても、ストーリーにとっては良い習慣です。タスクのビジネス価値は、少なくとも、その価値を獲得するためにユーザーが実行できる必要があることと同じくらい重要です。これは、利害関係者の数が増えるにつれて指数関数的に当てはまります。
ストーリーの依存関係を使用することは避けます。これにより、スロープが滑りやすくなります。前に言ったように、データベースが必要なことをどのように知っていますか。おそらく、フラットファイルまたは類似のファイルが状況に応じて機能する可能性があります。
データベースを前もって作成することは、コードのオプションを大幅に制限するため、実際には適切なオプションではありません。
開発には、モック、XML、またはその他の軽量データ入力メカニズムを使用して前進します。その後、コード全体の設計が進化し始めると、データベース設計の基礎としてMocks/XMLを使用できます。モックは捨てられません。モックは後でコード変更の自動検証に使用できるからです。データベースの作成は、反復で行う必要がありますか？モックに基づいてデータベースを作成し、将来の合意された時点でそれを提供できる誰かとモック構造をレビューすることは可能ですか？
ストーリー的には、「顧客として製品カタログを検索できます」という分析をさらに検討したいと思うかもしれません。製品ID、説明、色、サイズ、価格で製品カタログをどのように検索しますか？書かれているように、私は物語が完了するのに複数の反復を要する可能性が高いと思います。
最後に、[http://www.ambysoft.com/scottAmbler.html] [1]にあるScott Amblerの資料をいくつか読むことをお勧めします。
[1]： http://www.ambysoft.com/scottAmbler.html スコットはデータベースとそれらがどのようにアジャイルに関連するかに関して多くの仕事をしました。
乾杯！