バックログとボードでのワークフローの状態と状態のカテゴリの使用方法How workflow states and state categories are used in Backlogs and Boards

Azure Boards | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2013Azure Boards | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2013

すべてのワークフローは、状態、遷移、および理由で構成されています。All workflows consist of states, transitions, and reasons. ワークフローは、作業項目の種類 (WIT) に対して定義されます。Workflows are defined for a work item type (WIT). 遷移では、2つの状態間での順方向および逆方向の移動がサポートされます。A transition supports forward and backward movement among two states. カスタム状態を追加すると、システムによって、カスタム状態から他のすべての継承された状態への遷移が自動的に追加されます (削除を除く)。When you add a custom state, the system automatically adds transitions from the custom state to all other inherited states (except for Removed).

各状態は、状態カテゴリ (以前はメタ状態と呼ばれていた) に属します。Each state belongs to a state category (previously referred to as a metastate). 状態カテゴリは、アジャイルツールのバックログとボードのビューをサポートします。State categories support the Agile tool backlog and board views.

ワークフロー状態Workflow states

ワークフローの状態では、作業項目の作成が終了するまでの進行状況を定義します。Workflow states define how a work item progresses upon its creation to closure. たとえば、ユーザーストーリー (アジャイルプロセス) に対して定義されている4つの主要な状態は、[新規]、[アクティブ]、[解決済み]、[終了] の4つの状態の進行を定義します。For example, the four main states defined for the User Story (Agile process) define a progression of four states, from New, Active, Resolved, to Closed. (削除された状態では、バックログに表示される作業項目の削除をサポートします。詳細については、「 作業項目の移動、変更、または削除」を参照してください)。(The Removed state supports removing a work item from appearing on the backlog; to learn more, see Move, change, or delete work items.)

ユーザーストーリー、プロダクトバックログ項目、および要件 Wit の自然進行と回帰は、以下のようになります。The natural progressions and regressions of the user story, product backlog item, and requirement WITs are as shown.

ワークフローの状態: ユーザーストーリー、アジャイルプロセスWorkflow states: User Story, Agile process

ユーザーストーリーワークフローの状態、アジャイルプロセスUser Story workflow states, Agile process

状態のカテゴリState categories

一方、状態のカテゴリでは、アジャイル計画ツールと選択ダッシュボードウィジェットが各ワークフローの状態を処理する方法を決定します。State categories, on the other hand, determine how Agile planning tools and select dashboard widgets treat each workflow state. バックログ、ボード、ウィジェットによって使用される状態カテゴリが提案され、進行中で、完了します。The state categories used by the backlogs, boards and widgets are Proposed, In Progress, and Complete.

既定の継承された状態は、3つのシステムプロセスすべてとテストケース管理 Wit の状態カテゴリにマップされます。Here's how the default, inherited states map to the state categories for all three system processes plus test case management WITs. テストケース、テスト設計、およびテストスイートのワークフロー状態は、4つのシステムプロセスすべてで同じです。The workflow states for Test Case, Test Design, and Test Suite are the same across all four system processes.

注意

基本プロセスは、プロジェクトを Azure DevOps Services に追加する場合、または 2019 Update 1 Azure DevOps Serverする場合に使用できます。The Basic process is available when you add a project to Azure DevOps Services or Azure DevOps Server 2019 Update 1. 以前のオンプレミスのデプロイでは、[アジャイル]、[スクラム]、または [CMMI プロセス] を選択します。For earlier on-premises deployments, choose Agile, Scrum, or CMMI process.

CategoriesCategories Work tracking WitWork tracking WITs テスト追跡 WitTest tracking WITs
提案済み: 新しく追加された作業項目に関連付けられている状態に割り当てられ、バックログに表示されます。Proposed: Assigned to states associated with newly added work items so that they appear on the backlog. かんばんボードと Taskboards の最初の列が、提案された状態カテゴリにマップされます。The first column on the Kanban boards and Taskboards map to a Proposed state category. 作業予定To Do デザイン (テストケース)Design (Test Case)
進行中: アクティブな作業を表す状態に割り当てられます。In Progress: Assigned to states that represent active work. このカテゴリにマップされた状態に割り当てられた作業項目は、バックログに表示されます (非表示にすることを選択した場合を除きます)。また、かんばんボードの中央の列を構成します。Work items assigned to states mapped to this category appear in the backlog (unless you choose to hide them) and make up the middle columns on Kanban boards. 実行中Doing アクティブ (テスト計画)Active (Test Plan)
計画段階 (テストスイート)In Planning (Test Suite)
進行中 (テストスイート)In Progress (Test Suite)
準備完了 (テストケース)Ready (Test Case)
解決済み: ソリューションを表す状態に割り当て済みですが、まだ検証されていません。Resolved: Assigned to states that represent a solution has been implemented, but are not yet verified. 一般に、これらの状態はバグ Wit に適用されます。Generally these states apply to bug WITs. 既定では、解決済みの状態の作業項目はバックログに表示されます。Work items in a Resolved state appear on the backlog by default. アジャイルツールは、解決済みの状態カテゴリを [進行中の状態] カテゴリとまったく同じように扱います。The Agile tools treat the Resolved state category exactly the same as the In Progress state category. 該当なしn/a 該当なしn/a
完了: 完了した作業を表す州に割り当てられます。Completed: Assigned to states that represent work that has finished. このカテゴリに状態がある作業項目はバックログに表示されず、かんばんボードの最後の列に表示されます。Work items whose state is in this category don't appear on the backlog and do appear in the last column of the Kanban board. このカテゴリの状態を変更することも、このカテゴリに状態を追加することもできないことに注意してください。Note that you can't modify states in this category nor can you add states to this category. 完了Done
Closed (テストケース)Closed (Test Case)
完了 (テストスイート)Completed (Test Suite)
非アクティブ (テスト計画)Inactive (Test Plan)
削除済み: 削除された状態に割り当てられます。Removed: Assigned to the Removed state. 削除されたカテゴリにマップされた状態の作業項目は、バックログとボードのエクスペリエンスによって非表示になります。Work items in a state mapped to the Removed category are hidden from the backlog and board experiences. 該当なしn/a 該当なしn/a

/日付によってアクティブ化され、/日付フィールドによって解決されましたActivated By/Date and Resolved By/Date fields

—対応するワークフローカテゴリの状態に基づいて変更が行われたときに、システムに よってアクティブ化 されたこれらのフィールド、アクティブ化日解決****日、解決日 が更新され — ます。The system updates these fields—Activated By, Activated Date, Resolved By, and Resolved Date—when a change occurs based on corresponding workflow category states. ワークフローの状態が " 提案済み " の状態カテゴリに変更されると、[ アクティブ化 ] と [ アクティブ化日 ] が更新されます。When the workflow state changes to a Proposed state category, Activated By and Activated Date are updated. ワークフローの状態が 解決済み の状態のカテゴリに変化すると 、解決****日と解決日 が更新されます。When the workflow state changes to a Resolved state category, Resolved By and Resolved Date are updated.

ワークフローの状態を状態カテゴリにマップする方法の詳細については、「 バックログとボードでのワークフローの状態と状態のカテゴリの使用方法」を参照してください。To learn more how workflow states map to state categories, see How workflow states and state categories are used in Backlogs and Boards.

注意

ここで説明するフィールドを制御するロジックは、Azure DevOps Services、 Azure DevOps Server 2020.1 update、およびそれ以降のバージョンに適用されます。The logic governing the fields described here applies to Azure DevOps Services, Azure DevOps Server 2020.1 update, and later versions.

これらのフィールドはワークフローの状態カテゴリを参照するため、追加したカスタムワークフローの状態はフィールドの更新時に参照されます。Because these fields reference the workflow state categories, custom workflow states that you add are referenced when updating the fields. カスタマイズの詳細については、「 プロセスのワークフローをカスタマイズする」を参照してください。To learn more about customization, see Customize the workflow for a process.

その他のメモ:Additional notes:

  • フィールドは、設定されている以外のカテゴリの状態から作業項目が移動するたびに更新されます。The fields get updated anytime a work item moves from any category state other than that being set. たとえば、作業項目を [ 新規 ] から [ 修正 済み] に更新すると、[解決日] フィールドと [ 解決日 ] フィールドが更新されます。For example, if you update a work item from New to Fixed, the Resolved By/Resolved Date fields are updated. ただし、[固定] から更新し、同じカテゴリの状態にある テストの準備 ができている場合は、[解決 — — 済み] または [解決日] フィールドが更新されません。However, if you update from Fixed and Ready for Testing—which are in the same category state—the Resolved By/Resolved Date fields aren't updated.
  • 解決済み の状態から アクティブ 状態に移行するなど、後方に移行すると、システムに よって解決 された日付フィールドの値がクリアされます。When you transition backwards, such as going from a Resolved to an Active state, the system clears the values for Resolved By/Resolved Date fields. [ アクティブ ] から [ 新規] になっている場合は、[アクティブ化 /アクティブ 化された日付] フィールドの値がクリアされます。If you got from Active to New, the system clears the values for Activated By/Activated Date fields.
  • これらのフィールドの値は手動で変更しないでください。Don't manually change the values for these fields. システムルールによって管理されるシステムフィールドです。They are system fields that are governed by system rules. 設定しようとしたすべての値が書き込まれます。Any value you attempt to set will get over written.

状態とかんばん列を追加する場合When to add a State versus a Kanban column

状態とかんばんの両方の列を使用して、作業の状態を追跡します。Both States and Kanban columns are used to track the status of work. ワークフローの状態はプロジェクト全体で共有され、かんばん列はチーム内で共有されます。Workflow states are shared across a project while Kanban columns are shared within a team. チーム管理者はかんばん列を追加できますが、カスタム状態を追加できるのはプロジェクトコレクション管理者だけです。Only project collection admins can add custom states, while team admins can add Kanban columns.

組織が採用しているビジネスワークフローに従ってすべてのチームが状態を追跡できるようにするには、カスタム状態を追加します。Add custom states when you want all teams to track the status according to the business workflow adopted by the organization. プロセスをカスタマイズすることで、そのプロセスを参照するプロジェクトと Wit が自動的にカスタマイズされます。By customizing the process, you automatically customize the projects and WITs that reference that process.

また、複数のチームが追跡するワークフローの状態をサポートするカスタム状態を追加することにより、チームがかんばん列に基づいてクエリを作成したときに発生する可能性のある混乱を回避できます。Also, by adding custom states to support those workflow states that several teams want to track, you avoid the confusion that can arise when team's create a query based on a Kanban column. 各チームはかんばんボードの列とスイムレーンをカスタマイズできるため、異なるボードに表示される作業項目に割り当てられた値は同じではない場合があります。Because each team can customize the Kanban board columns and swimlanes, the values assigned to work items which appear on different boards may not be the same. この問題の主な回避策は、チーム区分パスによって作業項目の単一の所有権を維持することです。The primary work around for this issue is to maintain single ownership of work items by team area path. もう1つの回避策は、チーム間で共有できるカスタム状態を追加して列を形式化することです。Another work around is to formalize the columns by adding custom states which can be shared across teams.

プル要求による作業項目のオートコンプリートAuto completion of work items with pull requests

作業項目をプル要求 (PR) にリンクする場合、PR が正常に完了したときに自動的に作業項目を完了するオプションがあります。When you link a work item to a pull request (PR), you have the option to automatically complete those work items when you successfully complete the PR. 次の図に示すように、[ マージ後にリンクされた作業項目を完了 する] チェックボックスをオンにするだけで済みます。As shown in the following image, all you have to do is check the box to Complete linked work items after merging. システムは、既定では、将来の Pr のために選択します。The system defaults to your selection for future PRs.

プル要求の完了ダイアログ、PR オプションの完了による作業項目のオートコンプリート

次のような状況では、作業項目の状態が [完了]、[終了]、または WIT の [終了] カテゴリに属する状態に自動的に更新されません。In the following circumstances the system won't automatically update the work item state to Done, Closed, or the state that belongs to the Closed category for the WIT:

  • WIT が継承プロセスモデルで管理されている作業項目は、既に解決済みのカテゴリに属している状態になっています。The work item, whose WIT is managed with the Inheritance process model, is already in a State that belongs to the Resolved category. このインスタンスでは、システムによって状態が更新されることはありません。In this instance the system won't update the State. たとえば、アジャイルプロセスから派生したバグが解決済みの状態である場合、システムはそれを Closed に移行しません。For example, if a bug derived from the Agile process is in a Resolved state, the system won't transition it to Closed.
  • 作業項目は、既に完了したカテゴリに属している状態になっています。The work item is already in a State that belongs to the Completed category. これ以上の移行は必要ありません。No further transition is required.
  • 作業項目に関連付けられている WIT には、作業項目を次の状態に保存できないようにするワークフローフィールド規則が1つ以上含まれています。The WIT associated with the work item contains one or more workflow field rules that prevent the work item being saved to a next state. たとえば、規則では、作業項目を閉じる際に別のフィールドを定義する必要があります。For example, a rule requires that another field must be defined as part of closing the work item.
  • 内部設置型の配置と Azure Boards ホストされるプロセスモデルでは、ワークフローを移行するときに実行するアクション (ACTION 要素) を指定するようにワークフローを変更する必要があります。For on-premises deployments and Azure Boards Hosted process model, you must modify the workflow to specify actions (ACTION element) to take place when transitioning the workflow. 作業項目の種類のワークフローを変更する」、「アクションを指定する」を参照してください。See Change the workflow for a work item type, Specify Actions.

プロセスモデルの詳細については、「 作業追跡エクスペリエンスのカスタマイズ」を参照してください。To learn more about process models, see Customize your work tracking experience.