Hatena::ブログ(Diary)

kanonjiの日記 RSSフィード

http://kanonji.info/blog/ 2013年2月頃に移転しました。

2009-08-09

TracLightningをインストールしたのでメモ(3) チケット関連の設定

TracLightning 2.2.5をインストールし、大まかな全体への設定が終わったので、次はチケット関連の設定をしていきます。

チケットをどんな風に使いたいかによって変わるので、あくまで一例です。

書き終わってからよく見てみたら、例になってるのは優先度だけだったり・・・。

まぁ何を作ってるかやプロジェクトによって違うからしょうがない。


Tracプロジェクト毎に設定します。管理権限*1のあるユーザーでログインして、管理コンソールを開きます。

サンプルデータを削除する

コンポーネント、バージョン、マイルストーンには、サンプルデータが入っていて邪魔なので、とりあえず消します。

優先度

初期設定
  1. 重大
  2. 緊急
  3. 高(デフォルト)

初期設定では、この様になっています。

この設定だと、どんな基準で優先度を設定するのが良いのか、よく分かりませんでした。

  • 何故か「高」がデフォルトになっている。
  • デフォルトより優先度が低い場合に「中」と「低」どちらを付けるか、毎回迷いそう。
  • 「重大」と「緊急」のどちらが優先なのか、ぱっと見で分かりにくい。
こうしてみた
  1. 直ぐやる
  2. 早めに
  3. 普通(デフォルト)
  4. 後回し
  5. 多分やらない

基本的に「普通」と前後の「早めに」「後回し」の3段階で使い分けていきます。

特別扱いで、直ぐに対応する必要のある場合に「直ぐやる」を使います。

「多分やらない」はやる必要はないんだけど、出来るならやりたいとか、状況が変わったら優先度が上がるけど今はいらないというような場合に使います。

基本3段階の上下が特別という点については、見ただけでは分かりにくいですが、「直ぐやる」と「多分やらない」というラベルなら、そうそう気軽には使わないはず。

重要度

優先度ととてもよく似た重要度というものがあります。

 重要度(severity)は技術面での判断で,(バグの)深刻度,(作業の)難易度を表します。デフォルトでは項目は用意されていません。

 指標が2つ用意されているのは,優先度と重要度が必ずしも比例しないからです。極端な例ですが,「設定ダイアログを開いてDEADBEEF!とちょうど10回入力してOKを押すと必ずクラッシュするが,1文字でも異なると再現しない」というバグの場合,重要度は大きくします(クラッシュするので)が,優先度は低く(発生しにくいので)します。

http://itpro.nikkeibp.co.jp/article/COLUMN/20080731/311879/?ST=develop&P=6:title

これに書いてあるとおりですが、今回は重要度は設定しませんでした。

慣れないうちにあまり厳密な管理を強いると、多分使いこなせないので。

マイルストーンとバージョン

この二つもよく似ています。

マイルストーン
いつまでに対応するか。2.1のリリースまでに直したいなら2.1が入ります。
バージョン
どのバージョンに対してのチケットか。1.0系と2.0系がある場合、1.0系のみのバグがあったりすると思います。

まだリリース前の場合は、作業工程で分けたりも出来ます。

  • コアモジュールの完成
  • デザインの確定
  • 社内リリース
  • リリース

例えば、こんな感じ。

もうこの辺は、プロジェクト毎に違ってくるので、管理しやすいようにするのがいいです。

が、やっぱりセオリーとかパターンの様な、いい感じに収まる分け方があると思うので、その辺は調べていきたいところ。

ちなみに、今回はマイルストーンは設定中で、バージョンは使わないことにしました。

コンポーネント

チケット登録時に、どの機能に対してのチケットかを選ぶ為のものです。

サンプルで言うと、サンプルで言うと「ユーザー管理機能」と「検索機能」があって、どの機能のバグかという事ですね。

当然、プロジェクト毎に違うので、注意点だけ。

プルダウンで選ぶので、チケット毎に一つのコンポーネントしか選べない。

つまり、複数のコンポーネントにまたがるチケットは登録できません。

とはいっても、バグがコンポーネント毎に分かれて発生してくれたりはしないので、代表的なコンポーネントを選ぶ事になります。

なので、コンポーネントを細かく設定しすぎると、担当者の主観で似たバグのチケットで違うコンポーネントを選んだりと、情報が散らかってしまいます。

プルダウンで選ぶので、あんまり多いと選びにくい。

UIの問題ではありますが、あんまり細かくコンポーネントを設定すると、チケット登録が大変です。

10個くらいがちょうどいいという意見を見かけました。


チケットを活用する場合、どのくらいの作業毎に登録するかというチケットの粒度*2が難しいという話を聞きます。

チケットの粒度も、プロジェクト毎に違うし、開発現場によってやりやすい粒度も違うので、試行錯誤して調整していく事になると思います。

その際、チケットの粒度とコンポーネントの分け方は、割と密接に関連している気がします。

コンポーネントを細かくしすぎると、チケットの粒度も小さくなるはず。

解決方法とチケット分類

解決方法の初期設定
  • 対応済
  • 不正
  • 対応しない
  • 重複
  • 再現しない
チケット分類の初期設定
  • バグ
  • 機能追加
  • 仕様変更
  • タスク
  • 課題
  • 連絡

この2つは初期設定で割りと問題ない気がしますが、いくつか意図が分からない項目がありました。

チームメンバーにも確認して、みんなが同じ認識で使わないと、チケットが混ざって登録されてしまいます。

同じ分類にすべきなのに、人によってはタスクで、人によっては課題にしたり。


TracLightningは日本語化されているので、本来の英語を確認したら、意図が分かりやすいんじゃないかなと思ってますが、まだ確認してません。

  • 不正
  • タスク
  • 課題

自分としては、この辺が分かりにくいと思っています。

関連エントリー

*1:TRAC_ADMIN

*2:タスクの粒度とも

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証