主に問題の解明から成るタスクの時間をどのように推定できますか？

経験豊富な開発者は、コードが解決しているパターンと問題が十分に理解されている場合にコードの実装にかかる時間を推定することは比較的可能ですが、最終目標が十分に理解されているときに、どのように適切な推定を行うことができますか？実装は95％の理論的/問題解決であり、実装の量は非常に少ないですか？

私の仕事は、明確に定義された目標を達成するためのタスクで構成されることがよくありますが、その目標を達成する方法を見つける必要があり、ソリューションを理解するまで、どのような障壁が存在するかは明確ではありません。具体的には、コード生成ツールまたは自動化されたコード操作ツールに頻繁に取り組んでいます。ソリューションが完全に解決され、ツールが完成すると、実際の変更の95％がすぐに直接実行されます。ただし、生成ツールまたは分析ツールで予期しないエッジケースを処理するために、さらにいくつの問題を解決する必要があるかを見積もる方法はありません。

計画の目的のために、私の会社はそれがどれくらいの時間がかかるかについてのより良いアイデアを望んでいますが、ソリューションの各ステップを解決することを通して作業中にいくつの追加の問題が出てくるかわかりません。どのようにすればより良い見積もりを出すことができるのか分かりません。

話を先に進める前に、「ソフトウェアの推定：ブラックアートの謎を解く」は、推定を見たり考えたりする人々にとって優れたリソースであると言えます。以下の画像は両方ともその本からのものであり、アイデアが以下に提示されている場合の核となります。

既に述べたように、見積もりは、作業を正確に予測および計画できる重要な部分です。見積もりがないと、ビジネスにどのくらい時間がかかるかが見えなくなります。ビジネスにかかる時間について完全に間違った考えを持つことは珍しくありません。彼らが簡単だと思うことは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倍に狭まります。これがないではない、それはあなたの代わりに「この時にビットを見た後、それが3週間かかります」と言っされることを意味し、それは一週間かかりますことを意味-はい、推定値は上昇したが、また、見積もりの範囲が行ってきましたダウン。

推定ごとに、推定がその範囲内であることを90％確認する必要があります。間違っている可能性があります-10％の確率でその範囲から外れます。

プロジェクトのサイズを見積もるには多くの方法があります。これを過去のプロジェクトと比較し、プロキシを使用して（書くのにこれほど時間がかかる1000行のコードが必要だと思います）、ファンクションポイントを使用して（LOCに変換するには...）、多くの人々から見積もりを取得し、繰り返し改善していく...あるプロジェクトのためのある仕事、他のプロジェクトのためのある仕事。

非常に私が先頭に言及したこの本の中で重要な章では扱っ＃23で政治推定し、経営者や幹部を扱います。

見積もりの​​鍵は、少し作業した後、それを改良する反復プロセスです。

プロセスのあまりに早い時期に正確な推定値を与えると、エラーが発生しやすくなります。よくわからない場合は、広い推定値を指定し、しばらくしてから問題をさらに内省するために別の推定値に戻って、おそらくそれをどのように書いたかをスケッチします最後の同様の問題と推定に影響するその他の要因。

見積もりにはある程度の考慮が必要です。カフの見積もりを放棄しないでください。これらは、多くの場合、少し考えたときに必要なものと比較して、大きなエラーを伴います。

から見積もりを求められたときにどのように対応しますか？

見積もりを求められたときに何を言うか

あなたは「私はあなたに戻ってきます」と言います。

プロセスを遅くし、このセクションで説明する手順を実行するのに時間を費やすと、ほとんど常により良い結果が得られます。コーヒーマシンで与えられた見積もりは（コーヒーのように）戻ってきてあなたを悩ませます。

ソフトウェア推定の第4章から：

この点で、少しレビューした後の推定値は、カフス値からの推定値よりも体系的にワイルドでエラーが少ないことに注意してください。カフの推定値を無視しないでください。座ってタスクについて考え、少し考えてから見積もります。

上司：AJ、犬3匹、ウサギ2匹、カタパルト、修道女がいます。犬がウサギを食べたり、修道女をdrれさせたりすることなく、20フィートの壁を越えて反対側の湖に7つすべて（はい、カタパルトも）を入れる方法を見つける必要があります。ソリューションを思い付くまでにどれくらいかかりますか？

問題を解決するのにかかる時間を見積もる問題は、人によって時間がかかるということです。同様の問題を解決した履歴がある場合は、それまでにどれだけ時間がかかったかに基づいて推定できます。そうでない場合は、推定するのではなく、推測するだけです。

さらに、問題には許容できる解決策すらありません。または、おそらくソリューションには、プロジェクト全体を破棄する可能性のある追加の承認が必要になります。または、おそらく解決策は、問題の知覚された性質全体を変更するため、解決策は完全に不要になります。

あなたは合理的な推定を行うのに十分な情報を持っていない場合はこの話の教訓はその後、あるありません。未だに。詳細情報を入手してください。もっと調べてください。通常、「2日間以内に、さらに確かな数字を添えてご連絡します」と言っても問題ありません。

私のクライアント向けにソリューションを設計するとき、ソリューションがどのように見えるか、プロジェクトにどれだけ時間がかかるかを十分に理解できる一般的な設計が十分に完了するまで、契約に署名しません。これは、私が支払われない初期設計作業を行うリスクがあることを意味します（プロジェクトが通過しない場合）が、それは、行われている作業に対して大幅に過少請求されるリスクがあるよりはましです。

tylerlとMichaelTの答えの中間で、次のことを試してみることをお勧めします。

• 実行する作業を3段階または4段階に分割します。フェーズは次のとおりです。
  1. 問題分析
  2. ソリューションのプロトタイピング
  3. 実世界のソリューション
  4. 出力評価（テスト）
• 経験に基づいたフェーズ1（分析）のみ、または管理者にフェーズ1 + 2（分析+プロトタイプ）のみの見積もりを提供します。次に、問題のフェーズ1および2が完了したときに、フェーズ3 + 4の推定値を提供します（または、少なくとも推定値に自信を持てるように十分に進んでください）。

その背後にある理論的根拠は、特定のコードベース（おそらくそのサイズに応じて）を分析するのにX日間必要であり、一連の基本的なツールまたはスクリプトを実行している（そして失敗している）ことを経験から知っていることです。次に、エラーの数から、実行中のタスクの実際の難易度に関する情報が得られます。

これは経営陣が望んでいることとは異なる場合がありますが、実際に会う見込みを常に考えておく方が良いと思います。

この質問は主に研究の種類に関するものであるため、ソフトウェア開発者に尋ねるのは勇敢なアプローチであるため、一般的なメトリックは、推定値の2倍の時間がかかるソフトウェア開発者がおそらく優れた開発者であることです。 ただし、研究（およびアーキテクチャ設計）タスクはプログラミングの一部であり、多くの場合スキップまたは最小化されます。また、推定するのが難しい場合もあります。

私が自問する最初の質問は、これは解決できる問題ですか？ これは知性や脳力の問題ではなく、実際の現実の問題です。失敗が予想される結果であるGoogleムーンショットの世界にいる場合を除き、これがどうであれ、私はこれを実現することが予想されます。大まかな目安として、ソリューションの90％が何である必要があるかを既に知っているのでしょうか？

私が尋ねる2番目の質問、ソリューションについて考える上で他に知っておくと便利なことは何ですか？ これは本当にダブルチェックの方法であり、受け入れられる解決策を考え出すのに十分なことを本当に知っています。ソリューションが必要とするものをより適切に定義するのに役立つ一連の事実発見タスクを生成する場合があります。それぞれのタスクは通常、定義と推定が非常に簡単です。

3番目の質問は、この種の問題に最適なチームは誰ですか？ このタスクを取得する人は誰でも、自分のスタイルで結果を味わうでしょう。タスクの開始時に1,000万の質問があるプログラマーにこの種の問題を与えてから、最初は（ゆっくりではあるが）何かを提供することは、実装をすぐに打ち飛ばすプログラマーに与えるよりも良い選択かもしれません、しかし、問題があるとき、それはプロセスの最後でのみ発見されます。

次に、実際のタスクは、考えられるソリューション、実装、およびアプローチについて考え、報告する必要がある固定の時間スケールを持つことです。

彼らが報告するとき、あなたは解決策がまだ十分に明確に定義されていないので、可能な解決策のより広いセットを得るための選択肢を持ち、解決策を実装するか、反映することを先に進める

答えがまったく不明である研究用の質問では、何をする必要があるかについての明確なアイデアは言うまでもなく、私は通常、開始としてx時間を費やすことを提案します。

「これが可能かどうかはわかりませんが、調査に2日間を費やすことができます。おそらく解決策は得られませんが、いくつかのことを除外できる可能性があり、おそらくアイデアがあるでしょう具体的な次のステップは何か、それらがどのような時間投資を意味するのか。その後、別のステップを踏むことが理にかなっているかどうかを判断できます。」

したがって、他の方向に不確実性を置きます-見積もりはきちんと正確です（私は2日を費やします）、それまでに何が達成されるかは非常に不明確です。

タイムボクシング、基本的に。