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

[アーティクル]
04/04/2024

Azure DevOps Server 2022 - Azure DevOps Server 2019

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

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

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

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

Note

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

この例では、DEFAULTREASONREASONACTIONFIELD

ワークフロー状態図の例 - アジャイルバグ 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 つの各状態の有効な遷移と、それぞれの既定の理由を定義します。

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

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

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

理由を指定する

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

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

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>

アクションを指定する

一般に、チームメンバーは、[状態] フィールドに別の値を指定し、作業項目を保存することで、作業項目の状態を変更します。ただし、その遷移が発生したときに作業項目の状態を自動的に変更する要素を定義 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>

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

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

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

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

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

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

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

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

画面切り替えを定義する

理由を指定する

アクションを指定する

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

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

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

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

ツールのサポート

フィードバック

フィードバック

その他のリソース

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

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

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

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

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

画面切り替えを定義する

理由を指定する

アクションを指定する

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

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

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

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

関連記事

ツールのサポート

フィードバック

フィードバック

その他のリソース