6

私の会社は、いくつかのプロジェクトのカスタム開発ショップであり、いくつかはより大きく、いくつかはより小さくなっています。現在、私たちはすべてのクライアントとのコミュニケーションを電子メールで処理しています。そこで、設計ドキュメントを電子メールで送信し、マークアップして送り返します。次に、製品のベータ版を公開し、バグや新機能などをメールで送信します。

新しいバグ追跡システムの実装に取り​​組んでいるとき（今はMantisのようです）、機能要求とクライアントの追跡を改善する開発プロセスとのインターフェースを顧客に提供するのに最適な方法を考えました。提出されたバグだけでなく、クライアントに私たちの応答を伝えます。

誰かがこれを非常にうまく行うバグ追跡システムを知っているなら、私はそれを聞いて興味があります。そうでなければ、私はあなたの会社があなたのクライアントと効果的かつ効率的にインターフェースすることを可能にするいくつかの一般的なガイドラインまたは良いビジネス慣行を探しています。

更新：私の会社はLAMPPスタックを使用しています。私たちは限られた予算の小さな店なので、オープンソースで無料のツールに固執する傾向があります。

ほとんどの人は、Team Foundation Serverを使用してこれを処理するのですか、それとも電子メールをやり取りするのですか？

4

4 に答える 4

3

重要なのは、バグ/リクエスト専用の追跡システムを用意し、コミュニケーションのプロセスを確立することだと思います。少なくともこれで、一貫したフィードバックを得ることができるようになります。そこから微調整して、特定のニーズを得ることができます。

余談ですが、コミュニケーションに電子メールを使用するだけでなく、プロジェクト管理ツールとして BaseCamp のようなものを使用することを強くお勧めします。メッセージ、ドキュメント、タイムラインをクライアントに伝えるのに非常に役立つことがわかりました.

于 2008-10-23T18:11:06.637 に答える
2

Team Foundation Serverを使用している場合は、TeamPlainWebAccessをインストールすることをお勧めします。これらを使用すると、WebインターフェイスをTFSプロジェクトに公開できます。やるべきことは、クライアントに権限とユーザー名とパスワードを与えることだけです。

それ以外の場合は、 FogBugzのような有料ツールがいくつかあります。もちろん、開発者がバグを簡単に修正できるように、ソース管理に直接リンクされたバグレポートツールを使用する必要があります。

于 2008-10-23T16:13:01.727 に答える
1

もう1つの可能性は、2つの製品を組み合わせて使用​​することです。これは、12人のチームによる現在のセットアップです。

クライアントからの着信要求用のosTicket

  • サポートスタッフが問題を処理し、バグを検証できるようにします
  • メールアドレスとチケットIDだけでステータスを確認できます
  • 通常、ユーザーは十分に詳細なバグレポートを送信しないため、最初のステップとして適切です。

開発チケットのredmine

  • 問題が実際のバグである場合、QAまたは開発者によって作成されたチケット
  • 十分に堅固なプロジェクトおよびリリース管理を提供します
  • tracとmantisからの確実なステップアップです（そして移行ツールを提供します）
于 2009-02-16T15:54:42.337 に答える
1

特定のツールについては知りませんが (少なくともオープン ソースのツールは知りません)、要件の収集と実装プロセス全体をカバーするシステムをセットアップすることをお勧めします。要件は、システム内で追跡できます。これには、設計ドキュメントも含まれます (システムから「チェックアウト」および「コミット」できます)。このようにして、設計ドキュメントの複数のリビジョンが存在するという問題に取り組むことができます。さらに、設計ドキュメントと要件を簡単に追跡できます。このシステムがソース コード管理システムにリンクされている場合、開発プロセス/要件の追跡がさらに容易になります。

于 2008-10-23T19:02:27.093 に答える