見積もりの​​変更または忘れられたタスクをどのように説明しますか？

タスクレベルの見積もりと時間の報告を処理するために、ソフトウェアの見積もりの第10章でSteve McConnellが説明している手法を（大まかに）使用しています。。具体的には、タスクレベルの見積もりを作成するとき（プロジェクトでコーディングを開始する直前）に、かなり細かいレベルでタスクを決定します。これにより、可能な限り、単一ポイントのタスクがないようにします50 4時間を超える信頼度推定値。このようにして、タスクの見積もりプロセスは、ソフトウェアの構築に役立ち、見積もり中にタスクを忘れないようにします。また、各タスクで可能な時間範囲を考え出し、McConnellが記述した統計計算と履歴精度データを使用して、必要に応じて他の信頼水準で推定を生成できます。この方法は私にはかなりうまく機能しているように感じます。タスクとその推定値を追跡のためにTFSに入れる必要があるため、使用するように言われた信頼度の割合で推定値を使用します。

しかし、仕事を忘れたときどうすればいいのか、あるいは、自分が見積もった仕事の1つにきちんと収まらない仕事をしなければならなくなってしまいます。もちろん、この状況を回避しようとするのが最善ですが、忘れられた/変更されたタスクをどのように説明しますか？将来の見積もりに役立つように、できる限り最高の履歴データが欲しいのですが、今は基本的に、50％の信頼性の見積もりを行ったかどうか、および範囲の見積もりの​​範囲内で行ったかどうかを計算しています。

必要に応じて、質問内容を明確にさせていただきます。不明確な点をお知らせください。

『Weltzing With Bears：Managing Risk on Software Projects』（Peoplewareの作者であるDeMarcoとLister）は、これに対して素晴らしいアプローチをしています。これが私の再解釈です：

「すべてが完璧に進む」見積もりを作成します。もちろん、すべてが完璧に機能することはほとんどありません。そのため、発生する可能性は低く、たとえば0.1％です。言い換えれば、1000のうち1つのプロジェクトだけが完全に計画を立てることになります。これはほとんどの人が明らかに気違いである「見積もり」として使用するものです。

代わりに、推定を確率分布と考える必要があります。この「完全な世界」の推定は、推定確率分布の左端のポイントです。

次に、「このような同様のプロジェクトでこのようなことが起こった場合」の見積もりを作成します。この見積もりは、計画の誤解（http://wiki.lesswrong.com/wiki/Planning_fallacy）を回避して、「外からの眺め」（http://wiki.lesswrong.com/wiki/Outside_view）を取るのに役立ちます。

次に、「Xが90％の確率で完了する」と推定します。あなたが90％確信していることを非常に確信してください。言い換えると、10回のプロジェクトごとに1回だけ、この見積もりよりも長くかかることが予想されます。

これで、最初の推定値を0.1％の確率推定値として使用し、2番目の推定値を50％の確率推定値（季節の味）として使用し、3番目を90％の推定値として使用できます。

たとえば、0％、50％、90％の推定が5月1日、6月1日、8月1日だったとすると、推定曲線は次のようになります。

     100 |                                  ......
         |                        ..........
% chance |                ........
of being |          ......
  done   |      ....
         |   ...
         |...
       0 +-----------------------------------------
          \           \           \           \
           May 1st     June 1st    July 1st    August 1st

時間の経過とともに確率の成長がどのように遅くなるかに注意してください。このシナリオで99.9％の見積もりを求められた場合、それは翌年の1月1日かもしれません。

一言で言えば-不測の事態。

不測の事態とは、「その他」に追加する金額です。見積もりの​​他の場所では説明できません。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）不測の事態の変更 -これは、クライアントが変更を提起することをかなり確信しているが、それが競合のポイントになることを望まない場合です。X日またはX％のいずれかを追加すると、顧客が調達した変更のポットに入れられます。それを扱うには2つの方法があります：あなたがそれについて彼らに話し、それを使うのは彼らのものです、またはあなたはそれについて彼らに言わないかのどちらかです。

最初の方法が最適ですが、かなり教育を受けた、公正な顧客が必要です。物事は変更として分類され、彼は（見たものを推定することに基づいて）自分が適切だと思うようにポットを使うことができます。

あなたがそれが変化であるとあなたが言う2番目の方法が彼に余分に請求するように思わないでください。あなたが費やすすべてのものに注意する必要があるので、それが使い果たされて、顧客に戻って、より多くの時間またはお金を要求しなければならず、そして彼らは「待って、私は」 m何とか何とか何とか何とかして」とは、彼らがすでに変更していないすべてのことを、あなたが完全に不合理ではないという兆候として請求していないことを指摘することができます。これは常に機能するとは限りませんが、ほとんどの場合、ディスカッションにおけるあなたの手を強化します。

これらの3つのいずれも、あなたが忘れたことを明確にカバーしていませんが、それらの間で、あなたが持っている多くのギャップを埋めると思います。

タスクの見積もりを求められたら、チームにハイエンドの見積もりを提示し、自分にはローエンドの見積もりを提示します。そうすることで、最初に言及することを忘れていた可能性のある作業にタスクが完了した後、常に時間を確保できます。

追加のタスクを追加することにより、履歴の正確性が歪むのではないかと心配ですか？それとも、追加のタスクを含めないと精度が歪むと思いますか？

プロジェクトの最善のために、タスクは追跡システムに入力する必要があると思います。プロジェクトリーダーは、矛盾について経営陣に適切な説明を提供できると確信しています...