デフォルト ワークフローの理解

Issue Manager には、バグ、ドキュメントの問題、および機能拡張に対しての 3 種類のデフォルト ワークフローが用意されています。

•   デフォルトのワークフローについての説明を読み、それが自分の組織のニーズに合っていると判断した場合は、この章をそれ以上読む必要はありません。

•   一方、デフォルトのワークフローを変更する場合、または独自のワークフローを作成する場合は、「独自のワークフローの作成」を参照してください。

図を見る手がかり

3 つのワークフロー図では、次の記号とラベルを使用します。

デフォルトのバグ ワークフロー

図の説明

編集、再割り当て、コメントの追加、および回避策の追加の各アクションは、図から省略されています。

•   編集と再割り当ては各状態に対してあらかじめ定義されており、変更できません。これらのアクションは、問題の状態を変更しません。

•   コメントの追加はすべての状態に対して定義されており、問題の状態を変更しません。

•   回避策の追加は、開発準備完了、QA 準備完了、QA やり直し、および対応完了に対して定義されており、問題の状態を変更しません。

バグ ワークフローのデフォルトの理由コード

デフォルトのバグ ワークフローで提供されているすべての理由コードを確認するには、[設定｜ワークフロー] を参照してください。問題の種類として [バグ] を選択すると、その有効なアクションと理由コードが表示されます。

例

デフォルトのバグ ワークフローの一般的な処理パスについて考えます。報告されたバグは、レビュー未完了の状態でワークフローに入り、QA エンジニアの受信箱に送られます。バグは、確認された後、開発者の受信箱（開発準備完了状態）に送られます。開発者は、バグを解決したことを宣言し、解決アクションを実施します。解決アクションは、理由コード解決を添えて、QA 準備完了にバグを送ります。問題を受け取った QA エンジニアは、バグが修正されていることを検証します。つまり、検証アクションが実施されて、バグは対応完了状態に送られ、理由コードは解決が維持されます。

次に、前の例を少しだけ変更してみます。QA エンジニアは、バグが修正されたという開発者の主張を却下するものとします。バグは開発者の受信箱に戻されますが、今度は理由コードが却下になっています。開発者は問題を再現できないため、追加情報が必要アクションを実施します。バグは QA やり直しに送られます。これに対し、QA エンジニアは、重複として指定アクションまたは失効した問題アクションのいずれかを実施して問題を完了させるか、または問題を明らかにしてからバグを開発準備完了に差し戻すことができます。

デフォルトのドキュメント ワークフロー

図の説明

編集、再割り当て、およびコメントの追加の各アクションは、図から省略されています。

•   編集と再割り当ては各状態に対してあらかじめ定義されており、変更できません。これらのアクションは、問題の状態を変更しません。

•   コメントの追加は、QA 準備完了を除くこのワークフローのすべての状態に対して定義されており、問題の状態を変更しません。

ドキュメント ワークフローのデフォルトの理由コード

デフォルトのドキュメント ワークフローで提供されているすべての理由コードを確認するには、[設定｜ワークフロー] を参照してください。問題の種類として [ドキュメントの問題] を選択すると、その有効なアクションと理由コードが表示されます。

例

ドキュメントの問題が、レビュー未完了状態でワークフローに入るものとします。この時点で、レビュー担当者は 3 種類のアクションを実施できます。つまり、問題を承認するか、却下するか、別の問題と同じものとして指定するかです。却下された問題、または重複することが判明した問題は、完了処理されて、理由コードは却下または重複になります。レビュー担当者が修正の必要なドキュメントの問題であると判断した問題は、対応中ドキュメント状態に移動し、ドキュメント受信箱に送られます。ドキュメント スペシャリストは、この時点で、解決アクションまたは重複として指定アクションのどちらかを実施できます。

•   解決アクションは、「解決」理由コードを添えて QA 準備完了状態に問題を送ります。

•   重複として指定アクションは、重複の理由コードを添えて対応完了状態に問題を送ります。

後で修正が検証されると、問題は解決済みの理由コードで対応完了状態に移動されます。一方、修正が却下されると、問題は却下の理由コードでドキュメント受信箱に戻されます。

デフォルトの機能拡張ワークフロー

図の説明

編集、再割り当て、コメントの追加、および回避策の追加の各アクションは、図から省略されています。

•   編集と再割り当ては各状態に対してあらかじめ定義されており、変更できません。これらのアクションは、問題の状態を変更しません。

•   コメントの追加はこのワークフローのすべての状態に対して定義されており、問題の状態を変更しません。

•   回避策の追加は、レビュー未完了を除くすべての状態に対して定義されており、状態に影響を与えません。

機能拡張ワークフローのデフォルトの理由コード

デフォルトの機能拡張ワークフローで提供されているすべての理由コードを確認するには、[設定｜ワークフロー] を参照してください。問題の種類として [機能拡張] を選択すると、その有効なアクションと理由コードが表示されます。

例

機能拡張要求が承認されて、初期レビュー担当者（レビュー未完了状態）によりまたは管理チーム（管理呼び出し状態）により、開発部門（開発準備完了）に送られるものとします。初期レビュー担当者が可能性アクションを実施すると、管理チームが機能拡張要求を受け取ります。

初期レビュー担当者または管理チームが機能拡張要求を却下すると、問題は却下の理由コードで完了します。この却下アクションは、QA 準備完了状態の問題に対して実施される却下アクションとは異なります。この場合は、開発アクション（実装済み、実現不能、対応済み、または重複として指定）が議論されます。