變更工作項目類型的工作流程

Azure DevOps Server |Azure DevOps Server 2022

改變工作項目類型（WIT）的工作流程，以支持您的業務與團隊流程。 WIT 支援追蹤所有類型的工作，例如需求、工作、程式代碼缺失，以支援軟體開發。

工作流程決定了團隊成員所執行工作的邏輯進展與回歸。 它也會指定 [狀態] 和 [原因] 字段的下拉功能表中顯示的值。 如需詳細資訊，請參閱 關於進程和進程範本。

產品待辦專案工作流程 （Scrum 程式範本）

注意

本文說明如何自定義工作流程狀態。 若要更改特定工作項目所分配 的狀態 ，請參閱以下文章之一： Board、追蹤進行中工作，或 Task board，更新任務狀態。 您也可以執行對於許多工作專案的狀態的大量更新。

如需建置管線工作流程的相關信息，請參閱 開始使用 CI/CD。

更新工作項目類型的 XML 定義

如果你是 WIT 自訂新手，請注意以下幾點：

• 若要自訂工作項目類型的任何面向，請更新其 XML 定義。 欲了解更多資訊，請參閱所有 WITD XML 元素參考。
• 如果你正在自訂使用新工作項目體驗的網頁表單，請參考 WebLayout 和 Control 元素。
• 如果你正在自訂客戶表單以配合 Visual Studio，請參考 Layout XML 元素參考。
• 遵循自定義工作項目追蹤 Web 窗體中所述的步驟順序。

若要自定義工作流程，請遵循下列兩個步驟：

1. 修改 WIT 定義中 WORKFLOW 區段，如本主題所述。

2. 修改程式組態，將新的工作流程狀態對應至中繼狀態。

   當您變更在敏捷工具頁面出現的 WIT 的工作流程時，必須執行此第二步驟。 這些 WIT 屬於需求或工作類別。 如需狀態類別的詳細資訊，請參閱 工作流程狀態和狀態類別。

工作流程設計指導方針

先定義工作流程，先識別狀態及其間有效的轉換。 WORKFLOW WIT 定義的章節規定了當團隊成員變更工作項目狀態時，有效的狀態、轉換、轉換的原因，以及可選的動作。

一般而言，將每個狀態與團隊成員的角色關聯起來，並指定該角色人員必須完成的任務，這些任務是在改變狀態之前由該角色的人負責處理工作項目的必要步驟。 轉換會定義狀態之間的有效進展和回歸。 原因可識別小組成員將工作專案從某個狀態變更為另一個狀態的原因，而動作支援在工作流程中某個時間點將工作專案的轉換自動化。

例如，當測試人員開啟基於預設敏捷程序的新錯誤時，將狀態設為 新 。 開發人員在修正 Bug 時將狀態變更為 [作用中]，一旦修正，開發人員就會將其狀態變更為 [已解決]，並將 [原因] 字段的值設定為 [已修正]。 驗證修正之後，測試人員會將 Bug 的狀態變更為 [已關閉 ]，並將 [原因] 欄位變更為 [已驗證]。 如果測試人員判斷開發者沒有修正錯誤，就會將錯誤狀態切換為 「活躍 」，並指定原因為 「未修復 」或 「測試失敗」。

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

• 利用該 STATE 元素為每個對工作項目執行特定行動的團隊成員角色定義獨特的狀態。 您定義的狀態越多，您必須定義的轉換越多。 無論你以哪種順序定義狀態，它們都會以字母數字順序出現在 狀態欄位的 下拉選單中。

  如果您將狀態新增至出現在入口網站待辦專案或面板頁面上的工作項目類型，您也必須將狀態對應至狀態類別目錄。 如需詳細資訊，請參閱 工作流程狀態和狀態類別。

• 使用 TRANSITION 元素來定義每個有效的從一個狀態進展及回歸到另一個狀態的轉狀態。

  至少，為每個狀態定義一個轉移，以及從空狀態到初始狀態的轉換。

  您只能定義從未指派（null）狀態到初始狀態的一個轉換。 當你儲存一個新工作項目時，程序會自動將其指派到初始狀態。

  當小組成員變更工作項目的狀態時，該變更會觸發狀態轉換，以及您為所選狀態和轉換定義的動作。 使用者只能根據您為目前狀態定義的轉換來指定有效的狀態。 此外， ACTION 元素是 的 TRANSITION子專案，可以變更工作項目的狀態。

• 對於每個轉換，請使用 DEFAULTREASON 元素定義一個預設理由。 您可以使用REASON元素來定義任意多個您想要的選擇性原因。 這些值會出現在 [原因] 字段的下拉功能表中。

• 你可以指定當工作項目改變狀態、轉換或使用者選擇特定原因時適用的規則。 其中許多規則會補充您在定義下FIELDS區段中定義欄位WORKITEMTYPE時可以套用的條件式規則。 如需詳細資訊，請參閱稍後在本主題中的工作流程變更期間更新欄位。

• 您指派給狀態和原因的名稱不區分大小寫。

  工作專案表單或查詢編輯器中 [狀態] 和 [原因] 欄位的下拉功能表會顯示工作項目類型區段中指派 WORKFLOW 的值。

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

下列程式代碼範例顯示 WORKFLOW 敏捷式程式範本的 Bug WIT 定義 。 此範例會定義三種狀態和五個轉換。 元素 STATE 會指定 [作用中]、[已解決] 和 [已關閉] 狀態。 對於進展和回歸轉換的所有可能組合都是針對這三種狀態所定義，但其中一種除外。 從封閉到解決的過渡並沒有明確定義。 因此，若工作項目已關閉，團隊成員無法解決此類工作項目。

此範例不會列出DEFAULTREASON、REASON、ACTION和FIELD的所有元素。

敏捷 Bug 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>

判斷狀態的數目和類型

根據你希望該類型工作項目存在的不同邏輯狀態數量，決定有效狀態的數量與類型。 此外，如果不同團隊成員執行不同動作，考慮根據成員角色定義狀態。 每個狀態都會對應至小組成員必須在工作專案上執行的動作，以將它移至下一個狀態。 針對每個州，定義具體的行動以及允許執行這些動作的團隊成員。

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

州/省	有效的使用者	要執行的動作
已提出	專案經理	任何人都可以建立功能性工作專案。 不過，只有項目經理可以核准或拒絕工作專案。 如果項目經理核准功能，項目經理會將工作專案的狀態變更為作用中;否則，小組成員會關閉它。
使用中	開發主管	開發負責人負責監督功能的發展。 當功能完成時，開發主管會將功能項目的狀態變更為審核。
審查	專案經理	如果實作令人滿意，項目經理會檢閱小組所實作的功能，並將工作專案的狀態變更為 [已關閉]。
關閉	專案經理	預期不會在關閉的工作項目上執行其他動作。 這些專案會保留在資料庫中以供封存和報告之用。

注意

不論您指定狀態的順序為何，所有狀態都會依字母順序出現在特定類型之工作項目的表單上。

定義轉換

你透過定義有效的狀態進程與回歸，控制團隊成員可變更工作項目的狀態。 如果你沒有定義從一個狀態轉換到另一個狀態的轉換，團隊成員就無法將特定類型的工作項目從某個狀態變更到另一個特定狀態。

下表針對本主題稍早所述的四種狀態，以及每個狀態的預設原因，定義有效的轉換。

州/省	轉換至狀態	預設原因
已提出	主動（進展）	已核准用於開發
	封閉式 （進展）	未核准
使用中	審查（進度）	符合驗收準則
審查	封閉式 （進展）	功能完成
	主動（迴歸）	不符合需求
關閉	建議（回歸分析）	重新考慮以便核准
	主動（回歸）	錯誤關閉

您可以使用 TRANSITION 的 for 和 not 屬性，限制允許誰從某個狀態轉換成另一個狀態。 如以下範例所示，測試人員可以重新開啟錯誤，但開發者卻無法。

<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 元素，以在發生轉換時自動變更工作項目的狀態。 如以下範例所示，你可以指定若錯誤工作項目與開發者在版本控制中檢查的檔案相關聯，應自動解決：

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

當 Microsoft Visual Studio 應用程式生命週期管理的其他地方或外部（例如追蹤呼叫的工具）發生事件時，可使用該 ACTION 元素自動更改特定類型工作項目的狀態。 如需詳細資訊，請參閱 ACTION。

在工作流程變更期間更新欄位

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

• 當您想讓規則適用於所有轉換至狀態和進入該狀態的原因時，請在 STATE 下指派欄位規則。

• 當您想要讓規則套用該轉換，以及進行該轉換的所有原因時，請在 下方 TRANSITION 指派欄位規則。

• 在 DEFAULTREASON 或 REASON 下指派欄位規則，以便該規則僅適用於特定原因。

  如果某欄位應該總是包含相同的值，則在定義該欄位的 FIELD 元素下定義規則。 如需規則使用方式的詳細資訊，請參閱 規則和規則評估。

  盡量減少你為任何一種工作項目定義的條件數量。 每一條條件規則都會增加每次團隊成員儲存工作項目時的驗證流程複雜度。 複雜的規則集可能會增加儲存工作項目所需的時間。

  下列範例顯示 MSF Agile 軟體開發程式範本中套用至系統欄位的一些規則。

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

當你將工作項目的 狀態 欄位值設為「活躍」並儲存該工作項目時， 「啟用者 」和 「指派對象 」欄位的值會自動設定為目前使用者的名稱。 該用戶必須是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 元素會自動將「結束日期」和「截止日期」欄位設為空值，並使其變成唯讀，如下範例所示。

<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 的 狀態模型視覺化擴充功能 。