私はシニアソフトウェアエンジニアであり、数か月前にバグ修正の調整を手伝うように頼まれました。プロジェクトマネージャー（非技術者）は、生産性を1人/日あたり1つのバグ修正に改善するという目標を私に与えました。これは本当に難しいことであり、バグ修正率を向上させるために他の開発者/管理者が何をしたのか知りたいです。
この状況で役割を果たすいくつかの要因：
- チームは地理的に分散しており（ヨーロッパ、アジア、オーストラリア）、各地域に10〜20人の開発者がいます
- 会社に9か月しかいないので、あまり馴染みのない大規模なコードベース
- 経験の浅い開発者のみがバグ修正に割り当てられ、最も有能な開発者は機能拡張に取り組んでいます
- 私たちはアジャイルに従うので、ソース管理、継続的インテグレーション、バグデータベースを使用し、プロジェクトには新しい作業のスケジュールと仕様があり、テスターがいて、ユーザビリティテストを行います
- 私たちのコードは、社内およびサードパーティのコンポーネント/ライブラリの多くに依存しています
- プログラムマネージャーにはいくつかの古いバグ修正メトリックがあり、1人/日あたり0.7のバグ修正を示しています。私の懸念は、これがプロトタイプに取り組んでいる経験豊富な開発者のチームに基づいており、彼ら自身が書いたコードのバグを修正していることです。現在、コードに精通していない開発者のチームを調整しています。バグは検証チームに起因しています。
最初のいくつかの回答を読んだ後のいくつかの詳細：
- 私はバグ修正された生産性メトリックを使用することに反対しようとしましたが、このアプローチでは行き過ぎではありませんでした
- すべてのバグに優先順位が付けられ（1-5）、重大度（1-5）が含まれ、追加情報でタグ付けされます（たとえば、別のバグによってブロックされた、クラッシュ、再現不可能など）
- ほとんどのバグには、修正時に単体テストケースが記述されています
- コードの特定の領域のバグは、可能であれば、その領域に精通している人々に割り当てられます
- バグ修正率はチームごとに追跡され、修正履歴が保持されます
- 毎日のスタンドアップでは、ブロックの問題を求めて解決することで、人々を動かそうとしています。
- すべての新しいコードは単体テストで書かれています
- はい、私はさまざまな方法で生産性メトリックを改善するために最善を尽くしています-古い無関係なバグを閉じ、バグレポートなしで解決される問題のバグを作成して修正します
バグデータベースに直接アクセスして、バグ管理のありふれた側面を自動化し、レポートを作成するPythonスクリプトを開発しました。
-