作業項目の種類に関するワークフローの変更

Azure DevOps Server |Azure DevOps Server 2022

作業項目の種類 (WIT) のワークフローを変更して、ビジネスプロセスとチームプロセスをサポートします。 WIT は、ソフトウェア開発をサポートするために、あらゆる種類の作業 (要件、タスク、コードの欠陥) の追跡をサポートします。

ワークフローは、チームメンバーが実行する作業の論理的な進行と回帰を決定します。また、[状態] フィールドと [理由] フィールドのドロップダウンメニューに表示される値も指定します。詳細については、プロセスとプロセステンプレートの概要に関する記事を参照してください。

製品バックログ項目のワークフロー (スクラムプロセステンプレート)

製品バックログ項目のワークフロー、スクラムプロセス

注意

この記事では、ワークフローの状態をカスタマイズする方法について説明します。特定の作業項目に割り当てられている状態を変更するには、次のいずれかの記事を参照してください: ボード、進行中の作業の追跡、またはタスクボード、タスクの状態の更新。また、多くの作業項目に対して State の更新を実行することもできます。

ビルドパイプラインワークフローの詳細については、「 GET started with CI/CD」を参照してください。

作業項目の種類の XML 定義を更新する

WIT カスタマイズを初めて使用する場合は、次の点に注意してください。

作業項目の種類の任意の側面をカスタマイズするには、その XML 定義を更新します。詳細については、「すべての WITD XML 要素リファレンス」を参照してください。
新しい作業項目エクスペリエンスを使用する Web フォームをカスタマイズする場合は、 WebLayout 要素と Control 要素を参照してください。
Visual Studio で使用するクライアントフォームをカスタマイズする場合は、 Layout XML 要素のリファレンスを参照してください。
「作業項目追跡 Web フォームをカスタマイズする」で説明されている一連の手順に従います。

ワークフローをカスタマイズするには、次の 2 つの手順に従います。

このトピックの説明に従って、WIT 定義の WORKFLOW セクションを変更します。
新しいワークフローの状態を metastates にマップするようにプロセス構成を変更します。

この 2 番目の手順は、アジャイルツールページに表示される WIT のワークフローを変更するときに必要です。これらの WIT は、要件またはタスクのカテゴリに属しています。状態カテゴリの詳細については、「ワークフローの状態と状態のカテゴリを参照してください。

ワークフロー設計のガイドライン

最初に状態とそれらの間の有効な遷移を識別して、ワークフローを定義します。 WIT 定義の WORKFLOW セクションでは、有効な状態、遷移、遷移の理由、およびチームメンバーが作業項目の状態を変更したときに実行されるオプションのアクションを指定します。

一般に、各状態をチームメンバーロールと、そのロールのユーザーが状態を変更する前に作業項目を処理するために実行する必要があるタスクに関連付けます。遷移は、状態間の有効な進行と回帰を定義します。理由は、チームメンバーが作業項目をある状態から別の状態に変更する理由を特定し、アクションはワークフロー内の特定の時点での作業項目の切り替えの自動化をサポートします。

たとえば、テスト担当者が既定のアジャイルプロセスに基づく新しいバグを開いたときに状態を [新規 ] に設定します。開発者は、バグを修正するときに状態を Active に変更し、修正されると、その状態を Resolved に変更し、[理由] フィールドの値を Fixed に設定します。修正を確認した後、テスト担当者はバグの状態を Closed に変更し、[理由] フィールドを Verified に変更します。開発者がバグを修正しなかったとテスト担当者が判断した場合、テスト担当者はバグの状態を アクティブ に変更し、[理由] を [未修正] または [テスト失敗] として指定します。

ワークフローを設計または変更するときは、次のガイドラインを考慮してください。

STATE要素を使用して、作業項目に対して特定のアクションを実行するチームメンバーロールごとに一意の状態を定義します。定義する状態が多いほど、より多くの遷移を定義する必要があります。状態を定義する順序に関係なく、[ 状態 ] フィールドのドロップダウンメニューに英数字の順序で表示されます。

Web ポータルのバックログまたはボードページに表示される作業項目の種類に状態を追加する場合は、状態を状態カテゴリにマップする必要もあります。詳細については、ワークフローの状態と状態カテゴリに関する記事を参照してください。
TRANSITION要素を使用して、有効な各進行と回帰の状態間の遷移を定義します。

少なくとも、状態ごとに 1 つの遷移を定義し、null 状態から初期状態への遷移を定義します。

未割り当て (null) から初期状態への遷移は 1 つだけ定義できます。新しい作業項目を保存すると、プロセスによって自動的に初期状態に割り当てられます。

チームメンバーが作業項目の状態を変更すると、その変更によって移行がトリガーされ、選択した状態と遷移に対して実行するように定義したアクションがトリガーされます。ユーザーは、現在の状態に対して定義した遷移に基づいて有効な状態のみを指定できます。さらに、ACTIONの子要素であるTRANSITION要素は、作業項目の状態を変更できます。
遷移ごとに、 DEFAULTREASON 要素を使用して既定の理由を定義します。 REASON要素を使用して、必要な数の省略可能な理由を定義できます。これらの値は、 Reason フィールドのドロップダウンメニューに表示されます。
作業項目が状態を変更したとき、移行するとき、またはユーザーが特定の理由を選択したときに適用されるルールを指定できます。これらの規則の多くは、FIELDS定義の下の WORKITEMTYPE セクションのフィールドを定義するときに適用できる条件付きルールを補完します。詳細については、このトピックで後述する「ワークフローの変更中にフィールドを更新するを参照してください。
状態と理由に割り当てる名前は、大文字と小文字の区別をしません。

作業項目フォームまたはクエリエディター内の [状態] フィールドと [理由] フィールドのドロップダウンメニューには、作業項目の種類の [ WORKFLOW ] セクションに割り当てられた値が表示されます。

ワークフロー図とコード例

次のコード例は、アジャイルプロセステンプレートのバグ WIT 定義の WORKFLOW を示しています。この例では、3 つの状態と 5 つの遷移を定義します。 STATE要素は、アクティブ状態、解決済み状態、および Closed 状態を指定します。進行と回帰の遷移に使用できるすべての組み合わせは、1 つを除く 3 つの状態に対して定義されます。 Closed から Resolved への切り替えは定義されていません。そのため、作業項目が閉じている場合、チームメンバーはこの種類の作業項目を解決できません。

この例では、 DEFAULTREASON、 REASON、 ACTION、および FIELDのすべての要素は一覧表示されません。

ワークフロー状態図の例 - アジャイルバグ WIT

バグワークフローの状態、Agile プロセステンプレート

<WORKFLOW>
 <STATES>
    <STATE value="Active">
      <FIELDS> . . . </FIELDS>
    </STATE>
    <STATE value="Resolved">
     <FIELDS> . . . </FIELDS>
    </STATE>
    <STATE value="Closed">
     <FIELDS> . . . </FIELDS>
    </STATE>
 </STATES>
 <TRANSITIONS>
    <TRANSITION from="" to="Active">
       <REASONS>
          <REASON value="Build Failure" />
           <DEFAULTREASON value="New" />
       </REASONS>
       <FIELDS> . . . </FIELDS>
    </TRANSITION>
    <TRANSITION from="Active" to="Resolved">
     <ACTIONS> . . . </ACTIONS>
     <REASONS> . . . </REASONS>
    </TRANSITION>
    <TRANSITION from="Resolved" to="Active">
       <REASONS> . . . </REASONS>
    </TRANSITION>
    <TRANSITION from="Resolved" to="Closed">
       <REASONS>
          <DEFAULTREASON value="Verified" />
       </REASONS>
     <FIELDS> . . . </FIELDS>
    </TRANSITION>
    <TRANSITION from="Closed" to="Active">
       <REASONS>
          <REASON value="Reactivated" />
          <DEFAULTREASON value="Regression" />
       </REASONS>
     <FIELDS> . . . </FIELDS>
    </TRANSITION>
 </TRANSITIONS>
 </WORKFLOW>

状態の数と種類を決定する

有効な状態の数と種類を、その種類の作業項目が存在する個別の論理状態の数に基づいて決定します。また、異なるチームメンバーが異なるアクションを実行する場合は、メンバーロールに基づいて状態を定義することを検討してください。各状態は、チームメンバーが作業項目を次の状態に移動するために実行する必要があるアクションに対応します。状態ごとに、特定のアクションと、それらのアクションの実行を許可されているチームメンバーを定義します。

次の表に、機能の進行状況を追跡する 4 つの状態と、指定されたアクションを実行する必要がある有効なユーザーの例を示します。

都道府県	有効なユーザー	実行するアクション
提案済み	プロジェクトマネージャー	機能作業項目は、だれでも作成できます。ただし、作業項目を承認または不承認にできるのはプロジェクトマネージャーだけです。プロジェクトマネージャーが機能を承認すると、プロジェクトマネージャーは作業項目の状態をアクティブに変更します。それ以外の場合は、チームメンバーが閉じます。
アクティブです	開発責任者	開発リーダーは、この機能の開発を監督します。機能が完了すると、開発リーダーは機能作業項目の状態をレビューに変更します。
確認	プロジェクトマネージャー	プロジェクトマネージャーは、チームが実装した機能を確認し、実装が満足できる場合は作業項目の状態を Closed に変更します。
クローズ済みです	プロジェクトマネージャー	閉じている作業項目に対して追加のアクションは発生しません。これらのアイテムは、アーカイブおよびレポートの目的でデータベースに残ります。

注意

すべての状態は、指定した順序に関係なく、特定の種類の作業項目のフォームの一覧でアルファベット順に表示されます。

画面切り替えを定義する

チームメンバーが作業項目を変更できる状態を制御するには、有効な状態の進行状況と回帰を定義します。ある状態から別の状態への移行を定義しない場合、チームメンバーは特定の種類の作業項目を特定の状態から別の特定の状態に変更することはできません。

次の表では、このトピックで前述した 4 つの各状態の有効な遷移と、それぞれの既定の理由を定義します。

都道府県	状態への移行	既定の理由
提案済み	アクティブ (進行)	開発が承認されました
	完了（進捗）	未承認
アクティブです	レビュー (進行状況)	受け入れ条件が満たされました
確認	完了 (進行)	機能の完了
	アクティブ (回帰)	要件を満たしていない
クローズ済みです	提案 (リグレッション)	承認を再検討する
	アクティブ (リグレッション)	エラーで閉じた

要素の for 属性とTRANSITION属性を使用して、ある状態から別の状態への移行を許可するユーザーを制限できます。次の例に示すように、テスト担当者はバグを再度開くことができますが、開発者は開けられません。

<TRANSITION from="Closed" to="Active"  
   for="[Project]\Testers"  
   not="[Project]\Developers">  
   . . .  
</TRANSITION>

理由を指定する

チームメンバーが [状態] フィールドを変更すると、その遷移の既定の理由を保持したり、追加のオプションを定義した場合に別の理由を指定したりできます。 DEFAULTREASON要素を使用して、既定の理由を 1 つだけ指定します。チームがデータを追跡またはレポートするのに役立つ場合にのみ、追加の理由を追加します。

たとえば、開発者がバグを解決する理由として、修正 (既定)、遅延、複製、設計済み、再現不可、廃止のいずれかの理由を指定できます。各理由は、バグに関してテスト担当者が実行する特定のアクションを指定します。

注意

すべての理由は、 REASON 要素を指定する順序に関係なく、特定の種類の作業項目の作業フォームの一覧でアルファベット順に表示されます。

次の例は、チームのメンバーがバグを解決する理由を定義する要素を示しています。

<TRANSITION from="Active" to="Resolved">  
      . . .  
      <REASONS>  
      <DEFAULTREASON value="Fixed"/>  
      <REASON value="Deferred"/>  
      <REASON value="Duplicate"/>  
      <REASON value="As Designed"/>  
      <REASON value="Unable to Reproduce"/>  
      <REASON value="Obsolete"/>  
      </REASONS>  
      . . .  
</TRANSITION>

アクションを指定する

一般に、チームメンバーは、 State フィールドに別の値を指定し、作業項目を保存することで、作業項目の状態を変更します。ただし、その遷移が発生したときに作業項目の状態を自動的に変更する ACTION 要素を定義することもできます。次の例に示すように、バグ作業項目が、開発者がバージョン管理にチェックインするファイルに関連付けられている場合に自動的に解決されるように指定できます。

<TRANSITION from="Active" to="Resolved">  
      <ACTIONS>  
      <ACTION value="Microsoft.VSTS.Actions.Checkin"/>  
      </ACTIONS>  
. . .  
</TRANSITION>

ACTION要素を使用して、Microsoft Visual Studio アプリケーションライフサイクル管理または Visual Studio アプリケーションライフサイクル管理の外部 (呼び出しを追跡するツールなど) でイベントが発生した場合に、特定の種類の作業項目の状態を自動的に変更します。詳細については、「 ACTION」を参照してください。

ワークフローの変更中にフィールドを更新する

次のイベントが発生するたびにフィールドを更新するルールを定義できます。

すべての遷移とその状態に入る理由に対してルールを適用する場合は、 STATE でフィールドルールを割り当てます。
その切り替えとその遷移を行うすべての理由に対してルールを適用する場合は、 TRANSITION の下にフィールドルールを割り当てます。
その特定の理由に対してのみルールを適用する場合は、 DEFAULTREASON または REASON でフィールドルールを割り当てます。

フィールドに常に同じ値を含める必要がある場合は、そのフィールドを定義する FIELD 要素の下にルールを定義します。ルールの使用方法の詳細については、「ルールとルールの評価」を参照してください。

任意の種類の作業項目に対して定義する条件の数を最小限に抑えます。各条件付きルールは、チームメンバーが作業項目を保存するたびに発生する検証プロセスに複雑さを追加します。複雑なルールセットにより、作業項目の保存に必要な時間が長くなる場合があります。

次の例は、MSF アジャイルソフトウェア開発のプロセステンプレートのシステムフィールドに適用される規則の一部を示しています。

状態が変化したときにフィールドの値を変更する

作業項目の [状態 ] フィールドの値を [アクティブ] に設定し、作業項目を保存すると、[ アクティブ化者 ] フィールドと [ 割り当て済み ユーザー] フィールドの値が現在のユーザーの名前に自動的に設定されます。そのユーザーは、Team Foundation Server の有効なユーザーグループのメンバーである必要があります。 アクティブ化された日付フィールドの値も自動的に設定されます。次の例は、この規則を適用する要素を示しています。

<STATE value="Active">  
<FIELDS>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">  
      <COPY from="currentuser"/>  
      <VALIDUSER/>  
      <REQUIRED/>  
      </FIELD>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">  
      <SERVERDEFAULT from="clock"/></FIELD>  
      <FIELD refname="System.AssignedTo">  
      <DEFAULT from="currentuser"/>  
      </FIELD>  
. . .  
</FIELDS>  
</STATE>

別のフィールドの値が変更されたときにフィールドの値をクリアする

次の例に示すように、作業項目の [状態 ] フィールドの値を [アクティブ] に設定し、作業項目を保存すると、 EMPTY 要素は自動的に [終了日] フィールドと [終了日] フィールドを null に設定し、読み取り専用にします。

<STATE value="Active">  
      <FIELDS>  
. . .  
      <FIELD refname="Microsoft.VSTS.Common.ClosedDate"><EMPTY/></FIELD>  
      <FIELD refname="Microsoft.VSTS.Common.ClosedBy"><EMPTY/></FIELD>  
      </FIELDS>  
</STATE>

別のフィールドの内容に基づいてフィールドを定義する

作業項目の [状態 ] フィールドの値を [解決済み] に変更し、作業項目を保存すると、[ 解決された理由 ] フィールドの値は、[ 理由 ] フィールドでユーザーが指定した値に設定されます。次の例は、この規則を適用する要素を示しています。

<STATE value="Resolved">  
      <FIELDS>  
. . .  
      <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">  
         <COPY from="field" field="System.Reason"/>  
      </FIELD>  
      </FIELDS>  
</STATE>

ツールのサポート

ユーザーがワークフローを視覚化できるように、Visual Studio Marketplace から State Model Visualization 拡張機能をインストールします。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-03-27