BTS (Bug Tracking System)コミュの雑談

トピック作るまでもない雑談はてきとうにこちらで

コメント(28)

最初
全て
最新の40件

tracどうっすかね。

BTS勉強中で実装例をよくしらないのです。ちょこちょこと探してみるとTracというのにはBTSにWikiやSVNが混ざってるらしくて。ふむう

開発元がIssue Tracking and Project Managementといっているので、BTSではなくITSと呼ぶべきなのかもしれませんが。
http://www.portus.co.jp/atlassian_jira/index.php

今、試用版を使ってますが、商用だけあって、抜群に使いやすいです。

[4] mixiユーザー 07月05日 23:15

mantisを試験導入して啓蒙中です｡
オフィシャル配布の状態で日本語で中規模以上開発に使える
OSSのBTSがこれだったので…

BTSはインストールよりも啓蒙が肝心だし、開発側の人間が
一人エヴァンジェリストになればこっちのものだということを
実感したばかりです｡

[5] mixiユーザー 07月06日 13:28

チームの人数が増えると読むだけに徹しようとする
逆エヴァンジェリスト(?)みたいなユーザーが現れて
面倒だったりします。

[6] mixiユーザー 07月13日 00:45

皆様,SCMとの統合はどうされてますか？
使用しているSCMがCVSなので、scmbugで
mantisと繋ごうとしているのですが…

日本で誰もやってないんじゃないかというくらい情報が
少ないです（汗
scmbugのオフィシャルのマニュアルもいまいち分かりづらいし(汗
もうしばらくscmbugとの格闘が続きそうです。

#EUCのマルチバイト通らねーとかいうオチ,ないよねぇ。

ところで、mantisですが、ユーザの権限設定ができるレベルで
MySQLの運用ができれば,ものすごく導入が楽だと思います。
運用を考えたら,正しいダンプとリストアができること、という
条件もつきますが…

※MySQLはマルチバイトの取り扱いがPostgreSQLより面倒

インライン画像の使用や、書き込みに対して本名表示とか,
(デフォルトはユーザID表示)細かい設定項目を探すのが,
ちょっと面倒という欠点はあります｡

Scarabと比べると自由度は低いけれど,BTSとして使うだけなら
導入と保守のコストも小さいのはメリットだと思いますよ｡

[7] mixiユーザー 07月13日 20:11

はじめまして

影舞、Scarab、Mantis、Trac、JIRA等を試して

オープンソースなら今はMantisが良いかなと思っております。
商用だとJIRAがお気に入りです。

SCMは、CVSからSubversionに移行しました。

というbose...でございます。

よろしくお願い致します。

[8] mixiユーザー 07月25日 23:17

mantis1.0.5が出ました。
今回は細かいバグフィックスのようです。

ようやくscmbugでCVSとmantisをくっつけるやりかたが判明｡
ついでにCVSwebとmantisも統合できないかなぁ。

[9] mixiユーザー 07月25日 23:33

cvswebは危険だと言われてますね。LAN内専用ですか。

[10] mixiユーザー 02月24日 22:06

どうやら影舞が開発再開のようです。
http://d.hatena.ne.jp/h4y/

IIS & SQLServer & Rubyの構成で動作するので、ちょっと期待です。
職場ではMantisが浸透してきたところなので、使わないと思いますが。。。

[11] mixiユーザー 02月24日 22:08

あと、Starbug1の開発日記も見つけたので、ついでに。。。
http://d.hatena.ne.jp/smeghead/

[12] mixiユーザー 04月26日 23:35

こんな人気（ひとけ）のないコミュで質問するのも。。。ですが、みなさん、BTSのプロジェクトは、何を基準に分けていらっしゃいますか？

自分はパッケージプロダクト（ソフトウェア）の開発に携わることが多いのですが、BTSを利用する際、いつも迷うのが「どの単位でプロジェクトにするか」です。

初めはサブシステムごとにしていたのですが、「サブシステム間のインタフェース部分のバグは、どちらのバグか」など面倒なことになっていました。そこで、次は全体で１つにしてみたのですが、「数が多すぎて探しにくい」「自分の無関係なバグが多いので、あまり見なくなる」などの問題がありました。
さらにバージョンアップの際にプロジェクトを以前のバージョンと分けたところ、「旧バージョンで見つかったバグは新バージョンのプロジェクトにもコピーする」必要が出てきました。（両バージョンともサポート期間中なので、それぞれに対応する必要があるため。）

そんなこんなで、プロジェクトを大きくしたり小さくしたりしてきましたが、イマイチ良い「落としどころ」が見つけられずにいます。
みなさんは、どんな基準でBTS上のプロジェクトを分けられていますか？

[13] mixiユーザー 04月27日 04:09

BTSが使いやすくなるように分けます。
迷うなら細かい方に。

[14] mixiユーザー 04月27日 11:58

> BTSが使いやすくなるように分けます。

いやいや、どうやったら使いやすくなるかが分からないから、悩んでいる訳で。。。

> 迷うなら細かい方に。

やっぱり、「面倒がらずに、必要な分だけコピー」ってことですかねぇ。。。

[15] mixiユーザー 04月27日 18:26

その都度選択肢を並べて、その瞬間に使いやすいと思えるのはどちらかを選ぶだけです。
あとになって変わったら、また変えれば良いです。
変化を恐がらなければ、常にあらゆる時間帯で使いやすい状態が選択されていることになります。
抽出のための値は、カテゴリーだけではないので、
むしろカテゴリーの抽出のための地位を落とせば楽になります。
プロダクトやコンポーネントよりバージョンやマイルストーンや関係者情報が大事。
自分に関係があるか無いかは、カテゴリーで判断するのではなく、
個別のccフィールド等で条件付けることなります。

[16] mixiユーザー 04月27日 21:31

う～ん、少人数ならチョコチョコ変えても良いんですけど、開発者だけで30～50人、関係者含めるとその倍とかになると、多種多様な人がいるので変化に対応してもらえなかったりしますので。。。

あと、「必要な人に必要な情報を見させる」って言うのが結構大変で、pull型の情報はもちろん、push型の情報も不要な情報が多くなると見てくれなくなる。。。しかも、そういう人に限って、メールのフィルタ設定とかがヘタで情報の分別ができなかったりするんですよねぇ。。。

[17] mixiユーザー 04月27日 23:02

情報の分別ができない問題を先に直さないと、BTSに責任転嫁することになるでしょう。

[18] mixiユーザー 04月29日 22:47

> 情報の分別ができない問題を先に直さないと、

いや～、自分の部下や直接指導している後輩ならまだしも、自分と関係の薄い人や先輩、上司となるとなかなか。。。

あと、カテゴリーの変更は簡単ですが、プロジェクトの変更って結構面倒じゃないですか？・・・って、影舞やMantisだけ？

[19] mixiユーザー 04月30日 09:56

少なくともbugzillaには一括変更の機能があります。

[20] mixiユーザー 04月30日 10:29

直すべき根本的な問題が残されている状態で、
それらを覆い隠してくれるような神の道具であることを期待するのは難しいでしょう。
むしろ、能力や価値観の違いを際立たせるのがBTSです。
導入のための指導をする者にある程度の権限が与えられないと
組織全体の適切な使いこなしは難しいですね。
まずは怠慢なく全て入力させるのが第一で、
それの抽出を楽にするとか必要な情報だけpushさせるとかは
適切な入力に対して後からついてくるものです。
慣れない人なら検索エンジン感覚でpush無しで使った方がうまくいきやすいこともあります。

[21] mixiユーザー 05月31日 11:17

う～ん、なんでしょう、別に「神の道具」が欲しい訳ではなくて。。。

「良くない現状を少しでも良い方向に向かわせるには、何をすべきか。」が前提にあって、「BTSという道具は、どのように使うとより便利に使えるか。どのように使うとより現状の改善に役立つか。」になって。。。
途中で自分が「必要な人に情報を見させる」って話を入れてしまったせいで、話が逸れてしまったような。。。

少し前までは、開発プロセス改善のための情報収集も視野に入れていたので「どんな分析軸が必要か。どんな情報を収集すべきか。」まで考え、その属性情報の1つとしてプロジェクトも考えていました。
でも最近は、BTSの本来の機能である「不具合が修正されること（場合によっては意図的に修正されないこと）を管理・保証する（忘れてほったらかしにしない）」ことにもっと重点を置くべきかなぁとか考えています。どうも、副次的効果を期待し過ぎで本来の機能を果たせていないとか、本末転倒な気がするので。。。

ということで、現在は「お客様にサポートを提供している全てのバージョンに対して、バージョンごとにプロジェクトを分ける」方向に傾きつつあります。

まぁ、転職したせいで立場がソフトウェアアーキテクトから一開発者に変わったり、現在のプロジェクトが「不具合分析による開発プロセス改善」以前の問題を抱えているように感じているせいもあるのですが。

[22] mixiユーザー 05月31日 12:09

やるべきことを忘れないようにするのは、
担当者の誠意と解決速度によって実現されることで、
それがなくても望ましい結果が得られることをBTSに期待すると
未解決が溜まる一方になりそうですね。
未解決増加の悪循環に入ると、BTSは重圧やストレスの発生源になりかねないわけで、
そこに組織の備忘としての役割を期待すると、作業の速度も品質も落ちる。

そもそもBTSは願望や目標といった未来を記録するシステムではなく、
事実や行為や結論や根拠といった過去を記録するシステムなのですから、
やるべきことの記録よりも、やったことの記録を徹底するのが効果的でしょう。
やるべきことを忘れないためという期待を捨てることから、本当のBTS活用が始まるのですよ。
もしBTSが無ければ忘れてしまうような問題なら、
LATERかWONTFIXで閉じることを即刻検討です。
「やったことについて書くべきなのに書かない(または書き始めるのが遅い)」
「閉じるべきものを閉じない」
BTS活用失敗の典型的パターンですね。

そして、それ以前の問題、なんてものが残っていたら、まずそれを解決しないと
BTSの効果的な運用の開始はついてこれる者とそうでない者の差を生み出して、
ある種の失敗の原因になってしまいます。
それについては、記録の義務化を組織のルールにして、
分類毎に管理責任者を割り当てることで、事後修正は可能かもしれません。

[23] mixiユーザー 06月02日 22:28

とりあえず抽出に高い能力を求めるときは、影舞だと難しいでしょうね。
基本機能の豊富さと設定の余地で拡張しやすいbugzilla3か。
抽出のための任意のSQLが書けてアドオン拡張できる余地のあるtracか。

もし大勢で大規模に使うなら、3階層まで分類できてグループ管理のできるbugzilla系BTSが強いでしょう。
さらに閉じステータスが3種類に分かれているため、厳密な品質管理がしやすくなります。

[24] mixiユーザー 06月25日 09:29

この手のシステムは枯れ始めて、最近のバージョンアップは大きな変化がないかと思ったらそうでもないみたい。
現行安定バージョンと新バージョンの間の大きな進化は結構あるみたいですね。
tracはアドオンに頼るところがあるのか、本体の変化が少なくなった気がして残念。

[25] mixiユーザー 06月25日 09:35

なかじまゆうじさんに紹介されたtracコミュを関連コミュリンクに入れておきました。

他にも追加したいところや変えたいところがあるなら
副管理人設定しますので、ご希望あるならいつでもどうぞ。

[26] mixiユーザー 07月12日 08:50

「コミュリンクに入れてほしい」と思って書いた訳ではなかったのですが、リンクにあった方が人の行き来が多くなって、コミュの発展につながるかもしれませんね。ありがとうございます。

っで、「もうないだろう」と思って検索してみたら、ありました。。。

【redmine】
http://mixi.jp/view_community.pl?id=3225847

【Bugzilla-jp 支援部隊】
http://mixi.jp/view_community.pl?id=172907

ここまで書いたので、ついでに、
【Mantis -BugTracker-】
http://mixi.jp/view_community.pl?id=2414389

どこも過疎ってるんだから、このコミュで製品ごとのトピをたてるなりしてくれれば良いのに。。。

[27] mixiユーザー 06月13日 13:07

なんとなく宣伝
【Shibuya.trac第12回勉強会～チケット管理システム大決戦第二弾～】
http://sourceforge.jp/projects/shibuya-trac/wiki/meeting%2F17

中の人ではないですが（ｗ

[28] mixiユーザー 06月13日 21:56

tracの人気上昇は激しいですねぇ

ログインすると、みんなのコメントがもっと見れるよ