プロジェクトの期間を見積もるときの許容誤差はどのくらいですか？

私が働いている会社は、最大10％のエラーマージンを目指しています。

私はそれを比較するものが何もなかったので、私はそれについてどう考えるべきかわかりません。

多かれ少なかれ、私たちがあまりにも間違って推定している場合、測定するための良いベースラインは何でしょうか？どのように（％で）ずっとあなたがあると思います大丈夫ミスに？

あなたとあなたの同僚が以前に行ったことに非常に類似した何かを推定していない限り、+ /-10％は途方もなく楽観的です。経営陣は、ソフトウェアの経験があまりないか、ソフトウェア推定の大きな制限を認識していません。その論文にはいくつかの補足資料があり、多くの罰則があります。

典型的なソフトウェアプロジェクトであるルービックキューブよりもはるかに単純なシステムを調べてみましょう。最大20回の移動で任意の位置を解決できます。ただし、推定しているので、ソリューションを提供する前に特定のキューブを数分間しか見ることができません。良い見積もりをいただけますか？いいえ、プロセスの推定には、プロセスの実行よりも時間がかかる場合があります。

別のシンプルなシステム：ピノキオ。木製のオートマトンである彼のノーズピースは、嘘をつくと成長します。ピノキオが休んでいて、「私の鼻が大きくなった」と言うとどうなりますか？一部のシステムは予測を受け入れられず、決定できません。

これら2つの問題は、ほとんどのソフトウェアシステムに組み込まれています。そのため、推定値が+/- 10％に近づくことはありません。

私のアドバイスは、かなり詰め込んだ見積もりを与え、できるだけ早くプロジェクトを終わらせるために奴隷のように働き、それから10％以内かそれ以上になるまで忙しく見えるようにすることです。その時点で、壮大な成功を発表します。

プロジェクトに依存するため、あらゆる種類の「ターゲットエラーマージン」について非常にためらいます。新しいCRMシステムをインストール、構成、およびカスタマイズするのにかかる時間を見積もろうとする場合、どのようなカスタマイズが必要になるのか、どのようなビジネスプロセスの変更が必要になるのかが誰にもわからない会社には同様の大規模プロジェクトの履歴がないため、エラーマージンはかなり大きいはずです（つまり、18か月+/- 50％で見積もり9-27か月かかると思われるかもしれません）。プロジェクトが進むにつれて、仕様が明確になり、ビジネスプロセスに関する意思決定が行われ、開発者がより快適になります。これらのエラーマージンはさらに厳しくなります。101番目の基本的なeコマースサイトを構築するのにどれくらいの時間がかかるかを推定しようとしている場合、veは最初の100から良好な履歴を取得しているため、より正確な推定値を提供できると期待されます。ただし、ほとんどのプロジェクトは途中で落ちます。

範囲ではなく単一の数値を引用する場合、答えはおそらく、範囲を引用し始めることです。そのため、推定を行う人は、推定がどの程度正確であるかを指定できます。

良いベースラインはに基づいて1つになり、実際のデータあなたが収集してきました。

これを行う最初のステップは、すべての推定値を記録することです。2番目のステップは、実際の結果を記録することです。正直に言って、実際の「自己調整」をしようとしないでください。この情報を十分に収集すると、推定値がどれだけ優れているかを統計的に把握するためのデータが得られます。これは、誰が見積りを行い、誰が作業したかによって大きく異なる場合があります。これを行うことによってのみ、他の純粋なゴミである「エラーのマージン」を与えることが合理的に期待できます。

それだけではありません。推定値がオフになる原因を分析すると、将来の推定値の精度を向上させるのに役立ちます。注：それらはまだ推定値のままであり、そのため、単なる推定値です。

推定も最初の推定後に終了しません。これは、より多くの知識が得られるようにプロジェクトが進行するにつれて調整できるものであり、これにより、作業中に発生する可能性のあるエラーのマージンが削減されます。コミュニケーションについてオープンになればなるほど、以前のサプライズが議論されます。これにより、人々のサプライズが少なくなり、プロジェクトや顧客の期待を調整する時間が増えます。

第二に、おそらくエラーマージンを処理するより良い方法は、単にエラーのマージン％ではなく、「内部信頼」です。あなたは、単一の日付ではなく、信頼区間に基づいて配達日を推定しました。

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％以内であることがほとんどです。その後、翌月に再見積もりします。

私はここでいくつかの素朴な仮定をしました

1. すべての開発者が並行して作業できます。
2. テスターを考慮していない-テストする時間があるはずです
3. すべての開発者は同等です-フロントエンド、バックエンド、デザイナーなど

それらを考慮に入れる必要がありますが、これは一般的な考え方です。

多くの変数があります：

1. プロジェクトの期間は？

2. プロジェクトはどのように管理されますか？滝？アジャイル？スクラム？

ウォーターフォールの質問から推測します。その場合、マージンのリクエストを与えられると、ある程度の割合で失敗することがほとんど予想されます。

答えがアジャイルの方法論、特にSCRUMのようなものである場合。マージンの割合がどうであっても問題ではありません。2週間のスプリントでの50％のエラーマージンは1週間であり、1週間のスプリントでは2.5日間であり、どちらも非常に最悪のシナリオです。これは、配達日がスプリントごとに再推定されるためであり、時間の経過とともにますます正確ではなくなります。

Waterfallの場合、50％のエラーマージンは前代未聞ではありませんが、6か月である12か月のプロジェクトでは、12か月後の10か月まではそれほどひどくはありません。

かつて白亜紀/第三紀境界付近でソフトウェアチームを率いていたとき、実際には推定で+/- 10％に近づきました。私の非常に危険な記憶が役立つなら、それは約+/- 15％でした。しかし、これは、すでに行ったことを見積もっていたためです。比較的シンプルなリアルタイム通信ファームウェアで、Aからバイトを取得し、使い慣れた言語を使用してBに移動しました。 、数か所離れたオフィスで社内で設計されたハードウェアと話しています。文字通り何年もの間、上記のテーマのわずかな変種がたくさん。

通常のソフトウェアプロジェクトの推定でこの種のエラー率を達成することは、率直に言って滑luです。どうやらそれが達成されたように見えるのは、人々が過大評価してパッドを入れた（予算を使い果たすために余分なものやペットプロジェクトを行っている）か、夕方や週末に犬のように過小評価して働いて時間を補っているからです。

おそらく300％のことを聞いたことがありますか？

実際に使用しています。私が何年も見てきたことに完全に基づいています。1日か2日聞くと、本当に 1週間以上かかります。そしてテスト済み。すべての環境。ドキュメントが更新されました。ユーザビリティがテストされました。性能テスト済み。負荷テスト済み。数時間は本当に1日のようです。

私たちは推定が本当に下手だと思う：

• 他の人を助ける
• 中断される
• 新しい人の訓練
• その他の予定
• 病気や体調不良
• 去る人々をカバーする
• 休暇や休暇が必要
• 他人に気を取られる
• 他のグループに支えられている
• 現実よりも楽観的すぎる
• 断続的なテストの失敗に取り組むための時間を割り当てない
• テストの時間、特に自動テストの作成を簡単に除外

そのため、最高レベルで、300％を超える見積もりが必要なビジネス関係者の場合、私たちがやることは合理的に良い見積もりを目指していますが、より高いレベルでより一般的な価格を目指しています。バージョン1では、1つのフィールドを変更するためのユーザーのグループが1つだけであることを意味する場合でも、「ユーザー編集機能があります」。

それがに来るとき、「プロジェクト期間を推定する際、何が許容誤差があります？」多くのアジャイル環境で使用されているこのアプローチは、アルファ版またはベータ版を公開し、それを反復するための最小機能を質問に変更するのに役立つことがわかりました。