なにそれおいしいの
JIRAはAtlassianのIssue Tracking Serviceで、弊社もRedmineから徐々に移行中。移行の理由はWYSWIG EDITOR（画面上でみんなで見ながらその場でいろいろ編集）が強いことと、他の開発ツール（主にBitbucket、HipChat、Confluence）と連携が取れること。
JIRAにはIssue Tracking用に予めWorkflowが用意されているが、けっこう簡単にカスタムして使うこともできるので、チームやその時やりたいことに合ったWorkflowを定義することでより効果的に運用できる。
今回はリリースに向けてアプリのテストを開始したので、開発タスクとは別にBug Trackign用のWorkflowを定義してみた。
JIRAのWorkflowを編集する
必要な作業は以下の通り（新規のWorkflowを作る場合）
- JIRAのAdministration（右上のコグ）からIssuesを選択
- Add Workflowで新規のWorkflowを作成
- Workflowを作る（後述）
- JIRA ProjectのAdministrationで作成したWorkflowをアサインする
- （必要があれば）既存のIssueのStatusを変換してDeploy
Workflowの編集
WYSIWYGなダイアグラムエディタがあるので、ステップ（ステータス）を定義して間をTransitionでさくさく繋いでいく。
編集中のWorkflowはDraftなので、Publish Draftして公開。すでにActiveなWorkflowの場合はそのまま変更が適用されるハズ。
今回の変更
最初チーム内ではJIRAのSimple Issue Tracking Workflowを使っていたが、Start → Start Working → In Progress → Doneという超シンプルなものだったので、Bug Tracking用に以下の項目を追加した。
- BugのステータスはOpen（Active）→Resolved→Closedで遷移
- ResolveされたBugは必ずVerifyされてClosedになる。ClosedはThis bug is no longer an issue.の意味。
- ResolveのResolutionは複数あり、Fixed、Won't Fix（直しません）、By Design（仕様です）、Duplicate（重複しています）、External（外部要因です）、Postponed（次のマイルストーンに延期）、Not Repro（再現しない）など。これらは同じJIRAのAdministrationの、Issue AttributesのResolutionで追加できる。理由はResolveする際のコメントで追加する。
- Resolveする時はOpenerにBugを戻して、ResolutionがOKか確認してもらう仕組み。
- ワークフローとは別にJIRAユーザーとしてTriageというユーザーを作成。対策を決めるのにディスカッションが必要なものはそこにAssignした上で、Bug Triage Meetingでディスカッションする。
雑感
- 編集はかなり簡単。適用もそんなに難しくないので誰でもできるだろう。
- ただしある程度回しながら全員がワークフローに慣れないと、ちゃんと運用されない。スクラムとかを活用するべし。
- うちのチームではテスト期間中は毎日Bug Triage Meetingをやることにして、一応新規Bugは全て見る＆既存Bugのステータスをチェックすることにした。システムまかせは便利なのだけど、ワークフローのどこかで淀んだりする傾向があるのでそういうのをまさにスクラムやBug Triageでカバーするのがよい気がしている。コミュニケーションによってアイデアも生まれるし。
- 外部ベンダーさんにテストを依頼してたりするチームの場合は、HipChatの個別の部屋に特定JIRA Projectのアップデート流すみたいな連携をしたいんだが、できるんだっけか（調べる）
- 垂直に立ち上がるBug！！燃え上が〜れ〜燃え上が〜れ〜
以上。