組織は、開発者が取り組んだコードに対して提出された欠陥レポートの量に対して開発者にペナルティを科すべきですか？
組織は、開発成果物に対して提出された欠陥報告に対して開発者にペナルティを科すべきですか？
私は友人と話し合っていました。そこで彼は、開発者に対して提出された欠陥の数をとるマネージャーを正当化するかどうか彼に尋ねました。開発者は欠陥を持ち込むことができるので、私の見解は違いますが、欠陥を彼に対して保持することは、開発者の心に不必要な否定的な感情を引き起こす可能性があります。
開発者が注入する欠陥に基づいて開発者にペナルティを課すことの問題は何ですか？あなたの組織は、作業成果物に欠陥を作成したことで開発者を罰しますか
それは良いよりも害を及ぼすように聞こえます。マネージャーがそれをすることが公正であるかどうか少しの間無視して、ロジスティクスを見てみましょう...
問題1：すべてのバグは同じですか？
開発者1はバグを導入します：すべての顧客データを消去し、それらを呪います。
Developer 2は2つのバグをもたらします。フォームのラベルが左揃えにならず、2つのうるう年にまたがるイベントが作成されると、カレンダー機能が1秒ずれます。
明らかに、開発者2はバグ率が2倍になっているため、マネージャーからの悲しみに値するものです。もちろん、そうではないので、あなたはバグ評価システムを考え出します。そうすれば、ささいなバグのある開発者はそれほど難しくありません。しかし、待ってください。同じ些細な間違いを繰り返し繰り返し、テスターの時間を無駄にしている開発者が、間違いから学ばないため、システムは修飾子を考慮に入れるべきでしょうか？たぶん。これは複雑です。
問題2：バグと見なされるもの
マネージャ-このレポートには、現在の合計が含まれるはずでしたが、これはバグの1つです！
開発者-これは要件に含まれていませんでした。これはバグではなく機能です。
問題3：どのようにしてバグをグループ化しますか？
Developer-"[Manager's Name]、テスターは、10の異なる画面で速度が正しくなかったため、私に対して10のバグを報告しましたが、すべてgetVelocity関数の単一のバグに関連していました。私たちはそれについて3時間議論しましたが、彼らはびっくりしません。私たちはあなたと一緒に座って、いくつのバグを報告すべきかを決めることを望みます。ああ、ところで、私たちが攻撃する方法はありませんコードは明日完全な期限です。」
問題4：SLOCの増加はおそらくバグの増加を意味する
開発者1は終日彼のお尻に座っていますが、アリゾナ州の移民法をめぐってRedditの引数の間にバグのないコードを3行書くことができました。
開発者2は終日懸命に働き、John Connorが最初に得たチャンスを殺さない、完全に機能するAIを生み出します。 "
明らかに、革新によってより多くの進歩を遂げたり、より多くのリスクを負ったりする開発者にペナルティを課したいのですよね？
概要
これらのいくつかにはおそらく実行可能な解決策がありますが、締め切りに間に合うように努めるプログラミングチームのマネージャーとして、何がバグで何が重要で何が個別であるかについて議論することに時間を費やしてもらいたいと思います。バグ、バグの重要性など？これらはプロジェクトを前進させるものではありません。これは、作成される実際のソフトウェアに意味のある影響を及ぼさない問題で競争することを余儀なくされるチームにとって有害です。すべての従業員の過ちを細心の注意を払って記録し、後で顔を返せるようにする方法を見つけることに多くの努力を集中させることが、従業員の文化にとって何をしているのかは言うまでもありません。
必然的に、開発者はテスターにバグ追跡システムを回避して問題を直接報告し、「パーマネントファイル」に入らなくても問題を修正できるようにします。そうすれば、バグや人々が実際に取り組んでいることを正確に把握することさえできません。
次に、悪影響の問題があります。それは人事の話です。特に財政的に、従業員にペナルティを課す前に、かなり良いドキュメントを持っている方がいいです。そして、それらのいずれかが保護されたクラス（マイノリティ、退役軍人、女性、障害者など）である場合、セットアップしたシステムがそのクラス（またはそのクラス）のメンバーシップに基づいてそれらのいずれかを差別しないことを3倍確認することをお勧めしますたとえそれが計画の意図しない副作用であっても、裁判官はそのように確信することができます）。
つまり、最終的には、少ないバグを作成するインセンティブを作成するのではなく、困難です。バグの重要性を最小限に抑えるか、他の人に非難することで、バグを取り除いてください。
ショートバージョンいいえ。
プログラマーは、マネージャーがやりがいのあるものを最適化することで悪名高くなっています。 LOCに報いる場合、コードメトリックの行を埋めるために多くの空白を取得します。バグカウントで罰しようとすると、開発者がXがバグではないバグではないという戦争に陥ります（バグはコンパイラにあります）または [〜＃〜] api [〜＃〜] または他のどこか）-そして、それらに対して提出されたバグは間違っています。
私が最後に働いた場所には、製品の「担当」開発者がいました。 「担当」の開発者は何年にもわたって変化することはありませんでしたが、季節的な負荷が必要になったときに他の開発者がプロジェクトに取り組みました。誰も指を指して「あなたはそのバグを書いた！」代わりに、製品のバグを減らすことが目標でした。
バグのペナルティがあった私が働いたことのある場所でも、非常に高いターンオーバーがありました。指で指すことは、開発者の離脱につながった敵対的な環境に貢献しました。
開発者は、自分が作成するコードの品質について責任を負う必要があり、マネージャーが同じことを行うことを期待する必要があります。しかし、それは、バグが報告されるたびに一部の開発者が減点を受ける必要があるという意味ではありません。彼らの正しい心のマネージャーは誰も言うことはありません：
さて、ジョンソン、先週500行のコードをチェックインしましたが、これまでに241のバグレポートがそのコードにトレースされています。
小さな欠陥ごとに誰に責任があるかを突き止めるのは大変な作業であり、バグレポートの数は常にコードの品質について多くを伝えるとは限りません。しかし、優れたマネージャーは問題に気づき、それらを修正する方法を見つける必要があります。彼または彼女は言うかもしれません：
ジョンソン、それは先週のチェックインの1つの悪臭でした-私たちは通常の3倍の速度でバグレポートを受け取っています。私たちはその修正をできるだけ早く取得する必要があるため、私は「イーグルアイ」ファーガソンにコードを一緒に検討するように依頼しました。きっと二人はそれを理解するだろう。そしてイーグルアイは途中でいくつかのトリックを見せてくれるかもしれない。
すべての開発者は、コードの一般的な品質を含め、マネージャーがパフォーマンスに気付くことを期待するべきです。開発者は、同僚にも気付かれるはずです。結局のところ、それはすべてリポジトリ内にあります。ですから、あなたがバグ数の多い人なら、恥ずかしがらずに助けを求めてください。チームの残りのメンバーは、あなたがどこにいるかをすでに知っていると思います。チーム（およびマネージャー）を改善するために協調して努力すると、そのことに気づくでしょう。
したがって、yes、作成したコードに対して責任を負う必要がありますが、no、組織は、特定の欠陥について、またはいくつかの欠陥レポートを超えることについて、個々の開発者にペナルティを課すというポリシーを持ってはなりません。これは、指を向けたり、生産性が低下するほど注意を払ったりするなど、責任を回避する方法を人々に見つけるように促すだけです。人々が彼らが書いたものに対する責任を受け入れることを恐れているなら、それは開発努力を助けません。ところで、それは それを好転させ、特定のバグ修正に報いるのに役立ちません 。 ;-)
いいえ、できません。これは手作業ではなく、意図的にバグを作成するものではありません。悲しい恐怖のプログラマからどのように生産性を期待できますか？彼の周りは物事がクールでなければなりません。最終的に、ペナルティを課すことから利益を得る人は誰もいません。 
これは悪い考えでありながら、敵対的な職場環境を作り出すことはほとんどありません。
私は、職務遂行の動機としてANY NEGATIVE REINFORCEMENTが不幸な労働力と高い離職率を生み出すとまで言ってもいいでしょう。優れた開発者でさえ、滑りにストレスを感じるでしょう。
負の補強は子供や犬にとっても侮辱ですが、なぜあなたはそのような方法で専門家を扱いますか？
代わりに、低い欠陥数にポジティブな援軍を使用し、苦労しているチームのメンバーを積極的に支援してください。長期的に誰かとうまくいかない場合は、そのままにしておいてください。
私はここで傾向を覆し、手足を伸ばし、響きのあるYES！を与えますが、特定の資格があります。少なくとも、標準偏差が同僚よりも悪い開発者のみです。
ここにいくつかのロードされた問題があるので、少しそれを分解してみましょう。まず、「ピア」という言葉です。 10年のベテランの仕事と大学を卒業したばかりの新入社員の仕事を比較することは確かに正しくありません。初心者は経験が少ないですが、プロにはより難しい割り当てが与えられます。
次は標準偏差です。プログラマーは歴史的に、一方ではメトリックスのゲーミングの主張で自分たちの仕事の定量的測定の試みに抵抗し、他方ではソフトウェアを通じて定量化できないものを定量化する方法を毎日実践する技術を実践し、ロックスタープログラマーのXに関するメトリックスを引用します平均よりも倍の生産性。両側にいくつかの明白な真実があります。
私の信念は、「コード行」のような単純なものでさえ、使用のベストメトリックは目立つものを識別するためのものであるということです。標準偏差の境界を標準から1〜2離して設定し、個々のプログラマがパックから抜け出すことができないようにします。トップまたはボトムのプログラマーを探してはいけません。ここでの要点は、ほとんどの場合、誰も特定されないため、ゲームするものは何もないということです。しかし、時々それはあなたがプログラマーのその宝石を見つけるのを手助けするか、またはあなたの本当のパフォーマンスの悪い人が誰であるかをあなたに教えるでしょう。そして、あなたはあなたが何をすべきか知っていますか？ なし。少なくとも最初は。代わりに、それを未確認の知性と考えてください。情報を使用して人を監視し、他の場所で確認します。
同僚よりもはるかに頻繁にバグをチェックしているプログラマーがいる場合は、まず彼の全体的なパフォーマンスを裏付けるものを見つけてから、彼と話をします。そして初めて、それはおそらくただの話であるべきです。
組織が提出されたバグの量に対して開発者にペナルティを課すと、開発者はそれらが相当であると想定してペナルティを回避するために生産性が低下する可能性があるためです。また、QA担当者がここで別の要因であるバグの構成要素について寛大な見方をしている場合があるため、開発者に対してどのようなバグが提出されるかについても矛盾が生じる可能性があります。ペナルティのバランスをとろうとすることもできますが、それが実際にどれほどうまく行われているかを知りたいと思います。
私の元同僚は、この慣行が実際に実施された場所の話を私に話してくれました：開発者はコードで見つかったバグごとに罰せられ、発見したバグごとにQAが報われました。その結果、ペナルティから自分自身を保護する唯一の方法であったため、開発者は新しいコードの開発を単に停止しました。
開発者は、何が最善であるかについて怠惰で無知ではありません。私の意見では、プロジェクトの開始前に、開発者により多くの正確なタイムラインとより優れた仕様を与えることは、より生産的だと思います。
絶対にありません。
病気や怪我がどれほど深刻であるかを考慮せずに亡くなった患者がいるため、医師を降格させるようなものです。
欠陥が避けられないプロジェクトもあります。ニーズの競合、セキュリティガイドラインと競合するユーザー要件のあるプロジェクトスポンサーがいる場合、最後の変更がなくても、コードの品質に関係なく欠陥が発生します。
また、（少なくともほとんどの大規模組織では）周囲のインフラストラクチャの永続的な問題もあります。 OSのV3.8でデータベースのV1.25をコーディングしますが、稼働する直前に別の部門がV2.0およびV4.0にアップグレードします。 （または、ダウングレード、あるケースでは、アップグレードをキャンセルするためにV5.0 J2EEのみをコーディングし、リリースの前にV4.0までデファクタリングする必要がありました-多くの欠陥がありました。）.
最後に、官僚的な負担が大幅に軽減されるため、変更要求ではなく欠陥を提起する実用的なユーザーがいます。
いいえ。根本的な問題ではなく、症状を治療しようとしているように聞こえます。コードの一部に存在するバグの数とそれらを導入した人に焦点を合わせるのではなく、まずバグを排除するのに役立つシステムの開発に焦点を当ててみませんか？
単体テスト、統合テスト、テスト駆動開発、静的コード分析、デザインレビュー、コードレビューなどのツールは、多くの場合、コードベースに入る前にかなりの数のバグをキャッチできます。継続的インテグレーションは、問題を後でなく早期に特定するのにも役立ちます。
ところで、OPの質問に対する論理的なフォローアップ：バグが詰まったコードを継承した場合、残りのすべてのバグを修正すると、ペナルティが課されますか？元の命題では、コードに取り組んだので、今はバグの責任があります。
開発者の欠陥率にペナルティを課す動機は何ですか？
確かに目標は、開発者が記述しているコードのqualityを試して測定することです。
問題は、品質は少し不定形です。測定するのが本当に難しいです。実際、それを直接測定することはできません。他のものを測定することによってそれを試して近似する必要があります。
また、＃欠陥などの単一のKPIを選択すると、システムのゲームが発生します。各開発者に欠陥ごとに10ドルのペナルティを課すことを提案した場合、開発者の1人がテスターと契約するまでにどれくらいの時間がかかると思いますか...欠陥ごとに5ドルを支払いますログに記録されないことについて教えてください。
コードに関連するすべてのバグを再度担当させ、テスト部門からの苦情を転送します。バグが少ない方が良いことを彼らはすでに知っているはずです。
そして、すべてが順調に進み、バグレポートが届かない場合は、報酬として背中に手をたたくと、いくつかの親切な言葉が残りを行います。
それらを数えるのは間違いだと思います。あなたがそのようなものを数にまで粉砕することができる方法はありません。ただし、特定の開発者のコードに他の人が作成した同様のコードよりも多くの問題があり、これが一貫したパターンである場合、開発者はおそらくそれほど良くはなく、他のすべての条件は同じです。ミックスに入れるのは事実です。
いずれにせよ、私はこのビジネスに何十年も携わっていますが、異常に高いまたは異常に低いバグ率を持つプログラマーを見たことはありません。高速または低速のプログラマー、仕事を成し遂げるプログラマー、または問題が発生したプログラマーを見てきました。プログラマーが自然に非常に理解しやすいコード、非常に高速なコード、または非常に混乱するコードを書くのを見てきました。しかし、異常に高いまたは低いバグ率を持つプログラマーを見たことがありません。たぶん私は十分に注意を払っていませんでした。
私はこの考えに反対していませんが、欠陥について合意が得られている場合に限ります。欠陥を支配する上級技術者の指定されたグループです。多くの場合、ユーザー、BA、およびマネージャーは、コードの欠陥とは何かを決定する資格がありません。このようなものを1人（または任意）の個人の管理下に置くことは常に危険です。
しかし、私はそれが本当に必要であるとは思いません-開発者が一貫して悪いコードを書いているとき、彼の先輩と同僚が彼らの仕事をしているなら、それは長い間秘密ではなく、開発者は正式なシステムで結果に苦しむでしょう「デメリット」。
前提には同意しませんが...
技術的にやりがいのある機能も備えたプログラマーに「より高いリスク、より高い報酬」と報酬を与えた場合にのみ、それが実現可能になるでしょう。それ以外の場合、技術的な課題は責任（報酬の機会ではない）であるため、プログラマーがその環境で困難な作業を行う理由は何ですか。
それが非常に敵対的な環境を作り出すことにも同意します。私の経験では、かなりの量の欠陥は、要件のあいまいさまたは要件の欠如が原因です。そのため、これらの欠陥がビジネスアナリスト、システムエンジニア、またはプロジェクトスポンサーに明示的に割り当てられる可能性もあり、それらも同じペナルティの対象となるはずです。これは悪いことではありません。