プログラマです。


プログラムにバグがあった場合、カード型のデータベースに登録しています。
世の中には「バグ追跡システム」なるものが在ると聞き、MANTISというものを
少し使ってみましたが、置き換えたいと思うほど便利には感じませんでした。

バグ追跡システムの「これ!」といった便利な機能とは何でしょうか。
実際にお使いになられている方のご意見をお聞きしたいです。
よろしくお願い致します。

回答の条件
  • 1人2回まで
  • 登録:2007/05/12 00:18:35
  • 終了:2007/05/19 00:20:03

回答(4件)

id:Nigitama No.1

にぎたま回答回数311ベストアンサー獲得回数182007/05/12 00:26:32

ポイント23pt

やっぱり複数の人数で同時にかつ継続的に「トラッキング」できる点ですよね。

過去のバージョンとか、ベースとなったモデルとかも参考にできるし、なによりデータベースになることで大きな意味を持つと思います。

マンティスでもなんでもそうですが、最初は項目が多すぎてとっつきにくいですよね。

ほかにもバグジラ、バグナッツ、影舞などがあります。

一応全部使ったことがあります。

簡単管理をするのであれば、バグナッツとか影舞でいいんじゃないでしょうかねぇ?

id:hazratt

回答ありがとうございます。

説明不足でしたが、現状使用しているカード型DBは

Webベースですので、複数人数で同時に記録は当然ながら可能です。

簡単管理であれば、それで十分満たしているか多少不足はあるかも

しれませんが、乗り換えるほどでもありません。

ただ私は現状ではそれがうまく使えていないと感じており、

専用のシステムを提案したく試用してみましたが、

これといったアピールポイントを見つけられず、

このような質問に至った次第です。

2007/05/12 08:28:01
id:garyo No.2

garyo回答回数1782ベストアンサー獲得回数962007/05/12 00:34:09

ポイント23pt

まず、MantisなどのBTSですが、一人で使っては意味がありません。

複数の開発者と複数のテスター(起票者)がいる場合に初めて役に立ちます。

関係者が10人以上いてありがたみが始めてわかると思います。

BTSの便利な点は、バグの処理がワークフロー化されて自動的に処理されることです。

[起票者]バグ報告→[担当者]再現性確認→[担当者]対策済→[起票者]対策確認

このそれぞれで、必要な人にメールが飛びます。

新しくバグが登録されると担当者にメールが届き、担当者がより詳細な情報が欲しい場合は再度起票者にメールが飛びと

面倒を見る人が居なくても自動的に処理が進みます。

(開発者やテスターが複数の部署や会社にまたがるとこの連絡をやり取りするだけで専用の担当者が必要になります)

BTSなどで一番重要なことは「不具合を採番すること」だと思います。このことにより、「不具合管理番号○○○○○○番」の不具合と言って話が通じるようになります。

また、どの不具合のバグが何件あるかという情報が共有できます。

バグレポートもすぐ出力できます。

ソフト担当者は後どのバグがあるかと自分は何を対策すればいいのかが分かります(複数の人で開発していると誰がどのバグを直すかというのも決めないといけません。そうしないとバッティングしてしまいます)

また、評価担当者は自分が起票した不具合がいつ対策されてどのバージョンで対策版がリリースされるかわかります。

また、ニュース機能などで関係者間で情報を共有することができます。

id:hazratt

なるほど。読ませていただいてて納得する箇所がいくつもありました。

回答ありがとうございます。

> 関係者が10人以上いてありがたみが始めてわかる

うちの場合、チーム全体で10人で、営業職、新人などを考慮すると

有効戦力は 4.5人程度です。正直、新しいシステムお導入して劇的な

効果が期待できる環境ではないのかもしれませんね。

> [起票者]バグ報告→[担当者]再現性確認→[担当者]対策済→[起票者]対策確認

BTS の利点はこれ、ということですね。納得です。メンバーはみんな

新しいことを覚えるのを嫌がるので、徹底的な教育が必要だと感じました。

#ちょこっと始めてみたくらいじゃ、立ち消えになってしまう(^^;

> バグレポートもすぐ出力できます。

毎週報告会があるので、これは非常に重要ですね。

一覧印刷機能を使ってみましたが、Excel 出力では

簡素すぎますし、Word出力では一覧性に欠けます。

イメージとしては、一歩手前のHTMLでの一覧表示を印刷するのが

最もいいんですが、これまた印刷すると端が切れたり、

項目を調整したいと感じました。

いろんなご意見ありがとうございました。

同僚にMANTISをぶつけて、反応が非常に否定的で私もやる気を失いかけましたが

またMANTISを使い込んでみる興味が沸きました。

2007/05/12 08:52:31
id:convivial No.3

hirotoshi回答回数6ベストアンサー獲得回数02007/05/12 01:09:22

ポイント22pt

Webアプリを開発しているときなどは、

バグ追跡システムと開発中のWebアプリを

認証付きでグローバルに公開しておくと、

自宅からテストすることができます。

id:hazratt

アイディアありがとうございます。

今は会社でクローズドなプログラムを開発しておりまして、

インターネットを介した環境を構築するといろんな意味で

問題が噴出しそうです(^^;

個人的な開発ではそうさせていただこうと思います。

2007/05/12 08:58:27
id:hujikojp No.4

hujikojp回答回数101ベストアンサー獲得回数72007/05/12 02:36:28

ポイント22pt

mantisはつかったことがなく、gnats、trac、あと社内謹製のものぐらいですが。

とりあえず Excelなどで管理していたことがありますが、集団で作業するときに変更が衝突して困ります。それが一番です。

個人ではカード型データベースでも間に合うのではないでしょうか。

あとは、既存の BTSだと運用法が固まっていて、迷うことがすくないというのもあります。個人でやってると柔軟に運用しすぎて管理できなかったり。

id:hazratt

回答ありがとうございます。

trac には興味あります。仕事では Windows ですが、プライベートでは

Debian GNU/Linux です。確か Debian のバグ追跡システムも trac だった

気がします。理由はそれだけですが…(^^;

話は戻しますが、BTSはワークフローがあるからよい、ということですね。

ワークフローを徹底教育すれば管理コストの削減が見込める、と。

#やっぱり4~5人程度の規模じゃ導入は諦めたほうが無難なのかなぁ

2007/05/12 09:11:18
  • id:garyo
    自社の歴史的には「1.Excelで管理」→「2.自社内でデータベース作成」→「3.Mantis(BTS)使用」→・・・4.現在redMine検討中 といった感じです。


    最初開発規模が少ない場合は「1.Excelで管理」で管理していました。
    Excelのシートをやり取りしているうちに最新化管理や競合などの問題が出ていました。


    そのうち自社内でデータベースを作成し管理しました。この場合、社内で開発評価している時は問題ありませんでした。


    協力会社とやり取りをするようになって、社内のデータベースを共有するわけに行かないため、メールでデータベースの差分をやり取りして大変な目にあいました。


    そこで導入しようと思ったのが複数の会社間で情報共有が可能なWEBベースのBTSシステムでした。

    特に会社間での情報の共有を必要としないとしても

    オープンソースのBTSを導入した場合の効果として、業界標準に従うというのがあると思います。今はMantis(PHP),バグジラ(Perl),Trac(Python),影舞(ruby),redMine(Ruby on Rails)と色々ありますが、そのうち幾つかに集約して「業界標準のBTSはこれ」という風になると思います。(ソースコード管理などはCVS,SVN,VSSなどが標準ですよね)


    オープンソースのBTSは複数のプログラマがバグ処理に特化して作っているわけですから、自社の独自DBを使い続けるより、業界標準のツールを使ったほうが後々いいのではと思い導入しました。


    またBTSには色々なプログラマの要望が入っているわけですから各種ノウハウが詰まっていると思います。
  • id:hujikojp
    4,5人でも使う価値はあると思います。私個人ならカード式DBより OpenSource界でこなれた BTSを断然選びます。
    ただ、そのカード式DBの運用が定着してしまって移行にかかるコストに対するメリットがない可能性はありますね。
    具体的なはなしは分からないので、hazrattさんが感じている現在のシステムへの不満を書き出してみることから始めてみればいいのではないでしょうか。
    「新しいエンジニアがなれるのが大変」とか..


  • id:garyo
    BTS自体は非常に使いやすいToDo用のワークフローシステムです。
    「バグ」として登録している所を「機能(追加・要求)」にすれば開発管理(要求管理)になりますし、汎用的に「タスク」と捕らえればプロジェクト管理になります。
    流れとしてはBTS→BTS+プロジェクト管理 となっていくと思います。

    TracやredMineがその流れでしょう。
    Tracではバグ表を「チケット」と呼び汎用のタスク処理として使っていますし、redMineでは登録したバグ表の進捗がそのままガント図で表示されるようになっています。

    http://demo.redmine.org/ redMineのデモサイト
    http://demo.redmine.org/projects/gantt/1 ガントチャート例

    http://pragger.ikejisoft.com/ Tracの例

  • id:znz
    Debian自体が使っているBTSはtracではなくdebbugsです。
    他に大規模なところが使っているBTSといえばmozillaなどが使っているbugzillaが有名です。
  • id:hazratt
    みなさま、いろんなコメントありがとうございます。
    参考になります(コメントではなく、回答に登録していただければ
    ポイントをお渡しできるのに、というのは心のつぶやきですB-))。

    > garyo 様
    私のところも、自社パッケージとして独自DBを持っており、それが
    今まで出てきておりますカード型DBです。極単純なDBになりますので
    BTSを使用した方がいいのは決まってるのですが、なかなか…。
    私が社内の雰囲気に感じているのはよいものを知ることなくあるいは
    知ろうとせずに旧態依然としたシステムで満足しているということです。
    それが崩壊してくれないと次を考えられない、みたいな(^^;

    > hujikojp 様
    「新しいエンジニア」よりもベテランのエンジニアが問題だと感じています。
    新しいものを受け入れるキャパシティがないといいますか、拒絶反応を
    起こしていました(使う前から)。ちなみに、現行の運用ですと
    バグが発見されたらDBに登録されて、それ以後データは更新されず
    進捗会議等で「データ」として吸い上げられて解決までそっちの資料に
    乗っているという状態ですので、ワークフローにはなっておりません。

    > znz 様
    情報ありがとうございます。私の勘違いだったようでm(_ _)m
    でも、Debian と trac が私の中で結びついていたのはなぜなんだろう(笑)


    とりあえず、私もまだBTSには不慣れですので、ひとりでちょっと
    使い込んでみようと思います。その上で、今の業務に適していて
    現行よりもはるかに効率よく管理できることが分かったら提案して
    みたいと思います。

この質問への反応(ブックマークコメント)

トラックバック

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません