作者：豬齒魚技術團隊

在研發專案中，各團隊常常用看板管理任務的生命週期，並且不同團隊的看板任務流轉都是不同的。通過實踐，我們收集到不同團隊對看板管理的需求：

專案經理期望知曉團隊的整體工作情況，期望可以定製一套符合團隊的任務流程；
開發團隊注重每個人的任務進度及開發量，同步管理程式碼質量；
測試團隊針對測試的功能提交缺陷後，缺陷的修復情況如何；
產品團隊梳理完需求，需求各階段的狀態得到反饋。

針對各團隊的需求，Choerodon豬齒魚的看板管理引入 「狀態機」功能，用來制定不同的任務流轉的工作流程，跟看板中的列對應，針對看板中的每種狀態也定義了對應的工作流及處理問題時執行的特定操作。幫助大家專注研發流程，提升研發效率。

?

C7N「狀態機」使用場景

下圖為研發專案的通用研發流程，其中包括專案中需求各階段的流轉歷程，以及對程式碼開發的整個週期管理。

需求管理是研發專案活動中的一個重要過程，可以說需求是產品開發的開端，貫穿著整個產品的生命週期，從一開始的需求收集、到需求設計、開發、測試、最終上線，無論哪個環節都是依賴著需求進行的。

當需求評審通過後，專案進入到開發側，這時，開發團隊需要制定明確的迭代計劃，包括product backlog（產品待辦，也就是評審通過的需求）的優先順序、迭代目的等，隨後進入到開發階段。

開發人員確定任務後，建立對應的開發分支，開發完成後，開發人員本地自測，再合入開發環境測試主分支，安排測試人員進行開發環境測試。最後通過驗收測試後，系統釋出上線。

01

定製任務流程

以這套流程為例，在Choerodon豬齒魚中如何使用狀態機進行任務流程配置呢？

配置看板中的狀態與流轉

Choerodon豬齒魚看板管理契合專案從需求管理到開發、測試、上線的全流程配置。根據示例中的研發專案的整個流程體系，我們首先需要確認看板中明確迭代的三個階段：設計、開發、測試。

三個階段分別對應以下狀態節點：
設計：功能設計、技術設計、設計評審、設計完成；
開發： 待開發、開發中、本地自測、開發完成；
測試： 待測試、staging測試、驗收測試、已完成。

不同階段專注的內容可以彙集到不同的看板。如下，我們可以建立設計看板、開發看板、測試看板。

設計看板與開發看板的連線依靠：設計階段的設計完成=開發階段的待開發；
開發看板到測試看板的連線依靠：開發階段的完成態就是測試階段的初始態。

!

當然，如果需要全域性維度的檢視看板，我們也可以建立全域性看板。

根據制定好的看板、列和狀態以及場景，配置狀態的流轉方向可以控制看板中卡片的流轉。
以<故事>這個issue型別為例，流轉流程如下：

狀態的流轉狀態配置好後，在看板中拖動任務時，任務會根據流程流轉。

配置問題型別

此外，專案上往往存在多個不同型別的需求，對不同的需求有不同的處理流程。例如：

不同的需求同樣需要不同的issue型別來梳理，Choerodon豬齒魚通過不同型別issue的流程管理能力，以幫助專案實現多樣化，多情景的流程管理能力。詳細配置資訊，請參考使用者手冊「如何問題型別配置」

02

issue與分支聯動

開發團隊進入到開發階段後，產生了一條程式碼分支的生命歷程。即：確定任務後，建立對應的開發分支，開發完成後，開發人員本地自測，再合入開發環境測試主分支，安排測試人員進行開發環境測試。從這個流程提煉出了以下和issue相關的聯動：

開發人員本地開發分支feature合併入測試環境測試主分支master後，開發完成；
開發完成通知測試人員測試。

例如：根據上訴需求配置如下：

Choerodon豬齒魚支援issue和開發分支聯動起來，為團隊的DevOps實踐提供更好的支援。

03

故事與子任務聯動流轉

專案迭代過程中，開發人員專注於所負責的子任務的開發，忽略的使用者故事維度的管理和流轉，會造成子任務已經完成，但是使用者故事依舊在某個狀態積壓，不能及時進入測試流程。這將會導致這些使用者故事沒有得到充分的測試，最終會影響到產品的交付質量。Choerodon豬齒魚的狀態機功能支援父子任務進行狀態聯動，無需人工維護。

例如：開發子任務全部開發完成後，使用者故事自動流轉到開發完成狀態。