開発者はExcelマクロによるワークロードの見積もりを受け入れる必要がありますか？
新しいプロジェクトでは、友人がテストを書く必要がありました。テストを書くのに必要な時間は、開発者以外のマネージャーが書いたExcelマクロによって計算されました。
このような状況では、開発者は計算された時間内にテストを記述して実行する責任を受け入れる必要がありますか？これらのテストの結果は信頼できますか？
詳細については、私の友人は、彼が行っていない見積もりについて責任を負うことを拒否し、別のプロジェクトで成功するように依頼し、経験の浅い学校外のイエス・ガイに置き換えられました。
それは、開発者がどの程度敏感であるかに依存し、どのデータ/ロジックに基づいているかに依存します。 （それら可能性があります過去数年間に同様のタスクを解決するために、この開発者自身および/または他の人がどれだけの時間を要したかについて数年にわたって収集された統計データに基づく...またはそれら- 可能性があります彼のマネージャーの-正しいか正しくない-仮定に完全に基づいています。）
理想的には、他の誰かによって推定されたタスクにコミットして責任を負うことは合理的に期待できないことをマネージャーと話し合う必要があります。
明白に見積もりに応じることを拒否すると、確かに彼のプロンプトの置き換えが発生する可能性があるため、より柔軟なアプローチをとり、可能であれば直接的な対立を避けることをお勧めします。
おそらく、マクロはある種の入力データで動作しています。それは単なる乱数ジェネレータではありませんか？したがって、あなたの質問に答えるためには、入力データが何で、マクロが何をするかを知る必要があります。これがないと、答えはまったく意味がありません。
または、あなたの質問は、関連する経験のないマネージャーが作成した見積もりを受け入れることについて本当にですか？この場合、答えは「いいえ」です。あなた（またはあなたの友人）は、独自の見積もりを作成して、マネージャーに提出する必要があります。 2つの数値が一致しない場合は、一緒に作業して、最善の方法を見つける必要があります。おそらく、より少ないテストを書くことに同意するか、すべてを書くのに時間がかかる可能性があります。
ポイントブランクの拒否は誰にも役立ちません。また、対応できないタイムスケールで作業するのも楽しいものではありません。解決策は、専門家のアプローチを取り、妥協して作業を進めることです。
間違いなくNO。
小さなプログラムは、大きくて複雑なプログラムであっても、プログラミングジョブにかかる時間を見積もることはできません。理由については、 ソフトウェア推定の数学的制限 を参照してください。より長い、査読済みの論文、 ソフトウェア推定の大きな制限 も利用できます。
私はまた、問題のマネージャーの私の意見を再考します。過去にソフトウェアタスクの期間を推定するために他のすべてのものが試行されたとすると、スプレッドシートマクロは過去に試行されなかったと彼または彼女が信じるのはなぜですか。
うわっ！
これは巨大な「仕事のにおい」です。それは信じられないほどのマイクロ管理です。
彼らが従業員に見積もりを与えることを信頼できない場合、彼らはあなたに他に何を信頼しませんか？
絶対にありません。
私は、マネージャーが彼のExcelマクロが見積もりを正確に予測できると考えるのにそれほど騙されていないことを約束します。アルゴリズムでこのようなことを正確に予測するには、あまりにも多くの変数が関係しているというよく知られた事実については何も論じていません。もし彼がそのようなアルゴリズムを発明したなら、彼はそれを特許化し、私の意見では何百万もすべきです。
ここで実際に起こっているのは、マネージャーがこの想定されたExcelマクロを薄いベールに覆われた変装として使用して、非現実的な期待と過度のプレッシャーを開発者に強いているという事実を隠すことです。
彼はそれがBSであることを知っており、気にしていません。リソースをオーバーブッキングして、「価値のない」すべての開発者を永続的に「LATE」にすることで、物事をより速く実行しようとする言い訳です。
このマネージャーは搾取的なジャークのように聞こえます。
新しいプロジェクトでは、友人がテストを書く必要があり、テストの作成に必要な時間は、開発者以外のマネージャーが作成したExcelマクロによって計算されました。
ソフトウェアプロジェクトを含むプロジェクトの完了時間を推定するための パラメトリック推定モデル があります。通常、推定値は製品コード用ですが、テストコードの作成にかかる時間を推定するために推定できない理由はわかりません。ただし、これらの推定値は、それらに供給されるデータと同じくらい良好です。
使用される方法が有効な推定モデルであり、データが正確で有効であると仮定すると、開発者以外のマネージャーが作成したExcelマクロから適切な推定が得られない理由はありません。
そのような状況で、開発者は計算された時間内にテストを作成して実行する責任を受け入れる必要がありますか？
いかなる状況においても、見積もりを盲目的に受け入れてはなりません。どのように生成されたかに関係なく、推定値は完全ではありません。見積もりを確認し、潜在的な問題を特定し、それらの影響を評価し、必要に応じて見積もりを検討および調整するのはエンジニアの責任です。
これらのテストの結果は信頼できますか？
テストは、テストの設計と実装に費やされた努力と同じくらい優れています。テスターが低品質のテストを作成すると、欠陥がテストをすり抜けて、プロジェクトの後の段階に進みます。スケジュールのプレッシャーが低品質のテストにつながるのは当然のことです。そのため、適切なテストケースを設計してそれらのケースを実装する時間が足りない場合、テストはそれほど役に立ちません。
2つの異なる質問をしているようです。
これらのテストの結果は信頼できますか？
Excelは、他のツールと同様に使用するツールであり、計算の記述内容がアルゴリズム自体の結果に実際に影響することはありません。推定がExcelマクロからのものであるという事実は、計算の結果（つまり、推定の有効性）が有効であるかどうかとは無関係です。基礎となるモデルに誤った仮定がある場合は、基礎となる仮定が正しくないため、計算に何を使用してもかまいません。
そのような状況で、開発者は計算された時間内にテストを作成して実行する責任を受け入れる必要がありますか？
指定された時間内に開発者が作業を行うという要件が彼らの接触にある場合、見積もりが妥当である限り、それについて議論するためにできることはあまりありません。これが次のポイントにつながります。計算が妥当な時間を与えており、それらが開発者が自分で与える推定に類似している場合、与えられたタイムラインに反対しない理由はありません。実際、任意のタイムラインが与えられている場合とは対照的に、モジュールで使用されている前提条件に影響を与えることができるため、開発者にとって有利な場合があります。
必要な作業量に対してタイムラインが実行不可能であると思われる場合は、明らかにこの懸念を提起し、マネージャーと協力してより現実的なタイムラインを取得する必要がありますが、タイムラインが実現可能である場合、彼らはそれに反対するのに苦労します。
プロジェクト管理とタイムラインの見積もりに関しては、可能ですが、実行される作業の性質に大きく依存しています。ユニットテストコードの記述に必要な時間（開発者がフレームワークを理解し、以前に記述したことがある）に対して、テストコードが記述されているユースケースに対して新しいコードを記述する場合よりも、より正確な見積もりが与えられるでしょう。ために。
私はテストを書くことを軽視したくありませんが、プロジェクトにはおそらく以前に何人かの開発者がそれらを書くことがありました。推定値がこれらのデータに基づいている場合、友人が想定しているよりも正確である可能性があります。あなたの友人がプロジェクトを去り、反対の見積もりを作成したり、予測どおりに完了できるかどうかを確認したりしなかったので、私たちは決して知りません。
彼がしなければならなかったのは、見積もりがどれほど正確であるかを確認するために1つまたは2つのテストを完了し、正当な議論をしてマネージャーに戻ることだけでした。推定値の信頼性または遅れた結果についてフィードバックを提供できた他のチームメンバーがいる可能性があります。時々、1人のマネージャーが上司に「何か」を与えて、みんなを幸せに保つ必要があります。開発者はこれを誤った安心感だと考えています。おそらく、開発者が見積もりを出し、物事を成し遂げる意欲を示す動きがあった場合、経営陣はより信頼を築くでしょう。
私が推測しているのは、もし彼がより短い時間でテストを完了することができたなら、彼はそれについて何も言わないだろうということです。次に、彼が信じていない実践から自分を免除することは、高レベルの誠実さを示している可能性があります。
簡単で短い答え：
推定がどこから来ているかは気にしません。
実際に気にするのは推定そのものです。それに同意するか、同意しないで、なぜあなたが見積もる理由と量を説明します。それが最も重要です。
理論的には、開発者は、どのようにして到達したかに関わらず、他の人が行った見積もりを決して受け入れてはなりません。その理由の1つは、マネージャーが満足できるよりも長い見積もりを与えると、潜在的なスケジュールの問題や、実行する作業の範囲に関する誤解がすぐに明らかになるためです。
人々は一般にプログラミング時間の見積もりをそれ自体のプログラミングよりも難しいと感じています。そのため、マネージャーがExcelマクロを書くことができれば、それの問題を解決できれば、おそらくマクロを構築してコードを書くことができます（そうではありません）。
practiceで、作業を理解し、見積もりが妥当であると思われる場合は、単に方法論について懸念を表明するだけで、暫定的に合意して、それらが満たされるかどうかを確認することは理にかなっています。後で、作業が見積もりよりも長くかかっている場合は、できるだけ早くこれをマネージャーの注意を引く必要があります。実際の実装経験に基づいて、正確な理由を話し合う準備をしてください。うまくいけば、その時点であなたのマネージャーは不合理ではなく、あなたが機械的に生成された推定値に取り組むことを主張し続けるでしょう。