JIRA：閉じるか解決するか？
JIRAで解決済みの問題と解決済みの問題の両方を再度開くことができます。実際の違いは何ですか？ （QAが関係する場合など、問題を解決/クローズするために異なる権限が必要です）
私たちのチームには、解決するか閉じるかについて意見の相違があります。私は、ある権威を指摘し、「このようにするべきです」と言いたいです。
典型的な問題のワークフローは、バグに取り組んでいる人がそれを解決し、バグを開いた人が解決策が受け入れられるかどうかを決定する人です。もしそうなら、彼らはそれを閉じます。そうでない場合、彼らはさらなる議論/作業/論争のためにバグを再び開きます。
これの例外は、バグが重複している場合です。多くの場合、バグに取り組んでいる人は、それが重複であることに気付き、それからバグ自体を重複として閉じることができます。または、彼らはそれを重複として解決し、オープナーは同意して閉じます。
IIRC、JIRAには非常に柔軟な（複雑な場合）ワークフローがあるため、問題を送信するチームやグループに適していると思われるプロセスをセットアップできます。
編集：解決済みの問題を再開することに実際には対処しなかったことに気付きました。私の経験では、人々は自分が見ているのと同じ振る舞いを示す既存のバグを問題システムで検索するので、しばしば起こりません。そして、もし運が良ければ、既存の問題を調査することなくバグが頻繁に開かれます。
そうは言っても、QAまたはフィールド担当者は、元の所有者が閉じた後しばらくして「そのバグを覚えています。くそ、修正されたと言っています」と言います。この時点で、彼らは古いバグを再度開くか、新しいバグを作成して元のバグにリンクします。私の好みは、再び開くよりも、新しいバグがあり、リンクすることです。その理由は、「新しい」問題は同じ動作を示す可能性がありますが、まったく異なる原因がある可能性があるためです。これは、本当に一般的なエラーログメッセージが吐き出される場合によくあります。
- 通常、解決されるのは「テストの準備完了」です
- 通常、閉じられているのは「うまくいきました」
JIRAが解決済み/終了済みの状態とシステムの解決フィールドを使用する方法の詳細については、 このブログ投稿 もご覧ください。
外部のお客様に対して行う方法は、お客様に請求した時点でインシデントをクローズすることです（これは問題またはSEDタスクの場合もあります）。それまでは、インシデントは解決されたままです。
解決済みのインシデントは再開できますが、クローズしたインシデントを再開することはできません。
ところで、ITILがこれについて言っていることを読むのは賢明でしょう。これについて述べたように ページ ：
インシデントを再開するためのルール
十分な注意を払っていますが、正式に閉鎖されたにもかかわらず、インシデントが再発する場合があります。そのような場合のために、インシデントを再開できるかどうか、いつオープンできるかについて事前に定義されたルールを用意するのが賢明です。たとえば、インシデントが1営業日以内に再発した場合、再開できることに同意することは理にかなっていますが、このポイントを超えると、新しいインシデントを発生させる必要がありますが、以前のインシデントにリンクする必要があります。正確な時間のしきい値/ルールは個々の組織によって異なる場合がありますが、明確なルールに同意し、文書化し、ガイダンスをすべてのサービスデスクスタッフに提供して、均一性が適用されるようにする必要があります。
（通常）解決済みの問題に対して作業を編集したり記録したりすることはできません。これを考慮に入れる必要があります。
私のアドバイスは次のとおりです。テスターのみ
通常、Dev/Resourceは解決する必要があり、レポーターのみが閉じることができます。
CLOSEDはステータスでRESOLVEDはステータスだと思います。
- 問題は、DONE、NOT REPEATABLE、またはCANCELED（または、選択したステータス...ワークフロールールに設定されている）として解決できます。
- RESOLUTIONはJQLでも非常に簡単に使用できます。 PROJECT = DBAおよびRESOLUTIONは空です
- 解決済みの問題は、他の問題のコメントまたはリンクにリストされている場合、取り消し線付き文字で表示される
- DBレベルでは、解決日は別のフィールドであり、問題の日付セクションにも表示されます
解決済みの問題についても多くのレポートが利用できると思います。
結論... RESOLVEDは、さまざまな理由で「アクティブではない」ことを意味し、JIRAで特別な機能を備えています。 CLOSEDは単なる別のステータスです。
