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