バックログとボードのワークフローの状態について

  • [アーティクル]

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

すべてのワークフローは、状態、遷移、理由で構成されます。 ワークフローは、作業項目の種類に対して定義されます。 遷移は、2 つの状態間の前方および後方の移動に対応します。 カスタム状態を追加すると、カスタム状態からその他すべての継承された状態への遷移がシステムによって自動的に追加されます (削除済みを除く)。

各状態は、(以前はメタ状態と呼ばれていた) 状態カテゴリに属しています。 状態カテゴリは、アジャイル ツールのバックログ ビューとボード ビューに対応しています。

ワークフロー状態

ワークフローの状態によって、作業項目がどのようにして作成から終了に進行するかが定義されます。 ユーザー ストーリー (アジャイル プロセス) に対して定義されている 4 つの主な状態は、ユーザー ストーリーの進行状況を表します。 そのワークフローの状態は、新規、アクティブ、解決済み、終了です。 (削除済み状態は、バックログに表示される作業項目の削除をサポートしています。詳細については、作業項目の移動、変更、削除に関する記事を参照してください。)

作業項目の種類 (ユーザー ストーリー (アジャイル)、issue (Basic) プロダクト バックログ項目 (スクラム)、要件 (CMMI)) の自然な進行と回帰を次に示します。

ワークフローの状態: ユーザー ストーリー、アジャイル プロセス

ユーザー ストーリー ワークフロー状態、アジャイル プロセス

カテゴリの状態

カテゴリの状態によって、アジャイル計画ツールと選択ダッシュボード ウィジェットで各ワークフローの状態がどのように扱われるかが決まります。 バックログ、ボード、ウィジェットで使用される状態カテゴリは、"提案済み"、"進行中"、"解決済み"、"完了" です。

既定の継承された状態が、作業項目の種類: テスト計画を含む 4 つのシステム プロセスのカテゴリの状態にどのようにマップされるかを次に示します。 テスト ケース、テスト デザイン、テスト スイートのワークフローの状態は、4 つのシステム プロセスすべてで同じです。

Categories (カテゴリ)

作業の追跡

テストの追跡

提案済み: 新しく追加された作業項目に関連付けられている状態に割り当てられ、バックログに表示されます。 かんばんボードとタスクボードの最初の列は、提案済み状態カテゴリにマップされます。

新規

設計 (テスト ケース)

進行中: アクティブな作業を表す状態に割り当てられます。 このカテゴリにマップされた状態に割り当てられた作業項目は (非表示にすることを選択しない限り) バックログに表示され、かんばんボードの中央の列を構成します。

アクティブ (バグ、エピック、機能、ユーザー ストーリー)

アクティブ (テスト プラン) 計画中 (テスト スイート) 進行中 (テスト スイート) 準備完了 (テスト ケース)

解決済み: ソリューションが実装されたものの、まだ検証されていないことを表す状態に割り当てられます。 一般に、これらの状態はバグに適用されます。 カテゴリの状態が "解決済み" の作業項目は、既定でバックログに表示されます。 アジャイル ツールでは、カテゴリの状態 "解決済み" を、カテゴリの状態 "進行中" とまったく同じように扱います。

解決済み (バグ)

N/A

完了: 完了した作業を表す状態に割り当てられます。 このカテゴリの状態の作業項目はバックログに表示されず、かんばんボードの最後の列に表示されます。 このカテゴリの状態は変更することも、このカテゴリに状態を追加することもできません。

終了 (バグ、エピック、機能、ユーザー ストーリー)

終了 (テスト ケース) 完了 (テスト スイート) 非アクティブ (テスト プラン)

削除済み: 削除済み状態に割り当てられます。 "削除済み" カテゴリにマップされた状態の作業項目は、バックログとボード エクスペリエンスでは非表示になります。

削除済み (エピック、機能、ユーザー ストーリー)

該当なし

Note

完了または終了した作業項目は、変更日の値が 183 日 (約半年) を超えると、バックログとボードには表示されません。 クエリを使用すると、これらの項目を引き続き一覧表示できます。 バックログまたはボードに表示する場合は、それらの項目に軽微な変更を加えます。すると、クロックがリセットされます。

Note

完了または終了した作業項目は、変更日の値が 1 年を超えると、バックログとボードには表示されません。 クエリを使用すると、これらの項目を引き続き一覧表示できます。 バックログまたはボードに表示する場合は、それらの項目に軽微な変更を加えます。すると、クロックがリセットされます。

[アクティブ化した人]、[アクティブ化された日]、[解決者]、[解決日] フィールド

対応するワークフローのカテゴリの状態に基づいて変更が行われると、[アクティブ化した人]、[アクティブ化された日]、[解決者]、[解決日] の各フィールドがシステムによって更新されます。 ワークフローの状態が "作業中" 状態カテゴリに変わると、[アクティブ化した人] と [アクティブ化された日] が更新されます。 ワークフローの状態が "解決済み" 状態カテゴリに変わると、[解決者] と [解決日] が更新されます。

ワークフローの状態が状態のカテゴリにどのようにマップされるかの詳細については、ワークフローの状態と状態のカテゴリがバックログとボードでどのように使用されるかに関する記事を参照してください。

注意

ここで説明するフィールドを管理するロジックは、Azure DevOps Services、Azure DevOps Server 2020.1 更新プログラム、およびそれ以降のバージョンに適用されます。

これらのフィールドはワークフローの状態カテゴリを参照するため、追加したカスタム ワークフローの状態はフィールドの更新時に参照されます。 カスタマイズの詳細については、プロセスのワークフローのカスタマイズに関する記事を参照してください。

その他のメモ:

  • フィールドは、作業項目が設定されている以外のカテゴリの状態から変化するたびに更新されます。 たとえば、作業項目を "新規" から "修正済み" に更新すると、[解決者] と [解決日] フィールドが更新されます。 ただし、同じカテゴリの状態にある "修正済み" と "テスト準備完了" から更新した場合、[解決者] と [解決日] フィールドは更新されません。
  • "解決済み" 状態から "アクティブ" 状態へなど、逆方向に移行すると、システムによって [解決者] と [解決日] フィールドの値がクリアされます。 "アクティブ" から "新規" に移行した場合、システムによって [アクティブ化した人] と [アクティブ化された日] フィールドの値がクリアされます。
  • これらのフィールドの値を手動で変更しないでください。 これらはシステム ルールによって管理されるシステム フィールドです。 設定しようとする値はすべて上書きされます。

状態とかんばん列を追加するタイミングの比較

状態とかんばん列は、両方とも作業の状態を追跡するのに使用します。 ワークフローの状態はプロジェクト全体で共有される一方で、かんばん列はチーム内で共有されます。 カスタム状態はプロジェクト コレクション管理者のみが追加できる一方で、かんばん列はチーム管理者が追加できます。

組織が採用したビジネス ワークフローに従ってすべてのチームが状態を追跡する場合は、カスタム状態を追加します。 プロセスをカスタマイズすると、そのプロセスを参照するプロジェクトと作業項目の種類が自動的にカスタマイズされます。

複数のチームが追跡するワークフローの状態に対応するカスタム状態を追加すると、かんばん列に基づいてさまざまなチームがクエリを作成する結果引き起こされる混乱を回避できます。 各チームはかんばんボードの列とレーンをカスタマイズできるため、異なるボードに表示される作業項目に割り当てられた値が同じではない可能性があります。 この問題の主な回避策は、チーム区分パスによって作業項目の単一所有権を維持することです。 もう 1 つの回避策は、チーム間で共有できるカスタム状態を追加して列を形式化することです。

pull request を使用して作業項目を自動的に完了する

作業項目を pull request (PR) にリンクすると、PR が完了したときに、それらの作業項目を自動的に完了することができます。 詳細については、「プル要求で作業項目を自動的に完了する」を参照してください。

作業項目の状態遷移を自動化する

作業項目の状態は、その子タスクの状態に応じて自動的に更新できます。 詳細については、「作業項目の状態遷移の自動化」を参照してください。