あなたがプロジェクトマネージャーだとします。特定の開発者の特定のタスクの工数を日数で見積もることができます。推定を実行した後、いくつかの最小値と最大値を取得します。
この後、タスクを開発者に委任します。実際には締め切りも設定します。
締め切りを設定するときに、どちらの見積もりを使用するのが良いですか: 最小または最大?
最小見積もりは開発者にストレスを与える可能性があるため、最大見積もりは、タスクをより速く完了できる場合でも、開発者に割り当てられたすべての時間を使用する可能性があります (いわゆる学生症候群)。2つのアプローチの他の長所と短所は?
編集：
ちょっとした説明: 上司に報告するためではなく、タスクを委任するときに部下に締め切りを設定することについて話します。
編集：
もう1つ明確にするために、私は自分の実際の見積もりを念頭に置いて、上司にはわずかに大きい見積もりを提供し、部下にはわずかに小さい見積もりを提供することができます. そして、この質問は次のことに関係しています: 開発者を過小評価して、開発者をより一生懸命働かせるのは良い考えですか?
単純な平均だけでなく、最小推定値と最大推定値*の関数である最良の推測を使用する必要があります-
best_guess = (min * min_weighting + max * max_weighting) / 除数*
* Tom Neyland は、そうあるべきだと示唆しています(min_weighting + max_weighting)。実際、それが正しいかどうかはわかりませんが、元の の約数よりもおそらく正しいでしょう2.0。
最小値と最大値に与える重み付けは、タスクの複雑さ、タスクに関連するリスク、リスクが発生する可能性、開発者のスキルなどによって異なり、組織によって異なります。プロジェクトからプロジェクトへ。以前の見積もりとそれぞれにかかった実際の時間を記録しておくと、時間の経過とともにこれらの見積もりを改善することができます。
上級管理職や顧客と話すときは、これらの値と信頼値も使用する必要があります。最大を与えて早期に提供することは、最小を与えて遅く提供することと同じではありませんが、それでも開発を制御できないことを示しています.
信頼値とリスクのアイデアを与えることも、期待を管理するのに役立ちます。問題が発生した場合、それらは予期しないものではありません。
* これらの最小値と最大値の見積もりは、さまざまな方法で取得されます - 開発者への質問、過去の経験など。開発者をポーリングする場合、実際の最小値と最大値は異常値として扱われ、何らかの方法で破棄または変更する必要があります。ここで言いたいのは、「うまくいけば2週間、問題があれば1か月かかる」というフレーズから得られる値です。したがって、式に代入する値は生の数値ではありません。
代わりに、最良の、可能性のある、および最悪のシナリオの見積もりを求めてください。次に、プログラム評価とレビュー手法を使用します。ただし、最初にいくつかのPERT批評を確認することをお勧めします。
個々のタスクまたはクリティカルパスを構成するタスクの場合、最良のケースの見積もりを行うのは賢明ではありません。プロジェクトにはリスクや不確実性がまったくないというようなものです。実際の仕事が最良のシナリオ以外のものであることが判明した場合、あなたはスケジュールを吹き飛ばしてしまうでしょう。夜や週末に仕事をしなければならないのではなく、手に余計な時間を費やして、いくつかの便利なものを実装することで時間を埋めることをお勧めします。
一方、マネージャーがほとんど最悪の場合の見積もりを行った場合、ソフトウェアの世界では、ほとんどのプロジェクトが実現可能性と計画の段階を超えることは決してないであろう、最良の場合の数値よりも桁違いに大きくなる可能性があります。すべてのリスクが顕在化するわけではありません。
最良の推定値を求めることは、学生症候群との闘いに役立ちません。代わりに、暫定的なマイルストーンと成果物を含めます。学生症候群との闘いに役立つだけでなく、プロジェクトの進捗状況に関する信頼できるデータを入手し、潜在的な問題を早期に発見するための前提条件です。
min も max も使用せず、その間の何かを使用します。
過大評価の側で過ちを犯す方が良いです。長期的には、より優れたコスト動作を実現します。
過小評価によるストレスを克服するために、人々は長期的には有益ではない近道をするかもしれません. たとえば、最終的に返済しなければならない余分な技術的負債を取得すると、利息が発生します。コストは指数関数的に増加します。
スチューデント症候群による非効率性による余分なコストは直線的に作用します。
見積もりと目標は異なります。あなた (またはマネージャーや顧客) は、達成する必要のある目標を設定します。見積もりは、それらの目標を達成する可能性を教えてくれます。締め切りは、一種の目標です。選択する締め切りは、どのような信頼レベル (締め切りに間に合わないリスク) を受け入れる意思があるかによって異なります。P50 (締め切りに間に合う確率 0.5) が一般的です。場合によっては、P80 またはその他の信頼レベルでスケジュールしたい場合があります。確率曲線はロングテールであり、信頼性が高いほど、プロジェクトに時間を割く必要があることに注意してください。
全体として、個々のタスクの追跡にあまり時間をかけません。P50 ターゲットでは、いずれにせよ半分が遅れます。最も重要なのは、集計がどのように動作するかです。個々のタスクの見積もりを集計にまとめる場合、最小値も最大値も賢明ではありません。すべてのタスクが最小時間 (おそらく P10 時間など) または最大時間 (たとえば P90 時間) で完了することはほとんどありません。n 個の P10/P90 タスクの場合、確率は 0.1^n です。
PERT には、合理的なタスク期間の確率分布を考え出し、それらをより大きな全体に集約するためのいくつかの手法があります。ここでは数学には立ち入りません。さらに読むためのポインタを次に示します。
Steve McConnell: Software Estimation - Demystifying the Black Art . それは非常に読みやすく実用的ですが、少なくとも私が持っている第 1 版には、数学などに癖があります。
Richard D. Stutzke: ソフトウェア集約型システムの見積もり - プロジェクト、製品、およびプロセス。もう少しアカデミックで読みにくいですが、たとえば数学をよりよく説明しています。
これらの回答の多くに欠けているもの (おそらくトピックから少し外れているため) は、頻繁な更新です。若い/新しい開発者にとって、これはさらに重要です。彼らがコミットしたコードを読んだり、毎日チェックインして、特定の詳細なレポートを求めたりしてください。
これにより、開発者に過度のストレスを与えることなく、締め切りをタイトに設定することもできます。
頻繁な更新は、顧客/経営陣の期待を設定する上で最も重要なツールを提供します。つまり、物事を遅らせる可能性のある問題を早期に警告します。
最小値と最大値の差が大きい場合は、黒魔術の公式を使用するのではなく、開発者に戻って詳細な分析とプロトタイピングを依頼するのが最善だと思います。最小値と最大値の差はそれほど大きくありません。
質問への注意: 私の意見では、開発者/アーキテクトは、タスクを分解してそれらのタスクを見積もることができる最高の技術的知識を持っているため、見積もりは開発者/アーキテクトによって行われるべきです。
特定の開発者の見積もりを行っていて、その開発者の見積もりが概して正確であることがわかっている場合、最小値は (最初の) 論理的な期限です。プロジェクトの過程で、状況に応じて締め切りを調整します。
特定の開発者との経験がほとんどない場合、私の好意的に尊敬する以前のマネージャーの 1 人は、開発者自身に見積もりを依頼し、最初の締め切りをその開発者の最小値と最大値の間の距離の 3 分の 1 に設定して、開発者にそれを打ち負かすように要求します。
開発者はこれを開発するために洞窟に戻るのでしょうか、それともプロジェクトの過程で要件を変更する可能性は十分にありますか? ほとんどのプロジェクトでは、何かがうまくいかない可能性が高いと思います。そのため、プロトタイプを遅かれ早かれ完成させたほうがよいかもしれません。
最初の質問については、これをいくつかの異なる結果に分けて、それぞれを検討すると思います。
大幅な過小評価 -> これは、やるべきことがまだたくさんあり、マネージャーが合理的な見積もりを行うことができないように見えるという問題につながります。
軽微な過小評価 -> この場合、拡張機能があるか、スコープがカットされるか、いくつかのバグがリリースに含まれていますが、これは前のケースよりも優れています。
締め切り、時間、予算を厳守し、品質を維持 -> すべてがうまくいったので、これが最適に思えるかもしれませんが、これが可能な限り最高の結果だとは思いません。
わずかな過大評価 -> この場合、物事が早期に終了するか、余分な作業が追加されることを意味する、いくらかの余裕があります。ここでのポイントは、これは、一部の企業が予想よりも良い結果を出すために、利益予想をわずかに上回ることを試みる方法のように、前のケースよりもわずかに良い結果をもたらしているように見えるかもしれないということです。
大幅な過大評価 -> これは最悪のケースの結果になると思いますが、合理的な見積もりを提供できるという点で、誰かが自分のリーグから外れているという点では最初のケースと似ています。
これはあくまでも私の意見であり、他の人は私とは異なる見方をしている可能性があります。
約束を下回ったり、期待以上の成果を上げたりすることに疑問がある場合: あなたは、彼らが期待していた以上の成果を上げられるようになりたいと考えています。これに基づいて、常に見積もりの高い方を使用します。
もう少し複雑:
特定の潜在的な配信について、配信時間が発生する可能性に対して配信時間をプロットすると、正規分布の変動である曲線が得られ、開発者の最小見積もりは次のようになると想定できます。曲線の左側のどこかで、その最大値が右側に向かっています。
見積もりとして選択した単一の数値の左側にある曲線の下の領域は、その見積もりを達成するか、それより前に成功する確率を表します。したがって、左端に数字を指定すると、当たる確率は実質的にゼロになり、右端に数字を指定すると、当たる確率は事実上 100% になります。
あまり一般的ではないのは、平均値を与えると (最小値と最大値の平均値が実際の平均値に近いものを与えると仮定すると)、50% の確率でその期限に到達するだけだということです。事実上、平均を使用すると、締め切りに間に合わない可能性が半分になります。私はあなたのことは知りませんが、締め切りの半分を逃した男として見られるのは好きではありません.
つまり、たとえば 90% の確率でヒットする数値が必要です。便利なことに、95% は平均 + 2 つの標準偏差を表しますが、それを計算するのが難しい場合 (そして、私たちのほとんどはおそらくデータを持っていません)、私の経験では次のように述べています。
(3 x 最大 + 1 x 最小) / 4
妥当な結果が得られます。
ちなみに、開発者に締め切りを伝えるかどうかは、まったく別の問題です。個人的には、彼に ((2 x 最大 + 1 x 最小) / 3) のどこかを与え、残りを不測の事態として持ちます。
開発者の見積もりを最小限に抑えようとしているのなら、それはばかげています。どの業界でも、何かを成し遂げるための最低時間の見積もりを一貫して達成している人はいません。最終的には、最小推定値を大幅にパディングすることを学ぶだけで、すべての推定値がそれを超えるため、古い最小値に到達する
ことはありません。
アジャイル/スクラムでは、締め切りをしっかりと設定するのではなく、「このタスクの残り時間」を設定します。毎日、残り時間を更新します。費やした時間は追跡しませんが、残りの推定時間を追跡し、それについて正直でいようとします.
怠惰な開発者がいる場合、これは悪いことです。なぜなら、彼らはそのシステムを簡単に操作できるからです。価値のある開発者がいる場合、これは素晴らしいことです。彼らはかなり早く見積もりを上達させ、プロジェクト マネージャーとして、彼らの見積もりがどれほど信頼できるかを学び、個々の開発者の見積もりに基づいて、どの見積もりがチェーンに渡されるかについてより良い感触を得ることができます。
少しアジャイルに移行し、どちらがどちらであるかを発見したら、悪い開発者を解雇し、実際に気にかけたことに対して良い開発者に報酬を与え、より生産的で幸せなチームを作り、より正確な期待を上司に報告できるようにします。
見積もりを何に使用していますか？具体的には、通常過小評価していると、開発者がストレスを感じるのはなぜですか？
何かにかかる可能性のある時間をスケジュールしようとしている場合は、中間値を選択します。人々は通常過小評価しているので、おそらく長い面です。いずれにせよ、これらの見積もりを開発者の確固たる目標として使用するべきではないので、過度にストレスをかけるべきではありません。
これらの見積もりを使用してコミットメントを設定している場合は、過大評価する側で誤りを犯す必要があります。開発者に十分な時間を与えると、燃え尽き症候群、ユーザーが望んでいることを完全に実行しない保守不可能なバグのあるコード、および士気の低下と離職率の上昇につながります。コミットメントを到達可能に設定し、開発者に早期に終了するように促します。
これはプロジェクトによって異なります。
一部のプロジェクトでは迅速な開発が必要な場合があり、期限がすでに設定されていて開発を延長する良い機会がない場合、代替手段はありません。典型的な問題：新しいサービスをもたらすマーケティングキャンペーン。このような期限は通常の開発には十分ですが、一部の組織では非常に近いため、開発者はストレスを感じて作業し、本番段階で修正される多くのエラーを作成します。これは、開発者が最高の効果で作業する必要がある場合の一種のプロジェクトであり、成功すると十分な報酬を得ることができます。
一部のプロジェクトは正確に計画されており、ここでは、履歴データ、サブタスクに関する開発者の時間メトリック、リスクの計算など、すべての分析を使用できます。
ただし、とにかくMAX時間を使用しないでください。これは最も不正確な測定値であり、通常はさらに時間がかかります。そして、ここに単純な理由があります。開発者がこのMAXを提供するだけの場合、彼はほとんど測定しません。彼は、当時ほとんど情報がなかった直感をただ与えてくれます。しかし、彼が少なくとも30分を費やすと、彼は自分のタスクの詳細を理解し、それをサブタスクに分割して精度を上げることさえできます。したがって、開発者に「ねえ、みんな、ここで安定したコードを提供するのはいつになるか考えてみてください」のようなバイアスを与えることができますが、開発者に自分で測定を送ってください。それは仕事にとっても、プログラマー自身にとっても良いことです。
締め切りを設定するときにほとんどの見積もり担当者が使用する最初の間違いは、開発者がそのタスクで毎日フルタイムであると想定することです。これは悲惨な間違いです。これにより、過大な見積もりを使用して締め切りを把握しても、締め切りに間に合わない可能性があります。営業時間内に締め切りを過ぎても、クライアントに伝えたのは大きな問題です。人々は休暇を取ったり、病気になったり、陪審義務を負ったり、新しい人事方針について必要な会議に出席したり、誰かが行き詰まったときに別のプロジェクトを手伝うために呼び出されたり、古いコンピューターが壊れたときに新しいコンピューターにソフトウェアをロードしたりしなければなりません。最近デプロイしたコードの生産上の問題を調査しなければならないなどです。プロジェクトで 1 人あたり 1 日 6 時間を超えると見積もっている場合は、プロジェクト開始前の締め切りにすでに問題があります。私が人事の勉強をしていた時、私たちは、仕事に必要な人数を計算する際に、1 日 6 時間強の直接労働に相当する数字を使用しました。そして、使用した数値の基礎として、多くの統計分析を行いました。
ケースバイケースでどちらを使用するかを決める必要があると思います。最大見積もりがおそらくまだ少し低いことがわかっているプロジェクトがいくつかあります (通常、経営陣の誰かが実際の見積もりでクライアントに直面できなかった場合)。見積もりがもっと高いことがわかっている新しいことをしているプロジェクトもあります。オフになる可能性が高いため、このような場合は max. しかし、以前に行った作業が明確に定義されており、割り当てられた開発者が新しいスキルを習得しないことがわかっている場合は、最小値に近づきます (ただし、実際には最小値を使用しないでください。道路には予想外のバンプがあります)。 . また、プロジェクトが短いほど、最小値を達成できる可能性が高くなります。1 年間のプロジェクトよりも 1 週間のプロジェクトの方が適切な見積もりを取得する方がはるかに簡単です。
さらに重要なことは、状況が変わるたびに見積もりと期限を変更することです。クライアントが作業を追加した場合、締め切りと見積もりを延長します。ただそれを行うだけではありません。あなたの最高の開発者が辞め、プロジェクトに新しい人を入れなければならない場合は、その人がスピードを上げるために時間が必要なため、締め切りを延長します（ただし、時間を食べなければならない場合があります。クライアントはその費用を支払うことに同意しない場合があります）クライアントは、締め切りを逃したり、契約を結んだりしても、期待どおりに機能しないことよりも、締め切りを遅らせることを好む傾向があります (満足ではありませんが)。多くのプロジェクト マネージャーは、問題がなくなり、クライアントとの会話に直面する必要がなくなることを望んでいます。