Redmineの使い方ベストプラクティスを考えてみる

感想おまちしてます!

RedmineやTracのようなBTSはデータの持たせ方でいくらでも使い道が広がる。
しかし、裏を返せば、なんでもできるからどうやったらいいかが分かりにくかったりする。

そこで、これまでの経験から、最低限の使い方をきめておこうかと。

Redmineはデフォルトの状態(Ver0.8.0)として、カスタムフィールドは使わないで、使い方のベストプラクティスを考えてみる。

スポンサーリンク

トラッカー

トラッカーは以下を作成する。

  • 設計
  • 開発
  • テスト
  • バグ
  • 運用
  • 会議

プロジェクトで使う場合は、だいたい上記作業が大分類になると思うので、トラッカーは作業大分類としている。「要件定義」とかもあるなら入れてもいいかもしれない。

ステータス

初期は「新規」。作業に入ったら「担当」。終わったら「終了」。この3つだけ使う。やらなくてよくなった作業は進捗を100%にして「却下」に設定してCloseする。

優先度

これはそのまんま使う。

担当者

やる人。もしくは作業の中心になる人を設定する。
これはリーダーがアサインする場合と、自分で自分に設定する場合、自分が他人に譲ったり譲られたりする場合がある。

Version

マイルストーンとなるものを設定する。アプリとかのVersionみたいに、バージョンをマイルストーンにする場合があまりなかったので、「○○アプリ Phase1リリース」とかが多かった。

Versionには、ある時間になったらチケットがなくならなければならないようなマイルストーンとなるものを入れるべき。

カテゴリ

トラッカーで大分類を決めたので、中分類となる。藤原の場合は、プロジェクトで作る機能でわけていた。
MVCモデルに合わせて、画面・ビジネスロジック・DAO・・・みたいにしてもいい気がする。

カテゴリは入力を減らすために使わないという手もある。藤原はカテゴリを使わないで入力を減らす派。

開始日/期限日

開始日予定日と完了予定日を入れる。

予定工数

そのまま。

進捗

そのまま。
この値は停止はすれど、下がることはあり得ないとする。
作業が思った以上に増えた場合は、別にチケットを増やせばいい。

おわりに

MSのプロジェクトだと大中小分類とかができるが、それをカテゴリとかでがんばるよりは、カスタムフィールドを3つ作ってカテゴリを使わないほうが使いやすかった。

タイムトラッキングのデータは、管理者だったらかなり欲しい情報なので、正確な時間をいれてもらうようにしたほうがいい。
わけあって急ぎでタイムトラッキングデータをとれる大豆プラグインを作ったけど、ほしい情報をまとめて、プラグインをちゃちゃっと実装すれば、週や月で報告するデータもリアルタイムで取得できるようになる。

また、Redmineを使っていて思ったのが、使わない人もいれば使えない人もいるということ。

使わない人は使わざるをえないようにすべき。作業を見える化することには作業者としても意味がある。

使えない人は、使えるように管理者が指導すべき。作業をブレークダウンできない人間が、作業を確実に完了できるわけない。経験や勘とかに頼ってられないので、最初は管理者がチケットを切ってあげるとかでもよい。

最終的に、各自が自分のやるべきことを自分で整理できるようになれば、そのプロジェクトはきっといいメンバーが集まったといえるんじゃないかな。

なによりも、自分のチケットが終わればそれで終わりとならないように、Redmineを使って管理コストを下げた分、設計のMTGに時間をかけたり、課題のディスカッションを開いたり、飲みに行ったりして、プロジェクトメンバー間のコミュニケーション時間をとることがとても重要。

管理者は、作業者がハッピーに作業できるように、努力をすべき。