ストーリーポイントを平均より4〜5倍増やしていますが、バグの発生率は半分です。グラフによれば、それはさらに2倍のバグだという。

そのため、トップレベルのプログラマーは、平均的なピアよりも1 桁以上優れたコードを生成できると一般に受け入れられています。

また、プログラマーにとって、コードで発生するエラーの割合は比較的一定であることも一般的に受け入れられています。

代わりに、コードの作成時およびコードの作成後に使用されるプロセスの影響を受ける傾向があります。（私が理解しているように）人間はかなり一定の割合で間違いを犯す傾向があります-優れたプログラマーはそれらの多くに気づくだけで、より迅速に修正します。

• 上記の両方の主張は、Steve McConnellによるCode Completeからのものであることに注意してください。したがって、異なる観点の問題ではありません。

だから私は最近、私のコードでこれを見始めました。私は、（チームが推定したストーリーポイントで測定して）同程度のコードの約4〜5倍のコードを、より高い品質（パフォーマンスメトリックとチェックイン後に行われた変更の数に基づく）で打ち出すことができます。しかし、私はまだ間違いを犯します。優れた単体テストと、コードが何をしているのかをよりよく理解し、コードレビューを行う際の問題に対するより良い目との間で、4〜5倍の数のバグを生成していません。

しかし、QAが発見したバグは、チームの他の開発者の約2倍です。ご想像のとおり、これはメトリック測定を行う技術者以外の人々にいくつかの問題を引き起こします（私のボスを読んでください）

私は、ピアの半分の割合でバグを生成している（そして2倍修正している）ことを指摘しようとしましたが、2倍のバグを生成しているというグラフがあると、それは大変な売りです。

それでは、生産性の向上がバグの増加につながるという事実にどう対処するのでしょうか？

あなたはあなたの懸念を混ぜていると思います。そして、あなたが変更する必要があるあなたの側には何もありません。

生産性は、プロジェクトがどれだけ早く完了するかを示すヒントです。プロジェクトマネージャーと他のすべての人は、プロジェクトがいつ実施されるかを知りたいです。生産性が高いまたは速いということは、プロジェクトがより早く実現されることを意味します。

バグの割合は生産性ではなく、プロジェクトの規模に関係しています。たとえば、コードの行Nごとにバグがある場合がYあります。そのメトリック内には、これらのコード行がどれだけ速く書かれているかを示す（または気にする！）というものはありません。

それを結び付けるために、生産性が高い場合は、はい、バグをより迅速に「見る」ことができます。ただし、プロジェクトのサイズに関係しているため、とにかくその数のバグが発生することになります。

どちらかといえば、生産性が高いということは、プロジェクトの終わりにそれらのバグを追い詰める時間ができるようになることを意味します。¹

あなたの質問のより個人的な側面に対処するため。

上司が、発生するバグの割合ではなく、発生するバグの数を厳密に見ている場合は、教育セッションが適切に行われています。作成されたバグの数は、支持率がなければ意味がありません。

その例を極端に取り上げるには、上司に給料を2倍にすることを伝えてください。どうして？私はあなたのプロジェクトにバグをまったく作成していません。したがって、私はあなたよりもはるかに優れたプログラマーです。何？彼はあなたのプロジェクトに利益をもたらすコードを一行も作成していないという問題を抱えているでしょうか？あ。これで、レートが重要である理由がわかりました。

チームにはストーリーポイントごとにバグを評価するためのメトリックがあるようです。それ以外の場合は、作成されたバグの生の数で測定されるよりも優れています。最高の開発者は、より多くのコードを記述しているため、より多くのバグを作成する必要があります。上司にそのグラフを投げるか、少なくともその背後に別のシリーズを投げて、バグの数とともにストーリーポイントの数（または測定するビジネス価値）を示します。そのグラフは、より正確なストーリーを伝えます。

¹ _{この特定のコメントは、意図したよりもはるかに注目を集めています。それで、少しつまらなくて（驚き、私は知っています）、この質問への焦点をリセットしましょう。}

_{この質問の根本は、マネージャーが間違ったものを見ていることです。生成率と完了したタスクの数を調べる必要があるときに、生のバグの合計を調べています。「コードの行」やストーリーのポイント、複雑さなどを測定することに執着しないでください。それは目前の質問ではなく、それらの心配は私たちをより重要な質問からそらします。}

_{OPによるリンクに記載されているように、プロジェクトのサイズだけで、プロジェクトの特定の数のバグを予測できます。はい。さまざまな開発およびテスト手法により、このバグの数を減らすことができます。繰り返しますが、それはこの質問のポイントではありませんでした。この質問を理解するには、特定のサイズのプロジェクトと開発方法論について、開発が「完了」すると特定の数のバグが発生することを受け入れる必要があります。}

_{最後に、いくつかの完全に誤解されたこのコメントに戻りましょう。同じサイズのタスクを2人の開発者に割り当てると、生産性の高い開発者が他の開発者より先にタスクを完了します。したがって、より生産性の高い開発者は、開発期間の終了時により多くの時間を利用できます。その「余分な時間」（他の開発者と比較して）は、標準の開発プロセスに浸透する欠陥の処理など、他のタスクに使用できます。}

_{私たちは、他の開発者よりも生産性が高いという言葉をOPに受け入れなければなりません。それらの主張の中には、OPまたは他の生産性の高い開発者が彼らの仕事にスリップしていることを暗示するものはありません。機能により多くの時間を費やした場合、バグが減ることを指摘するか、デバッグがこの開発時間の一部ではないことを示唆すると、求められているものを見逃します。一部の開発者は他の開発者よりも高速であり、同等以上の品質の作品を作成します。繰り返しますが、OPが質問で示しているリンクを参照してください。}

コードのクリーニング、研磨、およびテストに余分な時間を費やしてください。まだ間違いはありますが、少ないでしょう。それには時間がかかります。コード出力率は低下しますが、バグのないコード出力が増加し、生産性が向上します。バグは高価だからです。

コードを蹴ってさらにバグを見つけるまで、ブランチまたはテスト環境にコードを保持できますか？一般に、ブランチのバグは、本番コードのバグよりも少ない波を引き起こします。

しかし、私はあなたの質問につながるあなたの主張を正確に掘り下げているわけではありません。そして、おそらくあなたの上司もそうではありません。

すべてのコーダーが同じエラー率を生成するとは思わない。2番目のリンクは、異なるコーダースキルレベルではなく、異なる言語を比較しているため、実際には完全にトピックから外れています。完全なコードは、コーダーのスキルではなくプロセスを検討している大規模なサンプル測定値に言及しています。そして、トップレベルのコーダーがより多くの/より良いコードを生成すると言うとき、その一部はバグが少ないことを意味します。アプリケーションに依存します。だから、そう、私はそれが異なる視点の問題だと思う。

最終的には、上司がよりきれいなコードを望んでいる場合、彼にきれいなコードを与えます。

私は四肢に出て、悪魔の擁護者になります。それは私があなたの苦境に同情しないと言うことではありませんが、まあ、私の同情はあなたを助けません。それで、私はフィリップの視点に追加させてください：

上司は製品の品​​質に関心があります。これは、部分的には彼の名前と評判がそれに結びつくためです。品質の一部は、知覚されるバグの量です。競合するドリルの4倍の速さで、しかも2倍の頻度で分解する素晴らしいドリルを販売している場合、評判は悪くなります。ドリルのパフォーマンスが優れていると言っても、人々はスピードに慣れますが、故障を覚えています。

後から考えると、ほとんどのバグは明らかに予防可能です。 あなたがもう少し注意を払っていれば、上司はこれらの問題と必要なクリーンアップを回避できると感じます。彼の観点からは、それは取るに足らない、感覚的なことであり、それについてあなたが主張することは、うまくいかず、見た目が悪くなります。

彼はあなたの優れた生産性を測定することはできません。 検証可能なメトリックに基づいて生産性が向上すると主張しますが、同僚はそれについてどのように感じていますか？彼らはあなたがより生産的なプログラマーであることに恐らく不承不承に同意しますか、それともあなたはあなたの意見で一人ですか？アサーションをバックアップする他の人がいる場合、あなたはより強力なポイントになります。

それは見方です。さて、あなたはこの苛立たしい状況をどのように「修正」するのでしょうか？

少し遅くしてください。 バグ率（*）を下げようとするタスクを配布する人に明示的に言及してください。そうすれば、摂取量の低下に驚かないようにできます。どちらかといえば、速度を落とすことで、供給不足からあなたに割り当てられるバグの数を減らすことができます。

_{（*）がありそこにいることを認め、一方では、違いますしているあなたが持っていることを認め、一方で、自分の名前のバグが、あなたはその金額を軽減しようとするでしょうということと、あまりにも多くのあなたの名前にバグをし、すべき行動を起こす。}

上司を説得しようとしないでください。うまくいかないからです。繰り返しますが、それはあなたが自分の主張を認めなければならないという意味ではありません。あなたは彼の懸念を却下することなく、対抗点を提示し、あなたの意見を保持することができます。論点を主張し、優れた生産性を十分に証明できない場合（できたとしても）、同僚をs辱したり、同僚を軽missしたりするリスクがあるためです。あなたはその男になりたくない。

同僚と同じ「量」のコードを20％の時間で生成すると仮定すると、コードの実際のデバッグと完璧化に4倍の時間を費やすことができ、バグ率がさらに低下します。それからあなたは自分を優秀なプログラマーと呼ぶことができます。

最大の問題は、品質を目指すのではなく、他のコードの5倍のコーディングをする理由です。これはあなたのエゴがあなたに指示するものですか、それともあなたの上司があなたに強制するものですか？

また、バグを修正するためのコストを考慮する必要があります。早期に見つけた場合でも、コードをすばやく「修正」するのに十分な「内部」にある可能性があります。それが開発の別の月後にのみ表示される場合、すでにプログラムされているコードの大きな部分を変更することを見つけること、または強制することさえ難しい場合があります。

あなたはコードを生成するスキルセットを持っているようであり、スピードではなく品質に焦点を当てれば、それを素晴らしいものにすることができます。しばらく試してください、あなたはそれを好きになるでしょう。

次の問題は、パフォーマンスを向上させるための承認（お金を話す）を取得することです。上司と話をして、どうすればいいかを尋ねてください。それは結局彼の会社とお金です。もし彼があなたにバグを減らしたいなら、彼はそれがどのように起こるかを決めるべきです。

開発者は、優秀な開発者でなくても、ソロを理解し、コーディングする能力を備えた、明るくて天才でもあります。優れた開発者は質の高い作品を作成し、プロジェクト全体を改善します。

私はこれがあなただと言っているわけではありませんが、私がこれまで働いた中で最もイライラするプログラマーの1人は、チームの誰よりも多くのコードを書いており、チームには良い人がいました。ランク付けソフトウェアを使用してコミットを追跡したため、一部の人々にとってはほぼ競争でした。彼はコードの山をかき混ぜ、ゼロのドキュメント、不可解な森林を残し、実際に私自身のコードのいくつかを理解するのを難しくしました（私はそれを自分で行うことができます、ありがとうございました！）彼は一人のショーになったので、最終的に彼はプロジェクトをほとんど脱線させました。人々は彼をフォローできませんでした。私たちはチームとして同期していませんでした。実際、保守性を取り戻すために、彼の機能のいくつかを数年後に書き直しました。

彼に求めていたのは、スローダウンしてより多くの時間を費やすことでした：1）コードベースの品質を向上させる2）チームとコミュニケーションをとる3）他の人を助け、機能/ストーリーを完成させるのに役立つものに取り組む4）修正虫

コードの行で生産性を測定することには同意しませんが、それは重要な指標です。コードカウンターにコメントが含まれていますか？その場合、「バグ率」を減らしながら、ライン出力を維持する簡単な方法があります。書くコメントの質と量を増やすだけです。コメントにバグが含まれることはめったにありません（バグは可能ですが）。一般的に、十分な品質のコメントはありません。私はコードインフレーションを容認していませんが、コメントする行為はミニコードレビューのようなもので、考えさせ、リファクタリングし、改善させます。

管理を啓発しようとすることは、初心者ではありません。古い決まり文句があります、「あなたは私またはあなたの嘘の目を信じますか？」上司に関係するのはバグの数です。合理化の量は彼らにそれが許容可能であることを伝えません。リスクは2倍以上です。さらに、バグカウントの影響を受けるのはあなただけではありません。QAには、バグを特定しようとする作業が2倍あるため、管理者はバグを少なくすることを望んでいます。

最善の解決策は、発生するバグの数を減らすことです。管理がより楽しくなるだけでなく、あなたもそうなります。しませんか？あなたが4倍に同僚を上回る誇る楽しむように私は限りかなり確信している原因、あなたは思い愛する彼らがバグよりも、あなたはそれがさらに少ないの同じ数を作る、または行うと言うこと。

あなたが述べたように、「...コードで発生したエラーの割合は...コードの作成時およびコードの作成後に使用されるプロセスの影響を受ける傾向があります。」バグを生成する割合を変更する場合は、コードの作成に使用するプロセスを変更する必要があります。

アセンブリラインがメソッドを使用して大量生産オブジェクトを生成するように、プログラマは生産メソッドを使用してコードを生成します。さて、ソフトウェア業界の慣行は、森の中にある枝から小物を削るようなものです。しかし、機械を製造しているので、大量生産の高速機械に使用されるのと同じ厳密さと規律を採用する必要があります。

これには、欠陥率を減らすために大量生産で使用されるのと同じ技術が含まれます。バグの原因を特定する根本原因分析と、バグが発生しないようにプロセスを変更します。または、少なくともQAの前にキャッチすること。

1. バグのリストを作成します。おそらく、QAの皆さんのおかげで、すでに1つ感謝しています。おそらく分類されます。バグのタイプ、重大度、バグがコードに挿入されたポイントなど。

2. バグの最大のカテゴリを選択してください。ボリュームが非常に大きいため、最初にそのカテゴリをターゲットにする必要があります。他のカテゴリには、見つけやすいものと作成しやすいものがあります。

3. これらのバグがコードのどこに導入されているかを把握し、それらのバグの発生を防ぐその段階（およびそれ以前）での変更の実施、およびその段階でのバグの発見を容易にする方法を検討します。

4. プログラミング以外の関連する偶発的な出来事に注意してください。また、作業の質に違いが生じる可能性があります。バックグラウンドミュージック、中断、食事時間、休憩なしの長時間の作業、空腹など

あなたが見つけたものはあなたが遅くなるように導くかもしれません。一方で、すでにあなたの後ろに置いたものを手直しする必要が少なくなるので、それはあなたがさらに速く生産するのを助けるかもしれません。現状では、4倍のコードが同僚より1桁優れているとは言えないため、プロセスを変更することが最も確実な方法です。

目標を、最も多くのコードを作成することから、会社が最も前進するのに役立つように変更します。

多くの同僚と余分な時間があるように見えるため、機能とバグ修正の迅速な提供に最も効果があるのは、同僚を助けることです。

同僚を助ける

• コードレビューを使用してコードの品質と教育を改善する。
• 彼らの仕事をより速くし、彼らの生活をより簡単にするプロセス自動化を作成します
• 彼らとより良いテストを書く
• 技術的なコードを攻撃してコードベースを改善する
• 他の人を助けるために常に利用できる頼れる男であること。
• 開発者の生産性を高めるツールの作成/改善
• あなたがより多くの影響力を持っている場合、あなたの同僚のためのより良いツール/機器/労働条件のための管理で主張する。
• より良いコードを書くための教育セッションの準備と指導。
• 謙虚さの練習

それでは、生産性の向上がバグの増加につながるという事実にどう対処するのでしょうか？

あなたの場合、これに答えることができるのは上司だけです。彼と話して、あなたのより良い比率を指摘し、彼に決めさせます。彼の決断が意味をなさない場合は、あなたの考え方で会社を探す時です。

専門家として、あなたはどんなクライアント条件でも働くことができるべきです、ただ彼らが結果を理解することを確かめてください。優れたバグ/ストーリーチャートは、上司がバグを少なくするために時間をかけると生産性がどれだけ低下するかを理解するのに役立ちます。

また、次の点を考慮する必要があります。

• ストーリーの複雑さ。たとえば、単純なゲッター/セッターラッパーと統計計算、リアルタイムプログラミング、さらにはリアルタイム統計...
• バグの重大度、それはテキストフィールドの小さなタイプミスか間違った計算結果、プログラムクラッシュ
• バグを修正するのにかかる費用は、今すぐ、後で行う場合、または他の誰かがあなたのコードを理解する必要がある場合の両方

状況としては、平均的なプログラマーの4倍の速さで作業していますが、一定の時間内に2倍のミスを犯しています。あなたが行う仕事の量に比べて、実際には「平均」と同じくらい多くの過ちを犯します。

作業ミス率の低いミス、または完成した製品（通常の4分の1の時間で完了できる）へのミスを指摘しようとするかもしれません。ほとんどのボスはそれを受け入れます。

彼らは時間ごとにミスの「許容」マインドセットで動作するため、そうしないいくつかのボスがあります。その後、一定の時間内に平均して2倍の作業を行い、作業ペースを遅くし、作業を確認する時間があるため、同じ（または少ない）間違いを犯す可能性があります。

上司があなたに仕事の質を向上させてほしいなら、仕事の質を向上させてください。

次善のプログラマの2倍の生産を目指しているのではなく、バグをゼロにすることを目指してください。

上司に、彼が使用している指標にかなり欠陥があることを伝える必要があります。NBAの警備員の売上高を見ると、フォワードよりも数字が高い傾向があることがわかります。しかし、それは彼らがより多くのボールを扱っているからです。開始ガード以外のガードが開始ガードの1/5をプレーし、平均.vsで3回以上ボールを回した場合。ゲームごとにボールを7回以上回転させるスターティングガード-一見すると、スターティングガードが悪いように見えます。しかし、ターンオーバーの数をプレイした分数で割ると、明らかに、開始ガードはプレイした分に基づいてはるかに良い数字を持っています。

同様に、バグの数を完了したストーリーポイントの数で割ると、はるかに優れた数になります。だから、それは私があなたの上司に提案するものです。完了したストーリーポイントで割ったバグの数になるようにメトリックを変更するか、開発者ごとのバグの総数が必要な場合は、少なくともこのための新しいメトリックを追加します。ただし、一部のストーリーポイントは他のストーリーポイントよりもはるかに難しく複雑であるため、かなりのばらつきが生じる可能性があります。また、これもマネージャーが考慮する必要があります。

私はあなたがすべきだとは思わないことは、減速することです。

測定値の追加

本当に重要なのは、あなたが追加する価値だと主張します。次に、その大まかな（手動）測定を紹介します。

• 作成する機能の価値を見積もる
• 給与を引きます
• バグの推定コスト（少なくともそれらを修正するためのコスト）を引きます
• あなたが生産する他のすべての技術債務の推定コストを引きます

残りはあなたの付加価値です。同様に他の皆のために。

これらの推定は難しいですが、大まかなものでさえ重要な場合があります。そして、これらの推定値を議論する単なるプロセスは、チームとプロジェクトにとって有用です。

トッププログラマーは、デバッグと理解が容易な非常に定期的なコードを書く傾向があり、利用可能なツール（静的分析、コンパイラーエラー、デバッグコード）を最大限に活用します。また、トッププログラマーは、自身のハードエクスペリエンスを通じてユニットテストの価値をすでに学びました。

したがって、1行あたりの問題の初期量は同じですが、問題はより早く除かれます。