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サマリという進捗報告のために存在すると言っても過言でない。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「Redmine」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
「ソフトウェア工学」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
「TestLink」カテゴリの記事
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- TestLinkの要件管理にUSDMを適用する方法(2023.01.22)
- TestLinkのテストケースはクラスとインスタンスの考え方で区別する(2023.01.22)
- テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク(2022.09.24)
- テスト管理ツールTestRail、CAT、QualityForwardの感想(2022.07.30)
「チケット駆動開発」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
コメント