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

Azure DevOps Server 2022 |Azure DevOps Server 2020 |Azure DevOps Server 2019 |TFS 2018

您可以變更工作專案類型的工作流程, (WIT) 以支援您的商務和小組程式。 WIT 支援追蹤所有類型的工作,包括需求、工作、程式碼缺失,以支援軟體發展。

工作流程會決定小組成員將執行之工作的邏輯進展和回復。 它也會指定出現在 [狀態] 和 [原因] 欄位下拉式功能表中的值。 如需預設進程範本中支援的預設工作流程狀態概觀,請參閱 選擇進程

產品待辦專案工作流程 (Scrum 程式範本)

產品待辦專案工作流程、Scrum 程式

注意

本文說明如何自訂工作流程狀態。 如果您想要改為變更指派給特定工作專案的狀態,請參閱下列其中一個主題:新增工作專案、更新工作狀態、Kanban 面板、追蹤進行中的工作,或工作面板、更新工作狀態。 您也可以 針對許多工作專案執行 狀態 的大量更新

如需建置管線工作流程的相關資訊,請參閱 開始使用 CI/CD

更新 WIT 的 XML 定義

如果您不熟悉 WIT 自訂,請注意下列事項:

若要自訂工作流程,請遵循下列兩個步驟:

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

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

    當您變更出現在敏捷式工具頁面上之 WIT 的工作流程時,需要執行第二個步驟。 這些 WIT 屬於需求或工作分類。 若要深入瞭解狀態類別,請參閱 工作流程狀態和狀態類別

工作流程設計指導方針

您可以藉由先識別狀態及兩者間的有效轉換來定義工作流程。 WORKFLOWWIT 定義的 區段會指定有效狀態、轉換、轉換原因,以及當小組成員變更工作專案狀態時,將會執行的選擇性動作。

一般而言,您會將每個狀態關聯至小組成員角色,以及該角色中的人員在變更其狀態之前必須執行來處理該工作項目的工作。 轉換會定義狀態之間的有效進展和回復。 原因可識別出為何小組成員會將工作項目從某一個狀態變更到另一個狀態,以及動作會在工作流程中的某個時點支援自動轉換工作項目。

例如,當測試人員開啟以預設敏捷式程式為基礎的新 Bug 時,狀態會設定為 [ 新增 ]。 開發人員會在修正 Bug 時,將狀態變更為 [ 作用 中],一旦修正,開發人員就會將其狀態變更為 [已解決 ],並將 [原因] 欄位的值設定為 [已修正]。 驗證修正之後,測試人員會將 Bug 的狀態變更為 [ 已關閉 ],而 [原因] 欄位會變更為 [已驗證]。 如果測試人員判斷開發人員尚未修正 Bug,測試人員會將 Bug 的狀態變更為 [ 作用 中],並將 [原因] 指定為 [未修正 ] 或 [ 測試失敗]。

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

  • STATE使用 元素,為每個將對工作專案採取特定動作的小組成員角色定義唯一狀態。 您定義的狀態越多,必須定義的轉換就越多。 不論您定義狀態的順序為何,它們都會以英數位元順序列在 [ 狀態 ] 欄位的下拉式功能表中。

    如果您將狀態新增至出現在入口網站中待辦專案或面板頁面上的工作專案類型,您也必須將狀態對應至狀態類別目錄。 若要深入瞭解,請檢閱 工作流程狀態和狀態類別

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

    您至少必須針對每個狀態定義一個轉換,並從 Null 狀態轉換為初始狀態。

    您可以定義一個只能從未指派 (Null) 到初始狀態的轉換。 當您儲存新的工作項目時,系統會自動將它指派為初始狀態。

    當小組成員變更工作項目的狀態時,該變更會觸發轉換,以及您定義來要針對所選取狀態和轉換執行的動作。 使用者可以根據您針對目前狀態定義的轉換,指定只有這些有效狀態。 此外,專案 ACTION 是 的 TRANSITION 子項目,可以變更工作專案的狀態。

  • 針對每個轉換,您會使用 DEFAULTREASON 元素來定義預設原因。 您可以使用 元素來定義您想要 REASON 的選擇性原因。 這些值會出現在 [ 原因] 欄位的下拉式功能表中。

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

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

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

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

下列程式碼範例顯示 WORKFLOW 敏捷式進程範本的 Bug WIT 定義。 這個範例會定義三個狀態和五個轉換。 元素 STATE 會指定 [作用中]、[已解析] 和 [已關閉] 狀態。 進展和回復轉換的所有可能組合都是針對這三種狀態所定義,但有一個例外。 尚未定義從 [已關閉] 到 [已解決] 的轉換。 因此,如果工作項目已關閉,小組成員便無法解決這種類型的工作項目。

此範例不會列出 、 REASONACTIONFIELD 的所有專案 DEFAULTREASON

範例工作流程狀態圖 - 敏捷式 Bug WIT

Bug 工作流程狀態、敏捷式程式範本

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

判斷狀態的數目和類型

您會根據想要讓該類型的工作項目存在其中的不同邏輯狀態數目,來決定有效狀態的數目和類型。 此外,如果不同的小組成員會執行不同的動作,則您可以考慮根據成員角色定義狀態。 每個狀態都會對應至小組成員必須在工作項目上執行以將它移到下一個狀態的動作。 針對每個狀態,您應該定義特定的動作,以及允許執行這些動作的小組成員。

下表提供四種狀態範例,這些狀態是定義來追蹤某個功能的進度,以及必須執行指定動作的有效使用者:

State 有效的使用者 要執行的動作
已提議 專案經理 任何人都可以建立功能工作項目。 不過,只有專案經理可以核准或能取消核准該工作項目。 如果專案經理核准某個功能,該專案經理便會將工作項目的狀態變更為 [作用中];否則,小組成員就會關閉它。
使用中 開發組長 開發組長會監視功能的開發。 當功能完成時,開發組長會將功能工作項目的狀態變更為 [檢閱]。
檢閱 專案經理 專案經理會檢閱小組實作的功能,而且如果實作是令人滿意的,即會將工作項目狀態變更為 [已關閉]。
已關閉 專案經理 任何其他動作不應該在已關閉的工作項目上發生。 這些項目會基於保存和報告目的而保留在資料庫中。

注意

特定類型之工作項目的所有狀態都會依字母順序顯示於表單上的清單中,而不論您指定它們的順序為何。

定義轉換

如果您定義了有效的狀態進展與回復,即能控制小組成員可用以變更工作項目狀態的方式。 如果您未定義從某一個狀態到另一個狀態的轉換,小組成員便無法將特定類型的工作項目從某一個特定的狀態變更為另一個特定狀態。

下表會分別針對本主題先前所述的四個狀態定義有效的轉換,以及每一個狀態的預設原因。

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

您可以使用 元素的 TRANSITIONfornot屬性,限制誰能夠從某個狀態轉換成另一個狀態。 如下列範例所示,測試人員可重新開啟 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 工作項目與開發人員簽入版本控制項的檔案相關聯,即應自動解決它們。

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

您可以使用 ACTION 元素,從追蹤呼叫) 的工具,在 Microsoft Visual Studio 應用程式生命週期管理或 Visual Studio 應用程式 (生命週期管理以外的其他位置時,自動變更特定類型工作專案的狀態。 如需詳細資訊,請參閱 ACTION

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

您可以定義規則,每當發生下列事件時更新欄位:

  • 當您想要讓規則套用至 該狀態的所有轉換,以及輸入該狀態的原因時,請指派下方的欄位規則 STATE

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

  • 在 或 REASON 下指派欄位規則 DEFAULTREASON ,當您希望規則僅適用于該特定原因時。

    如果欄位一律包含相同的值,您可以在定義該欄位的 FIELD 元素下定義規則。 若要深入瞭解規則使用方式,請參閱 規則和規則評估

    您應該試著將您為任一個工作項目類型定義的條件數目降至最低。 透過您加入的每個條件式規則,您會增加每當小組成員儲存工作項目時所發生之驗證處理程序的複雜度。 複雜的規則集可能會增加儲存工作項目所需的時間。

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

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

當工作專案的 [ 狀態 ] 欄位的值設定為 [作用中] 且工作專案已儲存時,[ 啟用 者] 和 [ 指派給 ] 欄位的值會自動設定為目前使用者的名稱。 該使用者必須是 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>  

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

當工作專案的 [ 狀態 ] 欄位的值設定為 [作用中] 且工作專案已儲存時,[關閉日期] 和 [已關閉者] 欄位會自動設定為 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 安裝 狀態模型視覺效果延伸模組 ,以視覺化工作流程。