私流のTracの使い方

プロジェクト管理システムであるTracを数年前から使っているのだけど、使い方が人によってまちまちだったので、私の使い方を以下に紹介。
※TracをBTSだという人もいるとは思いますが、私はプロジェクト管理システムと呼ぶことにします。

　最初に

Tracがあるメリットってなんなのか？

Tracがあると

• 他のメンバーがいつ何をおこなったか
• 現在、どれぐらいタスク(実装内容やバグ内容など)が残っているのか
• バグが起きたのは何が原因だったのか

このようなことが視覚化されます。

しかし、あくまでもどうやってこのプロジェクト管理システムを運用していくかが大事で、「とりあえず使ってみよう」では破綻してしまいます。
私が利用してきた環境は以下のような感じ。

• Trac(＋プラグイン追加)
  • プロジェクト管理システム
• Subversion
  • バージョン管理システム
• Hudson/Jenkins
  • 継続的インテグレーションツール

※だいたい2名～10数名のプロジェクトで利用してきた。
※100名前後のとこでも利用したことあるけれど、その時は管理者不在状態だったのでプロジェクト管理システムといえる状態ではなかった。

　[大前提]タイムラインが何より大事

メンバーの誰が何をやったかを簡単に把握するには、タイムラインが非常に大事。
そのため、Hudson(Jenkins)のビルド結果、チケットの変更もタイムラインに表示するようにしています。

タイムラインを適切に活用する上では、ソースをコミットする際でもチケットを記述する際でもコメントは必ずTracのWiki記法で書くということが大事です。
そうすることで、タイムラインを見て一目で何をやったか分かりますし、チケットなどにもすぐに飛べます。

コメントに何も書かなければ、そのソースのコミットは何をやったのかが分かりませんし、チケットは何を更新したかも分かりません。
コミットされたソースをいちいちチェックするのは労力がかかります。

この方針のもと利用するとタイムラインを見れば、だいたい何がおこなわれたか分かります。

以下の3つは、大前提に対する追記です。

　[1]TracのWiki記法を利用する

TracのWiki記法を覚えれば見た目が良くなるだけでなく、便利になります。

簡単なものであれば以下。

• #124と書けばチケット#124にすぐに飛べるようになります。
• [1]と書けばチェンジセットの1にすぐに飛べるようになります。

これ以外にも色々な書き方があって、適切に使えば非常に便利になります。

　[2]Subversionでコミットをする際はコメントをTracのWiki記法で必ず書く

ソースをコミットする際には、必ずTracのWiki記法を用いて記述します。
例えば、あるチケット#241に関するソースをコミットする際は、以下のように記述します。
– (refs #241) 更新処理のValidationの抜け落ちを修正。

　[3]1日のはじめと終わりにチケットとタイムラインをチェック

1日のはじめにタイムラインを確認し、他のメンバーが何をやったかを把握します。
これにより、ミーティングでの無駄な会話を減らすことが出来ます。

1日の終わりに自身の関係するチケットをチェックし、進捗状況を書いておきます。
この行動により、他のメンバーに何をやったかが伝えられます。

　チケットはチケットテンプレートを利用して記述内容のブレを無くす

チケットの書き方は何も方針がないと人によってばらつきます。
そこで、チケットテンプレートを利用し統一させます。

• チケットテンプレート

以前、チケットに以下の内容(例です)を書く方がいました・・・。

タイトル：○○をして欲しい
内容：○○をして欲しい

書いたのは営業さんでしたが、上述の内容では詳細が全然分からず、本人に確認を取らないといけません。
細かく書いてください！といっても、なかなか難しいのでテンプレートを用意するのがベターです。

チケットのテンプレート(バグの例)は以下のような感じです。

= 内容 =

= 再現手順 =
== 再現環境 ==

• 使用ブラウザ：
• 使用PC：

= 原因 =

= 関連 =
［［TicketQuery(keywords=~キーワード)］］

他にも色々ありますが、上記のようなことを徹底しています。
Tracなどのようなシステムを用意して、「使って！」といってもなかなかうまくいきません。
とりあえずは、上記のように何かしら使用方針などは決めておきたいものです。

最後に、上記の方針のもとにやっていても問題は多々出てきます。
以下が解決できない今後の課題の中の1つです。

[未解決]チケットの粒度をどうするのか

チケットの粒度はチケット作成者によってまちまちだったりします。
1つのチケットを処理するのに1人月かかったりするのもあれば、1人日で終わるのもあったりします。
あまりに、時間がかかるとチケットに書かれるコメントも増え、非常に見づらいです。
※チケットが延々とcloseできないと、フラストレーションが溜まったりもします。

どの程度の粒度が妥当なのかは、能力に依存するところもあるのでなかなか決めるのが難しいです。
まとめチケットを用意して、子チケットを用意するということもやりましたが、なかなかうまくいきませんね。