見積もりには練習が必要です。それはまた労働を必要とする。それは非常に多くの労力がかかるので、特に大きなものを見積もるように求められた場合には、見積もりにかかる時間を見積もることをお勧めします。
何か大きいものの見積もりを提供するように頼まれたとき、最も正直なことはストールすることです。ほとんどのエンジニアは熱狂的であり、熱望しています。ストールすると、ストールしても不快感を感じます。しかし、現場での見積もりは、おそらく正確で正直ではありません。
停止中は、タスクの実行や試作を検討することができます。政治的圧力が許せば、これは推定値を生成する最も正確な方法であり、実際の進歩をもたらす。
何らかの調査のために時間をとることができないときは、最初に見積もりの??意味を非常に明確にする必要があります。その意味を書面での見積もりの??最初と最後の部分に戻してください。各タスクが1日以下になるまで、タスクを徐々に小さなサブタスクに構成解除することによって、書面による見積もりを準備します。理想的には長さが最大である。最も重要なことは何も残さないことです。例えば、ドキュメンテーション、テスト、計画の時間、他のグループとのコミュニケーションの時間、および休暇時間はすべて非常に重要です。あなたがナックルヘッドを扱う毎日の一部を費やしている場合は、それのための広告申込情報を見積もりに入れます。これにより、あなたの上司はあなたの時間を最小限に抑えることができるようになり、さらに時間がかかることがあります。
私は暗黙のうちに推定値を埋め込む優れたエンジニアを知っていますが、そうしないとお勧めします。パッディングの結果の1つは、あなたの信頼が枯渇している可能性があることです。例えば、エンジニアは、本当に1日かかると思う仕事のために3日間を見積もるかもしれません。エンジニアは、2日間それを文書化したり、2日間他の有用なプロジェクトに取り掛かろうと計画しているかもしれません。しかし、その作業が1日で完了したことが検出され（そのように判明した場合）、たるみまたは過大評価の外観が生まれる。あなたが実際にやっていることを適切に可視化する方がはるかに優れています。ドキュメンテーションがコーディングの2倍の時間を要し、見積もりがそうであるとすれば、これをマネージャーに見えるようにすることで大きな利点が得られます。
代わりに明示的にパッド。あなたのアプローチがうまくいかない場合、タスクにはおそらく1日かかりますが、10日かかってもかまいません。そうでない場合は、少なくとも、確率の見積もりによって平均的に重み付けされます。識別して見積もりを割り当てることができるリスク要因は、スケジュールに入る必要があります。ある1週間に1人が病気になることはまずありません。しかし、多くのエンジニアを抱える大規模なプロジェクトには病気があります。同様に休暇の時間。そして、全社的な訓練セミナーが義務化される確率は？それが推測できる場合は、それを貼ります。もちろん、未知の未知数、または* unk-unks *があります。定義によるUnk-unksは個別に見積もることはできません。すべてのunk-unksのグローバルな広告申込情報を作成したり、上司に連絡する他の方法でそれらを処理したりすることができます。しかし、あなたの上司に彼らが存在していることを忘れることはできません。そして、unk-unksが考慮されていないと見積もりが予定になるのは、大変簡単です。
チーム環境では、作業を行う人に見積もりをさせるようにしてください。また、チーム全体で見積もりの??コンセンサスを得ようとする必要があります。人々は技術、経験、準備、そして自信の度合いが大きく異なります。強力なプログラマーが自分自身を推定し、弱いプログラマーがこの推定値を保持しているときには、カラミティが発生します。全体のチームが見積もりにラインごとに合意するという行為は、チームの理解を明確にし、リソースの戦術的な再割り当ての機会を可能にする（例えば、より弱いチームメンバーからより強いチームに負担を移すなど）。
評価することができない大きなリスクがある場合は、あなたのマネージャーがコミットしていないほど強力に述べ、リスクが発生すると恥ずかしいものになることはあなたの義務です。そのような場合には、必要なことがあれば、リスクを減らすために行われることを願っています。
- Extreme Programming *を使用するように会社に納得させることができれば、比較的小さなものを見積もるだけでよく、これはもっと楽しく生産的です。