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開発の歴史から得られたノウハウがたくさん詰まっているのだ。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 文化は組織構造に従う(2021.01.19)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
- カンバンはステータス名が大事(2021.01.02)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- プロジェクトマネージャーの資質として重要なものの一つに『曖昧さへの耐性』がある(2020.12.11)
「Redmine」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- RedmineをPJ管理ツールと呼ぶのは嫌いだ、Redmineはチケット管理ツールと呼ぶべきだ(2021.01.02)
- PMO観点でRedmineの使い方とは何か(2020.12.20)
- 若手プロジェクトリーダー向けのRedmine教育資料の構想(2020.12.24)
「ソフトウェア工学」カテゴリの記事
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
- 相殺フィードバックを再考(2020.06.17)
- SaaSのビジネスモデルがアジャイル開発を促進したという仮説(2020.06.14)
- なぜなぜ分析、FMEA、FTAの違い(2020.06.09)
「Git・構成管理」カテゴリの記事
- YoutubeのCCNA講座が秀逸だった(2021.01.04)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- RedmineでGitのbareリポジトリにアクセスする方法(2020.10.22)
- 第16回東京Redmine勉強会の感想 #redmineT(2019.05.19)
- 第19回Redmine大阪の見所 #redmineosaka(2019.01.26)
「チケット駆動開発」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
- チケット管理ツールの用途が変わってきている(2020.10.28)
「Agile」カテゴリの記事
- 文化は組織構造に従う(2021.01.19)
- 「ストーリーマッピングをはじめよう」本の感想~ストーリーによる企画や要件定義はSaaSと相性がいい(2021.01.17)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
- yWriterは映画の脚本を作るためのアプリだったのではないか(2021.01.05)
- カンバンはステータス名が大事(2021.01.02)
コメント