ワークフローの最適化

見るとわかるように、前の図は複雑すぎて役に立ちません。ワークフローを簡単にするために、[ディスパッチ] アクションを除去できます。 これは、正しい受信箱へのバグの配布を、Issue Manager のルーティング ルールが処理するからです。前の図では、[新規バグ] 状態と [ディスパッチ] アクションを削除し、QA エンジニアがバグをレビューできる状態からバグを開始できます。この状態は、[レビュー未完了] と呼ぶことができます。

このワークフローのもう 1 つの欠点は、実質的に状態が反復していることです。Issue Manager の方法論を使用すると、理由コードをアクションに割り当てることで、冗長な状態を除去できます。理由コードが必要な各アクションについて、簡単で内容がわかるキーワードを考えます。理由コードの詳細については、「理由コード」を参照してください。冗長な箇所を特定するには、ワークフローで繰り返されているパターンを探します。たとえば、前の図では、最後の状態の行 ([非バグ]、[先送り]、[再現不能]、[解決]) は、アクションごとに異なる理由コードを使用する 1 つの状態 [対応完了] にまとめることができます (たとえば、[対応完了/非バグ]、[対応完了/解決] など)。

最後から 1 つ前の行も、開発者の主張を検証する QA のロールを認識する 1 つの状態にまとめることができます。この状態は、[QA 準備完了] と呼ぶことができます。ここでも理由コードを使用して、バグの状態が変化した理由を示すことができます (たとえば、[解決] または [先送り] の理由コードでバグが [QA 準備完了] 状態に到着するなど)。QA が実施する 4 つの [却下] アクションは、1 つの [却下] アクションにまとめることができます。同様に、QA が実施する 4 つの [検証済み] アクションは、1 つの [検証済み] アクションにまとめることができます。

例