-------------------------------------------------- ----------------------------
バグ追跡システムは早期に作成し、あまり頻繁には作成しないでください
早い人ほどバグの使用に慣れます追跡システムがあればあるほど良い。プロジェクトが 3/4 終わった時点でバグ追跡システムをインストールしても、それは使用されません。人々がそれを使用できるように、バグ追跡システムを早期にインストールする必要があります。
プログラマーは一般的にバグ追跡に抵抗しますが、正しく使用すれば、プロジェクトに非常に役立ちます。
問題が床に落ちない。
問題は自動的に責任者に転送されます。
問題のライフサイクルが追跡されるため、人々は適切な情報をもとに議論することができます。
マネージャーは、システム内のバグの数と種類に基づいて、大きなスケジュールと人員配置の決定を下すことができます。
構成管理は、パッチが修正する問題と一致することを期待しています。
QA とテクニカル サポートには、開発者とのコミュニケーション手段があります。
セクシーなものではなく、プロジェクトの優れた堅実な改善です。
参考までに、修正したバグの数によって報酬を与えるのは良い考えではありません :-)
ソース コード管理はバグ追跡システムにリンクされるべきです。リリース前にソースが凍結されているプロジェクトの一部では、有効なバグ ID を伴うチェックインのみが受け入れられる必要があります。また、バグを修正するためにコードが変更された場合は、チェックイン コメントにバグ ID を含める必要があります。
出典
いくつかのプロジェクトで、DDTS が実行可能なシステムであることがわかりました (このリンクはこの PHP リリースでは検証されていません。DDTS は PHP では動作しない可能性があります)。 GNU バグ追跡システムも利用できます。独自のシステムを作成することは一般的なオプションですが、既存のシステムを使用する方がコスト効率が高いと思われます。
------------------------------------------------- -------------------------------
責任の尊重
ソフトウェアモジュールに対する責任の範囲は限定されています。モジュールは特定の人の責任であるか、共通のものです。この責任分担を尊重してください。自分に変更する責任がないものは変更しないでください。結果として生じるのは間違いとつらい感情だけです。