非現実的なタスクのプロジェクト見積もり
私はクライアントにサービスを提供することを中心とする大規模なIT企業の開発者です（つまり、開発部門は20人未満であり、組織の主要な部分ではありません）。私は現在の問題に関連するさまざまなタスクを解決しており、これまでのところすべて問題ありませんが、経営陣はどういうわけか、MSのVisioやAutodeskのAutoCadなどの業界の受賞歴のある製品のほとんどの機能を複製するアプリケーションを実装するアイデアを思いつきました。
彼らは私が上で説明した利用可能なリソースを使用してそれをしたいと思っています。私の最初の答えは「あなたの最も大胆なファンタジーでも不可能です」でした。そのような対策のプロジェクトは開発者/アーキテクト/テスターの数十のチームによって行われ、数百万ドルの費用がかかり、ゼロからの開発期間は少なくとも1,5-です。 2年。
彼らはそれを考慮しますが、このプロジェクトの期限がない（主題分野の背後にある法律はまだ行われておらず、今後数年で採用されない可能性がある）などの反論もほとんどないため、実装された各機能は次のように見なすことができますクライアントに配信され、「フィールドで」テストされるマイナーリリース。そしてもちろん、Autocadの1：1コピーは必要ありません。「製品全体の機能の10％など、いくつかの主要な機能」だけです。
その議論は見積もりにはまったく役立ちませんが、逆に、「AutoCadのこの機能を見て実装する」などの不確実な要件の変更が多く、専門のQA部門ではなく顧客によるテストが行われることを意味します（政治的に愚かさの正しい同義語）。
そのようなタスクを推論して推定する方法はありますか？いくつかの数字は役に立ちますが、大規模なプロジェクトのすべての開発コスト/詳細は利用できませんが、Microsoft SDEの平均的な既知の給与や、MS Officeリリースのタイムライン（Visioについての話）などのあいまいな事実でのみ操作できます。
これは、本によるスクラム手法の理想的なプロジェクトのように思えます（http://www.scrum.org/storage/scrumguides/Scrum_Guide.pdf）。
このプロジェクトは、それぞれが完成したときにリリースでき、それぞれが明確なビジネス価値を持つ、多数の小さなモジュールを提供するものと考えてください。ビジネスから「製品所有者」を取得してモジュールに優先順位を付け、チーム内でそれらを見積もります。この静脈を数回繰り返します。そして、このプロジェクトが悪い考えであることに会社が最終的に気付いたとき、彼らは未完成の仕事をたくさんするのではなく、実際に何か使えるものを手に入れるでしょう。
反復から反復へと、見積もりは徐々に改善され、やがて、各反復内でチームがどれだけ完了することができるかについて、本当に良い感触が得られます。