ITの地殻変動はどこで起きているのか？: プログラマの思索を読んで思い出したことをまとめておこう。
TracなどのBTS(バグ管理システム)を用いたチケット駆動の開発というスタイルで、アジャイル開発を実践されている方も多いことだろう。
私がTracを使っていて感じた不足をここに挙げておく。
インシデント管理
顧客からの要望などのインシデント票と呼ばれるものと、開発の為のタスク（チケット）は別のものだ。私も当初はこれらを混在してつかっていたのだけど、顧客からの問い合わせや要望といったものと、実際の開発作業の間には大きな溝がある。
例えば「Tracにインシデント管理機能をつけてよ」と言われた段階で「インシデント管理機能を作成」というチケットをあげてはいけない。
XPで言うところの計画ゲームをする際のタスクカードと、TODOであるところのTrac上のチケットは分けた方がいい。アイデアとしては出たものの、いつまでも放置されているゴミタスクが増えるばかりで嬉しくない。
本来のインシデントの管理は、顧客からいつどのような問い合わせや要望をうけたか、それに対してどう返答したのかを管理するものである。そこは開発作業の起点になることがある。が、開発対象のタスクとは違うものだ。似ているから混ぜてしまいがちだが、混ぜるなキケンだと言っておく。実際の開発をする段になってから「機能を作成」というチケットを別に作るべきだ。
こうしたやり取りを管理するための専用ツールが付加すればビジネス的にもっと使う価値が増す。
仕様のバージョン管理
仕様をWikiの機能を使って書いている人もいるかもしれないが、ソースコードと違って仕様をバージョン管理できない。仕様と言うのは修正が入ることがあるからリリースバージョン毎に違ってくることがある。ある特定のバージョンの仕様がどうなっていたかという情報へのリーチャビリティを確保したい。
テスト仕様のバージョン管理
仕様のバージョン管理とリンクしてテスト仕様のバージョン管理も行いたい。
テスト仕様はあるいはJUnitなどによる自動テストかもしれない。いつのバージョンのいつの仕様に対する自動テストないしテスト仕様はコレ！というものが得られるならば障害報告に対してスムーズな返答ができるようになる。…かもしれない。
少なくともテストがどの仕様とリンクしているかをトレースできるようにはしたいところ。もちろん、チケットやソースコードのコミットともリンク。
テスト実施の管理
テスト仕様のバージョンが管理できたなら、その実施結果も管理したい。
Excelで作ったテスト仕様書に、テスト実施ごとに実施結果入力欄を足していくような運用はもう嫌だ！再テストとかになったときにだんだんわけの分からないものになっていく。どのリビジョンのソースにどんなテストが実施されたのかを管理できるならこれほどうれしいことはない。
