12

十分な詳細は、通常の応答で十分です。

私たちが現在取り組んでいるプロジェクト (これは不完全であり、brs/ドキュメンテーション/ユーザー ストーリーが一切ない状態で私たちに引き渡されました) では、次のようなストーリーが得られます。

プロダクト オーナーとして、開発者に XXX ワークフローをテストしてもらい、正しく動作するようにしてもらいます。

と

プロダクト オーナーとして、YYY ワークフローが正しく機能するように開発者にテストしてもらう必要があります。

「正しく」が何を意味するのかは示されていません。

詳細を要求すると、あまりにも多くの詳細を要求していることが通知されます。これはアジャイルであるため、スプリント (2 週間のスプリント) の後半に要件が明確になり、その時点で詳細について心配する必要はありません。ストーリーに「人形の毛」の重みを付けて、難しいことをやめる. 全体像の男になりましょう。詳細は気にしないでください。

これがアジャイルのあるべき姿ですか？

4

7 に答える 7

16

When asking for more detail, one is informed that you are asking for too much detail and since this is agile, the requirement will become clearer later during the sprint (2 week sprint) and you should not worry about the detail just then, but rather to just give the story a weight in "doll hairs" and stop being difficult. Be a big picture guy. Don't worry about the detail.

Not really. User stories capture the essence but this doesn't mean no details. Details are transmitted during conversation and are definitely mandatory for a good understanding of what has to be done (not even mentioning that it seems hard to estimate anything if you don't know what to do and what is expected).

Communicating details about stories is actually a part of the job of the Product Owner (PO). This should occur during the first part of the Sprint planning meeting where the PO explains each stories to the team, before the planning poker and/or at anytime if any clarification is required. In other words, feel free to ask the PO for details (and ask the PO for the acceptance criteria too). And if there is too much uncertainty, put a big estimate in front of the story and explain why you can't make a "better" estimate.

To me, your PO/customer/stakeholders don't seem to participate very actively and this is a big, very BIG impediment. Your ScrumMaster needs to take care of this, there is no magical solution.

于 2009-11-20T17:30:40.553 に答える
8

ストーリーを快適に推測できるように、必要なだけ詳細を尋ねる必要があります。

ストーリー カードの裏側にいくつかの受け入れテスト基準を追加することができます (詳細を記述する必要はありません)。

顧客としてクレジットカードで支払いたい...

Visa、MasterCardでテスト

ところで、あなたの話は少し奇妙に思えます。それらは顧客/機能中心であるべきです。

于 2009-11-20T17:29:10.447 に答える
3

スクラムバックログアイテム/ユーザーストーリーは、バックログに追加するために非常に具体的である必要はありません。

それらをスプリント可能（スプリントでスケジュール可能）にするには、より詳細な情報が必要です。その時点で、推定できるように十分な詳細が必要であり、明確に定義された完了基準が必要です。

ユーザーストーリーは、それがカバーするシナリオについてプロダクトオーナーとの会話の約束です。

時期尚早の詳細は無駄です。

于 2009-11-21T17:25:14.937 に答える
2

ここでは、システムの機能ではなく、ユーザーストーリーを使用してプロセスを定義しているようです。しかし、開発者がテストに合格したかどうかを知るのに十分な詳細はここにはないと思います。

また、ここにリストしたのは受け入れ基準です。ユーザーストーリーは通常、より説明的であり、機能の本質を定義する1つ以上の受け入れ基準によって支えられています。

すぐにPOに戻る質問は、次のとおりです。ワークフローXXXのロジックは何ですか。各ステップでのオプションは何ですか？どのような（もしあれば）アクションがログに記録されますか？どのような電子メール/通知が送信されますか？どのように？誰に？

プロダクトオーナーが製品を明確に表現できず、スクラムマスターにアジャイルの仕組みを伝えている場合は、おそらく「トレーニング」が必要です。

空白の画面を提供してみて、何が欠けているかを彼に尋ねてください。

于 2009-11-23T14:32:02.360 に答える
1

どの程度の詳細が「十分」かは、多くのことに依存します。あなたの環境は、より詳細な情報が必要であることを示しているようです。

最初に、ストーリーの定義に詳細が必要になる場合があります。

  • あなたの製品所有者はリアルタイムで質問に答えることができません (あなたのチームの問題)
  • あなたのチームは複数のタイムゾーンに分散しています
  • あなたのチーム メンバーは、ストーリーを取り上げたときに何をすべきかわからないことに不満を漏らしています
  • あなたのチームがドメインやアプリケーションを理解していると、より詳細な情報が保証されます
  • ストーリーには非常に視覚的なコンポーネント (新しい UI 画面など) が含まれており、画像が UI レイアウトを伝える効率的なメカニズムを提供します。
于 2009-11-22T13:35:09.337 に答える
1

多くの場合、企業はハイブリッド プロセス戦略を採用しています。そうは言っても、これはrad（Rapid application development）+スクラムのようです。これが最初のスプリントにすぎない場合は、開始するのに十分な詳細です。最初のスプリントのこの時点で、ワークフローが生成する結果に関係なく、ワークフローが最初から最後まで実行できることを確認して前進するようチームにアドバイスします。これは多くの場合、ポケモンの例外処理 (特定の例外ではなく例外をキャッチ) を実行し、エラーをログに記録して、次のスプリントに情報を取り込むことを意味します。

于 2009-11-20T17:24:26.530 に答える
1

最初から最後まで最も単純なパスを記述する必要があります。すべての例外やバリエーションを説明する必要はありません。これらの例外やバリエーションに遭遇した場合は、顧客と会話し、必要に応じてストーリーを更新する必要があります。

于 2009-11-20T17:26:39.020 に答える