ストーリーポイントを平均より4〜5倍増やしていますが、バグの発生率は半分です。グラフによると、バグは2倍多いとのことですが、それに対処するにはどうすればよいですか？
したがって、一流のプログラマーは、より一般的なピアよりも 1桁多く/より優れたコードを生成 できることが一般的に受け入れられています。
プログラマーにとって、コードで発生するエラーの割合は比較的一定 であることも一般的に受け入れられています。
代わりに、それは コードの作成時およびコードの作成後に使用されるプロセス の影響を受ける傾向があります。 （私が理解しているように）人間はかなり一定の割合で間違いを犯す傾向があります。優れたプログラマーは間違いをより多く気づき、すばやく修正することができます。
- 上記のアサーションは両方とも、Steve McConnellによる Code Complete からのものであることに注意してください。したがって、異なる見方をする必要はありません。
だから私は私のコードでこれを最近見始めました。ピアの多く（チームが推定したストーリーポイントで測定）の約4〜5倍のコード量で、より高い品質（パフォーマンスメトリックとチェックイン後に行われた変更の数に基づく）で打つことができます。しかし、私はまだ間違いを犯します。単体テストの改善、コードの実行内容の理解、コードレビューの際の問題への目覚しさの間で、バグの数は4〜5倍ではありません。
ただし、QAが見つけたバグは、チームの他の開発者と同じくらいtwiceです。ご想像のとおり、これは非技術者がメトリック測定を行う際にいくつかの問題を引き起こします（上司を参照）。
私は仲間の半分の割合でバグを生成していることを指摘しようとしました（そして、2倍の数を修正しています）が、グラフが2倍の数のバグを生成していると言っている場合、それは売りではありません。
では、生産性の向上がバグ数の増加につながるという事実にどう対処するのでしょうか。
あなたはあなたの懸念を混合していると思います。そして、変更する必要があるyour側には何もありません。
生産性は、プロジェクトがどれだけ早く完了するかについてのヒントです。プロジェクトマネージャーや他の誰もが、プロジェクトがいつ実施されるかを知りたいと思っています。より高いまたはより速い生産性は、プロジェクトがより早く提供されることを意味します。
バグの発生率は生産性に関係しているのではなく、プロジェクトの規模に関係しています。たとえば、コードのN行ごとにYバグがあるとします。それらのコード行がどれだけ速く書かれるかを言う（または気にする！）そのメトリックス内には何もありません。
これを結びつけると、生産性が高ければ、はい、書かれているバグをより迅速に「見る」ことができます。しかし、プロジェクトのサイズに関係しているため、とにかくその数のバグが発生することになります。
どちらかと言えば、生産性が高いということは、プロジェクトの最後にそれらのバグを探す時間が増えるか、開発者が作成したバグをより早く見つけることができるということです。1
質問のより個人的な側面に対処するため。
上司がバグの発生率ではなく、発生するバグの数を厳密に調べている場合は、教育セッションが適切です。作成されたバグの数は、バッキングレートがなければ意味がありません。
その例を極端に言えば、給与を2倍にしたいということを上司に伝えてください。どうして？私はあなたのプロジェクトで絶対にバグなしを作成したので、あなたよりもはるかに優れたプログラマーです。何？彼は、プロジェクトに利益をもたらすコードを1行も作成していないという問題が発生するでしょうか？ああ。これで、レートが重要である理由がわかりました。
チームには、ストーリーポイントごとにバグを評価するための指標があるようです。他に何もない場合は、作成されたバグの数で測定するよりも優れています。あなたの最高の開発者すべき彼らはより多くのコードを書いているので、より多くのバグを作成しています。上司にそのグラフを捨ててもらうか、少なくともその背後に別のシリーズを投げて、バグの数とともにストーリーポイントの数（または測定するビジネス価値）を示します。そのグラフはより正確なストーリーを伝えます。
1この特定のコメントは、意図したよりもはるかに注目を集めています。それでは、少し知識を深め（驚き、私は知っています）、この質問への焦点をリセットします。
この質問の根本は、間違ったものを見ているマネージャーについてです。彼らは、生成率と完了したタスクの数を比較する必要があるときに、生のバグの合計を調べています。 「コードの行」、ストーリーのポイント、複雑さなどにこだわって取り掛かってみましょう。それは目前の問題ではなく、それらの心配はより重要な質問から私たちをそらす。
OPのリンクに示されているように、プロジェクトのサイズだけで、プロジェクト内の特定の数のバグを予測できます。はい、さまざまな開発およびテスト手法を使用して、この数のバグを減らすことができます。繰り返しますが、それはこの質問のポイントではありませんでした。この質問を理解するには、特定のサイズのプロジェクトと開発方法論について、開発が「完了する」と、特定の数のバグが表示されることを受け入れる必要があります。
それでは、最後に、いくつかの完全に誤解されているこのコメントに戻りましょう。同等のサイズのタスクを2人の開発者に割り当てると、生産性の高い開発者が他の開発者より先にタスクを完了します。したがって、より生産的な開発者は、開発ウィンドウの最後に利用できる時間が増えます。その「余分な時間」は（他の開発者と比較して）、標準の開発プロセスを通じて浸透する欠陥に取り組むなど、他のタスクに使用できます。
私たちは彼らが他の開発者より生産的であるという彼らの言葉でOPを取る必要があります。これらの主張に含まれるものは、OPまたは他のより生産的な開発者が彼らの仕事でずさんになっていることを意味しません。機能に多くの時間を費やしたり、デバッグがこの開発時間の一部ではないことを示唆したりすると、バグが少なくなると指摘することは、求められていることを見落とします。一部の開発者は他の開発者よりも速く、同等またはそれ以上の品質の作業を作成します。繰り返しになりますが、OPが質問に提示するリンクを参照してください。
その余分な時間の一部を費やして、コードのクリーニング、磨き、テストを行ってください。それでも間違いはありますが、少なくなるでしょう。それには時間がかかります。コード出力率は低下しますが、バグのないコード出力が増加し、生産性が向上します。バグは高いからです。
コードをキックし、さらに多くのバグをキャッチするまで、コードをブランチ環境またはテスト環境に保持できますか？ブランチ内のバグは、通常、本番コードのバグよりも波の発生が少ないです。
しかし、私はあなたの主張を正確に掘り下げてあなたの質問に導いているわけではありません。そして、おそらくあなたの上司もそうではありません。
すべてのコーダーが同じ率のエラーを生成するとは思いません。 2番目のリンクは、異なる言語のコーダースキルレベルではなく、異なる言語を比較しているため、実際には完全にトピックから外れています。コードコンプリートは、コーダーのスキルではなく、プロセスを見ているいくつかの大きなサンプル測定について言及しています。そして、彼らが一流のコーダーがより多く/より良いコードを生み出すと言うとき、その一部はそれがより少ないバグを持っていることを意味します。アプリケーションによって異なります。だから、そう、私はそれをIS異なる視点の問題だと思います。
最後に、上司がよりクリーンなコードを必要とする場合は、よりクリーンなコードを彼に与えます。
私は手足を出し、悪魔の擁護者になります。私があなたの窮状に同情しないと言っているわけではありませんが、まあ、私の同情はあなたを助けません。ですから、 フィリップの視点 に追加してみましょう：
上司は製品の品質に気を配っています。名前と評判がそれに結びつくためです。品質の一部は、感知されたバグの量です。競合するドリルの4倍の速さで、2倍の頻度で分解できる素晴らしいドリルを販売すると、評判が悪くなります。ドリルの方がパフォーマンスが良いといっても、速度には慣れていますが、内訳は覚えています。
後から見れば、ほとんどのバグは明らかに防ぐことができます。少しだけ注意しておけば、上司は感じるでしょう、これらの問題と必要なすべてのクリーンを回避できます-アップ。彼の観点から見ると、それは取るに足りない、意味のあることであり、あなたがそれについてあなたが主張することは、うまくいかないだけでなく、あなたを悪く見えるようにするでしょう。
彼はあなたの優れた生産性を測定できません。検証可能なメトリックに基づいてより高い生産性を主張するので、同僚はそれについてどのように感じていますか？彼らは、おそらくあなたがより生産的なプログラマーであるか、またはあなただけがあなたの意見であなたであることに同意するでしょうか？あなたがあなたの主張をバックアップする他の人がいるなら、あなたはより強い主張をするでしょう。
それは見通しです。さて、あなたが今いるこの苛立たしい状況をどのように「修正」するのですか？
少し遅くします。バグ率（*）を下げようとするタスクを配布する人に明示的に言及して、バグ率を下げます。摂取量が少ないことに驚かないでください。どちらかと言えば、速度を落とすことで、供給不足からあなたに割り当てられるバグの数が減ります。
（*）一方で、名前にバグがあることを認識していることと、その量を減らそうとすることと、一方で、あなたの名前にあまりにも多くのバグがあることを認め、行動を取るべきです。
上司を説得しようとしないでください。繰り返しますが、それはあなたがあなたのポイントを同意しなければならないという意味ではありません。あなたは彼の懸念を却下することなく、対置点を提示し、あなたの意見を保持することができます。要点を主張し、優れた生産性を十分に証明できない場合は（可能であっても）、同僚を侮辱したり、非難したりするリスクを負うことになります。あなたはあの男になりたくない。
同僚と同じ「量」のコードを20％の時間で生成すると仮定すると、実際にコードをデバッグして完璧にするために4倍の時間を費やすことができ、バグ率がさらに低下します。そうすれば、自分を優れたプログラマーと呼ぶことができます。
最大の問題は、なぜ品質を目指すのではなく、他の5倍のコーディングをするのかということです。これはあなたのエゴがあなたに命令するものですか、それともあなたの上司があなたを強制するものですか？
また、バグを修正するためのコストも考慮する必要があります。それを早期に見つけたとしても、コードをすぐに修正するのに十分な「内部」にある可能性があります。それが1か月の開発後にのみ表示される場合は、既にプログラムされているコードの大きな部分を見つけたり、変更するように強制することさえ難しい場合があります。
あなたはコードを作成するスキルセットを持っているようで、スピードではなく品質に焦点を当てれば、それを素晴らしいものにすることができます。しばらくお試しください。きっと気に入っていただけると思います。
次の問題は、パフォーマンスを向上させるための謝辞（お金を話す）を取得することです。上司に話しかけてどのように進めればよいか尋ねてください。結局のところ、それは彼の会社とお金であり、バグを減らしてほしい場合は、どちらの方法で行うかを決定する必要があります。
開発者は、優れた開発者でなくても、一人で理解し、コーディングする能力があれば、明るくて天才でさえあり得ます。優れた開発者は質の高い作品を作成し、プロジェクト全体をより良くします。
私はこれがあなただと言っているわけではありませんが、私が一緒に働いた中で最も苛立たしいプログラマーの1人は、チームの誰よりも多くのコードを書いており、チームには優れた人々がいました。ランキングソフトウェアを使用してコミットを追跡したため、一部の人にとってはほとんど競争でした。彼は一連のコードを削除し、ゼロのドキュメント、不可解な森を残し、実際に自分のコードの一部を理解しにくくしました（私は自分でそれを行うことができます。ありがとうございました！）。結局、彼は一人でのショーになったので、プロジェクトをほとんど脱線させました。人々は彼に従うことができませんでした。私たちはチームとして同期していませんでした。私たちは実際に、保守性を回復するために、数年後に彼の機能の一部を書き直しました。
私が彼に望んだことは、速度を落とし、より多くの時間を費やすことでした：1）コードベースの品質の向上2）チームとのコミュニケーション3）他の人を助け、彼が機能/ストーリーを完成するのを助けるものに取り組む4）修正バグ
コード行ごとに生産性を測定することに同意しませんが、それは重要なメトリックです。コードカウンターにコメントが含まれていますか？もしそうなら、「バグ率」を減らしながらライン出力を維持する簡単な方法があります。コメントの質と量を増やすだけです。コメントにバグが含まれることはほとんどありません（バグはある場合もあります）。一般的に、質の高いコメントはありません。私はnotでコードインフレを容認していますが、コメントするという行為はミニコードレビューのようなものであり、思考、リファクタリング、改善を強いられます。
管理を啓発しようとすることは、重要なことではありません。 「私やあなたの嘘つきの目を信じるつもりですか？」という古い決まり文句があります。上司が気にするのはバグの数です。合理化の量はそれが許容できることを彼らに伝えません。リスクは2倍以上です。さらに、バグ数の影響を受けるのはあなただけではありません。 QAには、バグを特定するための作業が2倍あるので、経営陣は、バグを少なくすることを求めています。
最善の解決策は、作成するバグの数を減らす、ピリオドです。管理はより幸せになるだけでなく、あなたも幸せになります。ね？あなたが同僚の4倍の性能を誇りに思っていることを楽しんでいる限り、私はかなり確信しているので、あなたはloveと同じ数、またはそれよりも少ない数のバグを作成することになると言います彼らはします。
あなたが述べたように、 "…コードで発生したエラーの割合…コードを書くときとコードが書かれた後に使用されるプロセスによって影響を受ける傾向があります。"バグの発生率を変更したい場合は、コードの記述に使用するプロセスを変更する必要があります。
プログラマーは、Assemblyラインがメソッドを使用して大量生産されたオブジェクトを生成するのと同じように、コードを生成するために生成メソッドを使用します。さて、ソフトウェア業界の慣行は、森の中で発見された枝からの小技のようなものです。しかし、私たちは機械を製造しているので、大量生産の高速機械に使用されるのと同じ厳密さと規律を採用する必要があります。
これには、不良率を減らすために量産で使用されるのと同じ手法が含まれます。バグが発生した理由を特定する根本原因分析と、バグが発生しないようにプロセスを変更します。または、少なくともQAが行う前にキャッチします。
バグのリストを作成します。あなたはおそらくすでにQAの皆さんに感謝しています。おそらくあまりにも分類されます。バグの種類、重大度、バグがコードに挿入されたポイントなど。
バグの最大のカテゴリを選択してください。ボリュームが非常に大きいため、最初にそのカテゴリをターゲットにする必要があります。他のカテゴリには、最も見つけやすいものと最も簡単に作成できるものがあります。
これらのバグがコードのどこに導入されているかを把握し、そのフェーズ（およびそれ以前）でそれらのバグが発生しないように変更を加え、そのフェーズでバグを簡単に検出できるようにする方法を検討します。
プログラミングに関連しない付随的事項に注意してください。また、それらはあなたの作品の質に影響を与える可能性があります。バックグラウンドミュージック、中断、食事時間、休憩なしで長すぎる、空腹など。
あなたが見つけたものはあなたをより遅くするように導くかもしれません。一方で、すでに置いてあるものを作り直す必要性が減るので、それはあなたがさらに速く生産するのを助けるかもしれません。現状の4倍のコードは、同僚よりも1桁も優れているわけではないため、プロセスを変更することが最も確実です。
目的を変更して、最も多くのコードを作成することから、会社が最も前進できるように支援する。
多くの同僚に加えて利用可能な時間があるようですので、機能の迅速な提供とバグ修正に与えることができる最も大きな影響は、同僚を助けることです。
同僚を助ける
- コードレビューを使用してコードの品質と教育を改善する。
- 彼らの仕事をより速く、彼らの生活をより簡単にするためのプロセス自動化を作成します。
- 彼らとより良いテストを書く
- コードベースを改善するためにテクニカルコードを攻撃する
- 他の人を助けるために常に利用できる頼りになる男であること。
- 開発者の生産性向上に役立つツールの作成/改善
- あなたがより強い影響力を持っているなら、あなたの同僚のためのより良い道具/設備/労働条件のために管理者と訴訟を起こすこと。
- より良いコードを書くための教育セッションの準備と指導。
- 謙虚さを実践する
では、生産性の向上がバグ数の増加につながるという事実にどう対処するのでしょうか。
あなたのケースでこれに答えることができるのはあなたの上司だけです。彼と話し、あなたのより良い比率を指摘し、彼に決めさせてください。彼の決定が意味をなさないならば、あなたの考え方で会社を探す時が来ました。
専門家としては、特定のクライアント条件で作業できる必要があります。クライアントが結果を理解していることを確認してください。素敵なバグ/ストーリーチャートは、時間をかけてより少ないバグを生成する場合に、生産性がどれだけ低下するかを上司に理解させるのに役立ちます。
次の点も考慮する必要があります。
- ストーリーの複雑さ、たとえば、単純なゲッター/セッターラッパーと統計計算、リアルタイムプログラミング、さらにはリアルタイム統計...
- バグの重大度。テキストフィールドの小さなタイプミスや間違った計算結果、プログラムのクラッシュなど
- バグを修正するためのコスト。今すぐ修正する場合も、後で修正する場合も、残したために他の誰かがコードを理解する必要がある場合も同様です。
状況は、平均的なプログラマーの4倍の速さで作業しますが、一定の時間内に2倍のミスを犯します。実行する作業量に比べて、実際には「平均的」と同じくらい多くの間違いを犯します。
作業率の低い間違い、または完成した製品の間違い（通常の4分の1の時間で完了できる）を指摘しようとする場合があります。ほとんどのボスはそれを受け入れます。
彼らは時間あたりのミスの「許容」マインドセットで働くので、そうしないいくつかのボスがあります。次に、作業ペースを遅くし、所定の時間内に平均で2倍の作業を行い、作業を確認する時間が増えるため、同じ（または少ない）間違いをする可能性があります。
付加価値の測定
本当に重要なのはあなたが加える価値だと主張する。次に、その大まかな（手動）測定を紹介します。
- 作成する機能の価値を見積もる
- 給与を差し引きます
- バグの推定コスト（少なくともそれらを修正するためのコスト）を差し引きます
- あなたが生み出す他のすべての技術的負債の推定コストを引く
残りはあなたの付加価値です。他のすべての人も同様です。
これらの見積もりは難しいですが、大まかなものでもポイントを作ることができます。そして、これらの推定値を議論する単なるプロセスは、チームとプロジェクトに役立ちます。
上司があなたに仕事の質を改善してほしいと望んでいるなら、あなたの仕事の質を改善してください。
あなたはバグをゼロにすることを目指しるべきであり、次善のプログラマーの2倍の数だけを作り出すことを目指すべきではありません。
上司に、彼が使用しているメトリックにはかなり欠陥があることを伝える必要があります。 NBAの警備員による離職率を見ると、フォワードよりも数字が高い傾向にあることがわかります。しかし、それは彼らがより多くのボールを扱っているからです。非スターティングガードがスターティングガードの1/5をプレーし、ボールを平均3回以上回した場合。ゲームごとに7回以上ボールを回すスターティングガード-一見するとスターティングガードの方が悪いように見えるかもしれません。ただし、ターンオーバーの数をプレイした分数で割ると、スターティングガードはプレイした分数に基づいてはるかに優れた数になります。
同様に、バグの数を完了したストーリーポイントの数で割ると、はるかに優れた数になります。それが、私があなたのマネージャーに提案することです。バグの数を完了したストーリーポイントで割った値になるように指標を変更するか、開発者ごとのバグの総数が必要な場合は、少なくともこの指標に新しい指標を追加します。ただし、一部のストーリーポイントは他のストーリーポイントよりもはるかに複雑で複雑なため、かなりの差異が生じる可能性があり、またそうなる可能性があり、これもマネージャーが考慮する必要があります。
私があなたがすべきではないと思うことは、減速することです。