開発者は、Excelマクロによって実行されるワークロードの見積もりを受け入れる必要がありますか？

新しいプロジェクトでは、友人がテストを作成する必要がありました。テストの作成に必要な時間は、開発者以外のマネージャーが作成したExcelマクロによって計算されました。

そのような状況では、開発者は計算された時間内にテストを記述して実行する責任を受け入れる必要がありますか？これらのテストの結果は信頼できるものですか？

情報については、私の友人は、自分が行っていない推定に対する責任を拒否し、別のプロジェクトで成功するように頼み、経験の浅い学校外のイエスに置き換えられました。

開発者にとってどれだけ賢明であるか、およびどのデータ/ロジックに基づいているかに依存します。（彼らは可能性がある、過去に同様のタスクを解決するために...または、彼らは-この開発者自身によって、および/またはその他による-要求されたどのくらいの時間については、数年にわたって収集した統計データに基づいているかもしれない彼のマネージャーさんに完全に基づいています-正しいか間違っている-仮定。）

理想的には、他の誰かが見積もったタスクにコミットして責任を負うことは合理的に期待できないとマネージャーと話し合う必要があります。

推定値へのコミットを明確に拒否すると、実際に彼の迅速な交換につながる可能性があります。

おそらく、マクロはある種の入力データで動作しているのでしょう。それは単なる乱数ジェネレーターではありませんか？したがって、あなたの質問に答えるためには、入力データが何で、マクロが何をするのかを知る必要があります。これがないと、答えはまったく意味がありません。

または、関連する経験のないマネージャーが作成した見積もりを受け入れることについて、あなたの質問は本当にありますか？この場合、答えは「いいえ」です。あなた（またはあなたの友人）は独自の見積もりを作成し、それらをマネージャーに提出する必要があります。2つの数値が一致しない場合は、一緒に作業して最適な方法を見つけ出す必要があります。テストの記述を減らすことに同意するか、すべてのテストの記述に時間がかかる可能性があります。

ポイントブランクの拒否は誰にも役に立たないでしょうし、あなたが会えないタイムスケールで働くことも面白くありません。

間違いなく

小さなプログラムは、大規模で複雑なプログラムであっても、プログラミング作業にかかる時間を推定することはできません。その理由については、ソフトウェア推定の数学的制限を参照してください。より長く、査読済みの論文であるソフトウェア推定の大きな制限も利用できます。

また、問題のマネージャーに対する私の意見を再検討します。他のすべてが過去にソフトウェアタスクの継続時間を推定しようとしたため、過去にスプレッドシートマクロは試行されていないと信じているのはなぜですか。

うん！

これは巨大な「仕事の匂い」です。それは信じられないほどのマイクロ管理です。

彼らが従業員を信頼して見積もることができない場合、他にあなたを信頼していないものは何ですか？

絶対にNO。

マネージャーは、Excelマクロが推定を正確に予測できると考えるのに惑わされないことをお約束します。アルゴリズムでこのようなことを正確に予測するには、変数が多すぎるというよく知られた事実を議論することすらありません。彼がそのようなアルゴリズムを発明した場合、彼はそれを特許し、私の意見では数百万を稼ぐべきです。

ここで実際に起こっているのは、マネージャーがこのExcelマクロを薄く隠された変装として使用して、開発者に非現実的な期待と過度の圧力を強いているという事実を隠すことです。

彼はそれがBSであることを知っており、気にしません。リソースをオーバーブッキングして、彼の「価値のない」開発者全員を永続的に「後期」にすることによって、物事を早く終わらせようとする言い訳です。

このマネージャーは搾取的なジャークのように聞こえます。

新しいプロジェクトでは、友人がテストを作成する必要がありました。テストの作成に必要な時間は、開発者以外のマネージャーが作成したExcelマクロによって計算されました。

ソフトウェアプロジェクトを含むプロジェクトの完了時間を推定するためのパラメトリック推定モデルがあります。通常、見積もりは量産コード用ですが、テストコードを書くのにかかる時間を見積もるために推定できない理由はわかりません。ただし、これらの推定値は、それらに供給されるデータと同程度にしか優れていません。

使用される方法が有効な推定モデルであり、データが正確で有効であると仮定すると、開発者以外のマネージャーが作成したExcelマクロから適切な推定値が得られない理由はありません。

そのような状況では、開発者は計算された時間内にテストを記述して実行する責任を受け入れる必要がありますか？

どんな状況でも、盲目的に見積りを受け入れるべきではありません。生成方法に関係なく、完全な推定値はありません。見積もりを確認し、潜在的な問題を特定し、その影響を評価し、必要に応じて見積もりを議論し、調整するのはエンジニアの責任です。

これらのテストの結果は信頼できるものですか？

テストは、テストの設計と実装に費やされた努力と同じくらい優れています。テスターが低品質のテストを作成すると、欠陥がテストをすり抜けて、プロジェクトの後の段階に進みます。スケジュールのプレッシャーが低品質のテストにつながることは理にかなっているため、適切なテストケースを設計し、それらのケースを実装するのに時間が不十分な場合、テストはそれほど有用ではありません。

次の2つの質問をしているように聞こえます。

これらのテストの結果は信頼できるものですか？

Excelは他のツールと同様のツールであり、計算が記述されたものがアルゴリズム自体の結果に実際に影響を与えることはありません。推定がExcelマクロから行われているという事実は、計算の結果（つまり、推定の有効性）が有効であるかどうかとは無関係です。基礎となるモデルに不適切な仮定がある場合、基礎となる仮定が正しくないため、計算に何を使用してもかまいません。

そのような状況では、開発者は計算された時間内にテストを記述して実行する責任を受け入れる必要がありますか？

開発者が指定された時間内に作業を行うという要件が連絡先にある場合、見積りが合理的である限り、それについて議論するためにできることはあまりありません。それは次の点につながります：計算が妥当な時間を与えており、開発者が自分で与える推定値と類似している場合、与えられたタイムラインに反対しない理由はありません。実際、任意のタイムラインが与えられている場合とは対照的に、モジュールで使用されている仮定に影響を与えることができるため、開発者にとって有利な場合があります。

タイムラインが必要な作業量に対して実行不可能であると思われる場合、明らかにこの懸念を提起し、マネージャーと協力してより現実的なタイムラインを取得するよう努める必要がありますが、タイムラインが実行可能な場合は、それらに反対するのに苦労します。

プロジェクト管理とタイムラインの見積もりに関しては、はい、できますが、それは行われている作業の性質に大きく依存しています。ユニットテストコードの記述に必要な時間（開発者がフレームワークを理解し、以前に記述したと仮定）に与えられるより正確な見積もりが、テストコードが記述されているユースケースに対して新しいコードを記述するよりも多く見られます。にとって。

筆記テストを軽視したくはありませんが、このプロジェクトではおそらく以前に複数の開発者がテストを作成していたでしょう。推定値がこれらのデータに基づいている場合、友人が想定しているよりも正確である可能性があります。あなたの友人がプロジェクトを去り、対立する見積もりを作成しようとしたり、予想どおりに完了するかどうかを確認したりしなかったため、私たちは決して知りません。

彼がしなければならなかったのは、推定がどれほど正確であるかを確認するために1つまたは2つのテストを完了し、正当な主張でマネージャーに戻ることでした。見積もりの​​信頼性や遅れの結果についてフィードバックを提供できた他のチームメンバーがいるかもしれません。時々、一人のマネージャーが上司に「何か」を与えて全員を幸せにしなければならないことがあります。開発者は、これを誤ったセキュリティ感覚と見なしています。おそらく、開発者が見積もりを提供し、物事を成し遂げる意欲を示す動きがあった場合、経営陣はより信頼を高めるかもしれません。

私が推測しているのは、彼がより短い時間でテストを完了することができた場合、彼はそれについて何も言わないだろうということです。繰り返しになりますが、彼が信じていない慣習から自分自身を免除することは、高レベルの完全性を示している可能性があります。

簡単で短い答え：

推定値がどこから来るかは気にしません。

実際に気にするのは、推定そのものです。それに同意するか同意しないで、あなたが推定する理由と量を説明してください。それが最も重要です。

理論的には、開発者は、それがどのように到達したかに関係なく、他の人によって行われた見積もりを受け入れるべきではありません。理由の1つは、上司が納得できるよりも長い見積もりを与えると、スケジュールの潜在的な問題や、実行する作業範囲に関する誤解がすぐに明らかになることです。

一般に、プログラミング時間の見積もりはプログラミング自体よりも難しいと感じているため、マネージャーがExcelマクロを作成してその問題を解決できる場合、おそらくマクロを作成してコードを作成できます（ほとんどありません）。

さて、実際には、作業を理解し、見積もりが合理的である場合、合格する方法論について何らかの懸念を表明するだけで、それらを満たせるかどうかを暫定的に合意することは理にかなっています。後で、作業が見積もりよりも長くかかっている場合は、できるだけ早く上司の注意を引く必要があります。実際の実装経験に基づいて、正確な理由について話し合う準備をしてください。その時点で、マネージャーが不合理にならず、機械的に生成された見積もりに取り組むことを主張し続けることを願っています。

最新のソフトウェア開発方法論の1つはアジャイルであり、よく知られているアジャイルフレームワークの1つはscrumです。ただし、この方法論では、開発者（スクラムチーム）がタスクの実行またはユーザーストーリーの実装に必要な時間を計算します。

私は間違いなくノーと言います。なぜなら：

1. 開発者以外のマネージャーは、仕事に必要な時間を見積もることができません
2. 仕事に必要な時間を見積もるには、Excelにはない人間の知性が必要です
3. このような作業慣行を受け入れることで、マネージャーは時間を見積もる際に開発者に取って代わるのに徐々に慣れてきます。これにより、大災害が発生する可能性があります。上司が言うこのシナリオを考えてみましょう。

オンラインで自転車を販売するための新しいプロジェクトを開始したいのですが、あなたとジョンがそれを達成するのに3週間かかることがわかっています。