Steve McConnel が説明する不確実性の円錐は、経験豊富なソフトウェア プロフェッショナルなら誰でも知っていることを表しています。 4059> 
この理由はたくさんあります。 4059>
- 同じ要件、
- 同じ人々、
- 同じビジネス コンテキスト、
- 同じテクノロジー、
- 同じ優先順位 &制約、
それぞれがユニークであることです。 コードのすべての行は手作業で作られています。 そして、スマートでクリエイティブな人々を含む知識労働は、溝を掘るような正確さには向いていません。 スポンサーは、プロジェクトがいつ完了し、どれだけの費用がかかるかを正確に知りたがります。
この難問に対処することは、時間そのものと同じくらい古くから行われています。 4059>
Dealing with the cone
Pad the estimate
After the sting of underestimating, one common reaction is to double or triple the estimate the next time round.ここでは、チームや企業がこの不確実性に対処する方法をいくつか紹介します。 4059>
大きすぎる数字を出すと、スポンサーは尻込みして、プロジェクトを承認しなくなります。
あまりに大きな数字を出すと、スポンサーが尻込みしてプロジェクトを承認してくれなくなりますし、あまりに低い数字を出すと、資金不足になる恐れがあります。 これは、数字を低く抑えるようにさらに圧力がかかる固定入札契約で入札する場合、二重の意味で厄介なことになります。 4059>
プロジェクトを相対的に評価する
人間は、物事を相対的に評価するのが得意です。 私たちは、岩がどれくらいの大きさなのかを正確に伝えることはできません。 しかし、何か他のものと比較して、それがどのくらい大きいかを伝えることはできます。
Be upfront and honest
Agile のデフォルトの動作モードは透明性と可視性です。 ですから、アジャイルの錐体への対処法が、前もって正直に話すことであるのは、驚くことではありません。
Look. 私たちは、これがどのくらい時間がかかるかわかりません。 これは私たちの最善の推測です。
不確実性を伝えるために、いくつかのアジャイルチームが取るもう1つのアプローチは、見積もりを範囲として提示することです。
これは、プロジェクトに伴う不確実性をスポンサーに目に見える形で示すという利点があり、次にスポンサーは、彼らが引き受けることができるリスクの大きさを決定することができます。 4059>
段階的な資金提供では、最初に全額を要求しません。 それは確実なことではなく、後々トラブルになる可能性もあります。 しかし、チームに 30 ～ 50 万ドルを与えて何かを作らせ、それがどのくらいかかるかを見ることで、先行する数値のばらつきを減らすのに大いに役立ちます。
根本原因
私たちは、年間予算の世界に住んでいます。 そして残念ながら、これが職場の緊張やドラマの多くを駆動しています。 ある意味では年間予算は自然なことですが（私たちは1年周期で生活し、時間を追跡しています）、市場において1年は長いので、計画を立てるにはひどいものです。
不確実性の円錐でつまずくことがあったら、ソフトウェアの見積もりの要点は、プロジェクトが可能かどうかさえ判断することであることを思い出してください。
あるいは、Steve McConnell が言うように。
The primary purpose of software estimation is not to predict a project’s outcome; it is to determine whether a project’s targets are realistic enough to allow the project to be controlled to meet them.
-Steve McConnell, Software Estimation.Of.S. (ソフトウェア見積もり): ブラックアートを解明する