バグのためにケースを再度開く必要がありますか、それともバグを新しいケースとして開く必要がありますか？

現在、私の職場では、さまざまなWebアプリケーションのすべての機能とバグを管理するためにFogBugzを使用しています。

Webアプリケーションの1つに新しい機能を追加すると、新しいケースが作成されます。たとえば、「CSVアップロードフォームの作成」です。

次に、私が費やした時間を記録してケースに取り組みます。このケースが完了したら、それを解決すると、ケースオープナー（通常はプロジェクトマネージャー）に割り当てられ、ケースマネージャーがケースを閉じます。

この機能にバグがある場合、プロジェクトマネージャーがケースを再度開き、バグの箇条書きリストを付けてケースを割り当てます。

私の意見では、これらの箇条書きのバグは個別のバグケースとして開く必要があると思います。そうすることで、追跡が容易になり、元の機能ケースのメモが散らからないようになります。

私のマネージャーは、機能に費やされた合計時間をすべて1つの場合に計算する方が簡単であると述べることに同意しません。

さらに、機能の参照番号が1つしかないため、クライアントの混乱が少ないと考えています。ただし、これは元のケースの完了後なので、バグは別のケースとして処理する必要があることを強調します。

バグは新しいケースとして再開する必要があると私は言っていますか？そして、これを管理するそれぞれの方法の長所/短所は何ですか？

あなたとあなたのマネージャーの両方があなたのそれぞれが好む方法を扱う正当な理由があり、妥協する必要は本当にありません。私のために機能し、両方の懸念に対処する解決策があります。

あなたのような場合、私は高レベルのタスク/低レベルのサブタスクのアプローチを使用します（JIRAから選んだ概念、FogBugzがサポートしている^ように明示的にサポートしているかどうかはわかり^ません）。このように、「クライアント向け」の箇条書きリストは高レベルのタスクに移動し、私にとって重要な「開発者の反復」はサブタスクに反映されます。

ハイレベルのタスクは「リニューアルオープン」されたとき、私は追加の努力を追跡するための新しいサブタスクを作成し、自己のために。

この方法により、開発者は機能仕様によって渡されたすべての順列、倒錯、およびひねりを明確に反映することができ、それでもマネージャーはそれを完全な形でクライアントに提示できます。ちなみに、完璧なプレゼンテーションは、開発者にとって私にとって価値があります。クライアントにとって読みやすくすることで、より正確な調整が得られるからです。

これにより、機能の実装に当初の予想よりもはるかに長い時間がかかる場合でも、当然のことながら明確な正当化が可能になります。

_{タスクまたはサブタスクごとの時間追跡について-JIRAはサブタスク追跡をより高いレベルの要約に含めることができるため、マネージャーがサブタスクで時間を追跡することは許容されます。ただし、これが当てはまらない場合でも、「親」タスクで時間を正式に追跡することで対応できます。この場合、サブタスクのコメントを使用して、特定の反復に費やされた時間を示します。}

機能が顧客にリリースされる前にこれがすべて発生している場合は、ケースが1つだけあります。ここでの議論は、QAに合格して解放される準備ができるまで、ケースは本当に完全ではないということです。その他の利点-請求およびエンドユーザーが参照できる単一のケース番号が有効かつ重要です。

機能がリリースされてバグが見つかったら、問題追跡ソフトウェアで新しい問題として発生させる必要があります。

私はあなたに完全に同意します、そしてFogBugzもそうです-それがバグと機能のために異なるカテゴリーを定義する理由です。FogBugzは、時間の使用を追跡するツールとして設計されていません。これは、証拠に基づくスケジューリングの導入の偶発的な副産物です。

完成した機能のバグは、機能のメインケースにリンクできます（FogBugzでは、タグ名または相互参照を使用するか、サブケースにすることで）。これは、PMが複数のケースにわたって情報を統合するために少し手間がかかることがわかりますが、特に固定価格の契約の場合、最初の開発に費やした時間とメンテナンスに費やした時間を区別できることもしばしば意味があります。すべてを1つのケースに入れると、これを行う能力を失います。

チケットが閉じられると閉じたままになるはずですが、バグトラッカーは他のケースにリンクできるはずです。新しいバグを作成して元のケースにリンクすると、説明した方法よりも優れた利点が得られることを指摘しておきます。

• クライアントは、各バグへのリンクを含む1つの参照番号を持つことができます。
• 各バグのステータスを個別に追跡できるため、優先順位付けとステータスレポートを改善できます。
• 個別のバグがあると、マネージャーはバグに費やした時間と新機能の開発に費やした時間を分析でき、変更とその変更の開発に関連するすべてのバグの総数を取得するための最小限の追加作業になります。
• バグを分離することで、マネージャーがバグの合計、バグ修正ごとの平均時間、クローズ/進行中のバグ/修正されたバグの比率など、他のメトリックをより簡単に収集できるようになります。
• バグごとにケースを分けることで、タスクをすべての開発者間でより適切に分割し、各自がそれぞれの作業に対して責任を負うようにするか、後日より多くの開発者を雇う場合にこの可能性を可能にします。

現在のセットアップの唯一の利点は、システムのメインユーザーではない人々にとって非常にシンプルなことです。バグトラッカーの目的は、開発者が1つの場所でバグに関するすべてを報告する場所を持ち、他の人が進行状況を見るのに十分友好的であることです。現在のシステムは、そのほぼすべての部分を損なっているようです。

製品が顧客に「出荷/リリース」される前または後にバグは見つかりましたか？

リリース前であれば、バグは元のチケットに対して追跡する必要があります。

リリース後であれば、各バグは独自のチケットである必要があります。

私が働いている場所では、QA担当者のみがケースをクローズできます。コードレビュー、エンジニアテスト、および利害関係者へのデモ（あなたの場合はプロジェクトマネージャー）のチェックボックスがあります。QAチームがこれらのフィールドのすべてがマークされていない「完了」とマークされたケースを見つけた場合、QAチームはそれを未完了としてマークし、私たちに送り返します。

ケースがこれらすべてのフェーズを通過し、QAがケースをクローズすると、彼らが見つけた新しい問題はすべてバグとして記録されます。

このシステムは私たちにはうまく機能しているようです。

どちらの方法でも議論できると思います。私は首相に座り、離散的な問題があなたを助けるのに役立つとあなたが考える理由を説明しようと思います。個人的には、ToDoアイテムごとに個別のチケットを作成する必要がありますが、なぜ彼がそのようにしたいのかはわかります。