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開発の歴史から得られたノウハウがたくさん詰まっているのだ。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
「Redmine」カテゴリの記事
- 「Redmineハンドブック」は良い本です(2022.12.17)
- 第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT(2022.11.06)
- 第22回東京Redmine勉強会の感想 #redmineT(2022.05.29)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった(2022.04.24)
「ソフトウェア工学」カテゴリの記事
- DDPは品質管理に役立つのか(2022.12.13)
- 組合せテストにおける因子と水準はどちらを最優先で考えるべきか(2022.12.04)
- XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた(2022.11.16)
- 第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT(2022.11.06)
- Javaのモジュールシステムの考え方をまとめてみた(2022.10.21)
「構成管理・Git」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
- 第21回東京Redmine勉強会の感想 #redmineT ~Redmineは業務も組織も包み込む柔軟性がある(2021.11.28)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- DDPは品質管理に役立つのか(2022.12.13)
- UMTPモデリングフォーラムのパネル討論の感想(2022.11.29)
- XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた(2022.11.16)
コメント