1

あなたのほとんどは確かにある種のバグトラッカーを使用しています。おそらく内部的にのみ、顧客が電子メールまたは電話でバグを報告したら、自分で新しいチケットを追加します。毎週のプロジェクト会議は、テーブルの反対側のPMが維持し、あなたを追いかけるのが大好きなExcelシートのフレーバーで来ることが望ましい新しいチケットの優れた情報源になることがあります。

より高度な（そして透過的な）バージョン：顧客が自分のバグをバグトラッカーに直接ファイリング（および進行状況を確認）できるようにします。JIRAのようなシステムでは、プロファイルを使用して特定のアクセス権などを設定できます。

しかし、今の質問：ユーザーによって発生したバグは、特定のモジュール/メソッド/EJB/クラスで1つのバグに変換されます。彼が使用している（あなたの）Webアプリケーションのバージョンは、エラーの原因となっているクラスのバージョンに変換されません。チケットの内部部分をすべての厄介な技術的な詳細で維持すると同時に、ユーザーに心地よいチケットを作成する方法（詳細情報が必要、承認済み、進行中など）？内部と外部の2つのチケットを作成しますか？それらをリンクしますか？

共有するスマートレシピはありますか？

4

4 に答える 4

2

バグシステムをカスタマーサポート追跡システムから分離し、それらの間のリンクを許可します。

  • バグは、ゼロ、1つ、または複数のカスタマーサポートチケットを指す場合があります。
  • カスタマーサポートチケットは、ゼロのバグ（たとえば、顧客の問題がソフトウェアとは関係がない）、1つのバグ（ソフトウェアの問題である場合）、または複数のバグ（たわごとが発生する）を指す場合があります。

次のようなクエリを実行します。

  • バグXの解決を待っている顧客
  • 未解決の重大なバグを待っている顧客
  • ユーザーYがすでに遭遇したバグ
  • ..。

また、各データベースには独自の「速度」があることに気付くでしょう。私の状況では、実際のバグの約4倍のカスタマーサポートコールがあります。

于 2010-03-16T08:08:29.633 に答える
1

（外部）ヘルプデスクと（内部）問題追跡の両方のための1つのシステム。チケット/問題の可視性を完全に制御でき、外部/内部アイテム間をリンクできる限り、これは大したことではありません。

続きを読む：

http://countersoft.com/downloads/whitepapers/Implementing_an_Issue_Management_Platform.pdf

于 2010-03-16T08:51:53.633 に答える
1

最も賢明な方法は、2つのシステム、またはエンドユーザーが（電子メールを介して）バグを送信するための代替メカニズムを用意することです。主な問題は、バグが必ずしもクラス内の1つのメソッドに変換されるわけではないということではありませんが、ほとんどの場合、ユーザーが少数の場合、peopelは既存のバグを読み取らず、「ボタンが機能しない」と考えます。

実際のインシデントシステムを分離すると（公開しますが、読み取り専用）、スタッフは着信バグをスクリーニングし、sur etheyを再現可能にして再現可能にし、既存のバグをチェックし、一般に、入力すると明確なバグを取得できます。そして、意味があるかもしれないし、意味がないかもしれない混乱を理解するのはそれほど難しくなく、同じバグのさらに別のエントリがすでに30回入力されています。

于 2010-03-16T08:08:17.777 に答える
1

JIRA の各コメントには、コメントを表示できるグループまたはプロジェクト ロールを設定できる「表示可能」フィールドがあります。それを使用して、「厄介な技術的な詳細」を非表示にすることができます。

あるいは、2 つの課題を作成してそれらをリンクすると言うのは、おそらく正しい方向に進んでいると言えます。これには、内部ワークフローを顧客から隠すという追加の利点があります。

于 2010-03-16T08:11:46.693 に答える