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