設計工作流程

發行項
08/12/2011

更新：2011 年 1 月

您可以針對工作項目類型設計工作流程，以支援商務和小組程序。工作流程決定將要執行之工作的邏輯進展和執行者。您會先識別狀態以及狀態之間的有效轉換，來定義工作流程。工作項目類型之定義的 WORKFLOW 區段定義了有效狀態、轉換、轉換的原因，以及當小組成員變更工作項目狀態時將要執行的選擇性動作。如需類型定義的詳細資訊，請參閱所有 WITD XML 項目參考。

一般而言，您會將每個狀態與這兩個項目相關聯：小組成員角色以及該角色人員為處理工作項目而必須執行的工作，完成後才能變更工作項目的狀態。轉換會定義狀態之間的有效進展和回復。原因會識別小組成員為何將工作項目從某個狀態變更為另一個狀態，而動作則支援工作項目在工作流程某個時間點的自動轉換。

例如，根據 Microsoft Solutions Framework (MSF) for Agile Software Development 5.0 流程範本，當測試人員開啟新 Bug 時，[狀態] 會設為 [作用中]。在修正 Bug 之後，程式開發人員將其狀態變更為 [已解決]，並將 [原因] 欄位的值設為 [已修正]。在驗證修正結果之後，測試人員將 Bug 的狀態變更為 [已關閉]，並將 [原因] 欄位的值保留為 [已修正]。如果測試人員判斷程式開發人員未修正好 Bug，測試人員就會將 Bug 的狀態變更為 [作用中]，並將 [原因] 指定為 [解決方法被拒絕] 或 [測試失敗]。

注意事項
您可以使用流程編輯器 (Visual Studio 的強大工具)，為工作項目類型和其他追蹤工作項目的物件建立及修改定義。不支援此工具。如需詳細資訊，請參閱下列 Microsoft 網站的網頁：Team Foundation Server Power Tools (2010 年 4 月) (英文)。

本主題內容

工作流程設計方針
工作流程圖表和程式碼範例
判斷狀態的數目和類型
定義轉換
- 指定原因
- 指定動作
當狀態變更時更新欄位
- 當狀態變更時定義欄位
- 清除欄位的值
- 根據其他欄位的內容定義欄位
檢視工作流程狀態圖表

工作流程設計方針

當您設計或修改工作流程時，請考慮下列方針：

透過使用 STATE 項目，為將要在工作項目上執行特定動作的每個小組成員角色定義唯一狀態。定義的狀態愈多，必須定義的轉換也愈多。不論定義狀態的順序為何，[狀態] 清單中的狀態都是依英數字元順序列出。
透過使用 TRANSITION 項目，為某個狀態到另一個狀態的每個有效進展和回復定義轉換。
您至少必須為每個狀態定義一個轉換，以及從 null 狀態到初始狀態的轉換。
針對每個轉換，您必須使用 DEFAULTREASON 項目定義預設原因。您可以使用 REASON 項目，視需要定義多個選擇性原因，數目不限。
只能定義一個從未指派狀態 (null) 到初始狀態的轉換。當您儲存新工作項目時，工作項目會自動指派為初始狀態。
當小組成員變更工作項目狀態時，該變更會觸發轉換以及為所選狀態和轉換定義要執行的動作。對為目前狀態所定義的轉換而言為有效的狀態，使用者才能指定。此外，ACTION 項目 (TRANSITION 的子項目) 可以變更工作項目的狀態。
您可以定義條件式規則，這些條件式規則將在工作項目變更狀態時、在工作項目轉換時，或在使用者選取特定原因時套用至任何欄位。許多這些規則補充您在 WORKITEMTYPE 定義底下的 FIELDS 區段中定義欄位時可套用的條件式規則。如需詳細資訊，請參閱本主題後面的當狀態變更時更新欄位。
您應該嘗試盡量減少為任何一種工作項目類型所定義的條件數目。每加入一個條件式規則，就會增加每次小組成員儲存工作項目時會進行之驗證程序的複雜性。複雜的規則集可能會增加儲存工作項目所需時間。
指派給狀態與原因的名稱不區分大小寫。

回到頁首

工作流程圖表和程式碼範例

下表針對追蹤程式碼缺失的工作項目類型顯示其定義的 WORKFLOW 區段，以及定義的工作流程狀態圖表。這個範例定義三個狀態、六個轉換和九個原因。 STATE 項目指定 [作用中]、[已解決] 和 [已關閉] 狀態。為三個狀態定義所有可能的進展和回復轉換組合，除了一個轉換例外。從 [已關閉] 到 [已解決] 的轉換未定義。因此，如果工作項目已關閉，小組成員便無法解決此類型的工作項目。

注意事項
此範例未列出 DEFAULTREASON、REASON、ACTION 和 FIELD 項目。

<WORKFLOW>
<STATES>
  <STATE value="Active">
    <FIELDS> . . . </FIELDS>
  </STATE>
  <STATE value="Resolved">
    <FIELDS> . . . </FIELDS>
  </STATE>
  <STATE value="Closed" />
</STATES>
<TRANSITIONS>
  <TRANSITION from="" to="Active">
    <REASONS>
      <DEFAULTREASON value="New" />
    </REASONS>
    <FIELDS> . . . </FIELDS>
  </TRANSITION>
  <TRANSITION from="Active" to="Resolved">
    <REASONS> . . . </REASONS>
    <FIELDS> . . . </FIELDS>
    < ACTIONS > . . . </ ACTIONS >
</TRANSITION>
<TRANSITION from="Resolved" to="Closed">
    <REASONS> . . . </REASONS>
    <FIELDS> . . . </FIELDS>
    < ACTIONS > . . . </ ACTIONS >
</TRANSITION>
<TRANSITION from="Resolved" to="Active">
    <REASONS> . . . </REASONS>
    <FIELDS> . . . </FIELDS>
</TRANSITION>
<TRANSITION from="Active" to="Closed ">
    <REASONS> . . . </REASONS>
    <FIELDS> . . . </FIELDS>
</TRANSITION>
<TRANSITION from="Closed" to="Active">
    <REASONS> . . . </REASONS>
    <FIELDS> . . . </FIELDS>
</TRANSITION>
</TRANSITIONS>
</WORKFLOW>

範例工作流程狀態圖表

判斷狀態的數目和類型

您可以根據要該類型工作項目處於的邏輯狀態 (狀態彼此相異) 其數目，判斷有效狀態的數目和類型。此外，如果不同的小組成員執行不同的動作，您還可以考慮依據成員角色來定義狀態。每個狀態對應於小組成員必須對工作項目執行以移至下個狀態的動作。您必須為每個狀態定義特定動作以及可執行這些動作的小組成員。

下表提供範例，此範例會定義用來追蹤功能進度的四個狀態以及必須執行指定之動作的有效使用者：

狀態	有效使用者	要執行的動作
已提議	專案管理人員	任何人都可以建立功能工作項目。不過，只有專案管理人員才能核准或不核准工作項目。如果專案管理人員核准功能，專案管理人員會將工作項目的狀態變更為 [作用中]，否則小組成員會將它關閉。
作用中	開發組長	開發組長會監控功能的開發作業。功能開發完成之後，開發組長會將功能工作項目的狀態變更為 [檢閱]。
檢閱	專案管理人員	專案管理人員會檢閱小組實作的功能，如果實作結果令人滿意則將工作項目的狀態變更為 [已關閉]。
已關閉	專案管理人員	對已關閉的工作項目不會再進行其他動作。這些項目會保留在資料庫中供封存和報告作業之用。

注意事項
不論指定狀態的順序為何，工作項目類型表單的清單中所有狀態都是依字母順序列出。

回到頁首

定義轉換

如果您定義有效的狀態進展和回復，則可控制小組成員可變更的工作項目狀態。如果未定義從某個狀態到另一個狀態的轉換，小組成員便無法將特定類型的工作項目從某個狀態變更到另一個狀態。

下表為本主題先前描述的四個狀態分別定義有效轉換，以及每個轉換的預設原因。

狀態	轉換至狀態	預設原因
已提議	作用中 (進展)	核准開發
	已關閉 (進展)	不核准
作用中	檢閱 (進展)	符合驗收準則
檢閱	已關閉 (進展)	功能完成
	作用中 (回復)	不符合需求
已關閉	已提議 (回復)	重新考慮核准
	作用中 (回復)	因錯誤而關閉

您可以透過使用 TRANSITION 項目的 for 和 not 屬性，限制哪些人員可將某個狀態轉換到另一個狀態。如下列範例所示，測試人員可以重新開啟 Bug，但程式開發人員則否。

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

回到頁首

指定原因

當小組成員變更 [狀態] 欄位時，該使用者可以保留該轉換的預設原因，或指定不同的原因 (如果您有定義其他原因選項)。您必須使用 DEFAULTREASON 項目指定一個預設原因。只有在有助於小組追蹤或報告資料時，才應該指定其他原因。

例如，程式開發人員可以在解決 Bug 時指定下列其中一個原因：已修正 (預設)、已延期、重複、按設計角度、無法重現或過時。每個原因會指定測試人員針對 Bug 要執行的特定動作。

注意事項
不論指定 REASON 項目的順序為何，特定類型工作項目之工作表單的清單中所有原因都是依字母順序列出。

下列範例顯示的項目會定義小組成員可能因哪些原因解決 Bug：

<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 項目，在轉換發生時自動變更工作項目的狀態。如下列範例所示，您可以指定當與 Bug 工作項目相關聯的檔案由開發人員簽入版本控制時，系統應該自動解決這些 Bug 工作項目。

<TRANSITION from="Active" to="Resolved">
   <ACTIONS>
   <ACTION value="Microsoft.VSTS.Actions.Checkin"/>
   </ACTIONS>
. . .
</TRANSITION>

您可以使用 ACTION 項目，在 Microsoft Visual Studio Application Lifecycle Management 中的其他地方或在 Visual Studio Application Lifecycle Management 外部 (例如，從追蹤呼叫的工具) 發生事件時，自動變更特定類型工作項目的狀態。如需詳細資訊，請參閱根據狀態、轉換或原因自動化欄位指派。

回到頁首

更新欄位

您可以定義規則，在發生下列事件時更新欄位：

當您要將規則套用至所有轉換以及進入該狀態的原因時，在 STATE 底下指派欄位規則。
當您要將規則套用至該轉換以及進行該轉換的所有原因時，在 TRANSITION 底下指派欄位規則。
當您只要將規則套用至特定原因時，在 DEFAULTREASON 或 REASON 底下指派欄位規則。

如果欄位應該永遠包含相同值，則在定義該欄位的 FIELD 項目底下定義規則。如需詳細資訊，請參閱設定工作項目欄位的條件。

下列範例示範一些套用至 MSF Agile Software Development v5.0 流程範本中之系統欄位的規則。

當狀態變更時變更欄位的值
當另一個欄位的值變更時清除欄位的值
根據其他欄位的內容定義欄位

回到頁首

當狀態變更時變更欄位的值

當工作項目的 [狀態] 欄位值設為 [作用中] 並儲存工作項目時，[啟動者] 和 [指派給] 欄位的值會自動設定為目前使用者的名稱。該使用者必須是 Team Foundation Server Valid Users 群組的成員。 [啟動日期] 欄位的值也是自動設定的。下列範例示範強制執行此規則的項目：

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

回到頁首

檢視工作流程狀態圖表

如果您使用 Team Web Access 開啟任一類型工作項目的狀態圖表，即可檢視該類型工作項目的工作流程定義。如需詳細資訊，請參閱使用 Team Web Access 管理工作。

秘訣
您也可以使用流程編輯器 (Visual Studio 的強大工具)，來檢視您正在定義的工作流程狀態圖表。不支援此工具。如需詳細資訊，請參閱下列 Microsoft 網站的網頁：Team Foundation Server Power Tools (2010 年 4 月) (英文)。

回到頁首

請參閱

其他資源

定義和自訂工作項目工作流程

變更記錄

日期	記錄	原因
2011 年 1 月	已將 WORKFLOW 元素的資料表移至新主題所有 WORKFLOW XML 項目參考。	資訊加強。
2010 年 7 月	全部重寫，提供所有 WORKFLOW 項目和屬性的詳細資訊、範例和摘要。	資訊加強。

2011 年 1 月

已將 WORKFLOW 元素的資料表移至新主題所有 WORKFLOW XML 項目參考。

資訊加強。

2010 年 7 月

全部重寫，提供所有 WORKFLOW 項目和屬性的詳細資訊、範例和摘要。

資訊加強。

共用方式為

設計工作流程

工作流程設計方針

工作流程圖表和程式碼範例

判斷狀態的數目和類型

定義轉換

指定原因

指定動作

更新欄位

當狀態變更時變更欄位的值

當另一個欄位的值變更時清除欄位的值

根據其他欄位的內容定義欄位

檢視工作流程狀態圖表

請參閱

其他資源

變更記錄

其他資源