ワークフローのデザイン
業務とチームの処理をサポートするため、作業項目の種類に対しワークフローを設計します。ワークフローでは、タスクの論理的な流れを決定して、それを実行する担当者を決定します。ワークフローでは、最初に状態、および状態間で有効な遷移の識別方法を定義します。作業項目の種類の定義にある WORKFLOW セクションでは、有効な状態、遷移、遷移の理由、およびチーム メンバーが作業項目の状態を変更したときに実行されるオプションのアクションを定義します。型定義の詳細については、「すべての WITD XML 要素のリファレンス」を参照してください。
通常、各状態は、チーム メンバーの役割とタスクに関連付けます。この役割とタスクでは役割を割り当てられた人が作業項目を処理してから、状態を変更する必要があります。遷移では、状態間で有効な進行と回帰を定義します。チーム メンバーがある状態から他の状態に作業項目を変更する理由の指定、およびワークフローのある時点における作業項目の遷移のオートメーションをサポートするアクションです。
.gif "重要 :") 重要 |
|---|
Team System Web Accessバックログまたはボードのページに表示される作業項目の種類に追加する場合は、その状態を metastate に状態をマップする必要があります。「プロセス構成を使用したバックログ ページおよびボード ページのカスタマイズ」を参照してください。 |
たとえば、状態は [新規作成] にテスト担当者が Team Foundation Server (TFS) で提供される既定のアジャイル プロセス テンプレートに基づく新しいバグを開くときに設定されます。開発者は [アクティブ] にバグを修正した場合、状態を変更し、修正、一度理由の値が [修正済み] に、フィールド セットと [解決済み] 開発者への変更の状態。修正を確認した後、テスト担当者が [終了] にバグの状態を変更して、理由フィールドが [確認済み] に変更します。開発者はバグが修正されたことを確認したら、テスト担当者がテスト担当者は [アクティブ] にバグの状態を変更し、[修正なし] か [テストに失敗しました] として理由を指定します。
[!メモ]
作業項目を追跡するための作業項目の種類とその他のオブジェクトの定義は、Visual Studio のパワー ツールであるプロセス エディターを使用して作成および変更できます。このツールはサポートされていません。詳細については、Microsoft Web サイトの次のページを参照: Team Foundation Server のパワー ツール[.]
このトピックの内容
ワークフローのデザインのガイドライン
ワークフロー図とコード例
状態の数と種類の決定
遷移の定義
理由の指定
アクションの指定
状態が変更されたときのフィールドの更新
状態が変更されたときのフィールドの定義
フィールド値のクリア
別のフィールドの内容に基づくフィールドの定義
ワークフローの状態を示す図の表示
ワークフローのデザインのガイドライン
ワークフローを設計または変更するときは、次のガイドラインを考慮してください。
STATE 要素を使用して、作業項目で特定のアクションを実行する各チーム メンバーの役割ごとに一意の状態を定義します。定義する状態の数が増えれば、定義する必要のある遷移の数も増えます。状態は定義したシーケンスに関係なく、[状態] にアルファベット順で一覧表示されます。
TRANSITION 要素を使用して、有効な進行と回帰に対し、ある状態から他の状態への遷移を定義します。
少なくとも、状態ごとに 1 つの遷移、および null 状態から初期状態への遷移を定義する必要があります。
遷移ごとに、DEFAULTREASON 要素を使用して、既定の理由を定義する必要があります。REASON 要素を使用すると、理由は必要なだけ定義できます。
作業項目内の状態と理由フィールドの値がドロップダウン メニューは、作業項目の種類の WORKFLOW のセクションで再配置エディターの表示をフォームまたは照会します。
割り当てられていない状態 (null) から初期状態への遷移は、一度だけ定義できます。新しい作業項目を保存すると、自動的に初期状態に割り当てられます。
チーム メンバーが作業項目の状態を変更すると、変更によって遷移が発生し、選択された状態と遷移に対して実行されるように定義したアクションが実行されます。ユーザーは、現在の状態に対して定義した遷移に基づき、有効な状態のみを指定できます。また、ACTION 要素 (TRANSITION の子要素) では、作業項目の状態を変更できます。
作業項目が変更されたとき、作業項目の状態が遷移したとき、またはユーザーが特定の理由を選択したときに適用されるフィールドに、条件付き規則を定義できます。これらの規則の多くは、WORKITEMTYPE 定義の FIELDS セクションで、フィールドを定義するときに適用できる条件付き規則を補完します。詳細については、このトピックで後述する「状態が変更されたときのフィールドの更新」を参照してください。
作業項目の種類 1 つに対し、定義する条件の数はできるだけ少なくしてください。条件付き規則を追加するに従って、チーム メンバーが作業項目を保存するたびに発生する検証プロセスが複雑になります。複雑な規則を設定すると、作業項目の保存に時間がかかることがあります。
状態と理由に割り当てる名前では、大文字と小文字は区別されません。
ページのトップへ
ワークフロー図とコード例
次の表に、コードの欠陥を追跡する作業項目の種類を定義する WORKFLOW セクションと、このセクションで定義されるワークフローの状態を表す図を示します。この例では、3 つの状態、6 つの遷移および 9 つの理由を定義します。STATE 要素では、状態 [アクティブ]、[解決済み]、[終了] を指定します。進行と回帰の遷移で適用可能な組み合わせは、これらの 3 つの状態に対して定義されますが、1 つの例外があります。つまり、[終了] から [解決済み] への遷移は定義されません。そのため、作業項目が終了になった場合、チーム メンバーはこの種類の作業項目を解決できません。
[!メモ]
この例では、DEFAULTREASON、REASON、ACTION および FIELD の要素が示されていません。
|
ワークフローの状態を示す図の例
.png "ユーザー ストーリーの状態ダイアグラム") |
状態の数と種類の決定
作業項目の種類を設定する論理的な異なる状態の数を基に、有効な状態の数と種類を決定します。また、別のチーム メンバーが異なるアクションを実行する場合、メンバーの役割に基づいて状態を定義することもできます。各状態は、次の状態に移行させるためにチーム メンバーが作業項目で実行する必要があるアクションに対応します。各状態ごとに、特定のアクションと、それらのアクションを実行できるチーム メンバーを定義する必要があります。
次の表に、機能の進行を追跡するために定義された 4 つの状態、および指定されたアクションを実行する必要がある有効なユーザーの例を示します。
状態 |
有効なユーザー |
実行するアクション |
|---|---|---|
提案済み |
プロジェクト マネージャー |
機能の作業項目はだれでも作成できます。ただし、作業項目を承認するかしないかを決定できるのはプロジェクト マネージャーだけです。プロジェクト マネージャーが機能を承認すると、プロジェクト マネージャー本人が作業項目の状態を [アクティブ] に変更します。それ以外の場合は、チーム メンバーが作業項目を終了します。 |
アクティブ |
開発者リード |
開発者は、機能の開発を指揮し、監督します。機能が完了したら、開発者が機能の作業項目の状態変更を指揮し、校閲します。 |
校閲 |
プロジェクト マネージャー |
プロジェクト マネージャーはチームが実装した機能を校閲して、実装に満足できれば、作業項目の状態を [終了] に変更します。 |
Closed |
プロジェクト マネージャー |
終了した作業項目で発生する予定のアクションはありません。これらの項目はアーカイブ用およびレポート用としてデータベース内に残ります。 |
[!メモ]
すべての状態は、特定の種類の作業項目ごとに、指定したシーケンスに関係なく作業項目のフォーム上の一覧にアルファベット順で表示されます。
ページのトップへ
遷移の定義
有効な状態の進行と回帰を定義する場合は、チーム メンバーが状態から、または状態に対して作業項目を変更できるように状態を制御します。ある状態から別の状態への遷移を定義しない場合、チーム メンバーは特定の種類の作業項目をある状態から別の状態に変更することができません。
次の表では、このトピックで前述した 4 つの状態それぞれに有効な遷移と既定の理由を定義しています。
状態 |
状態への遷移 |
既定の理由 |
|---|---|---|
提案済み |
アクティブ (進行) |
開発承認済み |
終了 (進行) |
未承認 |
|
アクティブ |
校閲 (進行) |
承認基準に一致 |
校閲 |
終了 (進行) |
機能の完成 |
アクティブ (回帰) |
要件を満たしていない |
|
Closed |
提案済み (回帰) |
承認を再検討 |
アクティブ (回帰) |
エラーによる終了 |
ある状態から他の状態への遷移の作成を許可するユーザーは、TRANSITION 要素の for 属性および not 属性を使用することで制限できます。次の例では、テスト担当者はバグを再び開けるようにし、開発者は開くことができないようにした例を示しています。
<TRANSITION from="Closed" to="Active"
for="[Project]\Testers"
not="[Project]\Developers">
. . .
</TRANSITION>
ページのトップへ
.gif "ms194981.collapse_all(ja-jp,VS.110).gif")
理由の指定
追加のオプションを定義している場合、チーム メンバーは状態フィールドを変更するときに、遷移に対する既定の理由をそのまま使用するか、別の理由を指定できます。既定の理由を 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>
イベントが Microsoft Visual Studio のアプリケーション ライフサイクル管理または外部 Visual Studio アプリケーション ライフサイクル管理 の他の場所に発生すると自動的に特定の種類の作業項目の状態を変更するには ACTION の要素を使用できます (たとえば、呼び出しを追跡するツールから)。詳細については、「状態、遷移、または理由に基づいたフィールド割り当ての自動化」を参照してください。
ページのトップへ
フィールドの更新
次のイベントが発生するたびにフィールドを更新する規則を定義できます。
規則を、すべての遷移先とその状態に移行する理由に適用する場合は、STATE でフィールド規則を割り当てます。
規則を、遷移とその遷移を発生させるすべての理由に適用する場合は、TRANSITION でフィールド規則を割り当てます。
規則を、特定の理由にのみ適用する場合は、DEFAULTREASON または REASON でフィールド規則を割り当てます。
フィールドに同じ値を常に設定する場合は、そのフィールドを定義する FIELD 要素で規則を定義します。詳細については、「作業項目フィールドの条件の設定」を参照してください。
次の表に、MSF for Agile Software Development v5.0 のプロセス テンプレートのシステム フィールドに適用される規則のいくつかを例として示します。
状態が変更されたときのフィールド値の変更
他のフィールド値が変更されたときのフィールド値のクリア
別のフィールドの内容に基づくフィールドの定義
ページのトップへ
状態が変更されたときのフィールド値の変更
作業項目の [状態] フィールドの値を [アクティブ] に設定した後にその作業項目を保存すると、[アクティブ化した人] フィールドと [担当者] フィールドが、自動的に現在のユーザーの名前に設定されます。そのユーザーは、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、のパワー ツールを表示できます。このツールはサポートされていません。詳細については、Microsoft Web サイトの次のページを参照: Team Foundation Server のパワー ツール[.]
ページのトップへ