Tracの運用方法

ネットで見ている限りTracやRedmineを高度に使いこなしている人も多いようだ。
僕自身はプラグインもほとんど使ってない。post-commitで満足している。

会社でもTracが大きく展開されているせいか、僕のまわりでもTrac使っている人は多い。

ただ使い方を聞いてみると結構アレって思うことがある。

Subversionだけしか使ってないとか、チケット使っているのにコミットコメントにチケット番号を入れないとかね。
後者に関してはもったいないよね。やり方を最初に教えればいいだけのような気はするが、なかなか浸透しないみたい。個人的にはチケット番号を入れないとコミット禁止とかは小規模ならやりすぎかなって思ってたけどそうでもないのかも。

まあ確かに今までのやり方を変えるのはなかなか難しい。

とくにメンバーが多い場合はみんながなじんでいるExcelベースになるのはある程度納得できるものがある。

さすがにソース管理はSubversionを使うようになっている。これがファイルサーバだったらさすがにまずいよね。

だから最初はTracのSubversionのみ使うってのもありだと思う。これなら既存のやり方と変わらないし、セットアップもTracLightningなら簡単だ。Windows系の開発をやっている人にLinux上でTracをセットアップさせるのはつらいだろうしね。

TracのSubversionのみ使ってたプロジェクトに入ったことあるけど、タイムラインとチェンジセットビューアのこと教えたら結構みんな見るようになったので少しは役立ったのだろう。

その次にチケットを使っていけばいいだろう。

ドキュメントもSubversionで管理するかどうかは現場次第だろう。
管理したほうがいいだろうけど、その場合ドキュメントをいじる全員（開発者じゃない人も含まれる可能性がある）がTortoiseSVNを使えないといけない。
これが難しそうだったらファイルサーバでいいだろう。
中途半端にファイルサーバとSubversionの二重管理になったら混乱してしまう。

あとTracのワークフローが貧弱だという話は良く聞くけど、個人的にはまったく困ってない。たいていnewの後はclosedにしてるからw　

まあメンバーの数が多い場合はリーダーが担当者を決めたり、closedにするのは担当者以外とかにしたほうがいいのだろう。

ガントチャートもいいとは思うが進捗率とか絶対入力されないだろうなって思う。ま、チケットの進捗は0か100かだと思うので実際にいらないんじゃねとか思ってる。消化したチケットの数で進捗をはかるのはありだと思う。これもチケットの粒度によるだろうが。

顧客向けの進捗と内部向けの進捗は違うということもある。前者はフィーチャー単位で後者はタスク単位になるだろう。なのでまずはExcelかMS Projectになるのかなと。

チケットの親子関係が定義できて、それがうまくスケジュールとして表示できるようならMS Projectもいらなくなるだろう。

Tracもプラグインを駆使すればかなり高度なことができるけど、プラグインの使い方がよくわからなかったり、現場の実態に会わなかったりする。

まずは現状にあった運用方法を考えていく必要があるのだろう。

Tracが常識になりつつあるのは日々実感しているので、いい運用方法を見つけていきたい。