Issue Manager では、バグ、ドキュメントの問題、および機能拡張という問題の種類ごとにデフォルトのワークフローが用意されています。これらについては、「デフォルト ワークフローの理解」を参照してください。これらのワークフローが組織のニーズを満たさない場合は、変更して使用できます。次のようなカスタマイズが可能です。
• 問題が通過する状態の数と名前。
• 特定の状態で有効なアクション。これらのアクションは、[ワークフロー] ウィンドウに表示されます。
• 現在の状態に対する各アクションによってもたらされる状態。 現在の状態 ---- アクション 1 ---> 新しい状態 1
現在の状態 ---- アクション 2 ---> 新しい状態 2
...など
• 各アクションを実行するアクセス許可を持つグループ。
• ユーザーが問題に対するアクションを実施するときに表示されるアクション ダイアログの外観。
推奨される方法
最も簡単で信頼できる方法は、デフォルトのワークフローに簡単な変更を行うことです（たとえば、状態名を編集する）。何もない状態から新しいワークフローを作成するのではなく、デフォルトのワークフローを変更することを強くお勧めします。この章で説明する概念に関する経験が少ない場合、またはまったくない場合は、特にそうです。
状態図とアクション（状態遷移とも呼ばれます）の概念に習熟していること。
ワークフロー作成の一般的なステップ
このセクションでは、組織の問題解決プロセスを紙と鉛筆またはホワイトボードでモデル化する準備作業を行います。適切な管理者などに会って、自分の組織における最適な問題処理プロセスについてよく理解しておくことをお勧めします。
ワークフローを作成する一般的なステップは以下のとおりです。問題の種類ごとにこのステップを繰り返します。
1 状態図を作成します。
- その種類の問題が最終状態に達するまでに通過する必要のある各状態を記述します。
- 最終状態に達するまでにこの種類の問題に対して実施できる各アクションを記述します。ワークフローで前の状態に問題を戻す "負の" アクションも含めます。
2 アクションに動詞を含む名前を付けます。
3 ワークフローを最適化します。
4 状態の所有者とアクセス許可を追加します。
5 グループおよびユーザーの問題の初期状態を決定します。
6 データ入力を準備します（省略可能）。
ホワイトボードまたは紙に状態図を描きます。各状態を箱の中に記述し、各状態の間には十分なスペースを設けます。
一方の端だけに矢印が付いた線として、状態間の有効な各アクションを描画します。1 本の矢印が 1 個の個別のアクションです。
例
次に示す例は、独自のワークフローに組み込む状態のサンプルです。新しいバグが入ってくると、組織内のだれかが、レビューのためにそのバグを適切な QA エンジニアにディスパッチします。QA エンジニアが報告された動作が新しいバグであることに同意すると、バグは修正のために開発部門に送られます。開発部門では、バグに対していくつかのアクションを実施できます。
• バグ レポートに記述されている動作は設計どおりの動作なので、問題はバグではない。
• 次のリリースまでバグの修正を先送りする。
• バグを再現できない。
• バグは修正済み。
もちろん、これらは開発者の主張でしかなく、まだ検証を受けていません。ワークフロー モデルでは、このような主張を、[解決]、[先送り]、[再現不能]、[非バグ] という状態で反映させます。疑問符は、これらの主張がまだ QA エンジニアによる検証を受けていないことを意味します。
QA エンジニアによる検証は、ワークフローでの最後のステップです。主張が検証されると、バグは 4 つある最終状態のいずれかに移動します。各状態は前の状態と同じ名前ですが、疑問符が付いていません。
各アクションには動詞を割り当てることをお勧めします。
ワークフローで前の状態にバグが戻る場合について考えます。このような負のアクションをモデル化します。たとえば、QA エンジニアは開発者の主張を却下する場合があり、問題は開発部門に戻されます。
また、問題がたどる各過程の検討中に、正のアクションが不足していことがわかる場合もあります。たとえば、QA エンジニアも問題レポートを却下し、結果としてその問題を完了させる場合もあります。次に示す例の図では、QA エンジニアによる [バグの却下] アクションにより、[非バグ] 状態に移行します。すべてのアクションが最終的には最終状態に至ることを確認します。
修正後の例
サンプルのワークフロー図に対する変更個所は、太字で示されています。
見るとわかるように、前の図は複雑すぎて役に立ちません。ワークフローを簡単にするには、[ディパッチ] アクションを除去できます。なぜなら、正しい受信箱へのバグの配布は、Issue Manager のルーティング ルールが処理するからです。前の図では、[新規バグ] 状態と [ディスパッチ] アクションを削除し、QA エンジニアがバグをレビューできる状態からバグを開始できます。この状態は、[レビュー未完了] と呼ぶことができます。
このワークフローのもう 1 つの欠点は、実質的に状態が反復していることです。Issue Manager の方法論を使用すると、理由コードをアクションに割り当てることで、冗長な状態を除去できます。理由コードが必要な各アクションについて、簡単で内容がわかるキーワードを考えます。理由コードの詳細については、「理由コード」を参照してください。冗長な箇所を特定するには、ワークフローで繰り返されているパターンを探します。たとえば、前の図では、最後の状態の行（[非バグ]、[先送り]、[再現不能]、[解決]）は、アクションごとに異なる理由コードを使用する 1 つの状態 [対応完了] にまとめることができます（たとえば、[対応完了/非バグ]、[対応完了/解決] など）。
最後から 1 つ前の行も、開発者の主張を検証する QA のロールを認識する 1 つの状態にまとめることができます。この状態は、[QA 準備完了] と呼ぶことができます。ここでも理由コードを使用して、バグの状態が変化した理由を示すことができます（たとえば、[解決] または [先送り] の理由コードでバグが [QA 準備完了] 状態に到着するなど）。QA が実施する 4 つの [却下] アクションは、1 つの [却下] アクションにまとめることができます。同様に、QA が実施する 4 つの [検証済み] アクションは、1 つの[検証済み] アクションにまとめることができます。
修正後の例
次に示すのは、ディスパッチ アクションと冗長性を除去して最適化した後のすっきりしたワークフローの図です。
Issue Manager では、問題はその状態と所有者に従って送られます。状態の所有者とは、組織内で、特定の状態にある問題を担当するロールです。たとえば、デフォルトのワークフローでは、QA は[レビュー未完了] 状態の問題を担当します。状態の所有者の詳細は、「状態の所有者」を参照してください。次に、最終的な図の各状態に所有者を割り当てる必要があります。
最後に、各アクションを実施するアクセス許可を持つグループを決定します。たとえば、デフォルトのワークフローでは、開発部門のユーザーだけが問題を修正できます（つまり、[解決] アクションを実施できます）。
データ入力シートの準備
必要に応じて、Issue Manager へのデータ入力を容易にするシートを準備します。ワークフローの情報は状態別に入力されるので、最初の列は現在の状態と所有者 にします。それから、以下の列見出しを追加します。
• 現在の状態に対して許可されているアクション
• 各アクションの結果である新しい状態
• 理由コード（該当する場合）
• アクセス許可 - 各アクションの実施を許可されているグループ
データ入力シートは次のようになります。
|
状態/所有者 |
アクション |
新しい状態 |
アクセス許可 |
|
|
|
|
|
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
|
|
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
|