研究開発業務の時間を見積もる際に留意すべき主なポイントは何ですか。「WPF」テクノロジーを使用して「ABC」タスクを見積もる必要があり、その経験がないとします。そのための研究開発が必要です。
5 に答える
純粋な研究プロジェクト
継続する余裕があるかどうかを再評価するために、多数の中間マイルストーン/レビューに加えて、時間またはリソースの上限を設定します。理想的には、研究に着手する前に、成功することの潜在的な利点について十分な考えを持っている. また、開始する前に、さまざまな成功の等級と、努力が実を結ばない場合の緊急時対応計画を定義することもできます。
スパイラルモデルの展開が重宝します。
既存の技術を問題に適用する
WPF などの現在主流のテクノロジについては、同等の経験を持つ人がテクノロジを習得するのにどれくらいの時間がかかるかを調べてみてください。証拠は、他の人の経験や利用可能なトレーニング コースから収集される場合があります。
最新でない技術やニッチな技術については、コンサルタントを雇うか、仕事を下請けする方がよいかもしれません (コンサルタントと請負業者の違いに注意してください)。
プロジェクトの採点
現状維持 - バグ修正 - 機能強化 - 新機能 - 新製品 - 革新的
規模。スケール上の各位置は、通常、2..5 倍のリスクと労力の増加を意味します。組織内でエンドツーエンドでバグを修正するのに通常 2 日かかる場合の基準点があると、拡張には 2 ~ 5 倍の時間がかかり、もちろん 4 ~ 10 日かかると推測できます。コーディングは、この取り組みのごく一部にすぎません。
テクノロジーを試す時間ができるまで、見積もりを出さないでください。一定の時間 (2 日、1 週間、管理者から得ることができる時間) を割り当てて、概念を理解し、それを使用して自分でコードを記述し、開発プロセスに何が必要で、学習曲線がどれほど急勾配であるかを把握します。それではお見積り。
理想的には、確かな証拠なしに見積もりを出すべきではありません。結局のところ、推定値は確率であり、確率は数学的に有効数字であり、腸の感覚が薄い空気から引き離されるのではありません。(これについて詳しくは、Steve McConnellによる「SoftwareEstimation」を参照してください。)
残念ながら、関連するテクノロジーについて非常に不確実なタスクの見積もりを提供する必要があることがよくあります。これは、たとえば、政府の助成金やその他の非技術的なシナリオの場合です。このような場合、実用的であるため、テクノロジーに精通していない場合でも見積もりを提供することをお勧めします。
私がよく使用する手法には、不確実性コーンとタイムボックス開発が含まれます。
お役に立てれば。
アプローチする最善の方法は、すでにそこにいる人に相談することです。彼の経験に加えて、彼があなたのスタッフと比較して優れているという一般的な考えは、あなたに公正な評価を与えるはずです.
テクノロジーが古ければ古いほど、より経験豊富な人々が周りに存在し、質問に対する答えを見つけるための Web 上の場所が増えます。
まったく新しいものを研究している場合...データソースは限られている必要があり、私は見積もりを取り、それを2倍にします....
新しいテクノロジーの研究にかかる時間と、開発にかかる時間を推測して、それを 2 倍することができます。もちろん、それはかなり漠然としていますが、通常、タスクの見積もりに関係するものはすべてかなり曖昧です (まあ、少なくとも私は好きではありません)。見積もりには非常に多くの要因が関係しています。新しいテクノロジーを扱う場合は、予想よりも時間がかかる可能性があります。通常、他の人によって書かれたコードを扱う必要があるため、本来あるべきものに複雑さの「x」要因が追加される可能性があります。簡単なタスク。
通常、時間を見積もるときは、少なくとも自分が座っている場所に全体的な「スパイク」があり (1 人であっても、他のチーム メンバーと一緒であっても)、1 時間か 2 時間 (またはどれだけ長い時間でも) プレイするのが常に最善です。選ぶ)。これにより、少なくとも、扱っている内容をよりよく把握するための少しの時間が得られます。新しいテクノロジーを見るときは、おそらく doco を少し読んだり、「入門」ガイドなどを読んで遊んだりしてください。その後、見積もり表に戻ると、何を扱っているかについてより良いアイデアが得られます。 .