estimation - 多くの時間を費やさずに見積もりを行うための最良の方法は何ですか?

Question

バックグラウンド

現在、私のチームは、主要な書き換えを出荷するための「バグ修正と研磨」フェーズにあります。いくつかのマイルストーンに対して予定されている、修正すべきバグの山がまだたくさんあります。各マイルストーンのバグを修正するために必要なエンジニアリング作業の見積もりを出すように依頼されました。

以前のマイルストーンでは、次のプロセスに従いました。

コードのその領域について最もよく知っている人にバグを割り当てます。バグを修正する可能性が高い人です。
各人に割り当てられたバグを調べてもらい、バグを修正するのにかかると思われる時間を 1 時間単位で見積もってもらいます。バグの修正に 1 日か 2 日以上かかる可能性があると思われる場合は、そのバグを可能性の高いサブタスクに分割し、それらを見積もります。
マイルストーンごとに各人に割り当てられた作業量を合計し、作業量が大幅に異なる場合はバランスを取ってください。
各マイルストーンの各人の合計に「パディング係数」を掛けて、過度に楽観的な見積もりを考慮します (1.5 を使用しています)。
特定のリリースのチームメンバー全体で最大の合計を取り、それをチームが既存のバグをクローズするのにかかる時間にします。
特定のマイルストーンに到達するまでに作成されると予想されるバグの数を見積もり、これらのバグのそれぞれを解決するのにかかる平均時間を見積もります。これを、各リリースの既存のバグをクローズする時間に追加します。これは、必要な作業量の最終的な数値であり、そのマイルストーンを確実に出荷する日付として提供されます.

これはかなり正確ですが (これまでの 3 つのマイルストーンではほぼ正確に達成できました)、かなり時間がかかります。

現在の問題

今後のマイルストーンのエンジニアリング時間の見積もりを提供するよう求められましたが、時間がかかりすぎるため、上記のプロセスを使用しないように求められました. 代わりに、チームの技術リーダーとして、確実性の低い見積もりを提供するように求められました。

私の主な見積もりの経験は、上記の方法のいくつかのバリエーションを使用したものです（長年のフリーランスのバックグラウンドから）。大きなタスクで「腰から撃つ」と、気が遠くなる傾向があることがわかりました。よくわからないコードの領域のバグを修正するのにかかる時間を見積もると、さらに悪化するのではないかと思います。

物事を細かいタスクに分解して見積もることなく、迅速に見積もるのに成功したヒント、トリック、またはテクニックは何ですか?

オプションではないもの：

見積もりを出していない - 私はこれを試したが、飛ばなかった:)
とてつもなく広い数値と信頼区間を選ぶ - 私はこれを検討しましたが、うまくいくとは思いません。
エビデンスベースのスケジューリング - JIRA を使用していますが、これにはエビデンスベースのスケジューリングツールが書かれていません。現在、FogBugz に移行することはできません。 JIRA、私たちは喜んでそれを支払います)。

score 7 · Accepted Answer

見積もりのための最良のヒント：たくさんのことを切り上げてください。

あなたはすでに見積もりのトピックの専門家であり、可能なことの限界を知っているようです。タスクを完了するために何をする必要があるかを評価せずにタスクを見積もることは不可能です。

評価にかかる時間は、見積もりの精度に正比例します。そして、これらのことは、時間の評価が非常に正確で、タスクを解決した時点で収束します。その瞬間、あなたはそれがどれくらいの時間がかかるかを正確に知っています。

うーん、申し訳ありませんが、これはあなたが聞きたかった答えではないかもしれません...それはそれについての私の考えです。

score 5 · Accepted Answer

いつでもリリースを作成する準備をしてください
利害関係者に行われた作業に優先順位を付けさせる
最優先項目に取り組む

ステップ1は、締め切りを逃さないことを意味します。

ステップ2は、見積もりに時間をかけずに見積もりを依頼している人に質問を戻す方法です。

編集...

上記はあなたの質問に本当に答えません、ごめんなさい。

利害関係者は、各タスクの時間と費用に基づいて作業に優先順位を付けたいと思うでしょう。次の期限までに完了することができると予想される最も優先順位の高い変更のどれかを尋ねられる可能性があります。

一番時間がかからないのは、自分がやるのにどれくらいかかると思うかという印象の3倍を使うことです。

あなたはそれよりも時間がかかるものを探していますが、以前の優れた見積もりほど長くはありません。

簡単、平均、トリッキー、または1、2、4、8、16、32時間の作業であるかどうかを推測するだけの場合でも、各バグを確認する必要があります。

コードベースに対していくつかのコード複雑度メトリック（循環的複雑度など）を作成し、タスクごとに、そのコードベースの2つまたは3つの部分を最も変更する必要がある点を突き止め、次の仮定に基づいて推定します。コードの複雑でない部分は、複雑な部分よりもすばやく変更できます。以前の見積もりのいくつかに基づいていくつかのヒューリスティックを考え出し、各バグ修正に使用して、必要な時間と変動性の見積もりを与えることができます。

score 3 · Accepted Answer

どうですか：

estimate=(bugs/devs)xdays (xK)

これは簡単なことですが、実際には非常に正確です。しかも1分で見積もり可能。信頼水準は詳細な方法よりも低くなりますが、最後の 3 つのマイルストーンのデータを確認し、この簡単な見積もりと詳細な見積もりの違いを確認して、チームの定数を表す"K"値を取得することをお勧めします。

驚いてください。

score 2 · Accepted Answer

あなたは、推定値と不確実性区間を作成する方法を尋ねてきました。これを考えるより良い方法は、最悪の場合の見積もりと最良の場合の見積もりを行うことです。2つを組み合わせて、推定範囲を設定します。よく理解されている問題は、当然、あまり理解されていない問題の見積もりよりも具体的です。たとえば、1.5〜2日のように見える見積もりは、おそらくよく理解されている問題の場合であり、2〜14日のように見える見積もりは、まったく理解されていない問題の場合に一般的です。見積もり間のギャップを大きくすることで、調査の量と見積もりの作成に費やす時間を制限します。これが機能するのは、現実的なベストケースとワーストケースのシナリオを比較的簡単に想像できるためです。不確実性の範囲がスケジュールで扱いやすい以上の場合、次に、あまり理解されていない問題を理解するために少し時間がかかります。それらを分割するのに役立つ場合があります。

作業に全体で1週間以上かかると予想される場合、通常、見積もりでは1時間の粒度ではなく半日の粒度を使用します。

score 2 · Accepted Answer

プランニングポーカーを使用して、プログラミングタスクの長さを見積もる方法の回答を参照してください

score 2 · Accepted Answer

簡単に言えば：

あなたの最も絶対にリベラルな見積もり * 3 = あなたの見積もり

上記は冗談のように見えるかもしれませんが、そうではありません。私はそれを何度も使用しました。あらゆる種類のソフトウェアプロジェクトの時間見積もりは、自動車ディーラーとの取引と同じようにゲームです。その式は、ピンチで管理を提供するものを取得し、遊ぶ余地も与えます.

ただし、何らかの方法でより詳細な詳細に到達できる場合 (これが、より正確な情報を得ることができる唯一の方法です)、ファンクションポイント分析に関する Google は、「高速ファンクションポイント分析」または「」と呼ばれることもあります。高速関数点推定」.

そこにいる多くの人々は、できるだけ早く見積もりをするのに役立つ無数のスプレッドシート、PDF などを持っています。スプレッドシートには数式が組み込まれているので、最初にスプレッドシートを確認してください。

お役に立てれば！

score 1 · Accepted Answer

public static class Time
    {
        /// <summary>
        /// Estimates the hours.
        /// </summary>
        /// <param name="NumberPulledFromAss">The number pulled from ass.</param>
        /// <param name="Priority">The priority.</param>
        /// <param name="Complexity">The complexity.</param>
        /// <returns>
        ///  a number in hours to estimate the time to complete a task.
        /// Hey,  you will be wrong anyway why waste more time than you need?
        /// </returns>
        public static int EstimateHours(int NumberPulledFromAss, int Priority, int Complexity)
        {
            var rand = new Random(NumberPulledFromAss);
            var baseGuess = rand.Next(1, NumberPulledFromAss);
            return (baseGuess + (Priority * Complexity)) * 2;
        }
    }

score 1 · Accepted Answer

あなたの見積もりはあなたがそれらに入れた時間と同じくらい正確です。今回は、問題を分解したり、慣れ親しんだ分野での過去の経験を利用したりする物理的な時間になる可能性があります。これがオプションでない場合は、バグ/ポリッシュをグループに分けてみてください。

数時間の些細な修正。
最大1日の努力。
非常に複雑-1週間の努力。

これらを分類したら、大まかなゲストを作成できます。

score 1 · Accepted Answer

アジャイルブログのこの記事では、多くのヒントが役立つ場合があります：AgileEstimating。

score 0 · Accepted Answer

見積もりの変動性の計算は、見積もりの計算よりも時間がかかります。

estimation - 多くの時間を費やさずに見積もりを行うための最良の方法は何ですか?

バックグラウンド

現在の問題

10 に答える 10

Related

Reference