プログラマーや技術者以外のスタッフに優しい方法でバグ追跡をどのように処理しますか？[閉まっている]

私たちは実際にプロジェクトにMantisを使用しています。または、「使用しようとしています」と言う必要があります。私が知っているすべてのバグトラッカーの問題は、プログラマーのためにプログラマーによって作られていることです。そのため、デザインは存在しないか、まったく馬鹿げています。

もちろんプログラマとして、私はカマキリを問題なく使用できますが、プロジェクトに関与するすべての人々が設計が非常に難しく、使いにくいために箇条書き付きのGoogleドキュメントを作成することを好む場合、バグトラッカーはどれほど便利ですか？彼らが見つけたバグや提案しているかもしれない。

フォーラムをインストールしようとしていますが、バグトラッカーと単純な箇条書きリストの間の「中間」ソリューションのように思えます。少なくともフォーラムでは、提案に関する議論を監視し、一元化できます。

私の懸念が明確でない場合、私の質問は次のように要約できます。

技術以外のユーザーに対するバグと提案のレポートをどのように処理しますか？

**関与することにより、私は実際のクライアントまたはエンドユーザーを意味しません。私は、インテグレーター、プロジェクトマネージャー、およびQAに関与している人々について考えています。

今年初めにMantisからFogBugz（およびKiln）に切り替えましたが、変更しなかったのは、「ユーザー」にバグトラッカーへのアクセスを一切許可しないことです。他の部門長の一部は読み取り専用アクセス権を持っていますが、正直なところ、彼らは管理者であり、通常は数週間以内にそれを忘れます。私たちのソフトウェアのユーザーはすべて、それが構成の問題、ユーザーエラー、またはソフトウェアのバグであるかどうかを判断する1人のトラブルシューティング担当者に対処します。この人物は、実際の問題をFogBugzに入力するためのゲートキーパーとして機能します。これにより、システムがあまり関係のない問題で混乱するのを防ぎます。

あなたの本当の質問に答えるために....バグ追跡ソフトウェアが「プログラマー」、「プログラマー」のみを使用するため、「プログラマー向け」であることは、私たちにとって本当に問題ではありません。他のすべての人は人間を直接扱います。

（注、当社の製品はシュリンクウェアではなく、すべてのユーザーは直接従業員であるか、サービス部門の従業員と協力しています。）

この種のことにはredmineを使用します。キーのトリックは、ユーザーの大部分は決して見られない、彼らはただsupport@example.comに電子メールを送信する- Redmineのを。いくつかのより高度なトリックを使用して（主にredmineアカウントをBCCし、問題番号を含める）、更新をredmineに保持し続けることができます。上級者向けには、redmineを直接使用できるようにしました。これは、MANTISよりもかなり現代的でユーザーフレンドリーであるためです。

現在、MKSを使用しています。プログラマーではない人のために、いくつかのレポートと、関心のある要約を含むダッシュボードをセットアップしました。つまり、初期セットアップを行う必要がありますが、欠陥の進行と全体的な要約をモニターできます。レポートとダッシュボードにアクセスする方法を示したら、データを独自に作成します。彼らはまた、チケットを変更するために、いくつかの訓練を必要ですが、そこになります常にあること、いくつかのトレーニングのオーバーヘッド。幸いなことに、関連する機能に比例していました。

私はRedmineを2回目にし、個人的にはバグジーニー（ええ、安っぽい名前ですが、よく設計されています。PHP環境にいる場合や、何らかの理由でRubyを実行できない場合）を使用して、ハイテクユーザー。

それに加えて、重要なことの1つは、エンドユーザーがデフォルトで入れたものよりも多くの問題を見る必要がないことです（オプションで、重複するチケットを避けるために検索機能を持つことができますが、それはニーズと設定によって異なります）。すべての問題を見ると、インターフェースが乱雑になり、エンドユーザーを混乱させます。一般に、ユーザーは表示する必要があるもののみを表示する必要があるため、プロジェクトマネージャーは、たとえば自分が管理するプロジェクトの問題のみを表示します。他の人が述べたように、エンドユーザーにとっては、チケットの送信をより簡単にすることができれば、より良いことです。トラッカーのUIを必要としないチケット送信（電子メール経由、またはチケット送信に必要なフィールドのみを含むシンプルなフォーム）が可能な場合のボーナスポイント。

以前はチームシステムと呼ばれていた「Visual Studioのアプリケーションライフサイクル管理機能」を使用します。私たちにとっての大きな利点の1つは、クエリ結果（「すべての要件」や「pri 2以下のすべてのバグ」など）をスプレッドシートまたはプロジェクトドキュメントにエクスポートできることです。プロジェクトマネージャー、エンドユーザーの担当者、利害関係者などはこれらのファイルを編集できます-優先度の変更、説明の更新、他の人への割り当て、その他-そして、ファイルがTFSに接続されているマシンに戻ったときに、発行と変更はリポジトリに戻ります。プログラマーはVisual Studioから直接ワークアイテムを操作しますが、プログラマー以外のユーザーがVSに近づくことはありません。また、TFSプロジェクトごとに共有サイトがあるので、

あなたがVSショップでないなら、たぶん選択肢ではないかもしれませんが、あなたがそうであるかどうかを考える価値があります。

QA / PMスタッフと話している場合は、さまざまなオープンソースおよびクローズソースの追跡ツールを評価する必要があります。ビルドなどを設定できる機能は優れているため、QA / PMの担当者は特定のビルドに対してチケットを挿入でき、問題を修正すると、どのビルドをテストするかを知ることができます。

私が使用したほとんどの適切なツールは、実際にはプログラマよりもプログラマではない人向けに調整されています。StarTeamは私にとっては非常にうまく機能しましたが、まだ動作しているかどうかはわかりません。必要に応じてフィールドなどをカスタマイズできます。彼らがそれで行き過ぎないようにしてください。

エンドユーザーについて話している場合は、ヘルプデスクソフトウェアを確認し、必要に応じてヘルプデスクの担当者をバグツールにエスカレーションする必要があります。