ITS (Issue Tracking System) トラッカー設計ガイド
トラッカーにおけるチケットのワークフローは、ライフサイクルを表すステータスと、何らかの属性を表すレゾリューションによって成り立っています。
ここでのポイントは、チケット処理の過程でボールを持つ役割の数以上にステータスを増やさないということです。ステータスの数はできる限り少なくし、運用上必要な属性情報はレゾリューション、カスタムフィールド、タグを使って実現するようにトラッカーを設計します。
ステータス
上記の理由から、必要なステータスは下記の5つのみとなります。
- [NEW] (起票者が [NEW] にする。)
- [RESOLVED] (修正担当者が [RESOLVED] にする。)
- [VERIFIED] (検証担当者が [VERIFIED] にする。)
- [REOPENED] (検証担当者が [REOPENED] にする。)
- [CLOSED] (リリース担当者が [CLOSED] にする。)
実際のところ、このほかに [REJECT] (却下) に相当するステータスを実装しているトラッカーは多いように思いますが、これはライフサイクルではなく、処理結果の一種（レゾリューション）であるため、ステータスとしては適切ではないと考えます。
また、[ASSIGNED] (アサイン済み) のようなステータスをデフォルトで導入しているトラッカーもありますが、基本的に「担当者」フィールドに By Name が入っているのであれは、アサイン済みであると判断できるため、冗長となりうるステータスと考えます。
【備考】 あくまで我々が管理しているのはバグではなくインシデントですので、バグであると判断されたかどうかによってワークフローを変えるべきではありません。通常のライフサイクルに載せることによって、修正担当者がインシデントをどのように切り分けたかにせよ、その判断の妥当性について検証担当者は確認をする機会を得ることができます。
レゾリューション
レゾリューションには、チケットがあるステータスのときにひもづけられる属性のうち、汎用的に利用したいものを定義します。
個人やプロジェクト単位で追加で利用したい属性に関しては、レゾリューションではなくタグを利用するをおすすめします。
これは組織において取得可能なメトリクスの粒度を統一するためという品質保証上の理由がひとつ、もうひとつはトラッカーの設定が複雑になるのを避けるためというプロジェクト効率化の理由がひとつです。
レゾリューションはステータスを変更するときにしか設定されませんが、タグば必要に応じていつでも付け外しをしてもよいという性質があります。
レゾリューションとして定義した方がよいもの
それぞれ、修正担当者が [RESOLVED] にする際にあわせて使用します。
INVALID
報告された内容は仕様通りの動作です。
単純な起票間違いはここに含んではいけません。
DUPLICATED
重複した報告です。
FIXED
調査した結果、バグでした。コードの変更が終わりました。
LATER
調査した結果、バグでしたが、直近のマイルストンに向けては修正しません。
WONTFIX
調査した結果、バグでしたが、この製品においてはもう修正せず、制限事項とします。
WORKSFORME
再現できません。より詳細な条件や再現手順を追記して再度報告してください。
タグで運用した方がよいもの
起票間違い
操作ミスにより登録されてしまったチケットで、INVALIDとは異なります。
ノイズとなってしまうので、管理者はそのチケットを削除するか、適切なトラッカーに移動させるかするべきです。
要望
要件定義漏れに相当する可能性がある内容の報告です。
仕様の欠陥に対する指摘は含まない点に注意が必要。
