TiDDを実践して気づいたことpart5～チケット管理システムとは

もう3年前の記事になるけど、参考になったのでメモ。

【元ネタ】
wikiとmantisを構築　業務をより効率的に - masahirorの気まま記録簿

Mantisは、BTSだけならばとても優秀なBTSだと思う。
しかし、Wikiが無く、SVNリポジトリと連携できない。
＃但し、フックスクリプトを作ればSCMと連携可能だし、パッチを当てればWiki機能を追加できる。

RedmineやTracが従来のBTSと異なる特徴や利点は何なのか？
それを明確にできれば、チケット駆動開発(TiDD)が一体何をもたらしているのか、チケット駆動開発の何が画期的なのか、が分かるだろう。

BTSは単なるバグ追跡システムで、基本機能は、Web上でバグを障害報告票で追跡すること。
障害報告票をExcelからWeb化することによって、バグ修正と検証の作業がとてもスムーズになる。
更に、このワークフローがとてもスムーズな為、Mantisでも、障害報告票をSW開発のタスク管理に使うアイデアは従来から知られていた。
このやり方は、障害報告票をIssueと呼び変えて、Issue(課題・問題)でタスクを追跡することから、Issue Trackingとも言われる。

更に、BTS(Bug Tracking System)をSW開発のタスク管理へ拡張したシステムはITS(Issue Tracking System)と呼ばれている。
ITSの代表的な例は、Tracであり、RedmineやJiraだろう。

だが、Redmineの管理画面に「Ticket Tracking」「Time Tracking」という機能を知って、そもそもこれらの本質は何だろう？という疑問を持っている。

ITSを更に拡張したチケット駆動開発(TiDD)の代表的な機能を整理すると、下記と考えている。

1・チケットで全てのタスクを追跡できる
2・チケットで工数や作業期間を追跡できる
3・チケットでSCMリポジトリ配下の成果物の変更を追跡できる
4・Wikiで情報共有できる

1はいわゆるIssue Tracking。
チケットをバグだけでなく問合せも設計もリリース作業も何でも扱おうと言う発想で、チケットをタスク管理に使える。
チケットをXPのタスクカードのように扱えば、自然にアジャイル開発になる。

すると、チケットにトラッカー(チケットの種類)という概念が必然的に生まれて、トラッカー単位にワークフローが作られる。
Issue Trackingの概念を突き詰めると、ワークフローに行き着く。
バグ修正と問合せのワークフローは当然異なるからだ。
そして、このワークフローは自然にペアプロのように、2人以上の目を通して作業することになり、品質強化に役立つ。

2はいわゆるTime Tracking。
チケットの属性に、作業開始・終了日の予定と実績、見積もり工数と実績工数を付与すれば、進捗管理に使える。
Redmineが優れている点の一つは、Time Trackingを利用してガントチャートをデフォルト表示してくれることだ。
他に、カレンダー・ロードマップ・変更履歴・バーンダウンチャートなどいくらでも集計結果をカスタマイズして出力できる。

コストもチケットの属性に載せれば、EVMも可能だから、工事進行基準の発想を取り入れて、リアルタイムにコスト管理も可能になるだろう。
又、累積の実績工数と終了チケット数を時系列にカウントすれば、信頼度成長曲線を作成できるから、品質管理にも使える。

これらの結果を使って、管理者は意思決定の情報をいくらでも自動収集できる。

3はチケットに構成管理情報を付与すること。これがTicket Trackingだと考える。
チケットがExcelのバグ報告票やMSProjectのタスクとは異なる最大の特徴は、SCMリポジトリ配下の成果物と連携できるため、要件からソース、そしてビルドモジュールまでのトレーサビリティを保障する事だ。

この機能は、最終的には、チケットをナレッジデータベースにすること。
チケットにSW開発の全ての作業履歴、ノウハウ、試行錯誤の結果が残るから、全文検索できるようにすれば、運用保守でリバースエンジニアリングしやすくなる。
あるいは、テストでバグを発見した時、何故要件が漏れていたのか、を追跡できるインフラにもなりうる。
また、ソースに「障害管理NO.123でバグを直した」というコメントを書く必要が無く、チケットを参照すればよいから、ソースもより綺麗になる。

4は掲示板やフォーラムにも使える。
プログラミングのちょっとしたノウハウ、ふりかえりMTや会議の議事録などを共有するのにも使える。
但し、厳格にバージョン管理した方が良いもの、例えば、設計書などは、Wikiではなく、SCMで管理した方がよいだろうと思う。

ExcelやMSProjectによるプロジェクト管理がITSやチケット駆動開発に劣るのは、上記4個の機能全てを実現するには力不足だからだろう。
つまり、チケット駆動開発が必然的に生まれた理由は、昨今のSW開発が短納期・大規模化・複雑化しているため、手作業ではもはや管理できず、上記4個の機能をツールで補完する事を必要としているからだろう。

SW開発の作業は全て、チケットから始まるのだ。
まさにチケットファースト。
そろそろ、ITSと言うのではなく、チケット管理システム(Ticket Tracking System：TiTS)と呼びたいくらいだ。