以人治天下，賢則大治，不賢則大亂。
以術知天下，術高多宵小。
以法治天下，法令莫不從，民生定。
一、總要有個流程
作爲一個研發，你最討厭什麼？
"小功能，十分鐘能搞定吧！"
"需求都清楚了吧，明天老闆要看效果！"
"有個急事，插一下！"
"這個地方，還要調整下，稍後給你更新的文檔！"
"這個當初肯定不是這樣定的，是你們的問題"
"代碼怎麼被覆蓋了？"
"測過的代碼怎麼沒上線？"
"這個線上問題是誰誰的變動引起的。"
"這個爲什麼沒測到？"
... ...
需求張口就提，說變就變；開發時間不明確，無法控制；測試不規範，不全面，質量無法保障等等，不一列舉。
沒有規範約束，沒有流程限制，沒有章程遵循。 可能對於某些場景會很高效，但問題也是層出不窮。
一個公司成長到了一定的規模，如果還是如上這種，那麼唯一的結果只有：混亂。
二、需要一個怎樣的流程
一個完整的研發過程包括哪些活動？
需求 => 開發 => 測試 => 上線。
1、需求怎麼提？
a）需求階段需要做什麼？
確定要做什麼 + 做成什麼樣 + 怎麼做
比如：
要做什麼：發表文章的功能頁面要改版，以更好的適應用戶的操作習慣。
做成什麼樣：新的功能佈局 + 新的編輯器支持 + 表情符號支持 + 話題插入支持 + 圖片編輯支持 + 自動實時保存支持。
怎麼做：輸出詳細的 prd 需求文檔 + 需求評審 + 資源調配 + 排期 + 進度控制。
相對來說，前兩步多是產品自身範圍內的工作活動，是需求的基礎。最後一項則是和關聯研發人員的協作，支持。以成品 prd 文檔作爲媒介，進一步展開後續的流程。
b）需求優先級界定
一個公司會有很多個產品，每個產品負責不同的業務範疇，那麼便會衍生出不同方向的需求。
需求有大有小，重要性也不盡相同，所以需要有一個排序的流程。
將所有的需求都擺在桌面上，由上層來結合公司發展方向及公司戰略來篩選哪些需要做，每一項的優先級。
2、需求評審
產品形成成熟的需求文檔後，則要進行需求的宣講，評審。也就是把上述的過程內容闡述給後續流程的研發人員（包括開發和測試等）。
所謂評審，既要評，又要審，也並不會是一錘定音，一遍過。 對需求內容的整體方向，產出，roi等綜合進行考評，合適的的方保留，不合適的去掉，可以改進的繼續改進。
對於比較大的，比較重要的或者比較複雜的需求，項目，可能需要經過多次評審，多次改進才能最終定稿。
這一流程節點產出是要作爲整個研發流程的指導性文件，應該做到不厭繁瑣，力求能夠盡善盡美。否則越是往後流程的返工，成本越大。
3、排期
我們講一個需求或者項目，即爲在特定的資源條件下實現特定的目的。
既定的資源包括時間，人力及設備成本等。
需求週期一般是既定的，比如，老闆說下個月什麼功能上線，你就得上線，轉圜餘地不大。
所以涉及到人力需求則要在如上既定時間週期下去安排，調配人力資源。包括開發及測試等。
其它成本包括服務器，網絡，外部付費技術資源（安全、校驗）等，是不是需要採購新的服務器，是不是需要拓寬網絡，是否是需要引入外部的校驗API等。
這一階段，主要是確定每個流程節點的時間需求，確保每個流程能夠在合適的時間開始和結束。
4、技術方案評審
需求確定後，流程流轉至開發人員，此時，開發人員應根據既定的 prd 需求文檔，產出詳細的技術方案文件。
聞道有先後，術業有專攻，每個人都有自己擅長的領域。單人主導的技術方案至少要經過交叉人員評審後方可定檔實施。
比如，
數據怎麼存儲？表字段設計的合不合理？需不需要分表？
需不需要介入緩存層？需要哪種形式的緩存？
系統間怎麼交互？交互方式？
接口設計是否合理？前後端交互流程？
哪些是核心業務邏輯？哪些業務可以拆分異步處理？
需不需要引入新的技術？
... ... 等等。
5、編碼開發
編碼開發其實佔用的時間並不多。
就好像炒菜一樣，菜品的清洗，準備往往是最耗時的，反而入鍋翻炒也就一會兒的事。
6、Code Review
我一直秉信 Code Review 是能夠極大保障代碼質量的。
Code Review 關注點包括：代碼設計、功能實現、複雜性、測試友好性、代碼風格、命名、註釋、文檔等。
Code Review 的形式可以採取代碼庫流程，或者集體拉會形式等。
7、提供測試
開發流程結束後，流程流轉至測試。
研發環境一般要提供完整的開發、測試、灰度、線上環境區分，以供不同階段不同流程需要。
這一階段，開發人員需要將開發結果部署到測試環境，提供給測試人員。
如有必要，也需要提供相關測試數據支持。
8、測試案例評審
測試案例輸出及評審通常和開發並行，由技術方案流程確定後起始。
測試人員根據既定的需求及技術方案文檔設計測試用例，包括新功能、變動功能及迴歸功能等。
測試用例完結後，需要和開發人員進行溝通評審，確保測試用例的完整性。
9、測試
測試環境及測試用例就緒後，開始流轉測試流程。
測試包括功能測試、集成測試、迴歸測試、灰度測試、線上驗證等。
由此節點開始可能需要橫跨所有後續流程。
測試往往是產品質量的最後一道防線。
及早發現問題、提出問題應爲首要，尤其不要試圖掩蓋問題。
上線前一秒發現問題都是居功至偉。
10、上線、驗證
功能上線，不同公司可能操作方會略有不同，開發、測試、SRE人員都有可能操作這一流程。
上線後功能驗證必不可少，由測試或者產品執行，確保產出和目標相符。
流程至此完結。