BTSのワークフローと解決状況とカスタムフィールド
それぞれのBTSのワークフローはなかなか特色があるね。
Tracのワークフローは以下のようになります。
new（新規） → assigned（アサイン済み） → accepted（受け入れ済み） → closed（クローズ）
TracWorkflow – The Trac Project
TracはResolution（解決状況）がある。
解決状況についてはこちらが参考になる。
BTSの解決状況(Resolution)は障害管理の名残り: プログラマの思索
Tracの後発のRedmineのワークフローは以下のようになります。
New（新規） → Assigned（担当） → Resolved（解決） → Closed（終了）
Redmineは解決状況は無いですが、Redmine本家のサイトはカスタムフィールド作ってやっているようです。
Seasar,HudsonのようなOSSでは見慣れたJIRAのワークフローは以下のようになります。
Open→In Progress→Resolved→Closed
http://confluence.atlassian.jp/pages/viewpage.action?pageId=23724583
JIRAは解決状況があります。
Mantisのワークフローは以下のようになります。
new（新規） → feedback（要追加情報） → acknowledged（内容確認済） → confirmed（再現済） → assigned（担当者決定） → resolved（解決済） → closed（完了）
Mantisも解決状況があります。
Bugzillaのワークフローは以下のようになります。
UNCONFIRMED→NEW→ASSIGNED→RESOLVED→VERIFIED
Bugzillaも解決状況があります。
最近知ったLaunchpadのワークフローは以下のようになります。このNewはBugzillaのUNCONFIRMEDと同じ意味あいで使うようです。
New→Incomplete→Comfirmed→Triaged→In Progress→Fix Committed→Fix Released
Triagedがよくわかんなかったんだけど、bzr系のプロジェクトでは「却下する訳じゃないけど修正予定は無いよ」って感じで使われてるらしい。
言ってみれば、「つ、つきあってください」ってコクったら「いいお友達でいましょ」って遠回しにフラレタみたいなw
Launchpadはステータスとして解決状況があるようです。
いろいろありますね。
仕事だとExcelでバグ管理も多いのですが、ワークフローはTracみたいな感じでしたね。
その代わり、バグの混入工程（例：基本設計）、摘出工程（例：結合試験）、本来摘出すべき工程（例：単体試験）、バグ内容（例：実装漏れ）、バグ原因（例：ライブラリの使用方法の誤り）等々の列がいっぱい加わります。後でバグ分析するために使うんでしょうけど、ちゃんと選択基準を示さないとみんな迷うでしょう。意図はわかるけど運用が難しそう。まあ試験結果報告書を書くためというのもあるんでしょう。手段が目的化してる部分はあるにせよ。
バグ管理は奥が深いですね。
