私は見積もりを吸います。誰かが私に何か時間がかかるかと尋ねると、私は完全に調子が悪くなるので、推測する勇気さえありません。通常、私はあまりにも楽観的であり、おそらく私の推測にいくつかの大きなX因子を掛けるべきです...
より良い見積もりをする方法を学ぶにはどうすればよいですか？私の大学では教えられていませんし、すべての労働の期限がありますが、私は何かが実際にどれくらいかかるかについて決して考えません。どっちがいい？みんなのために（特に私のもの）。
回答:
私はまだ得意ではありませんが、タスクを見積もる時間と実際にかかる時間を追跡することは大きな助けになることがわかりました。そうすれば、普段どのくらい離れているかをしっかりと把握できます。時間管理機能を備えた問題管理ソフトウェア（私の場合はJira）またはスプレッドシートは、これに役立ちます。
何よりも経験的なことだと思います。
時間管理のマーフィーの法則：何かがどのくらい把握するでしょう取る、それがどのくらいの図アウトする必要があり、それを取ると、2倍になります。
次に、次に高い時間単位に移動します。したがって、1日のプロジェクトに2週間を割り当てます。
それらをまとめて行うことで学ぶことができます。
Planning Pokerを使用しています。このコンセンサスに基づく推定するための技術。
見積もりを追跡し、効果的に行った結果と比較する必要があります。Velocityを取得します。
何かを推定するたびに、正確な推定を得るために最近の速度で乗算します。
Steve McConnell（MS Press）によるソフトウェア推定は、良い読み物です。
ソフトウェア見積もりの主なものは、次のようにまとめられます
履歴情報がなければ、見積もりは役に立ちません。
これが、反復プロジェクトが大規模な段階的ウォーターフォールプロジェクトよりもはるかに成功している理由の1つです。彼らは、彼らがそれがどうあるべきかについてのいくつかのブラックボックスのブードゥー教以外の少しの情報で、一度に1年間の計画を立てようとはしていません。反復ごとに、再推定/再計画が行われ、推定の基礎となる最後のいくつかの反復があります。
留意すべきその他のポイント：
Robert MartinのThe Clean Coderで説明されているPERTスタイルの推定手法について誰も言及していないことに驚いています。この方法では、楽観的（O）、名目（N）、悲観的（P）の3つのシナリオにかかる時間を推定します。次に、予想期間= (O+4N+P)/6と標準偏差が得られます(P-O)/6。
これはかなり上手く機能しているようで、経営陣が何かがおそらくどれくらいかかるかを本当に気にかけているときに何度か使ってきました。
他の人がコメントしているように、履歴データを調べることで見積もりを行いました（「このようなことをするのにどれくらい時間がかかりましたか？」）。
しかし、私のお気に入りの方法は、時間の推定をまったく行わず、点の推定のみを行い、反復にわたって速度を取得することです。チームが作業のサイジングと完了（ユーザーストーリー）にかなり一貫している場合、各作業にかかる時間を尋ねることさえしないため、時間を大幅に節約できます。
時間の見積もりを正確に計算するのは非常に困難であり、効果的に測定するのに十分な小さなチャンクに物事を分解するには多くの作業が必要です。そして、それでも変数が多すぎて、病気、休暇、気晴らしなどのことを考慮するのを忘れているため、それらはめったに正しくありません。
時間の見積もりを行う必要がある場合、反復内の小さなタスクに対してのみそれらを行うようにします。それよりも少なくなる可能性があることがわかっていない限り、すべてを半日（4、8、12時間）の見積もりで測定します。しかし、私は1時間未満でほとんど何も推定しません。
まず最も重要なことは、プロセスを定義し、それに固執する必要があることです。プロセスの各フェーズの終わりに計画の修正を含めます。プロセスを修正することもできますが、規則正しい方法です。
第二に、ある種の設計を行います。設計は計画の最初のステップです。図面なしで家を建てることはできません。
第三に、トラック時間（努力）。少なくとも区別する必要があります：
ユーザーによる受け入れテスト（欠陥の修正を含む）
各テストタイプの欠陥修正の労力を測定することは素晴らしいことですが、複雑さを増すため、後で行うことができます。
第四に、推定のための重要な基本項目を特定します。例えば：
第5に、基本項目と労力を関連付けます。例えば：
第6に、各プロジェクトのパフォーマンスと推定値からの逸脱を追跡します。したがって、相関係数を微調整できます。
第七に、繰り返して改善します。最初のプロジェクトの終わりに多くの洞察を得ることができます。3番目のプロジェクトでは、計画と見積もりが楽になります。
見ていhttp://en.wikipedia.org/wiki/Personal_Software_Processを、それが実際に動作します。
推定の問題に遭遇したときはいつでも、それらをより小さな部分に分割してみてください。それから、あなたがすでに断片に類似したことをしたかどうかを見てください。持っている場合は、それぞれの作品にかかる時間についての公正な考えをすでに持っているはずです。そうでない場合は、さまざまな種類のタスクにかかった時間を積極的に追跡し始める必要があります。これは、将来の見積もりに役立ちます。
統合とテストにはある程度の時間が必要なので、必要な合計時間は個々のピースの合計よりも長くなります。
同様のことをしていない場合は、おそらく他の人の経験に頼って、それらから推定値を得ることができます。しかし、これを額面どおりに受け取らないでください。経験を好むものは何もありません。
標的を撃つようなものです。推定の以前のショットは、あなたがそれを修正することができるように、あなたがどのくらい外れているかを教えてくれるはずです。
上記の最小タスクに分割するプロセスを実行して、それぞれを解決し、その推定値を2倍にするのが最も簡単だと思います。次に、それらを合計し、50％を追加します。これにより、理想的な条件でのおよそのプロジェクト時間が得られます。作業が実際に他の人と並行して行われるようになる場合、より長い時間が必要になります。あなたが他の人を待たなければならないなら、彼らがあなたが思うと思うのに2倍の時間がかかると期待してください。多くの場合、コンテンツやフィードバック、またはその他の情報を待つには、考えられるよりもはるかに長い時間がかかります。
私が作業する場所では、プロセスの各ステップのベストケース/予想されるケース/最悪のケースの推定値を算出します。これは、ガイドとして、また推定値がどのように機能するかを評価するのに役立ちます。
このテクニックは、タスクを過小評価するプログラマーの誘惑と戦う必要があることを除いてそれほど重要ではありませんが、重要なのは、いつ何かを提供できるかについて保守的であることです。何かを構築するのに7週間かかり、8週間を約束した場合は、少し早く来て見栄えを良くしたり、追加のテストを行って信頼性を保証することができます。6週間を約束した場合、それは絶対にあなたのせいではない場合でも、あなたは悪く見えることができます。疑わしい場合は、控えめに推測してください。
それについて本を書くのではなく、推定の「内訳」方法を使用する方法について少しアドバイスします。
割り当てを小さなコンポーネントタスクに分割します。各タスクを可能な限り最適に見積もります。
計画と設計のためのタスクを追加します（これには現在行っていることも含まれます）。それを見積もります。
まだ持っていない場合は、「タスクをまとめる」ためのタスクを追加します。このタスクは、最初は役に立たないと思われるかもしれません。ただし、この「ブレークダウン」推定方法を使用する場合、「タスク間のフォール」および「タスクを一緒にプル」するために、常に時間がかかることがあります。これは推定が難しい場合があります。あなたのベストを尽くす。
テストとドキュメント化のためのタスクを追加します。割り当てには多くのテストとドキュメントは必要ないかもしれませんが、少なくとも少し時間をかけて考える必要があります。
タスクの推定値を合計して、全体的な推定値を取得します。
先に進み、その合計推定値に2††を掛けます。これにより、次のことができるようになります。
そして最後に、大事なことを言い忘れていませんが、恐らく完全に間違っているあなた自身の見積もりをスケッチすることを恐れないでください。場合によっては、非常に不正確な可能性があっても、すべてをスケッチするだけで、何が関係しているのかをよりよく理解するための道を歩むことができます。
††より多くの経験を積むにつれて、この「ファッジファクター」はあなたの個人的なスタイルとあなたの職場環境に合うように調整することができます。
独自のバイアスを学びます。最後の推定値が係数2で低すぎる場合は、次回、初期推定値を2倍にします。（もちろん、ホフスタッターの法則により、それを正しく行うことは困難になります...）
また、前の作品の最初のリリース後にどれだけの作業が必要であったかを思い出し、それを次の見積もりに追加することも常に良い考えです。たとえば、最後のタスクを完了するには2か月かかりましたが、公開後、サポート、修正プログラム、および追加の変更により1か月かかるため、次回は同様のタスクで3か月を見積もっています。
開幕戦については、Barry Boehmによる「Software Engineering Economics」およびTom DeMarcoによる「Controlling Software Projects」をお読みください。これら2つを読み、要約したら、Barry Boehmによる「COCOMO 2によるソフトウェアコストの見積もり」を読んでください。
次にお話ししなければならないことは、LOTが確率と統計のクラス、さらには基本的な料理の本を取得したことです。
完璧な見積もりはありません。早期に到着する確率と、遅く到着する確率があります。Boehmの元の詳細なCOCOMOモデルは、実際の結果の30％以内であり、60％の時間よりも優れていると予測されました。それは、彼が本を書いて出版したときの一般的なものよりもずっと良かった。
最良の推測を行うと（そしてそれがすべての推定値です）、これらの確率を含めます。推定値を取得すると、遅れて入る確率が高くなります。見積もりを増やすと、早期に到着するか、時間通りに終了する可能性が高くなります。どれだけ引き込むか、または引き出せるかによって、確率がどのように変化するかが制御され、必然的に早いか遅いかのペナルティに依存しなければなりません。（ここにホラーストーリーを挿入します-そして、長年にわたってそれらの多くがありました！）
DeMarcoはこれにある程度取り組んでいます。彼はまた、「不可能な領域」があることを指摘しています：どんな種類のヒロイックが試みられようとも、いくつかのスケジュールはあまりにもきつすぎて作成できません。