project-planning - ユーザーストーリーの時間見積もり

Question

ユーザー ストーリーの実装に必要な時間をどのように見積もっていますか? それがどれくらいの時間がかかるかを知る前に行ったことがある場合。しかし、それがあなたにとってまったく新しいものである場合はどうでしょうか? 「サプライズ」のためにどれくらいの時間を確保していますか?

Answer 1

このための優れた手法は、ストーリーをやや小さなタスクに分割し、それらを相互に比較して(絶対ではなく) 見積もることです。したがって、次のように言えます。

• タスクAは2ユニットかかります（任意）
• タスク B はタスク A の約 2 倍の複雑さ (4 単位)
• タスクCは約半分が複雑（1単位）

絶対的な複雑さよりも相対的な複雑さを見積もる方が得意です。次に、実際にタスクの 1 つを実行し、1 つのユニットを実装するのにどれくらいの「リアルタイム」がかかるかを計算します。これで、すべてのタスクを計算できます。進行状況に応じて見積もりを更新し続けます。

この手法は、 Mike Cohn 著のAgile Estimating and Planningから引用したもので、このテーマに関する優れた本です。

Answer 2

「ソフトウェア見積もり-ブラックアートの謎を解く」のSteveMcConnelは、私よりも優れていると述べています。

「可能な限り数えなさい。数えられないときに計算しなさい。最後の手段としてのみ判断を使用しなさい。」

第7章-カウント、計算、判断（PDF）。

（これを思い出させてくれてありがとう:)

Answer 3

アジャイル開発の XP スクールでは、実際の時間ではなく、任意の単位で見積もることを提唱しています。（彼らは「グミベア」を使用していますが、何でも使用できます）。そのユーザー ストーリーを実装するのに必要なユニット数について、最も適切な推測を割り当てます。

確かに、あなたは間違っているかもしれませんが、あなたの推測がほとんど正しく、ビジネス/顧客が含めることができるストーリーの正確な予算を簡単に得ることができるとき、開発のフェーズに到達し、いくつかの反復が行われます.反復で。

見積もりが難しい初期の経験則として、最も簡単なタスクの 1 つを取り上げ、その値を 1 に割り当てます。そのタスクに関連して他のユーザー ストーリーを評価し、最適な推測を行います。何かが複雑すぎる、または十分に明確に定義されていない場合、非常に大きな数を指定する必要があります。

もう 1 つの重要な概念は、反復ごとに各ユーザー ストーリーの時間を再評価する必要があるということです。ストーリーがより明確に定義され、ベロシティの推定が向上するにつれて、ストーリーの時間がより正確になります。

サプライズに関しては、ユーザー ストーリーの見積もりには実際には影響しません... サプライズを表すユーザー ストーリーがないためです。

Answer 4

私が働いている場所で実装されたテクニック。ユーザー ストーリーごとに、見出し付きのカードにそれを書きます。各人にカードを取り、完了するのにかかると思われる時間数を記入してもらいます。お互いにカードを見せずに、タスクに対してカードを配置してもらいます。すべての結果が得られたら、数値を見て、上位と下位の値を確認します。通常、数値は互いに非常に近い値になります。

これらの値が平均よりもはるかに上または下にある場合は、開発者または情報提供者に、なぜ平均に比べてそれほど時間がかかるのか、またはそれほど時間がかかると思うのかを尋ねてください。個人ではなくチームから合意を得ることは、全員がタスクを引き受けることを意味します。

これは、私がアジャイル手法について読んだ本からのアイデアであり、著者がそれを信用するのを忘れていました。