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

我曾經遵循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來給予輔導 。

主要流程

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

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

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

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

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

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

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

DevOwner線下拆分Task，TL離線異步評審

Tester?測試UserStory填寫bug?

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再進行分析。

按嚴重級別進行匯總

按人員進行匯總

按關閉原因進行匯總

常見問題總結

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

結語

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

圖書推薦

如果大家想對Scrum和敏捷開發有更多的了解，有興趣的同學可以看看下面兩本書。我在上篇文章說建議大家多學一些除了代碼之外的東西。我是個說到做到的人。

總結

以上是生活随笔為你收集整理的中小企业团队敏捷产品开发流程最佳实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。