バックログとボードのワークフローの状態について
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
すべてのワークフローは、状態、遷移、理由で構成されます。 ワークフローは、作業項目の種類に対して定義されます。 遷移は、2 つの状態間の前方および後方の移動に対応します。 カスタム状態を追加すると、カスタム状態からその他すべての継承された状態への遷移がシステムによって自動的に追加されます (削除済みを除く)。
各状態は状態カテゴリに属しており、アジャイル ツールのバックログ ビューとボード ビューをサポートします。
ワークフロー状態
ワークフローの状態によって、作業項目がどのようにして作成から終了に進行するかが定義されます。 ユーザー ストーリー (アジャイル プロセス) に対して定義されている 4 つの主な状態は、ユーザー ストーリーの進行状況を表します。 そのワークフローの状態は、新規、アクティブ、解決済み、終了です。 削除済み状態では、バックログに表示されないように作業項目を削除できます。詳細については、「作業項目を移動、変更、または削除する」を参照してください。
作業項目の種類 (ユーザー ストーリー (アジャイル)、issue (Basic) プロダクト バックログ項目 (スクラム)、要件 (CMMI)) の自然な進行と回帰を次に示します。
ワークフローの状態: ユーザー ストーリー、アジャイル プロセス
カテゴリの状態
カテゴリの状態は、アジャイル計画ツールと特定のダッシュボード ウィジェットで各ワークフローの状態をどのように処理するかを決定します。 各種の作業項目では、状態カテゴリを使用して作業の進行状況を追跡します。 状態は、同じプロセスを使用するすべてのプロジェクトに適用され、バックログとボードでの作業項目の表示形態に影響します。 バックログ、ボード、ウィジェットで使用される状態カテゴリは、"提案済み"、"進行中"、"解決"、"完了" です。
次の表は、継承された既定の状態が、テスト プラン作業項目の種類を含む 4 つのシステム プロセスのカテゴリ状態にどのように対応しているかを示します。 テスト ケース、テスト デザイン、テスト スイートのワークフローの状態は、4 つのシステム プロセスすべてで同じです。
Categories (カテゴリ)
作業の追跡
テストの追跡
提案済み: 新しく追加された作業項目に関連付けられている状態に割り当てられ、バックログに表示されます。 ボードとタスクボードの 1 列目は、提案済み状態カテゴリに対応します。
新しい
設計 (テスト ケース)
進行中: アクティブな作業を表す状態に割り当てられます。 このカテゴリに対応する状態に割り当てられた作業項目は、バックログに表示され (非表示にした場合を除く)、ボードの中央の列を構成します。
アクティブ (バグ、エピック、機能、ユーザー ストーリー)
アクティブ (テスト プラン) 計画中 (テスト スイート) 進行中 (テスト スイート) 準備完了 (テスト ケース)
解決済み: ソリューションが実装されたものの、まだ検証されていないことを表す状態に割り当てられます。 一般に、これらの状態はバグに適用されます。 カテゴリの状態が "解決済み" の作業項目は、既定でバックログに表示されます。 バーンダウン チャートに "解決済み" 状態を含めることで、進行状況をより正確に追跡することもできます。 アジャイル ツールでは、カテゴリの状態 "解決済み" を、カテゴリの状態 "進行中" とまったく同じように扱います。
解決済み (バグ)
該当なし
完了: 完了した作業を表す状態に割り当てられます。 状態がこのカテゴリにある作業項目はバックログに表示されず、ボードの最後の列に表示されます。 このカテゴリの状態は変更することも、このカテゴリに状態を追加することもできません。
終了 (バグ、エピック、機能、ユーザー ストーリー)
終了 (テスト ケース) 完了 (テスト スイート) 非アクティブ (テスト プラン)
削除済み: 削除済み状態に割り当てられます。 "削除済み" カテゴリにマップされた状態の作業項目は、バックログとボード エクスペリエンスでは非表示になります。
削除済み (エピック、機能、ユーザー ストーリー)
該当なし
Note
完了または終了した作業項目は、変更日の値が 183 日 (約半年) を超えると、バックログとボードには表示されません。 クエリを使用すると、これらの項目を引き続き一覧表示できます。 バックログまたはボードに表示する場合は、それらの項目に軽微な変更を加えます。すると、クロックがリセットされます。
Note
完了または終了した作業項目は、変更日の値が 1 年を超えると、バックログとボードには表示されません。 クエリを使用すると、これらの項目を引き続き一覧表示できます。 バックログまたはボードに表示する場合は、それらの項目に軽微な変更を加えます。すると、クロックがリセットされます。
[アクティブ化した人]、[アクティブ化された日]、[解決者]、[解決日] フィールド
対応するワークフローのカテゴリの状態に基づいて変更が行われると、[アクティブ化した人]、[アクティブ化された日]、[解決者]、[解決日] の各フィールドがシステムによって更新されます。 ワークフローの状態が "作業中" 状態カテゴリに変わると、[アクティブ化した人] と [アクティブ化された日] が更新されます。 ワークフローの状態が "解決済み" 状態カテゴリに変わると、[解決者] と [解決日] が更新されます。
ワークフローの状態が状態のカテゴリにどのようにマップされるかの詳細については、ワークフローの状態と状態のカテゴリがバックログとボードでどのように使用されるかに関する記事を参照してください。
注意
ここで説明するフィールドを管理するロジックは、Azure DevOps Services、Azure DevOps Server 2020.1 更新プログラム、およびそれ以降のバージョンに適用されます。
これらのフィールドはワークフローの状態カテゴリを参照するため、追加したカスタム ワークフローの状態はフィールドの更新時に参照されます。 カスタマイズの詳細については、プロセスのワークフローのカスタマイズに関する記事を参照してください。
その他のメモ:
- フィールドは、作業項目が設定されている以外のカテゴリの状態から変化するたびに更新されます。 たとえば、作業項目を "新規" から "修正済み" に更新すると、[解決者] と [解決日] フィールドが更新されます。 ただし、同じカテゴリの状態にある "修正済み" と "テスト準備完了" から更新した場合、[解決者] と [解決日] フィールドは更新されません。
- "解決済み" 状態から "アクティブ" 状態へなど、逆方向に移行すると、システムによって [解決者] と [解決日] フィールドの値がクリアされます。 "アクティブ" から "新規" に移行した場合、システムによって [アクティブ化した人] と [アクティブ化された日] フィールドの値がクリアされます。
- これらのフィールドの値を手動で変更しないでください。 これらはシステム ルールによって管理されるシステム フィールドです。 設定しようとする値はすべて上書きされます。
状態または列の追加
作業の状況を追跡するには、状態と列の両方を使用します。 ワークフローの状態はプロジェクト全体で共有され、列はチーム内で共有されます。 カスタム状態を追加できるのはプロジェクト コレクションの管理者のみで、列はチーム管理者が追加できます。
組織が採用したビジネス ワークフローに従ってすべてのチームが状態を追跡する場合は、カスタム状態を追加します。 プロセスをカスタマイズすると、そのプロセスを参照するプロジェクトと作業項目の種類が自動的にカスタマイズされます。
複数のチームでの追跡を要するワークフロー状態をサポートするために、カスタムの状態を追加すると、同じ列に基づいて複数のチームがクエリを作成することによる混乱を回避できます。 各チームによるボードの列やスイムレーンのカスタマイズが可能であるため、各ボードに表示される作業項目に割り当てられた値が同じではない可能性があります。 この問題の主な回避策は、チーム区分パスによって作業項目の単一所有権を維持することです。 もう 1 つの回避策は、チーム間で共有できるカスタム状態を追加して列を形式化することです。
pull request を使用して作業項目を自動的に完了する
作業項目を pull request (PR) にリンクすると、PR が完了したときに、それらの作業項目を自動的に完了することができます。 詳細については、「プル要求で作業項目を自動的に完了する」を参照してください。
作業項目の状態遷移を自動化する
作業項目の状態は、その子タスクの状態に応じて自動的に更新できます。 詳細については、「作業項目の状態遷移の自動化」を参照してください。
関連記事
オンプレミス XML プロセス モデル
ダッシュボード ウィジェット