這篇文章談下如果我們要新開發一個配合DevOps平臺使用的研發過程管理模塊，那麼需要具備的一些關鍵功能和關鍵對象分析，在前面DevOps和外圍協同的時候我們也講到，DevOps平臺可以和類似禪道等研發項目管理平臺進行對接，實現研發項目和過程管理，而如果全新開發一個子模塊可以理解爲禪道功能的一個裁剪。

我們首先來看下華爲雲的DevOps平臺提供的關於研發管理能力

參考： https://support.huaweicloud.com/qs-devcloud/devcloud_qs_0202.html

可以看到，裏面的核心對象包括了項目，需求，任務，迭代幾個個關鍵要素。即首先進行項目規劃，然後錄入需求，對錄入的需求進行拆分，細化到細粒度的用戶故事，然後對用戶故事進行拆分爲具體的任務。同時一個項目可以規劃多個迭代，這個迭代則映射到具體的項目版本，同時將具體的需求或任務添加到不同的項目版本中。整個思路基本和scrum敏捷方法論一致，也體現了關鍵的對象間的協同。

整個概念裏面暫時沒有看到產品的概念，也沒有看到對變更和缺陷等的管理。

我們再來看下另外一個敏捷開發項目管理平臺ones.ai提供的功能

參考： https://ones.ai/index.html

由於這個平臺本身就是一個敏捷研發管理平臺，因此功能來說相對更全。其中項目管理部分包括了產品管理，項目管理，需求管理，任務管理，迭代管理和缺陷管理。

整個邏輯仍然是scrum敏捷方法論的思路，創建產品版本，規劃具體的迭代版本，將多個迭代關聯到具體的產品版本上面。同時錄入具體的需求，對需求進行拆分，將需求關聯到具體的迭代版本上。同時需求還可以和具體的測試用例管理，需求本身還可以進行任務拆分。

整個平臺重點是增強了測試管理，缺陷管理方面的能力。同時增加了產品版本的概念。產品版本和迭代版本是兩個完全獨立的對象並相互關聯。同時在該平臺還增加了項目集功能，可以將多個項目規劃到一個項目集中進行統一的管理和跟蹤。

關鍵對象和關係分析

對於研發過程管理，可以看到關鍵對象包括產品，項目，項目集，迭代版本，需求，任務，測試用例，缺陷，項目團隊，這也是敏捷項目管理的核心業務對象。

產品一般指我們標準化的產品研發，產品本身也會有版本，但是產品版本如何升級，同樣是需要規劃的研發項目，在研發完成後進行了產品版本升級。因此項目既包括了對內的研發項目，也包括了對外客戶的項目。基於一個標準產品我們會接很大對外項目，很可能都涉及到定製。

比如我們接到中國移動的項目，基於我們標準產品進行定製，那麼這個時候首先要建立中國移動這個項目，項目和產品之間建立關聯。項目本身最好還有大版本和小版本的概念，項目的小版本對應到具體的迭代版本。錄入具體的需求，在需求錄入完成後開始規劃迭代版本，將具體的需求規劃到迭代版本中。同時迭代版本本身屬於一個項目或項目大版本。

通過前面幾個步驟基本的產品，項目，需求，版本間的關係已經建立，接着重點就是具體的工作和任務。

對應需求可以拆分爲多個任務，當然任務是獨立的獨立，可以關聯到具體的需求，也可以獨立存在不關聯到需求。在任務創建完成後需要確定任務的開始完成時間，工作量評估，然後進入到具體的任務跟蹤。

整個scrum是需求和用戶故事驅動，因此需求錄入完成後，需要基於需求進行測試用例的編寫，一個需求可以對應多個測試用例，然後在開發完成後基於測試用例進行測試發現缺陷，那麼缺陷自然關聯到測試用例，同時也關聯到具體的需求。

一個客戶項目往往可能涉及到我們多個產品，因此一個客戶項目最好規劃爲一個項目集，即將多個項目版本納入到一個項目集中進行管理。這樣後續分析的時候可以從項目集維度進行統一的分析和度量。

所有上面的對應後面都會方面我們進行研發過程度量分析使用。

關鍵功能和差異分析

首先項目和項目版本的概念分離，即項目版本即對應到迭代版本或迭代這個對象上面。

一個產品可以對應多個項目，項目可以是內部研發項目，客戶是我們自己，也可以是外部項目對應具體的客戶。當是內部研發項目的時候，研發完成後往往升級產品版本。

項目創建的時候重點是給出項目的執行週期，項目對應的客戶，項目對應的產品，項目中的團隊成員等關鍵信息。在項目規劃完成後，規劃具體的項目版本，比如南方電網ESB項目V0.1版本，南方電網ESB項目V0.2版本，

具體的需求注意不掛接在項目下面，而是必須掛接到項目版本下面。

對於版本啓用大版本和小版本，注意大版本是可以直接發到客戶的版本，小版本爲內部版本，當然小版本還可以規劃爲小版本和迭代版本兩個版本段。

我們來看下具體的場景，當前已經有了標準的ESB V1.0產品版本，當我們接到南方電網ESB項目後，我們首先要錄入南網ESB項目，同時錄入一個V0.1項目版本。然後我們將需求先錄入到產品下面，錄入到產品下面的意思就是一個需求可以規劃到該產品下面不同的項目版本中。

我們來分析下，如果錄入了20個需求點，其中5個是標準化產品需求，15個爲定製需求，同時15個定製需求我們準備分三個迭代版本來進行實現。基於上面這個場景，具體操作應該是：

1. 選擇ESB產品，在產品中錄入具體的15個已經拆分後的需求功能點

2. 新創建研發項目V0.1版本，新創建南網項目V0.1, 0.2和0.3版本

3. 分別將上面的20個需求納入到具體的四個項目版本中

4. 對於南網項目單獨拉一個分支，同時注意對於研發項目版本的修改需要merge到南網項目分支上

這個梳理清楚後，我們再來看關鍵的需求到任務的關係。

我們舉個簡單的例子來看，服務實例查詢是一個獨立的需求功能點，那麼針對這個功能點就需要拆分任務，在這裏我們建議增加一個批量添加任務的功能，即針對一個需求功能點，往往存在需求，設計，編碼，測試設計，測試執行，或者開發會進一步分爲前端開發，後端開發。我們只需要選擇存在哪些步驟，然後基於這些步驟來自動創建相應的任務名稱。同時任務和人員有匹配，如果任務類型在該項目下只有一個該類型人員，則可以直接將任務默認安排到該人員。即實際可能拆分完成後爲：

服務實例查詢-需求開發 -- 張三

服務實例查詢-編碼 -- 李四

服務實例查詢-測試用例編寫 -- 王五

服務實例查詢-測試執行 -- 王五

我們再來看下scrum裏面的敏捷看板管理，一種最簡單的方法就是userstory，todo, doing, done幾個關鍵狀態進行管理，而實際上我們可以進行更細化的開發過程狀態跟蹤。即需求故事，待開發（任務清單），開發中，測試中，完成幾個關鍵狀態。

即我們可以設計爲在編碼任務，團隊人員領取任務後即進入中開發中狀態，在開發人員反饋任務完成的時候直接進入到測試中狀態，在測試人員反饋測試執行任務完成後進入到已完成狀態。跨泳道流轉的主體爲userStory。

測試人員具體具體的用戶故事點進行測試，測試發現的缺陷錄入到缺陷管理模塊中，缺陷自然掛接到具體的需求，同時能夠關聯到具體的項目和項目版本。方便我們後面進行質量分析和項目度量。