Redmineの運用例その2

Redmine運用例の記事があったのでメモ。

【元ネタ】
[Think IT] 第2回：ProjectKeeperに見る開発方法論 （1/3）
[Think IT] 第2回：ProjectKeeperに見る開発方法論 （2/3）
[Think IT] 第3回：SIOS Applicationsの過去未来 （1/3）
[Think IT] 第3回：SIOS Applicationsの過去未来 （2/3）
[Think IT] 第3回：SIOS Applicationsの過去未来 （3/3）

【特徴】
プロジェクト管理ソフトウェアProjectKeeperのタスク管理にRedmineを使っているらしい。
WebSphere＋DB2で動作するから、IBM系列と思われる。
記事を読むと下記の運用ルールがあると思われる。

1・Redmineには、製品ロードマップ、顧客要望、バグ情報などが一元管理されている。
　変更管理/構成管理は、Excel＋CVSからRedmine＋Subversionへ移行した。

2・トラッカーは「要望」「機能拡張」「障害」の3種類がある。

3・「要望」はストーリーカードのような位置づけ。「承認済み」ステータスになると「機能追加」のチケットへタスク分割される。

4・「要望」は下記のステータスになる。
オープン→承認待ち→承認済み→対応中→対応済み

5・「機能拡張」「障害」は下記のステータスになる。
オープン→アサイン済み→開発中→確認アサイン済み→確認中→終了

6・全てのソース修正にはチケットを必要とするルールがある。

7・単体テストと結合テストのテストケースはTestLinkでテストケース、実施記録を一元管理している。

8・TestLinkを導入したが、担当者が手動でテストを実施している。テストの自動化はできていない。

興味深いのは、「要望」を要件管理、「機能追加」は実際の開発のタスク管理に使い分けていること。
しかも、要望のチケットが承認後に、タスクに当たる機能追加のチケットが作られていること。

ストーリーカードが決定されたタイミングで、タスクカードが作られる運用がされているようだ。
これは、RedmineのScrumプラグインと同じ機能だ。
この機能が実現されなければ、変更管理、要件管理を制御するのは非常に難しいだろう。

また、TestLinkも導入しているのが興味を惹く。
TestLinkを運用している利点の一つは、過去のテストケースを再利用しやすいこと。
どこまで運用されているのか分からないが、この利点が品質向上につながってるのだろう。

惜しむらくは、Redmineサマリが公開されていないこと。
Ruby1.8やSKIPのように、Redmineサマリが公開されていれば、そのチームの運用ルールは一目で分かる。

Redmineチケットの属性にあるトラッカー、カテゴリ、バージョンをどのように決めるか、という点は、まさにRedmineサマリという進捗報告のために存在すると言っても過言でない。