自分はSIerの公共部門で勤務しています。
SIerなのでパッケージを構築することもあれば、パッケージをカスタマイズ導入することもあります。
独特とは思いますが、カスタマイズ導入に関してのRedmine運用に関してはあまり資料がありません。
弊社での運用を晒そうと思います。
プロジェクト名について
プロジェクト名はパッケージ名を使用しました。部としてRedmineを導入しているので、取り扱うパッケージ単位で管理するのが楽だと思いこうしました。
カスタマイズの場合は、パッケージ毎に子プロジェクトで納入先を登録しています。
リポジトリでいうとtrunkは親プロジェクトに、branchを納入先(子プロジェクト)で登録しています。
親プロジェクトはバージョンアップの管理、子プロジェクトはtrunkマージと個別カスタマイズを管理しています。
trunkマージは親プロジェクトでチケット生成時にRedmineの機能で子プロジェクトにコピーしています。
バージョンについて
親プロジェクトは通常？のバージョン管理をしています。1.0系とか1.1系みたいな感じです。
子プロジェクトはお金の発生単位で管理しています。
例えば○○法改正対応とか、○○年度保守とかです。
保守でバージョンが存在するのは、公共系は年度単位の予算で動いているからです。
※保守費内での法改正対応等
チケットについて
親プロジェクトのチケットは一般的な使い方です。子プロジェクトのチケットが独特です。
大体ストーリー(要件定義)1件につき1チケットで切ってます。
1件のカスタマイズが複数のユースケースに対して影響がある場合は子チケットを用意します。
EX：画面項目追加のカスタマイズが照会と発行のユースケースにかかる場合
SIerはなんでも管理したがるものです。
どのカスタマイズに何人日かかったかとか。
別で管理するのが面倒なので、Worktimeプラグインを導入してチケット消化にかかった時間を記録しています。
チケットのステータスはカスタマイズを行っています。
SIerにありがちですが、製造を一部外部委託する事があります。
受け入れ工程を登録しています。
コミットブロックについて
Redmineは素晴らしいツールですが、使ってもらわないとただのサーバの肥やしです。アーキテクトが握るSE・プログラマに対するただ一つの弱み？はコミットブロックです。
チケットが存在しない場合はコミットができないようにしています。
一応以下のコミットブロックルールを設定しています。
・チケット番号+コメントが入力されている事
・入力されたチケット番号がRedmineに存在すること
※branchと子プロジェクトも一致させる
・チケットがクローズされてないこと
LDAP連携
いつも使い慣れたIDとパスワードで入れるので、使用敷居を下げるのに一定の効果があると思っています。使わない手はありません。
最後に
ツール導入後に口を酸っぱくSE達にいってるのが、口頭でのコミュニケーションです。これに勝る物はありません。
課題
r-labsを参照していると、Wikiをトップページに持ってこれるみたいです。TOPがごちゃごちゃしてきたので、別ページを作成して飛ばしたいです。