前回は、1000人のエンジニアがRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。
1. Redmineのオブジェクト構造を理解した方がいい
Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。
プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ
注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考えるとよいです。
2. プロジェクト名は「プロジェクト」か「組織」がいい
プロジェクトには期限がないため、例えば、「○○チームのタスク管理」といったものを作ることができます。しかしながら、普通に「○○プロジェクト Phase1」「○○プロジェクト 2010 1Q」という名前をつけてもいいと思います。両者を比べてみるとどうなるでしょうか?
- 期限なしのプロジェクト名をつけると・・・
- ○ チケットが集約されるので管理がしやすい
- × 徐々にチケットが増えると検索が重くなってしまう
- 期限ありのプロジェクト名をつけると・・・
- ○ そのプロジェクトの情報のみを集約できる(情報制度UP・検索速度UP)
- × プロジェクトをアーカイブ化したときに検索できなくなってしまう
- × 分け方に注意しないと細かいプロジェクトがたくさんできてしまう
などなど。一長一短であることがわかりました。
私の経験では、プロジェクトを分けすぎて失敗し、「○○チーム2010」のような組織+年としてみて、年をまたぐチケットで困った経験があるので、シンプルに「○○チーム」という閉じないプロジェクトを作って運用しています。チケットの増加による検索遅延を防ぐために、「過去の思ひ出」というプロジェクトを作り、定期的にチケットを移動しています。
自分の会社がプロジェクトベースの管理をされている場合は、プロジェクト名をつけたほうがフィットするでしょうし、サービス開発のようなインクリメンタルな開発の場合は、組織名やサービス名で作るとよりアジャイルを意識する形になります。
3. バージョンは「ストーリー」か「期間」で考えたほうがいい
バージョンには期限を設定できます。バージョンは、アジャイルでいう「イテレーション」「スプリント」として使うことが出来ます。また、Redmineの本家のページのように「1.2.0」といったプロダクトのバージョン番号を使うことも出来ます。
また、バージョンをストーリーとして扱うことも出来ます。パーキングロットチャートプラグインを使って、バージョンをストーリーカードのように表示することができるので、バージョンにはストーリー名をつけ、顧客との調整でパーキングロットチャートを使っているという話も聞いたことがあります。
私は、当初「Sprint 1」などにしていたのですが、途中で「次は12だっけ?あれ、今12か?」と混乱してしまったので、「2010/01/01~2010/01/14」といったスプリントの期限をバージョン名にしています。
コメント
[…] 3年使ったRedmineの使い方について共有したい10のこと こちらは大規模プロジェクトでの話のようですが, プロジェクトの規模に関係なく適用できそうなことは参考にさせていただきました […]
[…] 3年使ったRedmineの使い方について共有したい10のこと http://blog.local-c.com/archives/53Redmineでのプロジェクト管理はじめました。LOCAL COLOR BLOG […]
[…] 3年使ったRedmineの使い方について共有したい10のこと […]