いつものように、システムを構成するときは、自分のニーズに合わせてできる限りカスタマイズする必要があります。個人的には、Redmine 自体のガイドラインや推奨事項については知りませんが、ここで行っていることを関連付けることはできます。:-)
機能/バグ/メンテナンスは、タスクをフィルタリングできるようにラベルを付ける方法にすぎません。これらは、Redmine で「トラッカー」として知られる特定のラベルです。追加のタイプのタスク用に独自のトラッカーを定義できます。
プロジェクトとサブプロジェクトも効果的にタスクにラベルを付ける方法ですが、それらをより広い包括的なカテゴリにグループ化します. 「プロジェクト」を作成するときは、必要なトラッカーをプロジェクトに割り当てます。私たちの場合、API を作成し、タスクがデスクトップ プログラマー向けか dsp プログラマー向けかを識別できるように、(事実上) 重複したトラッカー名でバグ、機能、および変更を識別するための個別のトラッカーを用意します。サブプロジェクトは、お客様が特定のサポートを必要とする製品ラインまたはカスタマイズを特定するために使用されます。また、バージョン ラベルを使用して各サブプロジェクトの特定のリリースを識別し、追跡しているすべてのタスクの優れたロードマップ ビューを取得できるようにします。Redmine システムには複数のプロジェクトがあり、それぞれが同様の方法で構成されており、一部のプロジェクト タスクはプロジェクト間で「
これは Redmine を構成する 1 つの方法にすぎませんが、いくつかのプロジェクト間の複雑な関係を考えると、管理できる最も簡単な方法です。これは私たちが試した 2 番目の構成であり、うまく機能することがわかりました。参考までに、最初の構成は、数年前に Trac から移行した後、システムから必要なものを見つけ出すためのテスト システムでした。現在の構成は約 2 年間使用されており、私たちのニーズにうまく合っているようです。
先に述べたように、システムから何が必要かを決定する必要がありますが、最も簡単なアプローチは、プロジェクトをトップダウンでどのように見るかを考え、システムをプロセスに合わせて構成し、プロセスを変更してシステムに合わせないようにすることです。ツール-常により「悲惨な」オプションのIMHO。バグや機能などを別のプロジェクトで追跡することはお勧めしません。ロードマップをまとめるのは通常難しく、特定のプロジェクトの総タスク負荷を視覚化することも難しくなります。複数の製品リリース サイクルをサポートする必要があり、Redmine システムの管理という点で作業負荷が増えるとわかった場合、作業が複雑になるため、タスク タイプをサブプロジェクトに分割するだけでも問題が生じる可能性があります。
今のところ思いつくのはこれくらいです。お役に立てば幸いです。:-)