プロジェクト期間を見積もるときに許容できる誤差範囲はどれくらいですか？
私が働いている会社は最大10％のエラーマージンを持つことを目指しています。アナリストは10％前後の見積もりを見逃さないことを期待しています。
比較するものがないので、どう考えたらいいかわかりません。
多かれ少なかれ、あまりに間違って推定している場合、測定するのに適したベースラインは何でしょうか？どのくらい（％）だと思いますか大丈夫見逃すことは？
あなたとあなたの同僚が以前にやったことと非常によく似たものを見積もっていない限り、+ /-10％は途方もなく楽観的です。あなたの経営陣は、ソフトウェアの経験があまりないか、または ソフトウェア推定の大きな制限 を認識していません。その論文にはいくつかの 付随する補足資料 があり、多くの punditry が見つかります。
一般的なソフトウェアプロジェクトよりもはるかに単純なシステムであるRubik's Cubeを調べてみましょう。あなたはできる 20の動きで任意の位置を解決する 、最大。ただし、推定しているため、ソリューションを提供する前に、特定のキューブを数分間しか見ることができません。あなたは良い見積もりを与えることができますか？いいえ、プロセスの見積もりには、プロセスの実行よりも時間がかかる場合があります。
別の単純なシステム：ピノキオ。木製のオートマトンで、彼の嘘は嘘をつくと大きくなる。ピノキオが休んでいるときに「鼻が成長している」と言うとどうなりますか？一部のシステムは予測に対応できず、決定できません。
これら2つの問題は、ほとんどのソフトウェアシステムに組み込まれています。そのため、+ /-10％に近い見積もりは決して得られません。
私のアドバイスは、かなりパディングされた見積もりを与え、スレーブのように作業してプロジェクトをできるだけ早く完了させ、10％以内またはそれ以上になるまで忙しく見えるようにすることです。その時点で、壮大な成功を発表します。
それは本当にプロジェクトに依存しているので、私はあらゆる種類の「目標誤差マージン」について非常にためらいます。新しいCRMシステムをインストール、構成、およびカスタマイズするのにかかる時間を見積もろうとしている場合、どのような種類のカスタマイズが必要になるか、どのようなビジネスプロセスの変更が必要になるかが誰にもわからない。会社には同様の大規模なプロジェクトの履歴がありません。エラーマージンはかなり大きいはずです（つまり、18か月+/- 50％と見積もられ、9-27か月と見積もられます）。プロジェクトが進むにつれて、仕様がより明確になり、ビジネスプロセスに関する決定が下され、開発者がより快適になるなど、これらのエラーマージンが狭くなるはずです。最初の100から良い履歴を得たときに、101番目の基本的なeコマースサイトを構築するのにかかる時間を見積もろうとする場合、はるかに正確な見積りを提供できるはずです。ただし、ほとんどのプロジェクトは、途中で失敗します。
ここで、範囲ではなく単一の数値を引用する場合、答えはおそらく範囲の引用を開始して、推定を行う人が推定がどれほど正確であると期待できるかを指定できるようにすることです。
良いベースラインは、あなたが収集した実際のデータに基づくものです。
これを行う最初のステップは、すべての推定値を記録することです。 2番目のステップは、実際の結果を記録するです。正直に言うと、実際のものを「自己調整」するように誘惑されないでください。この情報を十分に収集し、推定がどの程度優れているかを統計ベースに示すデータをいくつか用意します。これは、だれが見積りを行ったか、だれが作業を行ったかに基づいて大幅に異なる可能性があります。これを行うことによってのみ、他の純粋なゴミである「エラーのマージン」を与えることが合理的に期待できます。
それだけではありません。推定がずれている原因を分析すると、将来の推定の精度を向上させるのに役立ちます。注：これらはまだ見積もりのままであり、したがって見積もりのみ 。
また、最初の見積もりの後で見積もりが完了しません。これは、より多くの知識が得られるにつれてプロジェクトが進行するにつれて調整できるものであり、これにより、進むにつれて起こり得るエラーのマージンが減少します。コミュニケーションをよりオープンにすればするほど、以前のサプライズが議論されます-人々はそれほど驚かされず、プロジェクトまたは顧客の期待のいずれかを調整するためにより多くの時間を与えます。
第2に、エラーマージンを処理するためのより良い方法は、単にエラーマージンの％ではなく、 ' confidence internals 'であろう。配達日は、単一の日付ではなく、信頼区間に基づいて見積もられました。
[〜＃〜] pert [〜＃〜]は、統計的推論に基づいて推定を処理するためのフレームワークの一例です。例えば：
"私が今知っていることに基づいて、8か月で90％の信頼レベルを提供できます。10か月で95％の信頼性、2で99％の信頼性年など」
ここに注意してください：彼らがあなたを望んでいる自信が高ければ高いほど、見積もりは大きくなります。複雑さ（つまり、どれほど正確か）に応じて、80％と90％のわずかな違いになることもあれば、非常に大きなものになることもあります。
最後に-幸運;）ソフトウェアの見積もりで「最大エラーマージン」を解決して、「すべての見積もりが+/- 10％になる」などの指定ができる場合は、残りのボックスオフィスムービーをコミッションしてください。ソフトウェア業界の私たち。オフィススペースとマトリックスのクロスのようなものを考えています。D
実際には、プロジェクトの規模と複雑さに大きく依存します。
プロジェクトの見積もりが1週間とすると、10％が妥当です。 +/- 1/2日を意味します。
1か月の場合、10％は不安定です。私の経験から、1か月で何が見つかるかを予測することは不可能です。
1か月以上-すべての賭けはオフです:)。
これらは開発者ごとです-したがって、4開発者チームの場合、1週間== 1か月です。
4人の開発者チームの場合、1か月で実行できる機能のリストを作成し、それらの機能の10％以内に収めることが主なメリットです。その後、翌月に再見積もりします。
私はここでいくつかの素朴な仮定をしました
- すべての開発者が並行して作業を行うことができます。
- テスターとは考えていません-テストする時間があるはずです
- すべての開発者は同じです-フロントエンド、バックエンド、デザイナーなど...
あなたはそれらを考慮に入れる必要があります。しかし、これは一般的な考えです。
変数はたくさんあります：
プロジェクトの期間はどれくらいですか？
プロジェクトはどのように管理されますか？滝？アジャイル？スクラム？
ウォーターフォールの質問から推測します。これが事実である場合、マージンの要求を考えると、ある程度の割合で失敗すると予想されます。
答えがアジャイル方法論である場合、特にSCRUMのようなものです。マージンのパーセンテージが何であるかは問題ではありません。 2週間のスプリントでのエラーの50％マージンは1週間、1週間のスプリントでは2.5日間であり、どちらも最悪のシナリオです。これは、配信日がスプリントごとに再推定され、時間が経つにつれ、だんだん少なくなるのではなく、ますます正確になるためです。
ウォーターフォールを使用すると、50％のエラーマージンも前例のないものではありませんが、6か月の12か月を超えるプロジェクトでは、発見されず、12か月の10か月まではそれほど深刻ではありません。
私がソフトウェアチームを率いていたとき、おおよそ白亜紀/第三紀の境界付近でしたが、実際には推定で+/- 10％に近づきました。私の非常に危険な記憶が役立った場合、それは約+/- 15％でした。しかし、これは、 私たちがすでにやったこと：比較的シンプルなリアルタイム通信ファームウェア。Aからバイトを取り、私たちが設計したリアルタイム環境で、慣れ親しんだ言語を使用してそれらをBに移動し、社内のいくつかのオフィスから社内で設計されたハードウェアと通信しました。 。上記のテーマのわずかなバリエーションがたくさんあり、文字通り 年。
正直なところ、通常のソフトウェアプロジェクトの見積もりでこの種のエラー率を達成することを期待すると、 ばかげた。明らかに達成されたのは、過大評価されて埋められた（予算を使い尽くすために追加のプロジェクトやペットプロジェクトを行う）か、過小評価されていて、夕方と週末に犬のように働いて時間を補ったためです。
300％のことはきっと聞いたことがあるでしょう？
実際に使っています。私が長年見てきたことに完全に基づいています。 1〜2日聞くと、それは1週間以上本当にできましたです。そしてテスト済み。すべての環境で。ドキュメントを更新しました。使用性テスト済み。テストされたパフォーマンス。負荷テスト済み。数時間は本当に一日のようです。
次の理由により、見積もりは本当に苦手だと思います。
- 他人を助ける
- 中断される
- 新しい人を訓練する
- 今後の予定
- 病気や体調不良
- 去る人々をカバーする
- 休暇や休暇が必要
- 他人に気を取られる
- 他のグループに拘束されている
- 過度に楽観的で現実的である
- 断続的なテストの失敗に取り組むための時間を割り当てない
- テスト、特に自動テストの作成にかかる時間を簡単に除外
したがって、最高レベルでは、300％を超える見積もりを必要とするビジネス関係者がいるため、最終的に私たちがしていることは、かなり良い見積もりを目指していますが、より高いレベルでより一般的な価格を目指しています。 「ユーザー編集機能は、バージョン1で1つのユーザーグループが1つのフィールドを変更することのみを意味します。
"プロジェクトの期間を見積もるときに許容できるエラーマージンは何ですか？"多くのアジャイル環境で使用されているこのアプローチは、アルファを取得するための最低限の機能に質問を変えるのに役立ちますまたはベータ版がライブであり、それを繰り返します。