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

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

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

定義產(chǎn)品 

首先我們要確定開發(fā)的是產(chǎn)品，而非項目。產(chǎn)品和項目的區(qū)別是什么？與此對應(yīng)的另外一個問題是產(chǎn)品經(jīng)理和項目經(jīng)理的區(qū)別是什么？ 后面的問題我們不在此篇中討論，產(chǎn)品和項目的區(qū)別主要在兩方面體現(xiàn)：生存周期和目標。

 項目的生存周期比較短從啟動、策劃、執(zhí)行、監(jiān)控到收尾。驗收交付給用戶之后項目就結(jié)束了。而產(chǎn)品不存在結(jié)束的說法，因為產(chǎn)品是不斷更新的，直到被新產(chǎn)品替代，生存周期才結(jié)束。 

 項目的目標是在規(guī)定的時間內(nèi)，利用有限的資源，高質(zhì)量的完成某個特定用戶的需求。而產(chǎn)品更多是為了滿足一些用戶的通過用需求。

 當(dāng)然項目和產(chǎn)品之前存在很多的關(guān)聯(lián)，如果產(chǎn)品按迭代開發(fā)，每個迭代有時候像極了一個項目。項目和產(chǎn)品有時候是協(xié)同發(fā)展的。

中小公司團隊

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

敏捷開發(fā)流程對產(chǎn)品開發(fā)的影響

產(chǎn)品開發(fā)成什么樣是由產(chǎn)品經(jīng)理設(shè)計的，能不能滿足用戶的需求，會不會給公司帶來利潤很大程度上都依賴于產(chǎn)品經(jīng)理。俗話說把所有的寶都押在一個人身上是很危險的，因為產(chǎn)品本身需要滿足的是一群人的需求，以及產(chǎn)品經(jīng)理對需求的挖掘和理解各有差異，敏捷開發(fā)很大的一個出發(fā)點是通過延遲設(shè)計和實現(xiàn)來規(guī)避這個風(fēng)險。

MVP（最小可行性產(chǎn)品）的思路來自于《精益創(chuàng)業(yè) 》 

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

不能按開發(fā)任務(wù)的整體性來安排迭代任務(wù)，這里的標準是：每一個迭代完成之后應(yīng)該交付給用戶完整可用的產(chǎn)品。對于2B，特別是大B用戶類的產(chǎn)品，迭代周期可以長一些，多預(yù)留一些測試時間，待產(chǎn)品足夠穩(wěn)定之后再上線。

UserStory需求優(yōu)先級評估

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

我們采用 KANO模型法（基本型需求> 期望型需求>興奮型需求 ) + 滿足核心業(yè)務(wù)的投入產(chǎn)出比最大的需求優(yōu)先（ROI最大化） 組合評估。

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

P0-N，P1-N, P2-N 

• P0為基本核心需求

• P1為期望型需求

• P2為興奮型需求

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

希望各位開發(fā)人員以后機智一點，不要直接跟產(chǎn)品說這個需求做不了。而是問：“你這個需求為用戶帶來了什么？給公司帶來了什么？” 

改良版Scrum

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

Task - 開發(fā)任務(wù)

Bug - 缺陷 

角色

• Master  

• Product Owner

• Developer

• Tester

角色職責(zé) 

Master

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

• 迭代計劃會議

• 每日站會

• 迭代回顧會議 

Product Owner

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

• 定義UserStory優(yōu)先級

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

• 確保 UserStory 得到拆分以及執(zhí)行（Project Management項目管理）

• 驗收 UserStory  

Dev

• 作為Dev Owner 正確理解需求，從技術(shù)和實現(xiàn)角度與PM溝通需求，協(xié)助改進需求

• 將UserStory拆分為Task 

• 將開發(fā)代碼的合并請求關(guān)聯(lián)到Task 

Tester 

• 正確理解需求，從測試和用戶體驗角度與PM溝通需求，協(xié)助改進需求 

• 測試UserStory與Bug管理 

• 驗證Bug

目標（以企業(yè)能夠承擔(dān)得起的成本來做可持續(xù)發(fā)展）：

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

• 高效協(xié)作 ：可以用文檔溝通的方式，就不要開會 

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

• 培養(yǎng)團隊： 在允許的范圍內(nèi)充分授權(quán)團隊自己決策與執(zhí)行，TL與管理者應(yīng)該更多地輔導(dǎo)。
  

 

定義：

• UserStory: 只是一句話的需求描述什么角色需要什么樣的功能，并不是詳細的功能設(shè)計。

• 架構(gòu)方案設(shè)計: 指的是那些重大的框架性的調(diào)整，需要有人專門設(shè)計和開發(fā)好之后其它開發(fā)人員才可以在此基礎(chǔ)之上開發(fā)。屬于基礎(chǔ)建設(shè)之類的，比如：開發(fā)框架，消息隊列處理之類的通用組件和功能。TL要評估這個事情能不做的就留著給DevOwner去做，TL進行輔導(dǎo)。

• 產(chǎn)品原型：只包含本迭代內(nèi)的UserStory的詳細設(shè)計

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

• DevOwner: 每一個UserStory會分配一個DevOwner，通常是自己主動承擔(dān)的，會比Dev多一些項目管理的職責(zé)。可以培訓(xùn)開發(fā)人員的項目管理能力，但是需要Leader或者Manager來給予輔導(dǎo) 

主要流程

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

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

3. 開發(fā)測試在做本迭代開發(fā)任務(wù)的時候 ，產(chǎn)品經(jīng)理進行下一個迭代的產(chǎn)品詳細設(shè)計

4. 產(chǎn)品的詳細設(shè)計出來之后，直接將文檔發(fā)給整個團隊進行線下閱讀。TL和測試分別進行技術(shù)架構(gòu)方案和測試用例的編寫。

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

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

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

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

9. Tester 測試UserStory填寫bug 

10. Dev 修復(fù) bug 進入Bug管理流程

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

 

 

與主流Scrum的主要差異         

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

• 給UserStory 排優(yōu)先級的時候不需要團隊所有人員參與，多數(shù)情況是產(chǎn)品經(jīng)理和技術(shù)Leader決定就可以了 （Scrum建議團隊所有人員在估算會議一起參加） 

• 添加了產(chǎn)品詳細設(shè)計與測試用例設(shè)計和評審的過程（優(yōu)先鼓勵通過文檔異步的方式來評審）

• 評審/演示會議由產(chǎn)品經(jīng)理示情況進行線下驗收還是在會議上由開發(fā)自己來演示 

• 用gitlab issue來做可視化管理 

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

可視化管理

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

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

以下我們創(chuàng)建UserStory，Task，Bug在Gitlab里面都是issue，只是我們打上了不同的標簽。 

需求池

單獨新建一個需求池的Board把所有包含F(xiàn)eature(UserStory) 的標簽列出來。這里Doing就當(dāng)前迭代的需求，ToDo是下個迭代的需求。Open是所有待完成的需求。 

UserStory

需求由產(chǎn)品經(jīng)理創(chuàng)建之后將相關(guān)的一些文檔和原型地址都全部匯總到描述中，如果需求有變更需要同步更新。

• 在迭代會議的時候指定開發(fā)負責(zé)人DevOwner

• 由DevOwner對需求進行進一步的詳細分析之后拆分任務(wù)并創(chuàng)建Related Issue，并指派具體的開發(fā)人員

 

Task

開發(fā)的任務(wù)中關(guān)聯(lián)了對應(yīng)的UserStory和相關(guān)的代碼commit、merge request等。通過開發(fā)任務(wù)就可以直接找到與這個任務(wù)相關(guān)的代碼。

 

 

燃盡圖

Scrum在給所有的task打上StoryPoint之后，根據(jù)每天剩余（未完成任務(wù)）StoryPoint的總和繪制圖表就得到了燃盡圖。

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

Bug缺陷管理 

傳統(tǒng)的開發(fā)-測試流程造成了很多問題：開發(fā)寫完代碼之后對自己的任務(wù)甚至不做基本的檢測就丟給測試。測試也沒有精力去做一些自動化的工作。中間測試-開發(fā)還常常出現(xiàn)推諉，反復(fù)的情況。 開發(fā)也沒有機會去加強自己的測試sense和技能。最后只能造成雙輸?shù)木置妗?/p>

理想豐滿，現(xiàn)實骨感

Scrum以及敏捷開發(fā)提出來依靠測試驅(qū)動，自動化單元測試、集成測試來達到內(nèi)建質(zhì)量的提倡當(dāng)然是非常好的。但是國內(nèi)大多數(shù)中小團隊都達到不這樣的條件這樣做。我們只能退而求其次，在滿足用戶要求的產(chǎn)品質(zhì)量的基礎(chǔ)之后，逐漸培養(yǎng)開發(fā)人員的測試能力以及測試人員自動化腳本能力。

建立和持續(xù)改進機制

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

基礎(chǔ)測試流程

 

基礎(chǔ)測試流程與傳統(tǒng)的測試流程大致相同，這里主要的變化是將測試用例寫的足夠簡單以便于讓開發(fā)理解和快速校驗。我們在開發(fā)提交功能給測試之前需要自己先走一遍測試之前提供的該功能的用例確保每一項是通過的。 保證你寫的代碼能運行正常是每一個負責(zé)任程序員的基本素質(zhì)。 

測試人員從一開始就深度參與到這個迭代開發(fā)的每一個環(huán)節(jié)，加上對于開發(fā)任務(wù)的可視化管理。測試在打開bug的時候直接assign給對應(yīng)的開發(fā)人員。不需要leader再額外的approval。

標簽管理

以下是在gitlab labels中額外添加的一些標簽用來在后面迭代回顧的時候更好地統(tǒng)計bug進行質(zhì)量改進分析。

• Priority 優(yōu)先級 

• High

• Medium

• Low

• Severity  嚴重級別 

• Critical 致命

• Major 高

• Minor 中 

• Low 低

• Resolutions 關(guān)閉原因

• Fixed 最后確認是bug并且修復(fù)了

• Deferred 是bug，但是延期再修復(fù) 

• Duuplicate 重復(fù)了

• As Designed 設(shè)計就是這樣，不是我的鍋 

• Cannot Reproduce 不能重現(xiàn) 

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

測試用例

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

 

 

 

Bug回顧 

沒有回顧就沒有持續(xù)的改進 。在每一個迭代結(jié)束之后，我們都要將這個迭代產(chǎn)生的bug進行統(tǒng)計匯總、團隊一起分析，并與之前的迭代bug統(tǒng)計進行對比。gitlab沒有比較方便的統(tǒng)計圖表功能，所以我們會把有bugs標簽的issue導(dǎo)出到excel再進行分析。

按嚴重級別進行匯總

按人員進行匯總

按關(guān)閉原因進行匯總

 

常見問題總結(jié)

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

結(jié)語

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