独自のバグ追跡システムを構築しない理由 [終了]

StackOverflow https://stackoverflow.com/questions/62153

  •  09-06-2019
  •  | 
  •  

質問

これまで何度か、製品としてではなく内部ツールとして、独自のバグ追跡システムを構築したいというチームからの計画に直面しました。

私がよく聞いた議論は、通常次のようなものです。

  • 内部的に構築された Web フレームワークの観点から「自分のドッグフードを食べたい」
  • 高度に専門化されたレポート、またはおそらく独自の方法で一部の機能を調整する機能が必要
  • バグ追跡システムを構築するのは難しくないと信じている

既存のバグ追跡システムの購入を支持するには、どのような議論を使用できますか?特に、簡単そうに見えて実装が難しい機能、または難しくて重要だが見落とされがちな機能は何ですか?

役に立ちましたか？

解決

まずはこちらをご覧ください ああ、ああ メトリクス:

    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 を構築することは、リソースを浪費する素晴らしい方法であることがわかりました。

独自の内部バグ追跡システムを構築する理由は次のとおりです。

  1. 10年か20年かけてすべてのボゾコーダーを無力化する必要があります。
  2. 来年の予算削減を避けるために、いくらかの資金をフラッシュする必要があります。

それ以外の場合はやめてください。

他のヒント

質問を変えたいと思います。一体なぜ自分で構築したいと思うのでしょうか？
追加のフィールドが必要な場合は、変更可能な既存のパッケージを使用してください。
特別レポート？データベースをタップして作成します。

それは難しくないと信じていますか？それなら試してみてください。仕様を変更すると、機能のリストが表示され、時間が増加するのを確認できます。次に、リストが完成したら、独自のパッケージを実装する前に、変更できる既存のパッケージを探してみてください。

つまり、別の車輪を取り付けるために微調整が必​​要な場合は、車輪を再発明しないでください。

プログラマーは独自のチケット システムを構築することを好みます。これは、何十ものチケット システムを見て使用してきたため、そのシステムについてすべてを知っているからです。そうすれば彼らはコンフォートゾーンに留まることができます。

新しいレストランをチェックアウトするようなものです。それはやりがいがあるかもしれないが、リスクも伴う。ピザをもう一度注文したほうがいいです。

そこには意思決定に関する重要な事実も埋もれています。何かをする理由は常に 2 つあります。良いものと正しいもの。私たちは決定を下し (「自分たちで構築する」)、それを正当化します (「完全な制御が必要です」)。ほとんどの人は自分の本当の動機にさえ気づいていません。

彼らの考えを変えるには、攻撃する必要があります。 本物 正当化ではなく理由。

ここでは発明されていない症候群!

独自のバグトラッカーを構築しますか?独自のメールクライアントやプロジェクト管理ツールなどを構築してみてはいかがでしょうか。

として オメル・ファン・クローテン 言う それ以外の場合は、今すぐ支払うか後で支払うかです。

購入することも構築することもない、3 番目の選択肢があります。そこには無料の優れたものが山ほどあります。例えば：

学習以外の目的で独自のバグトラッカーを使用するのは、時間の有効な使い方ではありません。

その他のリンク:

私が言いたいのは、これはお金の問題です。自分にとって良いとわかっている完成品を購入する（場合によっては、無料であれば買わないこともあります）方が、自分で製品を開発するよりも優れています。という単純なゲームです 今払う 対 後払い.

まず、独自の構築を支持する議論に反対します。

内部的に構築された Web フレームワークの観点から「自分のドッグフードを食べたい」

もちろん、なぜ独自の Web フレームワークを構築するのかという疑問が生じます。価値のある無料のバグトラッカーがたくさんあるのと同じように、価値のあるフレームワークもたくさんあります。あなたの開発者は優先順位をきちんと持っているのだろうか?あなたの会社が実際にお金を稼ぐ仕事をしているのは誰ですか?

フレームワークを構築する必要がある場合は、ビジネスが収益を上げるために使用する実際のソフトウェアを構築するプロセスから有機的に進化させてください。

高度に専門化されたレポート、またはおそらく独自の方法で一部の機能を調整する機能が必要

他の人が言ったように、多くの優れたオープンソーストラッカーの1つを入手して微調整してください。

バグ追跡システムを構築するのは難しくないと信じている

さて、私は私の最初のバージョンを書きました バグトラッカー.NET C# の事前知識がなくても、わずか 2 週間で完了します。しかし、6 年と数千時間経った今でも、未完了の機能リクエストの膨大なリストがまだ残っているため、すべてはバグ追跡システムに何をさせたいかによって異なります。電子メールの統合、ソース管理の統合、権限、ワークフロー、時間の追跡、スケジュールの見積もりなどの程度。バグ トラッカーは、主要なアプリケーションになる可能性があります。

既存のバグ追跡システムの購入を支持するには、どのような議論を使用できますか?

購入する必要はありません。オープンソースの優れたものが多すぎます。 トラック, カマキリ_バグ_トラッカー, いくつか例を挙げると、私自身の BugTracker.NET などです。

特に、簡単そうに見えて実装が難しい機能、または難しくて重要だが見落とされがちな機能は何ですか?

自分専用に作成している場合は、配線で接続できるため、多くのショートカットを使用できます。さまざまなユーザー向けに、さまざまなシナリオでそれを構築している場合、難しいのは構成可能性のサポートです。構成可能なワークフロー、カスタムフィールド、および権限。

特徴としては 2 つあると思います。 良い バグトラッカーには両方が必要です フォグバグズ と BugTracker.NET には、1) 受信電子メールと送信電子メールの両方が統合されているため、バグに関する会話全体が別の電子メール スレッドではなくバグとともに存続します。2) スクリーンショットをバグ投稿に変換するユーティリティです。数回クリックするだけで。

私にとって最も基本的な議論は、時間のロスです。1～2か月以内に完成できるとは思えません。優れたバグ追跡システムが非常にたくさんあるのに、なぜ時間を費やす必要があるのでしょうか?調整する必要があり、すぐには利用できない機能の例を教えてください。

優れたバグ追跡システムは開発プロセスを反映するものでなければならないと思います。非常にカスタムな開発プロセスは本質的に企業/チームにとって好ましくありません。最もアジャイルなプラクティスが好まれる スクラム またはそのような種類のものであり、ほとんどのバグ追跡システムはそのような提案や方法に従っています。これについてあまり官僚的にならないでください。

バグ追跡システムは、若手開発者が始めるのに最適なプロジェクトになる可能性があります。これは、コーディング規約などでトレーニングするために使用できる、非常にシンプルなシステムです。若手開発者にこのようなシステムを構築させるのは比較的安価であり、顧客には見えない部分で間違いを犯す可能性があります。

ジャンクなら捨てればいいのですが、使われていれば、すでに会社にとって重要な仕事であるという印象を与えることができます。若手開発者がそのようなプロジェクトによってもたらされるライフサイクル全体と知識伝達のすべての機会を経験できることを犠牲にすることはできません。

ここではこれを実行しました。私たちが最初の作品を書いたのは 10 年以上前です。その後、テクノロジーを学ぶための手段として、Web サービスを使用できるようにアップグレードしました。私たちが最初にこれを行った主な理由は、バージョン履歴レポートや商用製品には見られないその他のいくつかの機能も生成するバグ追跡システムが欲しかったからです。

私たちは現在、バグ追跡システムを再度検討しており、Mantis に移行し、Mantis Connect を使用して独自のカスタム機能を追加することを真剣に検討しています。独自のシステムを導入するには多大な労力がかかります。

FogBugz も検討する必要があると思います :-)

最も重要なのは、バグ トラッカーが完成する前にどこにバグを送信するかということです。

でも真剣に。ツールはすでに存在しているため、車輪を再発明する必要はありません。特定の機能を追加するために追跡ツールを変更することは 1 つのことです (私は変更しました) トラック 前に）...書き直すのはただ愚かです。

指摘できる最も重要な点は、いくつかの特殊なレポートを追加するだけであれば、根本的なソリューションは必要ないということです。さらに、「自作ソリューション」が重要になる最後の場所は、内部ツールです。社内で何を使用しているかは、必要な作業が適切に行われているのであれば誰が気にするでしょうか。

すでに重要な (または最も重要ではない) タスクに取り組んでいるプログラマーは、すでに市場で入手可能なもの (オープンソースまたは商用) を開発しようとして逸脱すべきではありません。

次に、コア開発でバグを追跡するために使用するバグ追跡システムを追跡するバグ追跡システムを作成してみます。

初め：1.バグシステムが実行されるプラットフォーム（Java、PHP、Windows、Linuxなど）を選択します2。選択したプラットフォームで、利用可能なオープンソースツール（オープンソースでは、商業用ツールと無料ツールの両方を意味します）を見つけてみてください。必要に応じてカスタマイズするために最小限の時間を費やしてください。可能であれば、カスタマイズに時間を無駄にしないでください

エンタープライズ開発チームのために、私たちは使い始めました ジラ. 。追加のレポートや SSO ログインなどが必要でした。JIRA にはそれが可能で、すでに利用可能なプラグインを使用して拡張できました。コードは有料サポートの一部として提供されていたため、ログイン用のカスタム プラグインの作成には最小限の時間しか費やしませんでした。

無料/オープンソースのものをダウンロードするのではなく、他の人が言ったことに基づいて構築します。それをダウンロードして、自分のニーズに合わせて完全に変更してみてはいかがでしょうか?過去にそうする必要があったことは知っています。私は Bugzilla をインストールし、それを回帰テストとテスト レポートをサポートするように修正しました (これは何年も前のことです)。

より丸い車輪を構築できると確信するまでは、車輪を再発明しないでください。

最大の障害の 1 つは、データ モデルとワークフローについて悩むことだと思います。これには時間がかかると予想します 長さ 特定の状況下でバグに何が起こるべきか、実際にバグを構成するものは何かなどについて、多くの議論が含まれます。何度も議論するのに何ヶ月も費やすのではなく、構築済みのシステムを展開するだけであれば、すでに決まっている決定事項に関係なく、ほとんどの人はその使用方法を学び、それを最大限に活用するでしょう。オープンソースのものを選択すると、必要に応じていつでも後から調整できます。 多くの 自分で最初から作成するよりも早いです。

この時点で、バグ追跡/チケット発行に関する大きな新たな方向性がなければ、単に車輪の再発明となるでしょう。一般的には、他の誰もがそう考えているようです。

議論はバグの構成要素から始まり、どのようなワークフローを適用するかに発展し、最終的にはソフトウェア エンジニアリング プロジェクトの管理方法に関する大規模な議論に終わります。本当にそれが欲しいですか？:-) いや、考えなかった - 行って買ってみよう!

ほとんどの開発者は、自分には他の人にはない独自の能力があるため、何らかの形で独自のシステムを作成できると考えています。

それらの99％は間違っています。

あなたの会社に 1% に含まれる従業員がいる可能性はどれくらいですか?

私はこの議論の両方の側に立っていたので、ここでは少し対立させてください。

若い頃、私は独自のバグ追跡システムの構築を推進しました。私は既製品ではできないことをすべて強調し、経営陣にそれを実行してもらいました。彼らはチームを率いるために誰を選んだのでしょうか?自分！それは私にとってチームのリーダーとなり、デザインからツール、人事まであらゆることに発言できる初めてのチャンスでした。とても興奮しました。したがって、私がお勧めするのは、このプロジェクトを推進している人々の動機を確認することです。

私は年をとって、再び同じ質問に直面したので、FogBugz を使うことに決めました。必要なことの 99% を実現し、コストは基本的に 0 です。さらに、ジョエルはあなたに特別な気分をもたらす個人的なメールを送信します。結局のところ、それが問題ではないでしょうか。開発者は、これによって自分たちが特別になると考えているのでしょうか?

すべてのソフトウェア開発者は、独自のバグ追跡システムを構築したいと考えています。それはできるからです 明らかに 私たちはドメインの専門家であるため、すでに存在しているものを改善します。

(開発者の時間という点で) コストに見合う価値がないのはほぼ間違いありません。買うだけ ジラ.

バグ追跡システムに追加のレポートが必要な場合は、基礎となるデータベースに直接アクセスする必要がある場合でも、レポートを追加できます。

問題は、あなたの会社があなたに何をするためにお金を払っているのかということです。自分だけが使うソフトウェアを書くことですか?明らかに違います。したがって、バグ追跡システムを構築するための時間と費用を正当化できる唯一の方法は、無料のバグ追跡システムの使用に関連するコストよりもコストが低いかどうかです。

これが理にかなっている場合もあるかもしれません。既存のシステムと統合する必要がありますか?(時間追跡、見積もり、要件、QA、自動テスト)?あなたの組織には、たとえば SOX コンプライアンスに関連して、取得が困難な特定のデータ要素を必要とする独自の要件がいくつかありますか?

プロジェクト間の大幅な「ダウンタイム」につながる、非常に煩雑な環境にいませんか?

このような種類の質問に対する答えが「はい」の場合、「購入」か「構築」かの議論は、必ず「構築」することになります。

「高度に専門化されたレポート、またはおそらく独自の方法で機能を調整する機能が必要」な場合、それを行うための最良かつ最も安価な方法は、既存のバグ追跡システムの開発者に相談することです。その機能をアプリケーションに組み込んで世界中で利用できるようにするためにお金を払ってください。ホイールを再発明する代わりに、ホイールメーカーにお金を払って、バネのような形のスポークを取り付けてもらうだけです。

それ以外の場合、フレームワークを紹介しようとする場合は、それでも問題ありません。関連する免責事項を必ず記載してください。

バグ追跡システムの構築は難しくないと信じている人は、ウォーターフォール SDLC に厳密に従ってください。すべての要件を事前に把握してください。それは確かに彼らが複雑さを理解するのに役立ちます。これらは通常、検索エンジンを構築するのはそれほど難しくないと言う人々と同じ人たちです。フェーズ 2 では、テキスト ボックス、「検索」ボタン、「私は幸運を感じています」ボタン、そして「私は幸運を感じています」ボタンだけを実行できます。

一部のオープンソース ソフトウェアをそのまま使用する。確かにバグは存在します。まだ存在していないもの、またはバグ修正が保留されているものが必要になります。それは常に起こります。:)

オープンソース バージョンを拡張/カスタマイズする場合は、それを保守する必要があります。さて、テストに役立つと思われるアプリケーション 金儲けのアプリケーション 支える負担になる。

(私の経験では) 人々が独自のバグ追跡システムを作成する理由は次のとおりだと思います。

  1. 彼らは、構築が比較的簡単だと思われるシステムにお金を払いたくありません。
  2. プログラマーのエゴ
  3. 既存のシステムによって提供されるエクスペリエンスとソリューションに対する一般的な不満。
  4. 彼らはそれを製品として販売しています:)

私にとって、ほとんどのバグ トラッカーが失敗した最大の理由は、最適なユーザー エクスペリエンスを提供できなかったことであり、使いやすさが最適化されていない場合、頻繁に使用するシステムを操作するのは非常に苦痛になる可能性があります。

もう 1 つの理由は、私たち (プログラマー) のほとんど全員が、一度は独自のカスタム CMS または CMS フレームワークを構築したことがあるのと同じだと思います (有罪として有罪です)。できるからこそ！

私はそうしないすべての理由に同意します。私たちはしばらくの間、そこにあるものを使おうとしましたが、最終的には自分たちで書くことにしました。なぜ？その主な理由は、それらのほとんどが面倒すぎて、技術者以外の誰も関与できないからです。私たちはベースキャンプも試しました（もちろん、これはこのために設計されておらず、その点では失敗しました）。

また、クライアントにうまく機能するいくつかのユニークな機能も考案しました。「バグを報告」ボタンを 1 行の JavaScript でコードに記述しました。これにより、クライアントは小さなウィンドウを開いて情報を素早く入力し、データベースに送信することができます。

しかし、コーディングには確かに何時間もかかりました。大きなプロジェクトになりました。たくさんの週末の時間。

確認したい場合は: http://www.archerfishonline.com

フィードバックをお待ちしております。

我々はこれをやりました...何回か。独自に構築した唯一の理由は、それが 5 年前のものであり、適切な代替手段があまりなかったからです。しかし今では代替手段がたくさんあります。独自のツールを構築する際に私たちが学んだ主な点は、その作業には多くの時間を費やすことになるということです。そして、それはあなたの時間に対して請求される可能性がある時間です。中小企業としては、自分ですべての時間を費やすよりも、請求対象となる 1 ～ 2 時間で簡単に回収できる月額料金を支払う方がはるかに合理的です。確かに、ある程度の譲歩は必要ですが、長期的にははるかに良い結果が得られるでしょう。

私たちとしては、私たちのアプリケーションを他の開発者が利用できるようにすることにしました。でチェックしてください http://www.myintervals.com

なぜなら トラック 存在します。

また、新しいスタッフには、捨てずに構築できる他のシステムでの経験がある可能性が高いにもかかわらず、特注のソフトウェアについてトレーニングする必要があるからです。

なぜなら、それは請求対象の時間ではなく、販売するつもりがない限りあまり役に立たないからです。

非常に優れたバグ追跡システムが利用可能です。たとえば、 フォグバグズ.

私はスタートアップ企業で数年間働きました。 ブヨ, 、オープンソース ツールであり、基本的にその上に独自の精巧なバグ追跡システムを構築しました。主張は、商用システムに多額の費用を費やすことを避け、ニーズにぴったり合ったバグ追跡システムを入手できるというものでした。

もちろん、これは予想よりもはるかに困難であることが判明し、コードに加えてバグ追跡システムも保守しなければならない開発者にとっては大きな気を散らすものでした。これが当社の終焉につながった要因の 1 つでした。

「自分のドッグフードを食べる」ためだけに独自のソフトウェアを作成しないでください。より少ない時間と費用で同じこと (またはより優れた) を実行するソフトウェアを購入できるはずなのに、より多くの仕事を生み出すだけです。

それらを教えてください、 それは素晴らしいことです。会社はしばらくの間お金を節約することができ、あなたがこの無給サバティカルに取り組んでいる間、喜んで開発ツールを提供する予定です。プロジェクトに取り組むために年次休暇を取得したい人は誰でも自由に取得できます。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top