より大きなソフトウェアプロジェクトに必要な時間を見積もることが難しいことを説明するにはどうすればよいですか？

私はジュニア開発者であり、より大きなソフトウェアプロジェクトを完了するのにどれくらいの時間がかかるかを見積もることは難しいと感じています。一般にアーキテクチャを構築する方法は知っていますが、どの詳細を実行し、どの問題を解決する必要があるかを知るのは困難です。だから、どのプロジェクトを解決する必要があるのか​​、そしてそれらを解決するのにどのくらいの時間がかかるのかわからないので、より大きなプロジェクトを完了するのにどれくらいの時間がかかるかを見積もることは難しい。

ソフトウェア開発者ではない人にこれをどのように説明できますか？

あなたは彼/彼女に、世界の無人の角にある遠く​​離れた場所にアクセスするのにどれくらいの時間がかかるかを見積もることができます。極端な例として、ヒマラヤ山脈のあまり知られていないピークを選んでみましょう。ここでは、登山した人はほとんどいません。彼女は、旅行を開始する前に非常に多くの準備と練習、さらに数か月から数年の旅行を遅らせることができる許可の束を必要とするでしょう...そして、良いサポートチーム...そして一度丘の上に斜面では、彼女はピークに向かって登り始めるのを待って、良い天気を祈る必要があります...など。これらのほとんどは、事前の経験があっても、推定することは不可能ではありません。

ポイントは、各ソフトウェアプロジェクトは新しい山に登るようなもので、以前は誰も経験したことがないため、直接的な経験はありません。味付け開発者は、多かれ少なかれ上の経験を集めたかもしれない同様のプロジェクトが、常に新しい要素や驚きがあるだろう-そうでない場合は、ソフトウェアプロジェクトがあった場合、正確にいくつかの以前のように、それをやって絶対にない点はないだろう。

それを人に説明しましたか？あなたはプロのソフトウェアエンジニアです。そのため、ソフトウェアを構築する人は、ソフトウェアシステムの設計と実装に関して知識とフィードバックを検討する必要があります。

不確実性の円錐は、おそらく良い出発点です。ソフトウェアプロジェクトは、プロジェクトの後半で詳細が明らかになるまで推定が困難です。さらに、要件を変更すると、見積もりも変更されます。プロジェクトの開始時の最初の見積もりには、大きなばらつきがあります。

他の推定手法にも興味があるかもしれません。あなたはあなたがジュニア開発者であると述べました。一般的に、経験豊富な開発者は、より多くの問題を見つけて解決し、（できれば）推定値と実際の時間を追跡しているため、推定能力が向上しています。ワイドバンドデルファイやプランニングポーカーなどの推定手法を使用して、これを活用できます。

ジュニア開発者として、今すぐ見積もりと実際の時間の追跡を開始します。Software Engineering Instituteで開発されたPersonal Software Processについて読むことに興味があるかもしれません。コアPSPブックは、ソフトウェアエンジニアリングの規律、PSP：ソフトウェアエンジニアの自己改善プロセス、およびパーソナルソフトウェアプロセスの紹介です。個人用ソフトウェアプロセスの概要では、最も役立つと思われるトピックが網羅されていると思います。一般的にほとんどの開発者にとってはやりすぎだと思いますが、個人の生産性を向上させ、キャリアを通じて継続的に使用するさまざまなスキル（推定を含む）を磨くために引き出して使用できるいくつかの優れたアイデアと優れた実践があります。

見積もりでさらに多くの作業を行う場合は、Steve McConnellの2冊の本をお勧めします。ソフトウェアの見積もり：Demystifying the Black Art（芸術および科学としての見積もりに焦点を当てています）およびRapid Development：Taming Wild Software Schedules（一般的なソフトウェア）エンジニアリングプロセスとプロジェクト管理のトピック）。

文献を参照してください。複雑で、しばしば矛盾する資料が山積みになっており、実践（実験）で証明されているように、期待どおりに機能しません。少なくとも学者は本の山に左右されます。

必読：http : //en.wikipedia.org/wiki/The_Mythical_Man-Month

The Mythical Man-Month：Essays on Software EngineeringはFred Brooksによるソフトウェアエンジニアリングとプロジェクト管理に関する本であり、その中心テーマは「後期ソフトウェアプロジェクトに人材を追加することで後になる」というものです。このアイデアはブルックスの法則として知られており、プロトタイピングのセカンドシステム効果とアドボカシーとともに提示されます。

Brooksの観察は、IBMでのOS / 360の開発管理における経験に基づいています。彼は、スケジュールに遅れをとるプロジェクトにプログラマーを追加しました。彼は、プロジェクトをさらに遅らせたと、直感に反して結論付けることにしました。また、彼は、1つのプロジェクト（ALGOLコンパイラーの作成）が、関係するワーカーの数に関係なく、6か月を要すると主張するというミスを犯しました（より長く必要でした）。マネージャーがプロジェクト開発でこのようなエラーを繰り返す傾向があったため、ブルックスは彼の本が「ソフトウェア工学の聖書」と呼ばれることを思いとどまらせました。この本は、ソフトウェア工学の人間的要素に関する古典と広く見なされています...

彼らがこの見積もりで何をするつもりなのかを見つけてください。彼らは、数か月または数年かかるかどうかを知りたいと考えており、正確な時間を取得しようとしています（典型的なエンジニア）。

プロジェクトの一部で作業できるかどうかを確認し、必要に応じてより適切な見積もりを作成します。

彼らがプッシュし続けると、時間枠を適用できる限り多くのタスクを項目化することを余儀なくされます。見積もりに影響を与える可能性のあるものを見つけたらすぐに通知し、調整を行うことを伝えます。人々は通常、驚きを避けようとします。

私はソフトウェアを見積もることができると主張する人々に会いましたが、彼らがそれをどのように行うのか分かりません。また、彼らがどのようにそれを行うのかを説明することもできません。

コンサルタントとして、私のクライアントはしばしば固定入札ベースで作業することを要求します。したがって、現実的な入札を準備できるように見積もる必要があります。私はこれに一度も成功したことがありません。私は、私が低値をつけるのと同じくらい頻繁に高値をつけると思うだろうが、それは決して事実ではない。その結果、契約で多額のお金を失うことが多く、会社で正社員として働いていた場合よりも収入が少なくなります。

私はソフトウェアを見積もる方法を教えてくれる本を長年探してきましたが、まだ見つけていません。

これをコーダーではない人に説明することについて。業界の誰もが一貫して見積もりを達成できないことを指摘できます。新しいソフトウェア製品が事前に発表されるのは常に発生し、最初に発表された日付から数か月または数年後に出荷されます。

マイクロソフトのような大企業が自社製品の製造にかかる時間を見積もる方法を理解できない場合、どうすればよいですか？

私が時間単位で支払われているのか、それとも仕事で支払われているのかに関係なく、私のクライアントは常にこれらの見積もりを提供することを期待しています。そのような推定がどこにも教えられていない場合、彼らがどのようにそれらを生成することを期待しているのかわかりません。

プロジェクト全体の時間の見積もりは、通常プログラマではなくプロジェクトマネージャーが実行します。

プロジェクトマネージャーが必要なタスクの完全なリストを持っているという事実に基づいて、引数を作成できます。このリストがないと、推定は「悪い」推測になります。

また、時間は利用可能な人数や要件の範囲など、多くの要因に依存しますが、これはあなたが持っているとは言いませんでした。アーキテクチャだけでは十分ではありません。

もう1つのポイントは、ソフトウェアエンジニアリングはまだ他のエンジニアリング分野に比べてまだ初期段階にあり、推定可能な開発手法が登場するほど成熟していないということです。

ソフトウェアエンジニアリングも絶え間なく変化しています。技術が成熟したと見なされるほどになった頃には、多くの場合、新しい技術を支持して放棄されています。これにより、誰もが信頼できる推定値を生成できるように、1つのテクノロジーで十分な経験を積むことができません。

これを建設見積もりと比較してください。それは非常によく理解されている問題です。入札に基づいて契約が授与されるだけでなく、文明のof明期から人類が物事を築いているからです。