何度か、独自のバグ追跡システムを構築したいというチームの計画に直面しました。製品としてではなく、内部ツールとしてです。
私が好意的に聞いた議論は、通常、次のようなものです。
既存のバグ追跡システムの購入をサポートするために、どのような議論を使用できますか？特に、どの機能が簡単に聞こえるが実装が難しいか、または困難で重要であるが見落とされがちな機能はどれですか。
まず、次のOhlohメトリクスを見てください。
Trac: 44 KLoC, 10 Person Years, $577,003
Bugzilla: 54 KLoC, 13 Person Years, $714,437
Redmine: 171 KLoC, 44 Person Years, $2,400,723
Mantis: 182 KLoC, 47 Person Years, $2,562,978
これらの数字から何を学べるでしょうか？私たちは、Yet Another Bug Tracker を構築することは、リソースを浪費する素晴らしい方法であることを学びました!
そこで、私が独自の内部バグ追跡システムを構築する理由を以下に示します。
そうでなければしないでください。
質問を振り返りたいと思います。なぜあなたは自分で作りたいのですか？
追加のフィールドが必要な場合は、変更可能な既存のパッケージを使用してください。
特別レポート？データベースを利用して作成します。
難しくないと思いますか？それなら試してみてください。それをスペックアップして、機能と時間のリストが増えるのを見てください。次に、リストが完成したら、独自のパッケージを実装する前に、変更できる既存のパッケージを見つけてください。
要するに、別のホイールがフィットするために微調整が必要な場合は、ホイールを再発明しないでください。
プログラマーは独自のチケットシステムを構築するのが好きです。何十ものチケットシステムを見て使用してきたので、彼らはそれについてすべてを知っているからです。そうすれば、彼らは快適ゾーンにとどまることができます。
新しいレストランをチェックするようなものです。やりがいがあるかもしれませんが、リスクが伴います。ピザをもう一度注文したほうがいいです。
そこには意思決定の素晴らしい事実も埋め込まれています。何かをする理由は常に2つあります。それは、良い理由と正しい理由です。私たちは決定を下し（「自分で構築する」）、それを正当化します（「完全な制御が必要」）。ほとんどの人は彼らの本当の動機にさえ気づいていません。
彼らの考えを変えるには、正当化ではなく、本当の理由を攻撃する必要があります。
独自のバグトラッカーを作成しますか？独自のメールクライアントやプロジェクト管理ツールなどを構築してみませんか。
Omer van Kloetenが他の場所で言っているように、今すぐ支払うか、後で支払います。
購入も構築もしないという 3 つ目の選択肢があります。そこには良い無料のものの山があります。例えば：
学習以外の目的で独自のバグトラッカーを作成することは、時間の無駄です。
その他のリンク:
私はそれがお金の問題だと言うでしょう-あなたが知っている完成品を買うことはあなたにとって良いことです（そしてそれが無料の場合は買わないことさえあります）は自分で開発するよりも良いです。これは、今すぐ支払うか後で支払うかという単純なゲームです。
まず、独自の構築を支持する議論に反対します。
社内で構築されたWebフレームワークの観点から「自分のドッグフードを食べたい」
もちろん、それはなぜあなた自身のウェブフレームワークを構築するのかという疑問を提起します。価値のある無料のバグトラッカーがたくさんあるように、価値のあるフレームワークもたくさんあります。あなたの開発者は彼らの優先順位をまっすぐに持っているのだろうか？あなたの会社を実際にお金にする仕事をしているのは誰ですか？
OK、フレームワークを構築する必要がある場合は、ビジネスで収益を上げるために使用する実際のソフトウェアを構築するプロセスから有機的に進化させてください。
高度に専門化されたレポート、または独自の方法で機能を微調整する機能が必要
他の人が言っているように、多くの優れたオープンソーストラッカーの1つをつかんで、それを微調整します。
バグ追跡システムを構築することは難しくないと信じています
そうですね、 C＃の予備知識がなくても、 BugTracker.NETの最初のバージョンをわずか数週間で作成しました。しかし、6年後、数千時間経った今でも、取り消された機能リクエストのリストはまだたくさんあるので、バグ追跡システムに何をさせたいかによって異なります。電子メールの統合、ソース管理の統合、権限、ワークフロー、時間の追跡、スケジュールの見積もりなど。バグトラッカーは主要な主要なアプリケーションになる可能性があります。
既存のバグ追跡システムの購入をサポートするために、どのような議論を使用できますか？
購入する必要はありません。いくつか例を挙げると、 Trac、Mantis_Bug_Tracker、私自身のBugTracker.NETなどの優れたオープンソースのものが多すぎます。
特に、どの機能が簡単に聞こえるが実装が難しいか、または困難で重要であるが見落とされがちな機能はどれですか。
あなたが自分のためだけにそれを作成しているなら、あなたは物事を配線することができるので、あなたはたくさんの近道をとることができます。多くの異なるシナリオで、多くの異なるユーザーのためにそれを構築している場合、それは難しい構成可能性のサポートです。構成可能なワークフロー、カスタムフィールド、および権限。
優れたバグトラッカーに必要な2つの機能、FogBugzとBugTracker.NETの両方にあるのは、1）受信メールと送信メールの両方を統合することです。これにより、バグに関する会話全体が、個別のメールではなく、バグとともに存続します。スレッド、および2）数回クリックするだけでスクリーンショットをバグ投稿に変換するためのユーティリティ。
私にとって最も基本的な議論は時間の損失です。1、2ヶ月足らずで完成できるとは思えません。非常に多くの優れたバグ追跡システムが利用できるのに、なぜ時間を費やすのでしょうか。微調整する必要があり、すぐには利用できない機能の例を教えてください。
優れたバグ追跡システムは、開発プロセスを反映している必要があると思います。非常にカスタムな開発プロセスは、企業/チームにとって本質的に悪いものです。ほとんどのアジャイルプラクティスはスクラムまたはこれらの種類のものを支持し、ほとんどのバグ追跡システムはそのような提案と方法に沿っています。これについて官僚的になりすぎないでください。
最も重要なことは、バグトラッカーが完了する前にどこにバグを提出するのでしょうか。
しかし、真剣に。ツールはすでに存在しているので、車輪の再発明をする必要はありません。特定の機能を追加するために追跡ツールを変更することは1つのことです（私は以前にTracを変更しました）...1つを書き直すのはばかげています。
あなたが指摘できる最も重要なことは、彼らがやりたいのがいくつかの専門的なレポートを追加することだけである場合、それは根本的な解決策を必要としないということです。さらに、「自作ソリューション」が重要な最後の場所は、内部ツールです。あなたがそれを必要とするように仕事を成し遂げているなら、誰があなたが内部で使っているものを気にしますか？
バグ追跡システムは、ジュニア開発者を始めるのに最適なプロジェクトです。これは、コーディング規約などでトレーニングするために使用できる非常に単純なシステムです。ジュニア開発者にそのようなシステムを構築させることは比較的安価であり、顧客には見えないものに間違いを犯す可能性があります。
がらくたなら捨てることができますが、それを使えば会社にとってすでに重要な仕事があると感じさせることができます。ジュニア開発者がライフサイクル全体と、そのようなプロジェクトがもたらす知識移転のすべての機会を体験できることにコストをかけることはできません。
ここではこれを行いました。私たちが最初に書いたのは 10 年以上前です。次に、テクノロジーを学習する方法として、Web サービスを使用するようにアップグレードしました。私たちが最初にこれを行った主な理由は、バージョン履歴レポートと、商用製品には見られない他のいくつかの機能も生成するバグ追跡システムが必要だったからです。
現在、バグ追跡システムを再度検討しており、Mantis への移行と、Mantis Connect を使用して独自のカスタム機能を追加することを真剣に検討しています。独自のシステムを展開するための労力は、あまりにも大きすぎます。
FogBugz も検討する必要があると思います :-)
すでに重要な（または少なくとも重要な）タスクに取り組んでいるプログラマーであることは、市場ですでに利用可能なもの（オープンソースまたは商用）を開発しようとすることによって自分自身を逸脱させてはなりません。
次に、コア開発でバグを追跡するために使用するバグ追跡システムを追跡するためのバグ追跡システムを作成しようとします。
最初に：1。バグシステムが実行されるプラットフォーム（Java、PHP、Windows、Linuxなど）を選択します。2。プラットフォームで利用可能なオープンソースツール（オープンソース、つまり商用ツールと無料ツールの両方）を見つけてみます3を選択しました。必要に応じてカスタマイズするために最小限の時間を費やしてください。可能であれば、カスタマイズに時間を無駄にしないでください
エンタープライズ開発チームでは、JIRAの使用を開始しました。追加のレポート、SSOログインなどが必要でした。JIRAはそれが可能であり、すでに利用可能なプラグインを使用して拡張できました。コードは有料サポートの一部として提供されたため、ログイン用のカスタムプラグインの作成に費やした時間は最小限でした。
無料/オープンソースのものをダウンロードするだけでなく、他の人が言ったことに基づいて構築します。ダウンロードしてから、自分のニーズに合わせて完全に変更してみてはどうでしょうか? 私は過去にそうするように求められていたことを知っています。Bugzilla をインストールし、回帰テストとテスト レポートをサポートするように変更しました (これは何年も前のことです)。
より丸いホイールを構築できると確信していない限り、ホイールを再発明しないでください。
最大の障害の1つは、データモデル/ワークフローに苦しんでいることだと思います。これには長い時間がかかり、特定の状況下でバグに何が起こるか、実際にバグを構成するものなどについて多くの議論が含まれると予測しています。事前に構築されたシステムでは、ほとんどの人は、どのような決定がすでに修正されていても、それを使用して最大限に活用する方法を学びます。オープンソースのものを選択してください。必要に応じて、後でいつでも微調整できます。これは、最初から自分で作成するよりもはるかに高速です。
この時点で、バグ追跡/発券に大きな新しい方向性がなければ、それは単に車輪の再発明になります。一般的に、これは他の誰もが考えていることのようです。
私はこの議論の両側にいるので、ここで少し二人になりましょう。
私は若い頃、独自のバグ追跡システムの構築を推進しました。既成のものではできないことをすべて強調したところ、経営陣にそれを任せました。彼らはチームを率いるために誰を選びましたか？自分！チームリーダーになり、デザインからツール、そして人員に至るまで、あらゆる面で発言権を持つのは、私の最初のチャンスでした。ワクワクしました。ですから、このプロジェクトを推進している人々の動機を確認することをお勧めします。
私は年を取り、同じ質問に再び直面したので、FogBugzを使うことにしました。それは私たちが必要とするものの99％を実行し、コストは基本的に0です。さらに、ジョエルはあなたに特別な気分にさせる個人的な電子メールを送信します。そして結局、それは問題ではありませんか、あなたの開発者はこれが彼らを特別なものにするだろうと思いますか？
議論はバグを構成するものから始まり、適用するワークフローに発展し、ソフトウェア エンジニアリング プロジェクトを管理する方法についての大規模な議論に終わります。あなたは本当にそれをしたいですか？:-) いや、そうは思いませんでした - 行って買いましょう！
ほとんどの開発者は、他の誰も持っていない独自の力を持っているため、何らかの方法で独自のシステムを作成できると考えています。
それらの99％は間違っています。
あなたの会社に従業員が 1% いる可能性はどれくらいですか?
すべてのソフトウェア開発者は、独自のバグ追跡システムを構築したいと考えています。それは、私たちがドメインの専門家であるため、すでにそこにあるものを明らかに改善できるからです。
（開発者の時間の観点から）コストに見合う価値はほとんどありません。JIRAを購入するだけです。
バグ追跡システムに追加のレポートが必要な場合は、基盤となるデータベースに直接アクセスして追加する必要がある場合でも、これらを追加できます。
私はそうしないすべての理由に同意します。私たちはしばらくの間、そこにあるものを使用しようとしましたが、とにかく自分で書くことになりました。なんで？主な理由は、それらのほとんどが面倒すぎて技術者以外の人を雇うことができないためです。私たちはbasecampも試しました（もちろん、これはこのために設計されておらず、その点で失敗しました）。
また、クライアントとうまく機能するいくつかの独自の機能を考案しました。1行のJavaScriptを使用してコードにスクリプト化した「バグの報告」ボタンです。これにより、クライアントは小さなウィンドウを開き、情報をすばやく書き留めて、データベースに送信できます。
しかし、コーディングには確かに何時間もかかりました。大きなペットプロジェクトになりました。週末がたくさん。
チェックアウトしたい場合：http ：//www.archerfishonline.com
いくつかのフィードバックが大好きです。
Tracが存在する からです。
また、別のシステムで経験を積んでいる可能性が高いときに、別のソフトウェアで新しいスタッフをトレーニングする必要があるため、破棄するのではなく、構築することができます。
問題は、あなたの会社はあなたに何をするためにお金を払っているのですか? 自分だけが使うソフトウェアを書くことですか? 明らかにそうではありません。したがって、バグ追跡システムを構築するための時間と費用を正当化できる唯一の方法は、無料のバグ追跡システムの使用に関連するコストよりもコストがかからない場合です。
これが理にかなっている場合もあります。既存のシステムと統合する必要がありますか? (時間追跡、見積もり、要件、QA、自動テスト)? たとえば、取得が困難な特定のデータ要素を必要とする SOX コンプライアンスに関連する組織固有の要件はありますか?
プロジェクト間のかなりの「ダウンタイム」につながる非常に官僚的な環境にいますか?
これらのタイプの質問に対する答えが「はい」の場合、「購入」対ビルドの議論は必ず「ビルド」となります。
私たちはこれをやった... 数回。私たちが独自のものを作った唯一の理由は、それが 5 年前であり、良い代替品があまりなかったからです。しかし、今ではたくさんの選択肢があります。独自のツールを構築する中で学んだ主なことは、その作業に多くの時間を費やすということです。そして、それはあなたがあなたの時間に対して請求できる時間です. 中小企業としては、自分の時間を費やすよりも、請求可能な 1 時間または 2 時間で簡単に回収できる月額料金を支払う方がはるかに理にかなっています。もちろん、多少の譲歩は必要ですが、長期的にははるかに良い結果が得られるでしょう。
私たちに関しては、アプリケーションを他の開発者が利用できるようにすることにしました。http://www.myintervals.comでチェックしてください。
私はスタートアップで数年間働き、オープンソースツールであるGNATSから始め、基本的にはその上に独自の精巧なバグ追跡システムを構築しました。議論は、商用システムに多額の費用を費やすことを避け、ニーズにぴったり合ったバグ追跡システムを手に入れるというものでした.
もちろん、それは予想よりもはるかに困難であることが判明し、コードに加えてバグ追跡システムも維持しなければならなかった開発者にとって大きな気晴らしになりました。これが当社の倒産の要因の一つでした。
一部のオープンソース ソフトウェアをそのまま使用します。確かにバグがあり、まだそこにないものやバグ修正が保留されているものが必要になります。それはいつも起こります。:)
オープン ソース バージョンを拡張/カスタマイズする場合は、それを維持する必要があります。これで、金儲けアプリケーションのテストに役立つはずのアプリケーションが、サポートの負担になります。
「高度に専門化されたレポートが必要な場合、または独自の方法で機能を微調整する機能が必要な場合」、それを行うための最善かつ安価な方法は、既存のバグ追跡システムの開発者と話すことです。お金を払ってその機能をアプリケーションに組み込み、世界中で利用できるようにします。ホイールを再発明する代わりに、ホイール メーカーにお金を払ってスプリングのような形状のスポークを取り付けてもらいます。
それ以外の場合、フレームワークを紹介しようとしている場合は、それで問題ありません。関連する免責事項を必ず入力してください。
バグ追跡システムを構築するのは難しくないと信じている人は、ウォーターフォール SDLC に厳密に従ってください。すべての要件を事前に把握してください。それは確かに彼らが複雑さを理解するのに役立ちます. これらは通常、検索エンジンを構築するのはそれほど難しくないと言っている人々と同じです。フェーズ 2 では、テキスト ボックス、「検索」ボタン、および「私は幸運を感じています」ボタンと「私は幸運を感じています」ボタンのみを実行できます。
あなたがそれを売るつもりでない限り、それは請求可能な時間ではなく、非常に有用でさえないからです.
FogBugzなど、完全に優れたバグ追跡システムが利用可能です。
(私の経験では) 人々が独自のバグ追跡システムを作成する理由は、
私にとって、ほとんどのバグトラッカーが失敗した最大の理由は、それらが最適なユーザーエクスペリエンスを提供しなかったことであり、使いやすさが最適化されていない場合、LOT を使用するシステムで作業するのは非常に苦痛になる可能性があるためです。
もう 1 つの理由は、私たち (プログラマー) のほぼ全員が、いつかは独自のカスタム CMS または CMS フレームワークを構築したことがある理由と同じだと思います (有罪)。できるから！
私は独自のバグ追跡システムを構築しました。私も考えました：「それはどれほど難しいか、それは単なるバグ追跡システムです」ERR-間違った* -それをコーディングするのに6ヶ月かかりました。
私が自分で焼いた主な理由は、私が望む通りにそれを手に入れることでした。もう一つの理由は趣味のプロジェクトでした。
自分で作ることが正当化されるのは、趣味のプロジェクトである場合だけだと思います。どんな会社もそれに時間を費やすべきではありません。
ちなみに私のソフトウェアはBugwebと呼ばれています。
私はここのほとんどの人に同意します。多くのツール（無料でも）が利用できる場合、何かを再構築することは無駄です。何かをカスタマイズしたい場合は、ほとんどの無料ツールでコードを入手して試してみてください。
新しい開発を行う場合は、自分だけのために行うべきではありません。
社内追跡システムを構築するのは比較的簡単ではないと思いますし、有料またはオープンソースのソリューションに匹敵するものではないことは確かです. ほとんどの場合、私は「プログラマーのエゴ」か、サードパーティのソフトウェアを実際に使用できず、文字通りすべてのソフトウェアを構築しなければならない IT 部門を持っています。
独自の社内バージョン管理システムを持っている通信会社で働いていたことがありますが、それはかなりひどいものでしたが、チーム全体が忙しくしていました...
すでに多くの優れた製品が世に出回っているのに、時間を無駄にして一からやり直す必要はありません。
FogBugzを使用してください。
「自分のドッグフードを食べる」ためだけに独自のソフトウェアを作成しないでください。より少ない時間と費用で同じこと (およびより優れた) を行うソフトウェアをおそらく購入できるときに、より多くの作業を作成しているだけです。
明日 (来年)、社内のすべてのバグ追跡システムに人気のあるオープン ソース/商用ツールを導入することにした場合、このツールはどのようにしてすべてのバグ チケットを他のツールにエクスポートできるのでしょうか?
カスタム バグ追跡システムが本当に必要であり、そのような質問に答えられる限り、私はあまり気にしません。
彼らに、それは素晴らしいことだと伝えてください。会社はしばらくの間いくらかのお金を節約することができます。あなたがこの無給休暇に取り組んでいる間、喜んで開発ツールを提供します。プロジェクトに取り組む代わりに年次休暇を取得したい人は誰でも自由に取得できます。