Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022
ワークフローは、Azure Boards が作業項目を追跡する方法の中核です。 各作業項目の種類には、状態、遷移、および理由を定義する独自のワークフローがあります。 遷移は、作業項目を状態間で前後に移動します。 カスタム状態を追加すると、Azure DevOpsプロセス ルールに基づいて既定の遷移が追加されます。
Azure Boardsでは、状態カテゴリを使用して、バックログ、ボード、ウィジェット間でワークフローの動作を一貫して適用します。 この記事では、状態をカテゴリにマップする方法と、そのマッピングが項目の表示、ボード列、およびレポート動作にどのように影響するかを説明します。
ワークフロー状態
ワークフローの状態は、作業項目が作成から終了に移動する方法を定義します。 アジャイル プロセスでは、ユーザー ストーリーは通常、新規、アクティブ、解決済み、およびクローズの順に移動します。 バックログから作業項目を削除するには、削除済み状態を使用します。 詳細については、「作業項目を移動、変更、または削除する」を参照してください。
次の図は、一般的な作業項目の種類 (ユーザー ストーリー (アジャイル)、問題 (Basic)、製品バックログ項目 (スクラム)、要件 (CMMI) の一般的な進行と回帰のパスを示しています。
ワークフローの状態: ユーザー ストーリー、アジャイル プロセス
カテゴリの状態
状態カテゴリは、アジャイル計画ツールとダッシュボード ウィジェットがワークフローの状態を解釈する方法を標準化します。 Teams は、ワークフローの状態を [ 提案済み]、[ 進行中]、[ 解決済み]、[ 完了] のカテゴリの状態にマップします。
次の表は、テスト計画作業項目の種類を含む 4 つのシステム プロセス全体で、既定の継承された状態がカテゴリの状態にどのようにマップされるかを示しています。 テスト ケース、テスト デザイン、および Test Suite ワークフローでは、4 つのプロセスすべてで同じマッピングが使用されます。
Categories (カテゴリ)
作業の追跡
テストの追跡
提案： このカテゴリは、新しく追加された作業項目の状態に使用します。 項目がバックログに表示され、ボードやタスクボードの最初の列は「提案済み」に対応しています。
新しい
設計 (テスト ケース)
進行中: アクティブな作業状態には、このカテゴリを使用します。 アイテムはバックログに表示され (非表示でない限り)、中央のボード列にマップされます。
アクティブ (バグ、エピック、機能、ユーザー ストーリー)
アクティブ (テスト 計画);計画中 (テスト スイート);進行中 (テスト スイート);準備完了 (テスト ケース)
解決： このカテゴリは、ソリューションが実装されているが、まだ検証されていない状態 (通常はバグの場合) に使用します。 解決済みの項目は、既定でバックログに表示され、バーンダウン グラフに含めることができ、多くのツールで進行中と同様に動作します。
解決済み (バグ)
該当なし
完了： このカテゴリは、完了した作業状態に使用します。 アイテムはバックログに表示されず、ボードの最後の列にマップされます。 作業項目の種類ごとに、このカテゴリにマップできる状態は 1 つだけです。
終了 (バグ、エピック、機能、ユーザー ストーリー)
クローズ (テスト ケース);完了 (テスト スイート);非アクティブ (テスト 計画)
削除： このカテゴリを削除済み状態と共に使用して、バックログとボードエクスペリエンスからアイテムを非表示にします。
削除済み (エピック、フィーチャー、ユーザーストーリー)
該当なし
作業項目の種類が表示される場所
次の表は、各作業項目の種類カテゴリが表示される場所のクイック リファレンスとして使用します。
| 作業項目の種類のカテゴリ | 次に表示: |
|---|---|
| 要件 | 製品ボードのみ |
| 機能 | フィーチャー ポートフォリオ ボードのみ |
| エピック | エピック ポートフォリオ ボードのみ |
| カスタム | カスタムポートフォリオボードのみ |
ヒント
各ワークフローの状態をボード列にマップします。 状態がマップされていない場合、ボードには表示されません。
注意
- バックログとボードは、 変更日 が 183 日 (約 6 か月) より古い場合、完了または終了した作業項目を非表示にします。
- クエリを実行して非表示のアイテムを検索します。
- 変更日を更新するためにマイナー更新を行って、バックログまたはボードに項目をもう一度表示します。
注意
- バックログとボードは、 変更日 が 1 年以上経過すると、完了した作業項目または終了した作業項目を非表示にします。
- クエリを実行して非表示のアイテムを検索します。
- 変更日を更新するためにマイナー更新を行って、バックログまたはボードに項目をもう一度表示します。
[アクティブ化した人]、[アクティブ化された日]、[解決者]、[解決日] フィールド
システムは、ワークフロー カテゴリの状態の変更に基づいて、これらのフィールド (アクティブ化基準、有効化日、解決日、解決日) を更新します。
- ワークフローの状態が [進行中 ] カテゴリに変わると、システムは アクティブ化日とアクティブ 化日を更新 します。
- ワークフローの状態が 解決済み カテゴリに変わると、システムは 解決日 と 解決日を更新します。
ワークフロー状態を状態カテゴリにマップする方法の詳細については、「 ワークフローの状態と状態のカテゴリをバックログとボードで使用する方法」を参照してください。
注意
このロジックは、Azure DevOps Services、 Azure DevOps Server 2020.1 更新プログラム、およびそれ以降のバージョンに適用されます。
これらのフィールドはワークフロー状態カテゴリを参照するため、追加するカスタム ワークフローの状態でもフィールドの更新がトリガーされます。 詳細については、「 プロセスのワークフローをカスタマイズする」を参照してください。
その他のメモ
- フィールドは、作業項目が設定されているカテゴリ以外の状態から移動するたびに更新されます。 たとえば、作業項目を 新規 から 完了 に移動すると、解決者/解決日 フィールドが更新されます。 修正済み から テスト準備完了 に移動しても、これらは同じカテゴリ状態にあるため、解決者/解決日 フィールドは更新されません。
- [解決済み] 状態から [アクティブ] 状態など逆方向に移行すると、システムは、[解決者/解決日] フィールドの値をクリアします。 [アクティブ] から [新規] に移動すると、[有効化者]/[有効化日] フィールドがクリアされます。
- これらのフィールド値は手動で変更しないでください。 これらのフィールドはシステム ルールによって管理されるシステム フィールドであり、Azure DevOps によって手動で入力された値はすべて上書きされます。
状態を追加する時期と列を追加する時期
状態と列を一緒に使用して作業状態を追跡しますが、それぞれを異なるスコープに使用します。
- 状態: チーム間で共有されるプロジェクト レベルのワークフロー ロジック。
- 列: チーム レベルのボードの視覚化。
プロセス編集アクセス許可 (通常はコレクション管理者または委任されたプロセス エディター Project) を持つユーザーは、カスタム状態を追加できます。 チーム管理者とProject管理者は、ボード列を追加できます。
チームがクエリ、レポート、チーム間の一貫性のために共有ワークフロー定義を必要とする場合に、カスタム状態を追加します。 カスタム状態は、プロセスを参照する作業項目の種類に伝達されます。
共有ワークフローを変更せずに、チームがボード固有の作業ビューを必要とする場合は、列を追加または調整します。
混乱を避けるには、作業項目の所有権をチーム領域のパスに合わせて維持するか、複数のチームが同じプロセスに従うときに、カスタム状態で共有ワークフローを標準化します。
pull request を使用して作業項目を自動的に完了する
作業項目をプル要求 (PR) にリンクすると、PR の完了時Azure DevOpsリンクされた作業項目を自動的に完了できます。 詳細については、「プル要求で作業項目を自動的に完了する」を参照してください。
作業項目の状態遷移を自動化する
Azure DevOpsは、子タスクの状態に基づいて、親作業項目の状態を自動的に更新できます。 詳細については、「 作業項目の状態遷移の自動化」を参照してください。
関連コンテンツ
継承プロセス モデル
オンプレミス XML プロセス モデル
ダッシュボードウィジェット