Mantisの使い方
RedmineやTracよりもおそらくBTSで最も使われていると思われるMantisについて、ロードマップの設定方法がようやく分かったのでメモ。
【元ネタ】
バグ管理システム「Mantis」 - SourceForge.JP Magazine : オープンソースの話題満載
akky’s log ? Blog Archive ? mantisのroadmapを試してみたよ
Mantisでロードマップを使うには、下記の設定を行う。
1・プロジェクト設定画面のバージョンの編集で「リリース」のチェックを外す
→チェックを付けると、そのバージョンはリリースされたので、ロードマップに表示されなくなる。
2・チケット(詳細)の登録画面で「修正予定バージョン」にバージョンを設定する。
→リリース予定のバージョン(Target version)になる。
上記の設定によって、チケットがバージョン単位にグループ化できるので、Mantisを使って小規模リリースを運用しやすくなり、アジャイル開発を実践できる。
更に、Mantisの変更履歴を使うには、下記の設定を行う。
3・ロードマップ設定後、プロジェクト設定画面のバージョンの編集で、リリースのチェックを付ける。
→チェックを付けると、そのバージョンはリリースされたので、変更履歴に移る。
4・チケット(詳細)の登録画面で「修正済みバージョン」にバージョンを設定する。
→リリース済みのバージョン(Target version)になる。
5・完了チケットの「解決状況」が「実装済」のみ、変更履歴に掲載される。
完了チケットでも解決状況が「修正不要」ならば、変更履歴に掲載されない。
Mantisは、RedmineやTracよりもはるかに障害管理ツールの色彩が強い。
MantisのチケットはExcelの障害報告票をそのままWeb化したようなフォーマットだし、そのワークフローも障害管理のワークフローそのものになっている。
Mantisの一番の特徴は、チケットの検索結果一覧で、ステータスごとに色分けしてくれるので、一目でチケットの作業状態が分かること。
又、MantisはPHP+MySQLで動くので、インストールも簡単。
ソフトウェア開発のBTSを選ぶ時、RedmineやTracの運用が難しければ、Mantisから入った方が楽ではなかろうか?
そして、Mantisのチケットを単なる障害管理だけでなく、課題管理や要望の管理まで拡張すれば、BTSだけでなく、ITSとしても運用できる。
つまり、Issue TrackingとしてもMantisは使える。
MantisはRedmineやTracと比較して、Wikiが無かったり、SVNなどのSCMとチケットを連携する機能がデフォルトでなかったりするが、チケット管理そのものの機能は同等だ。
Redmineを使ってみて、ロードマップ機能の重要性が十分に分かったので、Mantisでも同様に使えると、威力を発揮するはず。
RedmineやTracでなくとも、Mantisでもチケット駆動開発は運用可能だし、アジャイル開発の運用も楽になるはずだ。
| 固定リンク
「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)
「チケット駆動開発」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
- チケット管理ツールの用途が変わってきている(2020.10.28)
コメント