作業項目の種類に関するワークフローの変更
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 への切り替えは定義されていません。 したがって、作業項目が閉じている場合、チーム メンバーはこの種類の作業項目を解決できません。
この例では、DEFAULTREASON
REASON
ACTION
FIELD
ワークフロー状態図の例 - アジャイル バグ WIT
<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 拡張機能をインストールすることで、ユーザーによるワークフローの視覚化をサポートできます。
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示