QLOOKアクセス解析
ホーム   »  スポンサー広告  »  スポンサーサイト   »  Redmine  »  チケットの分類方法を考える

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

チケットの分類方法を考える

Redmineのチケット分類について私のプロジェクトでの例を紹介させて頂きます。

チケットの分類の方針は非常に重要です。
これを誤るとのちの工数集計も面倒になったり、場合によっては
必要なデータが残っていないという事態も発生します。

分類についてはそれぞれのプロジェクト特性によって
色々な方法があるかと思いますがご参考になればと思います。

◆プロジェクトの規模/特性
・10名~30名程度。開発フェーズによって増減。
・プロジェクト期間は半年~1年ぐらい。
・完全なウォータフロー開発。

◆やりたかったこと
1.機能 - モジュール - フェーズ - 作業単位で工数集計が可能であること
  ⇒例えば A機能のBモジュールの画面設計工数が集計出来ること
2.機能、モジュール定義はプロジェクト毎にカスタマイズが可能であること
3.仕様変更工数が「①」と同じレベルで集計可能であること。
4.機能-モジュール単位で進捗状況が確認したい。
  ⇒例えばA機能のXXフェーズでの残作業工数やチケット数。
  ⇒例えばA機能全ての残作業工数やチケット数。

◆チケットの分類イメージ
大きな方針は以下の4つ。
・機能や案件は『バージョン』で管理。
・フェーズは『カテゴリ』で管理。
・仕様変更は『カスタムフィールド』で管理
・その他の細かな作業はチケットの親子関係で管理。

イメージは以下の資料を参照。


◆参考記事
・実践Redmine カテゴリ設計にご用心
Comment
Trackback
Trackback URL
Comment Form
管理者にだけ表示を許可する
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。