私流のTracの使い方

公開日: : 最終更新日:2014/04/20 開発環境


プロジェクト管理システムである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できないと、フラストレーションが溜まったりもします。

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

広告

関連記事

Jenkins + iPhoneアプリ(番外1) -TestFlightを利用する-

* これまで - -- 執事(Jenkins)を雇いました。 * やりたいこと Jenk

記事を読む

no image

Capistranoで簡単デプロイ -開発用サーバー編-

cakePHPを使って開発しているサービス()で、リリース周りを楽にしたいなと思いCapistran

記事を読む

no image

ターミナルでgitのコマンドを補完したりブランチ名を表示する – macでgitを便利に使うために –

* やりたいこと macのターミナルでgitをいじっていると -今のブランチってなんだっけ? -g

記事を読む

jenkins-files

Windows環境でもJenkins -執事さんとご対面-

Trac Lightningに同梱されていますし、Windows環境でHudsonを使っている人は結

記事を読む

no image

さくらのVPSでJenkins -執事さんとご対面-

さくらのVPSを利用している方は多いかと思います。 私も、自分で遊ぶ用(開発用)として借りてみまし

記事を読む

WordPressプラグイン「WP Hatena Notation」にPullRequestを投げた話

WordPressではてな記法が利用できる「WP Hatena Notation」を重宝しています。

記事を読む

Jenkins + スマホアプリ(1) -スマホアプリ用CI環境を作ってみよう-

前回までは、iPhoneアプリでのCI環境でした。 TestFlightがAndroidアプリにも

記事を読む

Jenkins + iPhoneアプリ(1) -執事を雇う-

アプリ開発をしていると、自動化出来るところは自動化したくなってきますよね。 開発しているアプリも増え

記事を読む

githubを使っての開発(1) -実践github-flow-

今は開発でgithubを利用しています。 開発をおこなう上で、githubをどのように扱えば良いの

記事を読む

スクリーンショット 2013-04-27 11.46.12

githubを使っての開発(2) -masterブランチにマージ-

前エントリーでgithub-flowをもとにした流れを書いたのですが、その中のマージについてもう少し

記事を読む

広告

Message

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

次のHTML タグと属性が使えます: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

広告

no image
[感想] Effective Objective-C 2.0 ☆☆☆☆★(4.5)

* 構成 - 第1章 Objective-Cに慣れる -

no image
[感想] iOSアプリテスト自動化入門 ☆☆☆(3.0)

* 構成 - Chapter 1 テスト自動化への取り組み

DeployGateを試してみた(iOS編) -DeployGateがiOSに対応-

今までのDeployGate - -[http://pplace.

iPhone/iPadアプリを開発するためにやったこと

今までに、iPhoneを3本ほどリリース((リリースしたアプリは全て1

no image
ターミナルでgitのコマンドを補完したりブランチ名を表示する – macでgitを便利に使うために –

* やりたいこと macのターミナルでgitをいじっていると -今の

→もっと見る

PAGE TOP ↑