近期因為疫情的影響，不少網際網路公司開始嘗試遠端工作。也出不了少如何做好遠端工作的方法，我認為不管是場地辦公還是遠端辦公都依賴於原來的產品開發流程。

我曾經遵循CMMI5的流程管理過15人左右的跨國/語言/文化團隊，也遵循敏捷Scrum管理過9人的小團隊，還針對一個從4人發展到近30人的團隊嘗試過各種方式的專案管理方法，這其中有2C和2B的產品，也有平臺/生態型產品。 最後在自己創立公司的5人小團隊（場地和遠端辦公融合方式）中摸索出了我認為最適合中小企業產品開發流程與管理方法。

 今天我們聊聊產品開發流程與管理。我們通過對Scrum的改造，利用Gitlab的issue對需求、開發和測試進行視覺化管理。應該來說能夠適應絕大多數的中小企業和團隊，當然再好的流程也會因不同的人來落地執行而產生不一樣的效果。

定義產品 

首先我們要確定開發的是產品，而非專案。產品和專案的區別是什麼？與此對應的另外一個問題是產品經理和專案經理的區別是什麼？ 後面的問題我們不在此篇中討論，產品和專案的區別主要在兩方面體現：生存週期和目標。

 專案的生存週期比較短從啟動、策劃、執行、監控到收尾。驗收交付給使用者之後專案就結束了。而產品不存在結束的說法，因為產品是不斷更新的，直到被新產品替代，生存週期才結束。 

 專案的目標是在規定的時間內，利用有限的資源，高質量的完成某個特定使用者的需求。而產品更多是為了滿足一些使用者的通過用需求。

 當然專案和產品之前存在很多的關聯，如果產品按迭代開發，每個迭代有時候像極了一個專案。專案和產品有時候是協同發展的。

中小公司團隊

我們這個流程更適合小公司和團隊，但是中型的公司如果資源比較緊張的時候也適用。小團隊的特點通常是可能沒有專職的UI設計（或者比較少）、沒有專職測試人員 （或者比較少）。沒有那麼規範的管理流程，有人身兼多職。所有該流程的目標是希望追求高效的團隊產出同時兼顧產品的長期發展。

敏捷開發流程對產品開發的影響

產品開發成什麼樣是由產品經理設計的，能不能滿足使用者的需求，會不會給公司帶來利潤很大程度上都依賴於產品經理。俗話說把所有的寶都押在一個人身上是很危險的，因為產品本身需要滿足的是一群人的需求，以及產品經理對需求的挖掘和理解各有差異，敏捷開發很大的一個出發點是通過延遲設計和實現來規避這個風險。

MVP（最小可行性產品）的思路來自於《精益創業 》 

敏捷開發中“迭代iteration"的思路跟MVP的思路基本一致，我們在進行敏捷開發中很重要的環節不是你的流程執行的對不對，而是迭代需求有沒有拆分好，否則不可能在使用者那邊過關。 這個重點環節需要Master和PO(Product Owner) 以及技術Leader一起來完成。

不能按開發任務的整體性來安排迭代任務，這裡的標準是：每一個迭代完成之後應該交付給使用者完整可用的產品。對於2B，特別是大B使用者類的產品，迭代週期可以長一些，多預留一些測試時間，待產品足夠穩定之後再上線。

UserStory需求優先順序評估

一個UserStory是一個完整的使用者需求，結合自身團隊的情況以及需求的難易程度可以在每次迭代計劃會議的時候來確定下個迭代要開發哪些UserStory。這其中團隊需要對如何挑選UserStory有一個明確的定義。

我們採用 KANO模型法（基本型需求> 期望型需求>興奮型需求 ) + 滿足核心業務的投入產出比最大的需求優先（ROI最大化） 組合評估。

在KANO的基礎上優先處理基本需求（也可以稱之為核需求），在核心需求依然很多需要排序的時候採用核心需求投入產出比最大化原則進行排序 。

P0-N，P1-N, P2-N 

• P0為基本核心需求

• P1為期望型需求

• P2為興奮型需求

N為ROI評估，為1到5數字，5的ROI最大，得此組合6永遠優先做P0-5的需求。ROI的評估大抵是以研發投入為成本，使用者價值和公司價值作為回報來評估。

希望各位開發人員以後機智一點，不要直接跟產品說這個需求做不了。而是問：“你這個需求為使用者帶來了什麼？給公司帶來了什麼？” 

改良版Scrum

Feature/UserStory- 使用者需求(我們團隊叫Feature是受歷史遺留影響）

Task - 開發任務

Bug - 缺陷 

角色

• Master  

• Product Owner

• Developer

• Tester

角色職責 

Master

• 保證Scrum流程的正確執行，以及以下會議的紀律 

• 迭代計劃會議

• 每日站會

• 迭代回顧會議 

Product Owner

• 清晰定義每一個UserStory，確保 DevOwn以及測試對UserStory的正確理解

• 定義UserStory優先順序

• 同步 UserStory文件及原型的變更 

• 確保 UserStory 得到拆分以及執行（Project Management專案管理）

• 驗收 UserStory  

Dev

• 作為Dev Owner 正確理解需求，從技術和實現角度與PM溝通需求，協助改進需求

• 將UserStory拆分為Task 

• 將開發程式碼的合併請求關聯到Task 

Tester 

• 正確理解需求，從測試和使用者體驗角度與PM溝通需求，協助改進需求 

• 測試UserStory與Bug管理 

• 驗證Bug

目標（以企業能夠承擔得起的成本來做可持續發展）：

• 用好文件：重要的文件一定要有

• 高效協作 ：可以用文件溝通的方式，就不要開會 

• 實用主義：不要花太多時間寫測試用例

• 培養團隊： 在允許的範圍內充分授權團隊自己決策與執行，TL與管理者應該更多地輔導。
  

定義：

• UserStory: 只是一句話的需求描述什麼角色需要什麼樣的功能，並不是詳細的功能設計。

• 架構方案設計: 指的是那些重大的框架性的調整，需要有人專門設計和開發好之後其它開發人員才可以在此基礎之上開發。屬於基礎建設之類的，比如：開發框架，訊息佇列處理之類的通用元件和功能。TL要評估這個事情能不做的就留著給DevOwner去做，TL進行輔導。

• 產品原型：只包含本迭代內的UserStory的詳細設計

• 測試用例：並不是非常詳細的測試用例，更像是check list

• DevOwner: 每一個UserStory會分配一個DevOwner，通常是自己主動承擔的，會比Dev多一些專案管理的職責。可以培訓開發人員的專案管理能力，但是需要Leader或者Manager來給予輔導 

主要流程

1. PO 定義UserStory 放入Catelog 需求池（只有有這個想法了，或者使用者提出來了就放到需求池。

2. 提前一個迭代對UserStory 進行排序，計劃下一個迭代的UserStory。

3. 開發測試在做本迭代開發任務的時候 ，產品經理進行下一個迭代的產品詳細設計

4. 產品的詳細設計出來之後，直接將文件發給整個團隊進行線下閱讀。TL和測試分別進行技術架構方案和測試用例的編寫。

5. 技術方案和測試用例的評審可以是通過文件線下來進行（不需要開會）

6. 產品原型的評審也是可以由線下進行不開會。

7. 組織迭代計劃會議，可以提產品原型中的問題。給每個UserStory分配好DevOwner

8. DevOwner線下拆分Task，TL離線非同步評審

9. Tester 測試UserStory填寫bug 

10. Dev 修復 bug 進入Bug管理流程

必須要開的會議只有一個迭代規劃會議、每日站會、迭代回顧會議。其它的會議儘量通過文件的形式離線解決。

與主流Scrum的主要差異         

• 需求UserStory的StoryPoint由技術Leader一個人給出即可，主要用來大致評估成本，開發的Task是由開發人員自己按小時評估工時。(Scrum建議都按StoryPoint來估）

• 給UserStory 排優先順序的時候不需要團隊所有人員參與，多數情況是產品經理和技術Leader決定就可以了 （Scrum建議團隊所有人員在估算會議一起參加） 

• 添加了產品詳細設計與測試用例設計和評審的過程（優先鼓勵通過文件非同步的方式來評審）

• 評審/演示會議由產品經理示情況進行線下驗收還是在會議上由開發自己來演示 

• 用gitlab issue來做視覺化管理 

• 單獨對Bug管理的流程進行了補充定義 

視覺化管理

敏捷開發中非常強調公開、透明、直接有效的溝通，這也是“白板”在敏捷開發中如此重要的原因之一。通過“白板”讓所有人直觀的看到所有任務的狀態、問題、以及任務之間的流動 。當然用白板和便利貼來管理任務會更有趣，但不是每個團隊都能玩好。工具是給人用的，只要抓住背後的核心訴求，大多數的工具都能達到效果。

我之前用的是Teambition來做的視覺化管理，現在的公司使用Gitlab Issue功能（它跟開發的程式碼評審結合的更緊密）所以我利用issue管理的功能和它的Board，Milesontes和 Labels功能結合起來就可以很好的對UserStory，Task和Bug來進行管理 。

以下我們建立UserStory，Task，Bug在Gitlab裡面都是issue，只是我們打上了不同的標籤。 

需求池

單獨新建一個需求池的Board把所有包含Feature(UserStory) 的標籤列出來。這裡Doing就當前迭代的需求，ToDo是下個迭代的需求。Open是所有待完成的需求。 

UserStory

需求由產品經理建立之後將相關的一些文件和原型地址都全部彙總到描述中，如果需求有變更需要同步更新。

• 在迭代會議的時候指定開發負責人DevOwner

• 由DevOwner對需求進行進一步的詳細分析之後拆分任務並建立Related Issue，並指派具體的開發人員

Task

開發的任務中關聯了對應的UserStory和相關的程式碼commit、merge request等。通過開發任務就可以直接找到與這個任務相關的程式碼。

燃盡圖

Scrum在給所有的task打上StoryPoint之後，根據每天剩餘（未完成任務）StoryPoint的總和繪製圖表就得到了燃盡圖。

理想的燃盡圖應該是像下圖中的虛線那樣規律性的下降直到0（所有任務開發完成），通過這個圖就可以看到在這個迭代內任務被關閉的情況，用來分析開發團隊的實際產出。

Bug缺陷管理 

傳統的開發-測試流程造成了很多問題：開發寫完程式碼之後對自己的任務甚至不做基本的檢測就丟給測試。測試也沒有精力去做一些自動化的工作。中間測試-開發還常常出現推諉，反覆的情況。 開發也沒有機會去加強自己的測試sense和技能。最後只能造成雙輸的局面。

理想豐滿，現實骨感

Scrum以及敏捷開發提出來依靠測試驅動，自動化單元測試、整合測試來達到內建質量的提倡當然是非常好的。但是國內大多數中小團隊都達到不這樣的條件這樣做。我們只能退而求其次，在滿足使用者要求的產品質量的基礎之後，逐漸培養開發人員的測試能力以及測試人員自動化指令碼能力。

建立和持續改進機制

我們現在10個人的團隊中有一個測試人員來建立和鞏固基礎測試流程、維護通用測試用例、 對開發人員對於測試技能培訓、 以及進行迭代bug回顧和觀測來達到持續改進的目的。

基礎測試流程

基礎測試流程與傳統的測試流程大致相同，這裡主要的變化是將測試用例寫的足夠簡單以便於讓開發理解和快速校驗。我們在開發提交功能給測試之前需要自己先走一遍測試之前提供的該功能的用例確保每一項是通過的。 保證你寫的程式碼能執行正常是每一個負責任程式設計師的基本素質。 

測試人員從一開始就深度參與到這個迭代開發的每一個環節，加上對於開發任務的視覺化管理。測試在開啟bug的時候直接assign給對應的開發人員。不需要leader再額外的approval。

標籤管理

以下是在gitlab labels中額外新增的一些標籤用來在後面迭代回顧的時候更好地統計bug進行質量改進分析。

• Priority 優先順序 

• High

• Medium

• Low

• Severity  嚴重級別 

• Critical 致命

• Major 高

• Minor 中 

• Low 低

• Resolutions 關閉原因

• Fixed 最後確認是bug並且修復了

• Deferred 是bug，但是延期再修復 

• Duuplicate 重複了

• As Designed 設計就是這樣，不是我的鍋 

• Cannot Reproduce 不能重現 

這些標籤可以可通過gitlab 的scoped標籤（父標籤::子標籤）的形式來管理，比如Priority::High, Prioirty::Medium, Priority::Low。

測試用例

我們的測試用例與標準的測試用例有很大的區別，基本上我們是不寫測試步驟的。只寫簡單的用例描述和預期結果，當然這個預期結果會盡量包含所有的分支。開發人員需要在提交測試之前自己確保這些功能都是正常的，否則我們會定義為嚴重的不負責任。

Bug回顧 

沒有回顧就沒有持續的改進 。在每一個迭代結束之後，我們都要將這個迭代產生的bug進行統計彙總、團隊一起分析，並與之前的迭代bug統計進行對比。gitlab沒有比較方便的統計圖表功能，所以我們會把有bugs標籤的issue匯出到excel再進行分析。

按嚴重級別進行彙總

按人員進行彙總

按關閉原因進行彙總

常見問題總結

通過加強開發自測試和建立持續改進機制我們逐漸讓測試人員有一些時間從質量管理更巨集觀的層面去做改進，也讓測試有一些時間去建立自動化體系。

結語

流程只是整個產品開發管理中很小的一部分。流程為人服務，而不應該是徒添負擔。 除了流程，我們還需要建立完善的團隊獎懲機制、員工培訓和晉升機制，整個團隊才會有活力。由於篇符有限，可能有些地方會有遺漏，還請各位海