主に問題を把握することからなるタスクの時間をどのように見積もることができますか？
経験豊富な開発者は、コードが解決するパターンと問題が十分に理解されている場合、コードの実装にかかる時間を見積もることは比較的可能ですが、最終目標が十分に理解されている場合に、実装は95％理論的/問題解決であり、実装は非常に少量ですか？
私の仕事は多くの場合、明確に定義された目標を達成するためのタスクで構成されていますが、その目標に到達する方法を見つける必要があります。具体的には、コード生成ツールや自動化されたコード操作ツールに頻繁に取り組んでいます。ソリューションが完全に解決され、ツールが完成したら、実際の変更の95％を直接非常に迅速に実行します。ただし、生成または分析ツールで予測できないEdgeケースを処理するために解決する必要がある追加の問題の数を見積もる方法はありません。
計画を立てるために、私の会社はどれくらいの時間がかかるかについてより良いアイデアを求めていますが、解決策の各ステップを解決していく過程で、さらにいくつの問題が発生するかわからないためです。より適切な見積もりを出すためのアプローチ方法がわかりません。
先に進む前に、 ソフトウェアの見積もり：黒のアートの謎を解く は、見積もりを見て考えている人にとって優れたリソースであると言っておきます。以下の画像は両方ともその本からのものであり、アイデアが以下に提示された場合のコアです。
お気づきのように、見積もりは、作業を正確に予測および計画できるようにするための重要な部分です。見積もりがないと、ビジネスにどれくらい時間がかかるかについてビジネスが盲目になります。ビジネスにかかる時間について完全に誤った考えを持つことは珍しくありません。簡単だと思うのは6〜8週間かかり、難しいと思われるのは金曜日の午後のハックです。
最初に見積もりを出すことです。見積もり自体は単一の数値ではありません-それはコミットメントです。 「ABCにかかる時間」->「約5日」とは、約5日ということです。ただし、適切な見積もりは、その範囲内にあると90％確信できる範囲です。 「1日と5日かかると私は90％確信している」と言う場合は、それを言います。 「1〜10日かかると思うので、5日はおそらく平均だと思います」から作業しないでください。これは概算ではなく、時間の50％が間違っています。
まあ、時間の50％以上で、プログラマーはタスク時間の悪名高い評判です。
不確実性のコーンを考えてみましょう： 
http://www.construx.com からの画像- http://www.construx.com/Thought_Leadership/Books/The_Cone_of_Uncertainty/ の記事全体
その範囲の最初の推定値が16倍であることを認識してください。これは「午後から2週間かかると思います」と同じですが、まだわかりません。デザインを少し進めると、範囲は4倍に狭まります。これはしないは1週間かかることを意味します。代わりに、「これを少し見てから3週間かかる週間」-はい、見積もりは上がりましたが、見積もりの範囲も下がりました。
あなたが与えるそれぞれの見積もりでは、見積もりがその範囲内にあることを90％確信する必要があります。あなたは間違っている可能性があります-時間の10％はその範囲外になります。
プロジェクトのサイズを見積もる方法はmanyあります。それを過去のプロジェクトと比較し、プロキシを使用して（書くのにこれには長い時間がかかる1000行のコードが必要になると思います）、関数ポイントを使用して（LOCに変換するために...）、多数の人々から見積もりを取得し、それを繰り返し洗練させる...いくつかのプロジェクトのためのいくつかの仕事、他のプロジェクトのためのいくつかの仕事。
この本の冒頭で述べたvery重要な章は＃23で、-politicsを扱い、マネージャーや幹部を扱います。
見積もりの鍵となるのは、少し作業した後でそれを洗練する反復プロセスです。
見積もりの精度が高すぎると、プロセスの早い段階でエラーが発生しやすくなります。よくわからない場合は、広い見積もりを与え、しばらくしてから別の見積もりを返して、問題の詳細を調べ、おそらくそれをどのように行うかをスケッチし、作成したコードの量を確認します。最後の同様の問題および推定に影響を与えるその他の要因。
見積もりには多少の考慮が必要です-袖口の見積もりを出さないでください。これらはしばしば、あなたがそれについて少し考えたときと比べて、それらに関連するhugeエラーを持っています。
見積もりを求められたときの発言
「折り返しご連絡いたします。」
プロセスを遅くし、このセクションで説明する手順を実行する時間を費やすと、ほとんどの場合、より良い結果が得られます。コーヒーマシンで与えられた見積もりは、コーヒーと同様に、あなたを悩ませます。
ソフトウェア見積もりの第4章から：
この場合、少し見直した後の推定値は、カフ外の推定値よりも体系的にワイルドでエラーが発生しやすいことに注意してください。袖口の見積もりを行わないでください。座ってタスクについて考え、少し考えてから見積もります。
ボス：AJ、犬3匹、ウサギ2匹、カタパルト、および修道女がいます。犬がウサギを食べることなく、尼僧を溺死させることなく、20フィートの壁を越えて反対側の湖に7つすべて（そう、カタパルトも）を入れる方法を見つける必要があります。ソリューションを思いつくまでにどのくらいかかりますか？
問題を解決するのにかかる時間を推定する問題は、人によって時間が異なるということです。同様の問題を解決した履歴がある場合は、以前にかかった時間に基づいて推定できます。そうでない場合は、推定ではなく、単に推測しているだけです。
さらに、問題は許容できる解決策を持たない場合もあります。または、おそらくソリューションには、プロジェクト全体を破棄する可能性のあるさらなる承認が必要になります。あるいは、解決策が問題の認識された性質全体を変更し、解決策が完全に不要になる場合もあります。
話の教訓は、妥当な見積もりを行うのに十分な情報がない場合は、しないです。未だに。詳細をご覧ください。もっと研究してください。通常は、「2日以内に確実な数値をお知らせします」と言っても問題ありません。
クライアント向けのソリューションを設計するときは、ソリューションがどのように表示され、プロジェクトにかかる時間を把握できる一般的な設計が完了するまで、契約に署名しません。これは、私が支払いを受けない初期の設計作業を行ったリスクがあることを意味します（プロジェクトが完了しなかった場合）が、それは、行われた作業に対して大幅に過少請求されるリスクよりも優れています。
tylerl と MichaelT の答えの中間で次のことを試してみることをお勧めします。
- 実行する作業を3つまたは4つのフェーズに分割します。フェーズは次のとおりです。
- 問題分析
- ソリューションのプロトタイピング
- 実世界のソリューション
- 出力評価（テスト）
- 経験に基づくフェーズ1（分析）、またはフェーズ1 + 2（分析+プロトタイプ）のみの見積もりを管理者に提供します。次に、問題のフェーズ1と2が完了したときに、フェーズ3 + 4の見積もりを提供します（または少なくとも見積もりに自信を持つことができるように十分に進んでください）。
背後にある理論的根拠は、特定のコードベースを（おそらくそのサイズに応じて）分析し、基本的なツールまたはスクリプトのスーツを実行する（そして失敗する可能性がある）にはX日間必要であることを経験から知っているということです。次に、エラーの数から、現在のタスクの実際の難易度に関する情報が得られます。
これは経営者が望んでいるものとは正確には違うかもしれませんが、実際に会うであろう見積もりを出すことは常に良いことだと私は信じています。
この質問は主に研究の種類に関するものであるため、ソフトウェア開発者に尋ねるのは勇敢なアプローチです一般的な測定基準は、推定値の2倍の時間がかかるソフトウェア開発者は、おそらく優れた開発者です。ただし、そうは言っても、調査（およびアーキテクチャ設計）タスクはプログラミングの一部であり、スキップ/最小化されることがよくあります。それらはしばしば推定するのが難しい。
私が最初に尋ねる質問これは解決できる問題ですか？これは知性や脳力の問題ではなく、現実的な問題の1つです。失敗が予期される結果であるGoogleムーンショットの世界にいない限り、難しい現実は、私がthisを提供することが期待されるということですthisであることがわかります。おおまかな目安として、ソリューションの90％が必要であることはすでにわかっているでしょうか。
私が尋ねる2番目の質問ソリューションについて考える上で知っておくと他に役立つことはありますか？これは、実際にソリューションを考え出すのに十分知っているかどうかを再確認する方法です許容できる。一連のファクトファインディングタスクを生成して、ソリューションが何である必要があるかをよりよく定義するのに役立ちます。それぞれのタスクの定義と推定は通常非常に簡単です。 。
3番目の質問はこの種の問題に対してチームに最適なのは誰ですか？このタスクを実行する人はだれでも、独自のスタイルで結果を味わうことができます。この種の問題を、タスクの開始時に1000万の質問があり、それから離れて最初は何かを提供するプログラマーに（ゆっくりではありますが）与えることは、実装をすばやく開始するプログラマーに与えるよりも良い選択かもしれません、しかし問題がある場合、それはプロセスの最後に発見されただけです。
次に、実際のタスクは、考えられるソリューション、実装、アプローチについて考え、レポートする必要がある固定の時間スケールを持つことです。
彼らが報告するとき、あなたは可能な解決策のより広いセットを取得することについての選択肢を持ち、解決策はまだ十分に明確に定義されていないので、解決策の実装に進むか、反映する
何が必要かについての明確な考えは言うまでもなく、答えがあるかどうかがはっきりしない調査的な質問では、通常、最初にx時間を費やすことを提案します。
「これが可能かどうかはわかりませんが、2日間かけて調査することができます。それでは解決策は得られないかもしれませんが、いくつかのことを除外することができ、おそらく考えがあるでしょう。具体的な次のステップとは何か、どのような時間的投資が意味するのか。次に、次のステップに進むことが理にかなっているかどうかを判断できます。」
したがって、不確実性を他の方向に向けます-見積もりはかなり正確です（私は2日間を費やします）。それまでに何が達成されるかは非常に明確ではありません。
基本的にタイムボックス化。