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

[アーティクル]
07/25/2024

Azure DevOps Server 2022 - Azure DevOps Server 2019

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

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

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

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

Note

この記事では、ワークフローの状態をカスタマイズする方法について説明します。代わりに、特定の作業項目に割り当てられている State を変更する場合は、 Board、Track work in progress、 Task board、Update task status のいずれかの記事を参照してください。また、多くの作業項目に対して State の更新を実行することもできます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

作業項目フォームまたはクエリエディター内の [状態] フィールドと [理由] フィールドのドロップダウンメニューには、作業項目の種類の [ 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 つの状態と、指定されたアクションを実行する必要がある有効なユーザーの例を示します。

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

Note

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

画面切り替えを定義する

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

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

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

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

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

理由を指定する

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

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

Note

すべての理由は、 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 アジャイルソフトウェア開発のプロセステンプレートのシステムフィールドに適用される規則の一部を示しています。

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

作業項目の State フィールドの値が Active に設定され、作業項目が保存されると、 Activated By フィールドと Assigned To フィールドの値が現在のユーザーの名前に自動的に設定されます。そのユーザーは、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>

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

次の例に示すように、作業項目の State フィールドの値が Active に設定され、作業項目が保存されると、次の例に示すように、 EMPTY 要素を使用する場合、Closed Date フィールドと Closed By フィールドは自動的に null に設定され、読み取り専用になります。

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

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

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

<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 拡張機能をインストールすることで、ユーザーによるワークフローの視覚化をサポートできます。

次の方法で共有

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

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

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

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

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

画面切り替えを定義する

理由を指定する

アクションを指定する

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

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

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

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

ツールのサポート

フィードバック

その他のリソース

次の方法で共有

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

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

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

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

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

画面切り替えを定義する

理由を指定する

アクションを指定する

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

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

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

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

関連記事

ツールのサポート

フィードバック

その他のリソース