プログラマの思索

Tracを使い始めて、Redmineと異なる視点を感じる所があったのでメモ。

【1】RedmineやTracを障害だけでなく要望も含めてタスク管理する発想は、Issue Trackingと呼ばれる。
元々、チケット駆動開発(Ticket Driven Development)は、バグ管理システム(Bug Tracking System)を汎用化した課題管理システム(Issue Tracking System)から発生した開発プロセス。

すると、障害管理で使われるステータスだけでは管理しにくい場面が出てくる。

例えば、ITILではシステム運用保守で、問題管理、インシデント管理、変更管理、リリース管理の4つの視点を提供する。

BTSのバグ管理は、問題管理と同じ。
問題管理のワークフロー(チケットの状態遷移図)は下記が普通だろう。

新規→担当→解決→検証中→検証完了→終了(リリース完了)

このパターンがプロジェクト管理ではおそらく最も基本的なワークフロー。
何故なら、開発者とテスト担当者がペアになって一つの問題を解決する基本的な作業パターンだから。
バグ修正という一つの成果物を二人の目を通すことによって、考慮漏れや検証漏れを確実になくせる。

だが、このパターンだけでSW開発全てが作業できるわけではない。

ベンダーへの問合せ、顧客から来た苦情への対応などのインシデント管理は、違うワークフローを必要とする。
ベンダーとのやり取りは下記のようなワークフローが必要だろう。

受付済→問合せ中→回答済→終了

つまり、インシデント管理は問題管理とは異なる状態遷移図になる。

TracやRedmineを実際のプロジェクト管理で運用し始めると、インシデント管理を運用しにくいとよく言われる。
その一番の原因は、BTSのデフォルトのワークフローである障害管理と現場で運用しているインシデント管理業務が対応できていないからだ。
バグ管理のステータスだけでSW開発全てを対応するのは所詮無理がある。

又、SW開発で最も制御しにくいワークフローは仕様変更。
このワークフローは、ITILでは変更管理で制御しようとする。

変更管理の基本フローでは、変更計画を作った後に、ソース修正とリリースを実施し、その後にレビューする。
下記のようなワークフローが必要だろう。

新規→設計中→方針決定→担当→解決→検証中→検証完了→終了(リリース完了)

方針決定のステータスまでは、設計者が担当し、その後は、問題管理と同じワークフローになるだろう。
このワークフローの途中で、仕様変更に対応する必要がないと判断したら、却下というステータスも発生する分岐もあるだろう。

結局、チケット駆動開発を実践しようとして混乱する根本原因の一つは、ワークフローと言う概念を認識していないから、と言える。
ワークフロー、つまり、チケットの状態遷移図は表裏一体の概念。

ここで、ワークフローとは、チケットの種類で分類すべき対象である。
Redmineでは、トラッカーと呼ばれる機能になる。
ITILの言う問題管理、インシデント管理、変更管理などは、Redmineのトラッカーの単位で管理すべき対象なのだ。

更に、このワークフローに出てくるステータスには、PGなら解決、テスターなら検証中のように、必ず一人の担当者がアサインされる。
上記の状態遷移図はアクティビティ図でも置き換えて表現できる。

上記をまとめると、SW開発の業務フローは、デスクトップアプリのイベント駆動プログラミングのように分析可能。
つまり、下記の3つの視点は同値。

チケットのアクティビティ図(フローチャート)
⇔チケットの状態(ステータス)遷移図
⇔チケットのステータスのデシジョンマトリックス(ステータスの組合せ)

この観点で、チケット駆動開発の代表的なツールであるTracとRedmineを比較してみる。

【2】Redmineでは、ワークフローを下記で制御する。
Web上の管理画面で制御できるので、非常に使いやすい。

Redmine.JP | Issue tracking system（バグ追跡システム）

Redmine.JP | チケットのステータスの意味

Redmine - RedmineIssueTrackingSetup - Redmine

つまり、Redmineでは、トラッカー(チケットの種類)、ロール(ユーザの権限)毎に、先行・後行ステータスのデシジョンマトリックスで制御する。

例えば、トラッカーには「バグ」「仕様変更」「ベンダー対応」「環境構築」のようにワークフロー単位で設定し、ロールごとに遷移できるステータスを制御する。
バグ修正のような問題管理は開発者やテスト担当者で相互にやり取りするが、変更管理では、最初に設計者が方針を決定した後に、開発者へ手渡すようなワークフローが必要になるだろう。
特に、最後にチケットを終了できる権限は管理者だけとし、必ず品質チェックを通るような運用は実際の現場では多いだろう。
つまり、Redmineでは、ユーザのロールによって、ステータスの変更を制御するのが簡単。

Tracでは、下記のような方法で制御するらしい。
trac.iniへ状態遷移のフローチャートを書くスタイル。

ワークフロー機能のカスタマイズ方法 - かおるんダイアリー

Trac-0.11のワークフロー - Do You PHP はてな

TracWorkflow ? The Trac Project

Tracでワークフローを追加するのは、正直難しい。
上記の設定方法を見ると、ワークフローというアクティビティ図で描かれたフローチャートを無理やり表現したものなので、trac.iniから理解するのは難しい。
できれば、trac.iniに直接設定するのではなく、RedmineのようにWeb上で制御できるようにして欲しい。

また、Tracでは、ワークフロー単位、ユーザのロール単位で状態遷移できる仕組みが僕にはまだ分からない。
管理者だけの問題管理用のステータスだけでは、インシデント管理や変更管理に対応するは正直無理がある。

残念ながらTracはRedmineよりもワークフロー管理機能が扱いづらいため、未完成なチケット駆動開発のツールのような印象を受ける。

しかし、Tracを扱う人達も上記の問題に気付いており、色々試されているようだ。
TracはRedmineよりもプラグインも多いため、ワークフローをカスタマイズできるプラグインが実現できればいいなと思う。