TracやMantisによるチケット駆動開発の運用方法
最近、RedmineではなくてTracやMantisを使う機会が多い。
チケット駆動開発をTracやMantisで運用する方法について考えたことをメモ。
【チケット駆動開発を運用する時の注意点】
Redmineでなくても、TracやMantisでもチケットをXPのタスクカードのように扱うことはできる。
BTSのチケット管理をプロジェクト管理に置き換える発想は、Redmineの場合と変わらない。
しかし、Redmineに比べると、TracやMantisによるチケット駆動開発とAgile開発を組み合わせて運用するためには、いくつかのノウハウが必要だ。
僕の経験では、Redmineに比べるとTracやMantisは、イテレーション管理とSCM連携がやりにくい。
【1】Agile開発の基本である小規模リリースを実現するには、イテレーションをBTSに実装しなければならない。
Redmineなら、バージョンがそのまま当てはまるのですごく自然だ。
しかし、そのイテレーションをTracやMantisへ当てはめるにはノウハウが必要。
その内容については以前書いた。
バージョンのないRedmineプロジェクト~TiDD初心者が陥りやすい罠: プログラマの思索
Agile開発の肝はイテレーションにあり: プログラマの思索
つまり、TracやMantisにもバージョンの概念はあるし、ロードマップの機能もあるので、それを流用すればいい。
例えば、Mantisのロードマップや変更履歴は下記のようになるから、バージョンをリリースしたバージョンでリネームする運用にすればいい。
Tracのロードマップも同様。
【2】又、まちゅさんが発見したプラクティスである「No Ticket, No Commit!」のご利益を被るには、BTSにSCM連携の機能がなくてはならない。
Redmineなら、SCMリポジトリを簡単に閲覧できるだけでなく、「fixes」「refs」などのコミットログを使い分けるとステータスを自動更新できる機能があったり、チケット単位にSCMリビジョンの履歴を表示してくれたり、機能が豊富だ。
RedmineがExcelよりも素晴らしい点: プログラマの思索
チケット駆動開発でXPの計画ゲームを実施する: プログラマの思索
しかし、TracやMantisでは、コミットログとチケットNoをそもそも紐づける設定方法が結構面倒。
だから、サポートするためのいくつかの方法が必要だと思う。
Mantisなら下記のように、SVNコミットフックのスクリプトを用意して、MantisへログインするSVN用ユーザを作り、コミットするとコミットログのチケットNoがリンクする仕掛けを準備する必要がある。
むしろ、TortoiseSVNに元々付属しているBTSと連携する機能を使った方が楽だ。
その方法については、以前からよく知られている。
Tracなら下記のやり方がある。
ソフト/Bug Tracking/trac/TortoiseSVNやSubclipseとチケットを連動 - discypus
TracDoc/TortoriseSVNTrac -- HirobeのHack倉庫 -- Trac
もちろんMantisでも方法は同様だ。
TortoiseSVNとITS・BTSの連携 - idesaku blog
※TortoiseSVNからBTSへ連携する方法については既に過去に調べているので、下記もご参考下さい。
TortoiseSVNからBTSと連携する: プログラマの思索
TortoiseSVN から Redmineと連携する: プログラマの思索
TortoiseHgもRedmineチケットへの接続をサポート: プログラマの思索
但し、MantisやTracでは、チケット単位にSCMリビジョンを表示してくれる機能はないみたい。
ソースからチケットNoを辿ることはできるけれど、チケットから関係するSCMリビジョンに辿るのは自動化されていないように思う。
SCM連携の利点は、要件からビルドモジュールまでのトレーサビリティを実現してくれることにある。
このトレーサビリティによって、機能追加の影響調査や障害修正時の同類バグ調査がやりやすくなる。
だから改善の余地はあると思う。
【3】でも、TracやMantisを使ってみて、Redmineとは違う発想のBTSなのだと思うようになった。
Tracはクエリ機能のおかげで、レポート出力の機能が豊富。
自分でSQLを書けば、いくらでも好きなレポートを出力できる。
そして、TracはBTSの中で最もWikiが書きやすい。
共有したい情報があれば、Wikiに自由に書いていけばいい。
Mantisは障害管理だけに使うならば、BTSの中で最強だと思う。
Mantisチケットのレイアウトはまさに障害報告票をWeb化した形式なので、テスターやプログラマは特に違和感なくBTSを運用できるだろう。
又、Mantisのチケット一覧は、ステータスごとに色分けしてくれるので、カラフルで見やすい。
各種BTSを触ってみた感想は、BTSの運用こそがSW開発の基本のような気がしたこと。
BTSの機能には、世界中の開発者のベストプラクティスが含まれている。
BTSには、過去のSW開発の歴史から得られたノウハウがたくさん詰まっているのだ。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「Redmine」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
「ソフトウェア工学」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
「構成管理・Git」カテゴリの記事
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
「チケット駆動開発」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
「Agile」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーにおける4チームのインタラクションをUMLで整理してみた(2025.01.12)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
コメント