タスクの見積もりの​​準備に問題がありますか？ 2日間の方法を使用します。

ソフトウェア開発業界の最大の問題は、タスクの完了時間を十分に高い精度で予測できないことです。 非常に頻繁に-これは、開発者が完了時間に十分に膨大なまたは曖昧なタスクの根拠のない仮定を与えることを許可するという事実によるものです。





たとえば、1時間と2時間のタスクを完了するのにかかる時間の違いについて話している状況を考えてみましょう。 このような数字で操作し、1つのタスクを1時間で完了するのに時間がかからない理由を説明するのは非常に簡単です。 しかし、34時間のタスクと35時間のタスクの違いに関しては、そのような1時間の違いの理論的根拠はまったく信じられないようです。 実際、このような比較は、 最適な推定値が評価されるタスクのサイズに依存することを示しています 。



そのため、ストーリー（ユーザーストーリー）を小さな部分に分割する必要があるという結論に達しました（部分が小さいほど、推定の精度が高くなります）。 これらの部品はどのくらい小さくすべきですか？ この質問に対する答えは、2日間のメソッドの名前にあります。



おそらく、この方法の最大の利点は、ルールが1つしかないことです。ユーザーストーリーを実装時間の観点から2日を超えない部分に分けてください。



この簡単な方法は、多くの、まったく明白ではないが、良い便利な習慣の出現にもつながります。



-機能の不明瞭または大部分の研究/議論に貢献します。

-大規模なユーザーストーリーの共有を強制します。

-最初は明らかではなかったことを認識する能力を養います。



すべてのストーリーを最大2日間の長さに分割できることを説得するつもりはありませんが、ほとんどのストーリーはこの2日間の方法に適合すると主張します。



私の方法を確認するか、プロジェクトの実際の問題に対処しようとするかどうかに関係なく、数日でその効果が見られることをお約束します...まあ、またはあなたのお金の100％の返金を保証します！



翻訳者から



私は著者を補足し、そのような方法はユーザーストーリーの高レベルの評価に適していると言い、機能ポイント法などの極端なプログラミングで推定値を準備するために使用される方法を参照し、結果に基づいて推定値を再計算します-昨日の天気と速度の方法適用されるユーザーストーリー：アジャイルソフトウェア開発向け

。