« 金曜にバグを発生させるコミットが多い | トップページ | 最近の技術のトレンド~分散バージョン管理と関数型言語 »

2009/04/27

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サマリという進捗報告のために存在すると言っても過言でない。

|

« 金曜にバグを発生させるコミットが多い | トップページ | 最近の技術のトレンド~分散バージョン管理と関数型言語 »

Redmine」カテゴリの記事

TestLink」カテゴリの記事

ソフトウェア工学」カテゴリの記事

チケット駆動開発」カテゴリの記事

プロジェクトマネジメント」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/49479/44815444

この記事へのトラックバック一覧です: Redmineの運用例その2:

« 金曜にバグを発生させるコミットが多い | トップページ | 最近の技術のトレンド~分散バージョン管理と関数型言語 »