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

業務とチームの処理をサポートするため、作業項目の種類 (WIT) のワークフローを変更します。 WIT は、すべての種類の仕事 (要件、タスク、コードの欠陥) の追跡をサポートして、Team Foundation Server (TFS) を使用したソフトウェアの開発をサポートします。

ワークフローは、チーム メンバーが実行する作業の論理的な進行と回帰を決定します。 また、[状態] フィールドおよび [理由] フィールドのドロップダウン メニューに表示される値を指定します。

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

TFS が提供する既定のプロセス テンプレートでサポートされる既定のワークフロー状態の概要については、「プロセス テンプレートの選択、チーム プロジェクトの成果物の使用」を参照してください。 ビルド定義のワークフローについては、「ビルド プロセス テンプレートのカスタマイズ」を参照してください。

ワークフローのデザインのガイドライン

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

通常、各状態は、チーム メンバーの役割とタスクに関連付けます。この役割とタスクでは役割を割り当てられた人が作業項目を処理してから、状態を変更する必要があります。 遷移では、状態間で有効な進行と回帰を定義します。 チーム メンバーがある状態から他の状態に作業項目を変更する理由の指定、およびワークフローのある時点における作業項目の遷移のオートメーションをサポートするアクションです。

たとえば、テスト担当者が (TFS) に付属する既定のアジャイル プロセス テンプレートを基に新しいバグを開くと、状態は Team Foundation Server[新規] に設定されます。 開発者は、バグの修正時に状態を [アクティブ] に変更します。修正が完了したら、開発者は状態を [解決済み] に変更し、[理由] フィールドの値を [修正済み] に設定します。 修正を確認した後は、テスト担当者がバグの状態を [終了] に変更します。[理由] フィールドの値は [確認済み] に変わります。 バグが開発者によって修正されていないことをテスト担当者が確認した場合、テスト担当者はバグの状態を [アクティブ] に変更し、[理由] を [修正なし] または [テスト失敗] に設定します。

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

• STATE 要素を使用して、作業項目で特定のアクションを実行する各チーム メンバーの役割ごとに一意の状態を定義します。 定義する状態の数が増えれば、定義する必要のある遷移の数も増えます。 状態は定義したシーケンスに関係なく、[状態] フィールドのドロップダウン メニューに英数字の順で一覧表示されます。

  Team Web Access のバックログ ページまたはボード ページに表示される作業項目の種類に状態を追加する場合は、その状態をメタ状態にマップすることも必要です。 「プロセス構成 XML 要素のリファレンス」を参照してください。

• TRANSITION 要素を使用して、有効な進行と回帰に対し、ある状態から他の状態への遷移を定義します。

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

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

  チーム メンバーが作業項目の状態を変更すると、変更によって遷移が発生し、選択された状態と遷移に対して実行されるように定義したアクションが実行されます。 ユーザーは、現在の状態に対して定義した遷移に基づき、有効な状態のみを指定できます。 また、ACTION 要素 (TRANSITION の子要素) では、作業項目の状態を変更できます。

• 遷移ごとに、DEFAULTREASON 要素を使用して、既定の理由を定義します。 REASON 要素を使用すると、理由は必要なだけ定義できます。 これらの値は、[理由] フィールドのドロップダウン メニューに表示されます。

• 作業項目が変更されたとき、作業項目の状態が遷移したとき、またはユーザーが特定の理由を選択したときに適用される規則を定義できます。 これらの規則の多くは、FIELDS 定義の WORKITEMTYPE セクションで、フィールドを定義するときに適用できる条件付き規則を補完します。 詳細については、このトピックで後述する「ワークフローの変更中にフィールドを更新」を参照してください。

• 状態と理由に割り当てる名前では、大文字と小文字は区別されません。

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

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

次のコード例は、アジャイル プロセス テンプレートのバグ WIT 定義の WORKFLOW を示しています。 この例は、3 つの状態と 5 つの遷移を定義しています。 STATE 要素では、状態 [アクティブ]、[解決済み]、[終了] を指定します。 進行と回帰の遷移で適用可能な組み合わせは、これらの 3 つの状態に対して定義されますが、1 つの例外があります。 つまり、[終了] から [解決済み] への遷移は定義されません。 そのため、作業項目が終了になった場合、チーム メンバーはこの種類の作業項目を解決できません。

この例は、DEFAULTREASON、REASON、ACTION、および FIELD のすべての要素を示してはいません。

<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>

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

状態の数と種類の決定

作業項目の種類を設定する論理的な異なる状態の数を基に、有効な状態の数と種類を決定します。 また、別のチーム メンバーが異なるアクションを実行する場合、メンバーの役割に基づいて状態を定義することもできます。 各状態は、次の状態に移行させるためにチーム メンバーが作業項目で実行する必要があるアクションに対応します。 各状態ごとに、特定のアクションと、それらのアクションを実行できるチーム メンバーを定義する必要があります。

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

状態	有効なユーザー	実行するアクション
提案済み	プロジェクト マネージャー	機能の作業項目はだれでも作成できます。 ただし、作業項目を承認するかしないかを決定できるのはプロジェクト マネージャーだけです。 プロジェクト マネージャーが機能を承認すると、プロジェクト マネージャー本人が作業項目の状態を [アクティブ] に変更します。それ以外の場合は、チーム メンバーが作業項目を終了します。
アクティブ	開発者リード	開発者は、機能の開発を指揮し、監督します。 機能が完了したら、開発者が機能の作業項目の状態変更を指揮し、校閲します。
レビュー	プロジェクト マネージャー	プロジェクト マネージャーはチームが実装した機能を校閲して、実装に満足できれば、作業項目の状態を [終了] に変更します。
終了	プロジェクト マネージャー	終了した作業項目で発生する予定のアクションはありません。 これらの項目はアーカイブ用およびレポート用としてデータベース内に残ります。

注意

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

遷移の定義

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

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

状態	状態への遷移	既定の理由
提案済み	アクティブ (進行)	開発承認済み
	終了 (進行)	未承認
アクティブ	校閲 (進行)	承認基準に一致
レビュー	終了 (進行)	機能の完成
	アクティブ (回帰)	要件を満たしていない
終了	提案済み (回帰)	承認を再検討
	アクティブ (回帰)	エラーによる終了

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

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

理由の指定

追加のオプションを定義している場合、チーム メンバーは状態フィールドを変更するときに、遷移に対する既定の理由をそのまま使用するか、別の理由を指定できます。 既定の理由を 1 つのみ指定するには、DEFAULTREASON 要素を使用する必要があります。 チームでのデータの追跡またはレポート生成を支援する場合は、追加の理由を指定する必要があります。

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

注意

すべての理由は、特定の種類の作業項目ごとに、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 アプリケーション ライフサイクル管理 の外部で (たとえば呼び出しを追跡するツールから) イベントが発生したときに、特定の種類の作業項目の状態を自動で変更できます。 詳細については、「状態、遷移、または理由に基づいたフィールド割り当ての自動化」を参照してください。

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

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

• 規則を、すべての遷移先とその状態に移行する理由に適用する場合は、STATE でフィールド規則を割り当てます。

• 規則を、遷移とその遷移を発生させるすべての理由に適用する場合は、TRANSITION でフィールド規則を割り当てます。

• 規則を、特定の理由にのみ適用する場合は、DEFAULTREASON または REASON でフィールド規則を割り当てます。

フィールドに同じ値を常に設定する場合は、そのフィールドを定義する FIELD 要素で規則を定義します。 規則の使用法の詳細については、「作業項目フィールドへの規則の適用」を参照してください。

作業項目の種類 1 つに対し、定義する条件の数はできるだけ少なくしてください。 条件付き規則を追加するに従って、チーム メンバーが作業項目を保存するたびに発生する検証プロセスが複雑になります。 複雑な規則を設定すると、作業項目の保存に時間がかかることがあります。

次の表に、MSF Agile Software Development のプロセス テンプレートのシステム フィールドに適用される規則のいくつかを例として示します。

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

作業項目の [状態] フィールドの値を [アクティブ] に設定した後にその作業項目を保存すると、[アクティブ化した人] フィールドと [担当者] フィールドが、自動的に現在のユーザーの名前に設定されます。 そのユーザーは、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>

Q & A

Q: ツールによってワークフローを変更する、またはワークフロー状態図を表示することはできますか。

A: できます。 Visual Studio のパワー ツールであるプロセス エディターを使用すると、定義中のワークフローを変更することや、ワークフロー状態図を表示することができます。 詳細については、Microsoft Web サイトのページ「Team Foundation Server パワー ツール」を参照してください。

Q: WIT 定義の XML 要素の概要はどこで入手できますか。

A: 「すべての WITD XML 要素のリファレンス」を参照してください。