unit-testing - 開発者のパフォーマンスの測定に関するもう 1 つの問題

Question

開発者のパフォーマンスの測定に関する質問が殺到していることは承知していますが、ご容赦ください。開発者のパフォーマンスを測定できないという古くからの議論は知っていますが、現実には、当社では何らかの方法でそれを行う「必要性」があります。

私は比較的小規模な会社 (開発者という点では小規模) で働いており、経営陣は「最初のイテレーションでテスト (QA) に合格する機能」に基づいて開発者のパフォーマンスを測定する必要性を感じていました。

私たちはどうにかして、これはさまざまな理由から悪い考えであると彼らに納得させることができ、代わりに、すべての単体テストがパスするコードをテストに入れることによって開発者を測定することにしました。私たちのチームでは、以前は単体テストを開発するための「要件」自体がなかったので、単体テストを開発する必要性を形式化する機会であると感じました。つまり、開発者に単体テストを作成するインセンティブを与えます。

私の問題は次のとおりです。ほぼ間違いなく、すべての単体テストに合格しないコードを QA にリリースすることはないため、単体テストに基づいて開発者のパフォーマンスを合理的に測定するにはどうすればよいでしょうか? 単体テストに基づく優れた開発者の特徴とは?

単体テストに合格しても失敗する機能はありますか?
特定の機能の単体テストをまったく作成していない、または適切な単体テストを作成していませんか?
書かれた単体テストの質？
書かれた単体テストの数?

どんな提案でも大歓迎です。それとも、この種のパフォーマンス測定で完全に的外れですか?

score 6 · Accepted Answer

おそらく、この種のパフォーマンス測定では完全に的外れでしょうか?

問題は、「何を測定するか」ではありません。

問題は「何が壊れているのか」です。

続いて、「破損をどのように測定しますか？」が続きます。

続いて、「改善をどのように測定しますか?」が続きます。

修正しようとしているものがあるまでは、次のようになります。

測定するものを選択します。
人々は、その指標に従って最も「見える」ことを行うことで反応します。
あなたは間違ったものを測定していることに気づきます。

具体的には。

「最初のイテレーションでテスト (QA) に合格する機能」とはどういう意味ですか? 動作するようになるまでコードを保存します。後で良く見えます。したがって、最初の反復で QA に合格するまで遅らせます。
「単体テストはパスするが失敗する機能は？」これは「不完全な単体テスト」のようです。だからあなたはすべてを過大評価します。考えられるすべてのテストを作成するには、十分な時間をかけてください。この測定によって不利益を被らないように、配信を遅くします。
「特定の機能の単体テストをまったく作成していないか、適切な単体テストが作成されていませんか?」これをどのように測定するかはわかりませんが、前のものと同じように聞こえます。.
「書かれた単体テストの質？」主観的な測定。いつもお得なプランです。品質を測定する方法を定義すると、その特定の測定値を最大化するものが得られます。もっとコメントが欲しいですか？それらを数えます。これ以上の空白は? それを数えます。
「書かれた単体テストの数は？」テストの数を数えることほど、冗長なテストを書く動機はありません。このメトリックに従って見栄えがする場合は、ほぼ同じコードを簡単にコピーして貼り付けることができます。

あなたはあなたが測定したものを手に入れます。どのような測定基準を設定しても、測定された特定のものが他のほとんどの品質問題を覆すことがわかります。何を測定しても、他の測定値を減らしながら、その測定値を最大化することを絶対に望んでいます。

編集

「測るな」とは言いません。私は「あなたはあなたが測定したものを手に入れる」と言っています。他の指標を犠牲にして最大化したい指標を選択してください。指標を選択するのは難しくありません。何を測定するかを経営陣に伝えることの結果を知っておいてください。

score 4 · Accepted Answer

単体テストは品質ツールであり、生産性ツールではないと私は主張します。単体テストを奨励し、経営陣に生産性指標を提供したい場合は、コードを本番環境に移行するために単体テストを必須にし、特定の期間 (毎週、隔週、毎週、何でも）。人々がどんなシステムでもゲームをすることが前提であるとすれば、目標を達成するようにゲームを設計してください。

score 3 · Accepted Answer

Joelが、この種の測定は開発者によって悪用されるだろうと言ったとき、それは的を射ていたと思います。設定したものは達成されず、(システムを使用しているすべての人の認識から) 品質に苦しむことになる可能性がありますが、品質の測定値はすべて、物事がかつてないほど良くなったことを示唆しています!

編集します。あなたは経営陣がこれを要求していると言っています。あなたは小さな会社です。あなたの経営陣は、誰もが棒を振って去ることを許すことはできません. これはゴミであり、あなたはそれに関与しないと彼らに伝えてください.

全体的な考えが、彼らが人をランク付けして冗長にすることができるようにすることである場合 (現時点ではそうかもしれません)、何人の人が行かなければならないかを尋ねてから、最悪だと思われる開発者を選択してください。知性と判断力であり、愚かな経験則ではありません

score 2 · Accepted Answer

なんというか、欠陥闇市が思い浮かびますが……これはちょっと逆なんですけどね。

開発者に関して言えば、メトリクスに基づくシステムはどれも機能しません。なぜなら、それは従来の方法で測定できるものではないからです。このようなものに関してあなたが配置しようとするものは何でもゲームされ（問題を解決することは私たちが一日中していることであり、これは解決すべき別の問題であるため）、コードに悪影響を及ぼします（たとえば、私が書いた先日、機能を確認するのに十分な約5つの単体テストを備えた単純なスペル修正プログラムがありましたが、単体テストで測定された場合、別の100を書くのに別の1日を費やすことができ、すべて合格しますが、価値はありません)。

経営陣がこのシステムを導入したい理由を理解する必要があります。報奨金を与える場合は、Joel Spolsky のインセンティブペイに関する記事を参照してください。これは、私が見たものからそれほど離れていません (ボーナス日について考えてみて、実際にどれだけの人が満足しているかを確認してください。当然だと思っていたものを手に入れました-そして、どれだけ多くの人が本当に腹を立てていますか-彼らが当然だと思っていたよりも少なく手に入れた人)。

score 2 · Accepted Answer

Steve Yegge を引用するには:

ディルバートの漫画で公式に嘲笑されたようなことを企業が行うことは許されないという規則を設けるべきではないでしょうか?

score 1 · Accepted Answer

ここノルウェーの自宅で新聞で読んだ研究がいくつかありました。一言で言えば、オフィスタイプの仕事は一般的に成果報酬の恩恵を受けていない. その理由は、ほとんどのオフィスタイプの仕事でパフォーマンスを測定することはほとんど不可能だった.

しかし、例えばイチゴ狩りのような単純な仕事は、パフォーマンスを測定するのが本当に簡単なので、成果報酬の恩恵を受けました. ハイパフォーマーがより多くのベリーを収穫したことを誰もがはっきりと見ることができるため、ハイパフォーマーがより高い報酬を得ても、誰も気分を害することはありません.

オフィスでは、他の人がより良い仕事をしたかどうかが常に明確であるとは限りません。そして、多くの人がやる気を失うでしょう。彼らは、教師に対する業績給でテストし、それが否定的な結果をもたらすことを発見しました. 高い給料をもらった人は、なぜ自分が他の人よりもうまくやったのかを理解していないことが多く、低い給料をもらっていた人は、通常、自分が他の人よりも低い理由を理解できませんでした.

彼らが見つけたのは、金銭以外の報酬が通常役立つということでした. よくできた仕事などで上司から励ましの言葉をもらう。

Steve Jobs がどのようにして人々にパフォーマンスを発揮させたかについては、iCon をご覧ください。基本的に、彼は人々に、自分たちが大きな何かの一部であり、世界を変えようとしていると信じ込ませました。それが人々に努力と実行をさせるものです。開発者がお金のためだけに多大な労力を費やすとは思いません。それは、彼らが本当に信じているもの、および/または楽しいまたは楽しいと思うものでなければなりません.

score 0 · Accepted Answer

単体テストにはいくつかの要素の組み合わせが必要であり、開発グループ外の誰かが次の測定に関してスコアカードを簡単に作成できるようにする必要があります。

1) 単体テストは、コードと、UI 要素に入力される可能性のある一般的な入力データをどの程度カバーしていますか? これは基本的なことのように思えるかもしれませんが、良い出発点であり、nCover のようなツールで簡単に定量化できるものだと思います。

2) 頻繁にテストされる境界条件はありますか? たとえば、数値の代わりにパラメーターや文字の null を使用したり、その他の基本的な検証テストを行ったりしますか? これはまた、さまざまなメソッドのパラメータを調べたり、ここでのバイパスを防ぐためのコーディング標準を設けたりすることで、簡単に定量化できるものです。たとえば、コンストラクタ以外のすべてのオブジェクトのメソッドは 0 パラメータを取るため、境界テストはありません。

3) 単体テストの粒度。テストは 1 つの特定のケースをチェックし、1 つのテストで多くの異なるケースを実行しようとはしませんか? テストクラスには何千行ものコードが含まれていますか?

4) 可読性と保守性の観点からコードとテストを評価します。新しい人は、何が起こっているのかを理解するのに何日も費やす必要がありますか、それともコードは自己文書化されていますか? 例として、意味のあるメソッド名とクラス名、およびそこにあるドキュメントが含まれますか?

最後の 3 つのことは、マネージャー、チームリーダー、または開発者のグループ外の誰かがランク付けして処理できるのではないかと私が考えるものです。これを悪用するためのいくつかのゲームがあるかもしれませんが、問題はどのような最終結果を得たいかということです? 私は、十分に文書化され、高品質で、簡単に理解できるコード = 優れたコードだと考えています。

score 0 · Accepted Answer

デミングと総合品質管理を調べて、どの仕事でも業績評価をまったく行うべきではない理由についての彼の考えを調べてください.

代わりに、異なることが証明されない限り、すべての従業員が許容可能な従業員であると仮定してください。

誰かが容認できないことをしたり、必要なレベルのパフォーマンスが得られなかったりした場合は、パフォーマンスの問題として書き留めてください。彼らを会社から追放する前に、彼らが何件の記事を受け取るかを判断してください。

誰かが何かをうまくやった場合は、何か良いことをしたことを書いてください。ボーナスを提供する場合は、良いパフォーマンスが発生したときに提供してください。さらに良いのは、人々がアタボーイを手に入れたときに必ず発表することです. 人々はそれらを手に入れるために努力します。確かに、システムを操作し、他の業績に基づいて書き上げようとする政治的なタイプがいるでしょうが、どのシステムでもそれは起こります。優れたパフォーマンスのときに誰がそれらを取得したかを発表することで、社内政治のプレーヤーが最適に機能できるようにする秘密を取り除きました. ジョーが何か素晴らしいことをしたことをみんなが知っていて、代わりにメアリーに報酬を与えたら、人々はそれについて話し始めます. 少なくとも、ジョーとメアリーの両方がアタボーイになるかもしれません。

毎年、全員に同じパーセンテージの昇給を与えます。これは、許容できるパフォーマンスを示した従業員のみを保持し、年間を通して優れた従業員が何か良いことをしたときにいつでも報いるためです。

測定に行き詰まっている場合は、誰かのパフォーマンスの悪さを指摘した回数と、パフォーマンスの良さを指摘した回数を測定してください。次に、それについて合理的に客観的になるように注意し、良いことをしたときにあなたの友達ではない人や、悪いことをしたときにあなたの友達になる人でさえも書き留める必要があります. しかし、現実の世界には客観的な基準がないため、どのように客観的な基準を主張しても、マネージャーはプロセスにおいて主観的になるでしょう。

score 0 · Accepted Answer

人々の給料を単体テストのパフォーマンスに結び付けようとすると、結果は良くありません。

人々はシステムを操作しようとします。

私があなたが求めていると思うのは：

動作し、バグの少ないコードを人々にデプロイしてもらいたい
一貫してそれを行う人に報酬を与えたい

あなたのシステムはどちらも達成しません。

テストが失敗するかどうかに人々の給料を結びつけることで、テストを書く意欲をそぐことになります。せいぜい何の利益ももたらさず、最悪の場合給料を制限するようなコードを書く人がいるでしょうか? 全体的なインセンティブは、テストベッドのサイズを最小限に抑えることです。これにより、失敗の可能性が最小限に抑えられます。

これは、あなたが知らないバグを除いて、より多くのバグを取得することを意味します。

また、バグを防止する人ではなく、バグを導入した人に報酬を与えることも意味します。

基本的に、目的の反対を取得します。

score 0 · Accepted Answer

これらは、あなたの4つの具体的な質問に対する私の最初の考えです:

これはトリッキーです。一見問題ないように見えますが、コードが単体テストに合格した場合、開発者が不正行為を行ったり (以下を参照)、テスト自体が間違っていたりしない限り、これをどのように実証するかを理解するのは困難です。
これが最善のアプローチのようです。すべての関数には単体テストが必要であり、コードを検査することで、存在するものと存在しないものを明らかにできる必要があります。ただし、1 つの欠点として、開発者が空のテスト (つまり、実際には何もテストせずに「合格」を返すだけのテスト) を作成することがあります。これを見つけるには、長いコードレビューに投資する必要があるかもしれません.
どのように品質を評価しますか？誰が品質を評価するのですか？これは、QA チームが非常に熟練した独立した開発者にアクセスできることを前提としています。
何か (コード行、書かれた単体テスト) の数を数えることは、初心者ではありません。開発者は、無駄なテストを大量に書くだけです。

私はoxbow_lakesに同意し、実際、これを書き始めてから出てきた他の回答にも同意します.ほとんどの形式の測定は、開発者によってゲーム化されるか、さらに悪いことに憤慨するでしょう.

score 0 · Accepted Answer

主観的ではありますが、開発者のパフォーマンスを測定する唯一の方法は時間だと思います。

1 つの会社で十分な時間を与えられれば、優れた開発者が目立つようになります。プロジェクトリーダーは、誰が最高の資産であるかを知っています。十分な時間があれば、悪い開発者が暴露されます。残念ながら、そこには究極の問題、十分な時間があります。

score 0 · Accepted Answer

基本的な心理学 - 人はインセンティブを求めて働きます。ボーナスを得る/仕事を続ける/私が書いたテストの数に基づいている可能性が何であれ、私は無意味なテストを大量に書くでしょう-おそらく、製品を世に出すという本当の仕事を実際に行うことを犠牲にしてドア。

あなたが思い付くことができる他の基本的なメトリックは、同じ問題に悩まされ、同様に無意味です.

開発者を「評価」することを主張する場合は、もう少し横的なものを使用できます。おそらく、MS 認定試験のいずれかで得点します (これには、人々を訓練するという副作用があります)。少なくともそれは客観的であり、中立的な第三者によって独立して検証されているため、「ゲーム」することはできません. もちろん、そのスコアはチーム内でのその人の有効性とは似ていませんが、恣意的な内部測定よりは優れています.

また、ある種の複雑さ測定ツール (単純な方が優れている) を使用してコードを実行し、その結果を採点することを検討することもできます。繰り返しになりますが、それは人々がより良いコーダーになるのを助ける効果があり、それはあなたが本当に達成したいことです.

score 0 · Accepted Answer

アッシュかわいそう…

管理職の無知を利用して、まったく関係のないことを推し進めたことは称賛に値しますが、実行可能な手段を考え出す必要があります。

ばかげていない、または簡単にゲーム化されていないパフォーマンス測定を思いつくことはできません. 単体テストでは変更できません。Kopecks と Black Market は数分でリンクされたので、個々のパフォーマンス測定を必要としないための手段を提供したいと思います。

まず、ソフトウェアは相反する目標の間の最適化です。それらの 1 つまたはいくつかを評価すること (QA 中にいくつのテストが行われるかなど) は、最終製品を損なう他の領域での深刻なトレードオフにつながります。

第二に、チームワークとは、数人の個人が結びついた成果物以上のものを意味します。相乗効果は、個人の努力やスキルにまでさかのぼることはできません。チームでソフトウェアを開発する場合、相乗効果は非常に大きな影響を与えます。

第 3 に、ソフトウェアの総コストは時間が経ってから明らかになります。メンテナンス、スケーラビリティ、新しいプラットフォームとの互換性、将来の製品との相互作用はすべて、かなりの長期的なコストを伴います。短期的なコスト (前年比、または生産へのリリース) を測定しても、長期的なコストはまったくカバーされません。

各開発者に同僚に「投票」してもらいませんか? 昨年、私たちの目標を達成するのに最も貢献したのは誰ですか? 彼らのパフォーマンスを判断する際に、(どうやら - 彼らのマネージャーまたはリードとして)あなたを信頼してみませんか?

unit-testing - 開発者のパフォーマンスの測定に関するもう 1 つの問題

14 に答える 14

Related

Reference