Dev、QA、プロダクション間のバグを管理する

Question

私のソフトウェアチームはJiraを使用してバグを管理し始めたばかりなので、Jiraが利用可能なプロセスはかなり新しいです。

私たちが構築したシステムは、内部的にアプリケーションまたは顧客が直面しているWebアプリケーションであり、製品ライフサイクルタイプの開発ライフサイクルではなく、変更要求ベースでこれらの環境にリリースします。

Jiraを使用する方法は、各プロジェクト（通常は単一のCRです）がJiraで独自のプロジェクトを作成することです。

• 開発コードとユニットテストを以下のように当社のプロセスが統合テストの準備が整うまで
• 開発者は、統合テストを開始し、任意のバグは開発という名前のバージョンで、Jiraの中で提起され、その後です。
• すべての開発バグが修正されたら、QAに移ります。そこでは、ビルドをテストチームに渡します。新しいバージョン 'QA'が作成され、QAで見つかったすべてのバグがこのバージョンに対して記録されます。
• すべてのバグが閉じられると、プロジェクトはLiveになり、プロジェクトはJiraで閉じられます。私は、我々は間違った方法でバージョンフィールドを使用している疑いがあるが、私はのJiraに新しいですように私たちがしている場合はわからない、または、Jiraのの、より機敏な製品の種類の用途で見てきたものから、

それを行うより良い方法があれば。

このタイプの環境でJiraを使用している人から、Jiraを使用する正しい方法が何であるかを知ることができます。

Answer 1

JIRAをさまざまな環境で使って、チームのサイズやプロジェクトの種類を変えてみた後、私がお勧めしたいのはこれです。

• JIRAプロジェクトを使用して、組織内のチームメンバーのサブセットに対応する大規模で個別の機能領域を指定します。新しいWebアプリケーションまたは内部顧客アプリ。
• プロジェクトまたはそれを処理するチームが十分な大きさのものである場合は、JIRAコンポーネントを使用してさまざまな機能領域を定義します。次に、コンポーネントに新しいコンポーネントを自動的に割り当てるコンポーネントのリードを割り当てることができます。その結果、どの機能領域が最もバグがあり、テストチームからより多くの関心が必要なのかを追跡できます。
• バージョンについては、説明したように、開発、ライブ、およびQAバージョンを確実に設定できますが、これは伝統的にJIRAの問題ステータスにマッピングされています。標準のJIRAワークフローでは、開発者が作業している間に問題がオープンされ、機能やバグ修正が完了した時点で解決され、QAが機能や修正を検証すると終了します。
• 同じアプリケーションの新機能を指定する複数のCRがある場合は、JIRAバージョンを使用して、機能セットやタイムスケジュールに基づいてさまざまなリリースのアプリケーションを定義します。

上記のアプローチを使用すると、各チームや個々の開発者/テスト担当者の作業を追跡し、テストや配備の準備が整うようにアプリのすべての問題が解決されたことを知ることができます。私は伝統的な製品ライフサイクルを使用していないと言いましたが、あなたの組織が非常に小さく、最初のバージョンが準備された後に破棄されるアプリケーションを開発しない限り、このアプローチから多くの利益を得ると思います。