回答:
あなたが与えることができる最良の答えは、より正確な見積もりを与えることができるように、迅速なプロトタイプをノックアップする時間を求めることです。なければ、いくつかのツールの経験や問題、あなたが与える任意の推定値は、本質的に無意味です。
余談ですが、見積もりが長すぎると問題が発生することはほとんどありません。予期しない問題が発生し、優先順位が変更され、要件が「更新」されます。要求した時間をすべて使用しなくても、テスト時間が増えるか、「早期」にリリースできます。
私の見積もりでは常に楽観的でしたが、特に経験と自信に欠けて上司に不快な真実を告げる若いプログラマーである場合、それはあなたの人生に大きなストレスを与える可能性があります。
秘密を教えます。そのテクノロジーの専門家であったとしても、見積もりは非常に不正確になる可能性があります。本質的にR＆Dタスクである何かをするとき、それは獣の性質です。残念ながら、経営陣はしばしば製造モデルを適用しようとし、正確な見積もりを要求します。私のポイントを説明するために、次の2つの取り組みを正確に推定することの難しさを考慮してください。
A）先月作成した2K傘とまったく同じ11K傘をもう1つ製造します。B）新しい種類の傘をデザインし、最初のものを作ります。
ソフトウェア開発はBですが、Aを想定した見積もりを求めています。
あなたができる最善のことは、タスクを可能な限り最小の断片に分割し（各1日2日以内）、次に、最終的な数を3倍にすることです（スポルスキー法）。
あるいは、Steve McConnellは、ソフトウェアエンジニアリングのこの側面に関する1冊の本（おそらく数冊）を持っています。 http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351
Steve McConnell（および他の人）は、不確実性の円錐について話します。基本的には、次のような見積もりを提供します。
作業には3〜9週間かかり、4週間が最も可能性が高いです。
プロジェクトが進むにつれて、見積もりを調整できます。より多くの作業を行い、必要な労力をよりよく理解すると、見積もりをより正確に調整できます。
それは私にとってはうまくいきましたが、プロジェクトの他の利害関係者にプロセスを理解してもらうには多少の努力が必要になる場合があります。
見積もりと信頼レベルの両方を与えることを検討することをお勧めします。つまり、3か月から6か月または6か月から9か月で完了する確率は50/50、または9か月で75％の確率で、90％は1年で完了しました。
あなたが考慮したいと思うかもしれないもう一つは「群衆の知恵」アプローチを使用することです。周りを回って、25〜50人に、それがかかると思う時間と平均を見積もります。Mike CohnのPlanning Pokerは、これに非常に似ていますが、1人の開発者だけで計画するのは困難です。
見積もりを次のように分類します。
途中で見積もりと特定のマイルストーンを調整することを提案します。未知の未知数は既知の未知数になり、既知の未知数は経験を積むにつれて既知の既知数になり、既知の既知数の推定値は現在までの進捗状況に基づいて調整できます。最初の見積もりを行い、約25％完了したら再度見積もり、次に50％で再度見積もり、次に85％で再度見積もりを行うことができます。各マイルストーンで、見積もりはタスクが実際にかかる時間に収束し始めます。
私の推定には明確なラベル付けシステムを使用しています...クラスA、クラスB、クラスC。
クラスCの推定値が最初に得られます。それは未知数のためにプラスまたはマイナス50％として公に述べられています。彼らが私にクラスBを与え続けることを望んでいるなら、私は研究するためにお金が必要です。
クラスBはプラスまたはマイナス25％です。時々これは十分であり、彼らは私に構築するためのお金を与えます。そうでなければ、より少ないお金とより多くの研究。
クラスAはプラスまたはマイナス10％で、最終的なものであり、合格または不合格です。それが行きであり、私が見積もりから離れすぎている場合、私は頻繁にそして早く告白します。
「私がこれまでに経験したことのないサードパーティのコントロールを利用している」というフレーズを削除すると、より大きな問題をより適切に説明できるようになると思います。
「アジャイル」が私たちに何かを教えてくれたのであれば、経営陣が継続的にプロジェクトをそのように見積もると期待しているのであれば、それがないので提供できないと言うと「見栄えが悪い」十分な情報があれば、あなたはFAILへの高速道路にいます。
最大の問題は、あなたが制御できず、まだ特定されていない問題です。どのくらいの頻度で振り返って自分に言ったことがありますか。「まあ、ボタンで見積もりを出しました。3回目の試行で、それがわかった後、バージョンが必要であることがわかりました。 1週間の休暇と、プロジェクトマネージャーが...を1週間必要とし、妻が妊娠していて... "
「重要なリスク要因を特定して、xx日以内に成果物をテストするための成果物のチェックリストを考え出すことができます。その時点で、別の増分見積もりを提供します。」
そして、あなたが彼らに「私は将来そのタイプの信頼できる推定値を決して与えようとしないでください。私が試みたら私を解雇してはいけないと主張してください」と提案することができれば本当に素晴らしいでしょう。
（誇張されていますが、ごくわずかです。）
見積もろうとしないでください。見積もりが正確になる方法はありません。結局のところ、単なる見積もりです。
代わりに、機能を小さな部分（たとえば、1〜2日以内）に分割し、これらの部分を実用的で完全なテスト可能な価値のあるコードとして顧客/マネージャーに提供することをお勧めします。そうすれば、彼は日々の進捗状況を自分で確認できます。これはまた、すべての目標を達成していなくても、実際に開発が完了したら、開発を中止して完了したと見なすこともできることを意味します。
このアプローチの詳細については、アジャイルプラクティスの「リリース計画」と「反復計画」をご覧ください。
より長い時間の見積もりを求めても、時間内にそれを行う場合は、見積もりを下回って延長を要求するよりもはるかに良く見えます。
プロトタイプを模擬して、所要時間をよりよく理解できるようにします。経営陣に正直になって、学習曲線の予期せぬ遅れに予算を割り当てられるようにします。
編集：より「反復的な」締め切りを取得できるかどうかも確認できます。「実用的思考と学習」では、Andy Huntは、人々がプロジェクトの終わりに近いプロジェクトの専門家であり、最初は知識が少ないことを強調しています。誰もがプロジェクトに精通していない最初の段階で、設計と時間の見積もりをすべて行うことはあまり意味がありません。期限を「繰り返し」、問題をチャンクで解決すると、より多くの成功を収めることができます。
正確な見積もりの多くは自己認識です。多くのコードを記述した場合、多くのAPIを学ぶ必要があった場合は、次のような質問を感じ始めます。
その間、次のようなことを理解する必要があります。
これらのすべてに基づいて、何かがかかる時間の感覚を養い、ひどく不完全な情報に直面しても、想定を述べることができます（「APIは正常であると想定しています...」）。
プログラミングするとき、私はいつも自分が本当に思っていることを取り入れ、それを3倍して見積もりを出します。1週間で仕事ができると思うなら、クライアントに3週間かかると言います。本当に3週間かかると思うなら、9週間と伝えます。
これを行うことで、私は自分を「約束の下、やり過ぎ」に設定します。これを成功させることができれば、あなたの人生ははるかに良くなり、クライアントは非常に幸せになります。
あなたのケースでは、見積もりを提供する前に、少なくともあなたが何に飛び込んでいるのかを少なくともある程度理解したいと思うでしょう。おそらく、見積もりを出すのにかかる時間について見積もりを出す必要さえあるでしょう。3を掛けると、クライアントが満足します。
経験のあるものに分解します。それを切り刻む行為はあなたがあなたが知っていることとあなたが知らないことについてのより良い考えをあなたに与えるでしょう。
断片が十分に小さく、それらが単一の定義されたタスクと見なされると、それらのいくつかは完全に見積もることができなくなります。それらの場合は、最初にプロトタイプを作成するか、作品のサイズに応じて、ある程度の時間を残してください。2週間から4週間の作業よりも大きく見積もれない部分がある場合は、最初にそれらを切り刻んでください。
結局、あなたはいくつかの非常に奇妙な技術的解決策（あなたはうまくいくはずだと思うが、確かではない）に取りかかり、それがうまくいったら、それをバックアップするために行わなければならない多くの仕事をします。いくつかの不足しているデザインが存在するでしょう。そのためには、いくつかのよく知られたライブラリまたは非常に単純なアルゴリズムを初期バージョンに選択するのが最善です。
タスクを分解できない場合は、十分な経験を持つ人を雇う必要があります（経験の不足は他の方法でも悩まされることになるため）。誰かを雇うことができない場合は、ランダムに長い期間（6か月から2年）だけ交渉して、乱雑なプロトタイプにまっすぐ進む必要があります（何が適切で何が正しいかを知るのに十分な経験を自分自身に与えることができるまで）違う）。しかし、もしあなたがそれに失敗するなら、自分を子供にしないで、それを正しい「やり方」でやっていると考えることが重要です。プロトタイプは破棄されることを意図していた。うまくいけば、プロトタイプのカウントダウンが完了したら、それを実際に構築する準備ができています。
ポール。
外部の数値を推測してすぐに評価を開始し、将来の情報が推定に影響する可能性があることを知らせますが、最新の状態に保つことができます。
評価するときは、Webで公開されたドキュメントまたは毎週の更新を通じて、常に通知しますが、更新された「終了予定日」と拡張の理由（ある場合）を常に含めます。
ほとんどのマネージャーはそれを理解する必要があります-終了日を尋ねることによって、彼らは本当に「スケジュールをどのように計画することができるかいくつかのアイデアを私たちに与えてください」と「永遠に時間を取らないでください」と言っています。
最終的に1回または2回以上延長する場合は、見積もりで吸い込んだ新しい知識に基づいて、スケジュール全体を再評価します。
RBの発言に加えて、この状況で自分が慣れているツールでかかる時間を見積もり、その見積もりを2倍にして学習曲線を作成します。
重要な部分は、見積もりが推測であることを経営陣に伝えることです。彼らがより正確な見積もりを求めている場合、または彼らが-神様に- 時間制限を売り込もうとした場合（確かに、Starshipの構築には2日しかかかりません）エンタープライズ、あなたはあなたが良いです）あなたの銃にこだわる、あなたの見積もり、またはそれが信頼できないという事実を妥協しないでください。
経営陣があなたを上書きしてタスクをタイムボックス化する場合（例：「2日以内に実行する必要があります」）、再度、その見積もりであることを知らせます。これは、自分の見積もりとまったく同じです。
書面でこれをすべて入手してください。
私は自分の仕事でかなり見積もりを扱っており、それは本当の挑戦です。私の最大の課題の1つは、別の開発者がどれだけ熟練しているかを知らずにタスクを完了するのにかかる時間を見積もることです。
「約束どおり、やり過ぎ」メソッドで最初の成功が見られるかもしれませんが、時間の経過とともに、「やりすぎ、やりすぎ」の考え方を実践する他の人々に負けてしまいます。どちらの方法でも、正確さに欠けると戻ってきます。精度は、テクノロジーの経験と未知数の数を制限することに非常に関連しています。
私が提案する1つのことは、あなたの見積もりがどのような予算に反するかについていくらかのアイデアを得ることです。予算が少ない場合は、なじみのないテクノロジーに夢中になることなく、自分が知っていることに固執してください。予算がもう少し柔軟であれば、少し実験する余裕があります。
また、提供できるのはWild Ass Guess（WAG）だけのタスクがあることも認識してください。これらについては、見積もりに最小時間を設定し、最大値がわからないことを明確にする必要があります。多くの場合、この種の見積もりは、特定の機能/要件が管理者によって除外される十分な理由です。
これは、プロジェクトマネージャーとプログラマーの両方に不可欠なスキルです（もちろん、習得することもできます）。記事「Estimating Software Development Tasks Made（a little bit）Easier」が見つかりました。これは、プロジェクトのタスクをより正確に見積もるために役立つと期待しています。
上記のすべての回答は、見積もり自体の作成に関するほとんどすべてをカバーしています。
私が強調することの1つは、見積もり（小さなExcelスプレッドシート、ラジョエル、または非常にシンプルな場合はメモ帳のドキュメント）を追跡し、毎日の終わりに、これを提供できる最も正確な数値に更新することです。 。これを上司に返す必要がない場合でも、これを最新の状態に保つことで、状況がどのように進んでいるかについてより良いアイデアが得られます。さらに重要なのは、作業が進むにつれて見積もりが変化する理由がよくわかることです。。
これを行うことで、この特定のテクノロジーとこれまでに使用したことがない他のテクノロジーの両方について、将来の見積もりがよりよくなります。これは、一定の間隔で期待が変化するときに気づき、それが起こった理由を解明する必要があるためです。
これは非常に一般的な状況です。未知のものに対処する必要があります。これに取り組むための便利な方法は、実際のプログラミングタスクに加えて、やるべきことを学んでいることを理解することです。経営陣はそれを認識しておく必要があります。
あなたがこのような状況にあるとき、プロジェクトは突然R＆Dプロジェクトになり、プログラムを学び、制作しているので、通常より長い時間があなたを悪く見せるわけではありません。私はあなたがどれだけ速く学んでいるか、またはあなたが見つけるかもしれないどんな問題に対処しなければならないのか（Stack Overflowはあなたが持っているオプションの1つです）知りません。
いつものように見積もりをし、1.5（素早い学習者であり、質問を解決するためのリソースにアクセスできる場合）を掛けるか、平均的な学習者であり、自分だけに頼っている場合は2.5を掛けるべきです。
これが役に立てば幸いです！