變更工作項目類型的工作流程
Azure DevOps Server 2022 - Azure DevOps Server 2019
您可以變更工作項目類型 (WIT) 的工作流程,以支援您的商務和小組程式。 WIT 支援追蹤所有類型的工作,例如需求、工作、程式代碼缺失,以支援軟體開發。
工作流程會決定小組成員將執行的工作邏輯進展和回歸。 它也會指定 [狀態] 和 [原因] 字段的下拉功能表中顯示的值。 如需詳細資訊,請參閱 關於進程和進程範本。
產品待辦專案工作流程 (Scrum 程式範本)
注意
本文說明如何自定義工作流程狀態。 相反地,如果您想要變更 指派給特定工作項目的狀態 ,請參閱下列其中一篇文章: 面板、追蹤進行中工作,或 工作面板、更新工作狀態。 您也可以針對許多工作專案執行狀態的大量更新。
如需建置管線工作流程的相關信息,請參閱 開始使用 CI/CD。
更新工作項目類型的 XML 定義
如果您不熟悉 WIT 自定義,請注意下列事項:
- 若要自定義工作項目類型的任何層面,您必須更新其 XML 定義。 XML 定義會在所有 WITD XML 元素參考中 描述
- 如果您要自定義使用新工作項目體驗的 Web 窗體,您會想要參考 WebLayout 和 Control 元素
- 如果您要自定義要與 Visual Studio 搭配使用的用戶端表單,您會想要參考 Layout XML 元素參考
- 遵循自定義工作項目追蹤 Web 窗體中所述的步驟順序。
若要自定義工作流程,請遵循下列兩個步驟:
WORKFLOW
修改 WIT 定義的 區段,如本主題所述。-
當您變更出現在敏捷式工具頁面上之 WIT 的工作流程時,需要這個第二個步驟。 這些 WIT 屬於需求或工作類別。 如需狀態類別的詳細資訊,請參閱 工作流程狀態和狀態類別。
工作流程設計指導方針
您可以先識別狀態和它們之間的有效轉換,以定義工作流程。 WORKFLOW
WIT 定義的 區段會指定有效狀態、轉換、轉換原因,以及當小組成員變更工作項目狀態時,將會執行的選擇性動作。
一般而言,您會將每個狀態與小組成員角色建立關聯,以及該角色中人員必須執行的工作,才能變更工作項目的狀態。 轉換會定義狀態之間的有效進展和回歸。 原因可識別小組成員將工作專案從某個狀態變更為另一個狀態的原因,而動作支援在工作流程中某個時間點將工作專案的轉換自動化。
例如,當測試人員開啟以預設 Agile 程式為基礎的新 Bug 時,[狀態] 會設定為 [新增 ]。 開發人員在修正 Bug 時將狀態變更為 [作用中],一旦修正,開發人員就會將其狀態變更為 [已解決],並將 [原因] 字段的值設定為 [已修正]。 驗證修正之後,測試人員會將 Bug 的狀態變更為 [已關閉 ],並將 [原因] 欄位變更為 [已驗證]。 如果測試人員判斷開發人員尚未修正 Bug,測試人員會將 Bug 的狀態變更為 [作用中],並將 [原因] 指定為 [未修正] 或 [測試失敗]。
當您設計或修改工作流程時,請考慮下列指導方針:
STATE
使用 元素來定義每個小組成員角色的唯一狀態,以對工作項目採取特定動作。 您定義的狀態越多,您必須定義的轉換越多。 不論您定義狀態的順序為何,它們都會以英數位元順序序列在 [狀態] 欄位的下拉功能表中。如果您將狀態新增至出現在入口網站待辦專案或面板頁面上的工作項目類型,您也必須將狀態對應至狀態類別目錄。 如需詳細資訊,請檢閱 工作流程狀態和狀態類別。
TRANSITION
使用 元素來定義每個有效進展和從某個狀態回歸到另一個狀態的轉換。您至少必須為每個狀態定義一個轉換,以及從 Null 狀態轉換為初始狀態的轉換。
您只能定義從未指派的轉換到初始狀態的一個轉換。 當您儲存新的工作專案時,它會自動指派給初始狀態。
當小組成員變更工作項目的狀態時,該變更會觸發轉換,以及您為選取狀態和轉換定義的動作。 使用者只能根據您為目前狀態定義的轉換來指定有效的狀態。 此外,
ACTION
元素是 的TRANSITION
子專案,可以變更工作項目的狀態。針對每個轉換,您可以使用 元素來定義預設原因
DEFAULTREASON
。 您可以使用 元素來定義您想要REASON
的選擇性原因。 這些值會出現在 [原因] 字段的下拉功能表中。您可以指定工作專案變更狀態、轉換時,或用戶選取特定原因時套用的規則。 其中許多規則會補充您在定義下
WORKITEMTYPE
區段中定義欄位FIELDS
時可以套用的條件式規則。 如需詳細資訊,請參閱 本主題稍後的工作流程變更 期間更新欄位。您指派給狀態和原因的名稱不區分大小寫。
工作專案表單或查詢編輯器中 [狀態] 和 [原因] 欄位的下拉功能表會顯示工作項目類型區段中指派
WORKFLOW
的值。
工作流程圖表和程式代碼範例
下列程式代碼範例顯示 WORKFLOW
敏捷式程式範本的 Bug WIT 定義 。 此範例會定義三種狀態和五個轉換。 元素 STATE
會指定 [作用中]、[已解決] 和 [已關閉] 狀態。 對於進展和回歸轉換的所有可能組合都是針對這三種狀態所定義,但其中一種除外。 未定義從 Closed 轉換為 Resolved 的轉換。 因此,如果工作專案已關閉,小組成員就無法解析此類型的工作專案。
此範例不會列出、 REASON
ACTION
和 FIELD
的所有專案DEFAULTREASON
。
範例工作流程狀態圖 - 敏捷式 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>
判斷狀態的數目和類型
您可以根據您希望該類型的工作專案存在的不同邏輯狀態數目,判斷有效狀態的數目和類型。 此外,如果不同的小組成員執行不同的動作,您可以考慮根據成員角色定義狀態。 每個狀態都會對應至小組成員必須在工作專案上執行的動作,以將它移至下一個狀態。 針對每個狀態,您應該定義特定動作,以及允許執行這些動作的小組成員。
下表提供四個狀態的範例,這些狀態是定義來追蹤功能進度,以及必須執行指示動作的有效使用者:
州/省 | 有效的使用者 | Action to perform |
---|---|---|
已提案 | 專案經理 | 任何人都可以建立功能工作專案。 不過,只有項目經理可以核准或拒絕工作專案。 如果項目經理核准功能,項目經理會將工作專案的狀態變更為作用中;否則,小組成員會關閉它。 |
使用中 | 開發潛在客戶 | 開發負責人負責監督功能的發展。 當功能完成時,開發潛在客戶會將功能工作專案的狀態變更為 [檢閱]。 |
檢閱 | 專案經理 | 如果實作令人滿意,項目經理會檢閱小組所實作的功能,並將工作專案的狀態變更為 [已關閉]。 |
結案 | 專案經理 | 預期不會在關閉的工作項目上執行其他動作。 這些專案會保留在資料庫中以供封存和報告之用。 |
注意
不論您指定狀態的順序為何,所有狀態都會依字母順序出現在特定類型之工作項目的表單上。
定義轉換
如果您定義有效的狀態進展和回歸,您可以控制小組成員可以變更工作項目的狀態。 如果您未定義從某個狀態轉換為另一個狀態的轉換,小組成員就無法將特定類型的工作專案從特定狀態變更為另一個特定狀態。
下表針對本主題稍早所述的四種狀態,以及每個狀態的預設原因,定義有效的轉換。
州/省 | 轉換至狀態 | 預設原因 |
---|---|---|
已提案 | 主動(進展) | 已核准用於開發 |
封閉式 (進展) | 未核准 | |
使用中 | 檢閱(進展) | 符合驗收準則 |
檢閱 | 封閉式 (進展) | 功能完成 |
主動(回歸) | 不符合需求 | |
結案 | 建議 (回歸) | 重新考慮核准 |
主動(回歸) | 已關閉錯誤 |
您可以使用 元素的 for 和 not 屬性,限制允許誰從某個狀態轉換成另一個狀態。TRANSITION
如下列範例所示,測試人員可以重新開啟 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
元素,在Visual Studio應用程式生命週期管理或Visual Studio應用程式生命週期管理以外的 Microsoft其他地方發生事件時,自動變更特定類型的工作項目狀態(例如,從追蹤呼叫的工具)。 如需詳細資訊,請參閱 ACTION。
在工作流程變更期間更新欄位
您可以定義規則,以在發生下列事件時更新欄位:
當您想要讓規則套用至 的所有轉換,以及輸入該狀態的原因時,請在 底
STATE
下指派欄位規則。當您想要讓規則套用該轉換,以及進行該轉換的所有原因時,請在 下方
TRANSITION
指派欄位規則。在 或
REASON
底下DEFAULTREASON
指派欄位規則,以便只針對該特定原因套用規則時。如果欄位應該一律包含相同的值,您可以在定義該欄位的
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>
當另一個字段的值變更時,清除域的值
當工作專案的 [狀態] 欄位的值設定為 [作用中] 且工作專案已儲存時,[關閉日期] 和 [關閉依據] 字段會自動設定為 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 安裝 狀態模型視覺效果延伸模組 ,以支援使用者以可視化方式呈現工作流程。