見積もりで変更または忘れられたタスクをどのように説明しますか？
タスクレベルの見積もりと時間レポートを処理するために、私は（大まかに）Steve McConnellがソフトウェア見積もりの第10章で説明している手法を使用しています。具体的には、タスクレベルの見積もりを作成するとき（プロジェクトでコーディングを開始する直前）に、タスクをかなり詳細なレベルで決定するため、可能な場合は常に、単一ポイントのタスクがありません。 ％-4時間を超える信頼度の見積もり。このように、タスク見積もりプロセスは、見積もり中にタスクを忘れないようにしながら、ソフトウェアの構築に役立ちます。各タスクで可能な時間の範囲も考え出し、McConnellが説明する統計計算と過去の精度データを使用して、必要に応じて他の信頼水準で推定値を生成できます。この方法は私にとってかなりうまく機能しているように感じます。タスクとその見積もりを追跡のためにTFSに入れる必要があるため、使用するように指示された信頼度のパーセンテージで見積もりを使用します。
しかし、タスクを忘れた場合、または私が見積もったタスクの1つにうまく収まらない作業を行う必要が生じた場合、どうすればよいかわかりません。もちろん、この状況を回避するのが最善ですが、忘れられた/変更されたタスクをどのように説明しますか？将来の見積もりに役立つ最高の履歴データが欲しいのですが、現在は基本的に、50％の信頼度の見積もりを行ったかどうか、および範囲の見積もりの範囲内で行ったかどうかを計算しています。
必要に応じて、質問内容を明確にさせていただきます。不明な点をお知らせください。
一言で言えば-不測の事態。
不測の事態とは、「その他のもの」に追加する金額です。つまり、見積もりの他の場所では説明できないものです。 SMcはソフトウェア見積もりでそれをカバーしていますか？私は思い出せません、そして私のコピーは働いています（私はこれに答える休日にいます-私はどれほど悲しいですか）...
とにかく、一般的に言って、私が見ることをお勧めする3種類の不測の事態があります：
1）リスク固有の不測の事態-ここで、特定のリスクを特定し、それに関連する潜在的なオーバーランをカバーするために特定の時間を追加します。ここで最初に明確にすることは、リスクとは何かということです。それは、プロジェクトに悪影響を与える可能性のあるものであり、あなたのコントロールの範囲外です。
この最後の部分は重要です。「思ったより少し時間がかかる」だけでなく、「会社の標準であるため、使用する必要があると言われているサードパーティのスケジューリングモジュールはタスクに対応できない可能性があります」です。追加する偶発リスクの量を計算する方法は、リスクが通過する可能性のある確率を小数（50％= 0.5）で表したものに、そのリスクの影響を掛けたものです（この例では、CRONを手動で作成する必要があるとします）。スケジューラを使用する代わりにジョブを実行します。これには10日かかりますが、この数は10日です）。
したがって、リスクが発生する可能性が50％あり、発生した場合にそれを回避するのに10日の労力がかかる場合は、5日を追加します。プロジェクトで特定されたすべてのリスクのすべての値を合計し、合計に追加します。
2）Shit Happens Contingency-エレガントでなくても、私が今まで聞いた中で最高の説明。それはITプロジェクトです、たわごとが起こります。それはあなたが思うようには決して行きません、物事はより長くかかります、逃されるなど。一般に、SHの不測の事態は10％（絶対最小）から25％（より高くなる可能性があります）の間で、15％がほぼ典型的であり、正確なレベルは不確実性と一般的なリスク（ゴールポストの移動、不確実な要件など）のレベルに依存します）。
あなたのPMがSH偶発事象を受け入れない場合（そして、彼はITプロジェクトの経験がないか、盲目的な楽観主義者である可能性があります）、それをすべての個別の金額に追加するだけです。彼が何をしているのかを知っているので、彼は自分のリスクログを持っていて、このことについて考えることであなたを愛しています。確かに、彼が何らかのPM資格（PRINCE2など）を持っている場合、彼は知っているでしょうそれについて。
3）Change Contingency-これは、クライアントが変更を提起することをかなり確信しているが、それが競合点になることを望まない場所です。 X日またはX％のいずれかを追加すると、顧客が提起した変更のポットに入ります。それを扱うには2つの方法があります：あなたがそれについて彼らに話し、それを使うのは彼らのものであるか、あなたはそれについて彼らに言わないかのどちらかです。
最初の方法が最善ですが、かなり教育を受けた公正な顧客が必要です-物事は変化として分類され、彼は自分のポットを適切と思うように使うことができます（あなたが物事を思いついたときに見積もることに基づいて）。
あなたがそれが変化であるとあなたが言う2番目の方法ですが、彼に追加料金を請求するようには見えません。あなたはそれを費やすすべてのことに注意する必要があるので、それがなくなるまでになり、顧客に戻ってより多くの時間またはお金を要求しなければならず、彼らは「待ってください」と言いますm paying blah blah blah」あなたは、あなたが完全に不合理ではないというサインとして、あなたが請求していない、彼らがすでに変更したすべてのものを指摘することができます。それは常に機能するとは限りませんが、ほとんどの場合、議論の中であなたの手を強化します。
これらの3つはどれも、あなたが忘れたものを具体的にカバーしていませんが、それらの間であなたが持っている多くのギャップを埋めると思います。
タスクの見積もりを求められたら、チームにハイエンドの見積もりを与え、自分自身のローエンドの見積もりを用意します。そうすることで、タスクが完了した後、最初に言及するのを忘れた可能性のあることに取り組む時間が常にあります。
余分なタスクを追加することで、履歴の正確さが歪むのではないかと心配ですか？それとも、余分なタスクを含めないと精度が歪むと思いますか？
プロジェクトの最善のために、タスクは追跡システムに入力する必要があると思います。プロジェクトリーダーは、不一致について経営陣に適切な説明を提供できると確信しています...