概述
有讀者反饋，讀了文章 一線技術管理者究竟在管什么事？ 收獲滿滿，但還有點不過癮，還想了解更細的東西...
這篇文章分享開發流程規范，目的是提高產品質量，優化開發流程，供大家參考。
規范是死的，人是活的，希望自己定的規范，不要被打臉。
接下來從以上六個階段進行逐一拆解。
1 需求評審
作為技術人員肯定都參加過需求評審會，不知道有沒有遇到這樣的情況？
- 產品經理按照 PRD 文檔讀一遍，參會人員無動於衷。
- 產品經理剛講了一個需求點，參會人員就產生了激烈的討論，都在證明自己是對的。
- 參會人員對需求的目標不明確，對需求點進行發散思維討論，最終偏離方向。
遇到以上問題，肯定是在參加需求評審之前未做充分准備，那么問題來了，需要提前准備什么？
評審前
不要聽產品同學說，該需求是大老板跟進的、非常重要、非常緊急之類的，就問產品三個問題：
- 解決了什么問題？
- 提升了什么指標？
- 有什么商業價值？
這三個問題搞清楚了，再進行評審。
產品經理發出 原型 和 PRD 初稿后，開發人員要有 1-2 天時間（具體時間根據項目大小而定），熟悉文檔，有任何疑問可以反饋給開發經理，由開發經理統一收集再反饋給產品經理，產品經理逐一進行答疑。
熟悉完文檔后，開發人員和開發經理需要一起確定：
- 技術選型（前端/后端框架、日志中間件、消息中間件、數據庫...）
- 技術架構（組件與組件之間如何協同工作，如何部署）
- 技術難點預知（明確存在的技術難點，並確定解決方案）
- 性能瓶頸預知（明確可能存在性能瓶頸的地方，並確定應對措施）
- 上下游系統交互（明確在流程中的哪個位置，約定接口文檔提供時間、接口聯調時間）
- 功能模塊划分（任務拆分和分配）
技術方案確定后，需要輸出技術設計文檔，包括：總體設計、概要設計、詳細設計、接口設計 等。
評審中
開發人員必須參加，有需求不明確的地方當場提出，同時開發人員也需要思考產品需求是否合理，可適當提出自己的產品意見。
一般評審至少有兩次（初稿和終稿）。
評審后
評審后，如有需更新技術文檔的請及時進行更新。
開發經理首先需要考慮團隊現有的資源及項目的優先級，然后根據技術設計文檔進行評估排期。
排期模板如下：
2 技術評審
評審前
開發人員一定要重視技術設計！
開發人員一定要重視技術設計！
開發人員一定要重視技術設計！
重要事情說三遍！
技術評審主要評審什么？
系統關系圖、模塊關系圖、流程圖的設計，畫圖工具根據自己愛好即可。接口設計，需要考慮接口的 兼容性、擴展性、參數命名遵守 參數命名規范 等。數據庫設計，需要遵守 數據庫設計規范，並記錄 數據表變更文檔。詳細設計，需要考慮公共類、公共方法、方法定義 遵守 項目框架目錄規范。
評審中
開發人員和開發經理必須參加，涉及到總體設計和概要設計時，需要邀請 架構師 參與，涉及到數據庫調整時，需要邀請 DBA 參與。
一般評審至少有兩次（初稿和終稿）。
評審后
評審后，如有需更新排期文檔的請及時進行更新。
排期確定后，通過郵件方式進行回復排期，使用標准化的 回復排期郵件模板。
按部就班，按計划行事。
3 需求開發
編碼
開發人員編碼過程中，需要遵守團隊的 編碼規范，同時嚴格按照設計文檔中的技術方案執行，除了保證代碼邏輯的正確性外，還需要考慮代碼封裝性、可維護性、可擴展性，當編碼階段發現技術方案需要調整時，需要及時通知開發經理，經過同意后才能實施，涉及到引入新框架和新技術，也需要提前通知開發經理。
代碼審查
開發人員需要控制代碼提交的頻次和粒度，每次代碼提交之后 24 小時內，需要主動聯系代碼審查人完成檢查，開發經理負責檢查是否執行到位。
代碼審查主要審查什么？
- 規范性檢查（是否符合代碼規范、提交備注規范等）
- 健壯性檢查（是否陷入死循環、資源未釋放等）
- 安全性檢查（是否存在SQL注入、XSS、SSRF、CSRF、越權、文件上傳等）
- 性能檢查（是否存在未加緩存頻繁連接DB，是否需要連接池）
聯調
開發人員積極主動地推動聯調工作，如果遇到阻礙及時通知技術經理進行協調。
自測
聯調完畢后，開發人員需要同時完成自測，並將標准化的 自測報告 發給測試團隊。
對於有性能要求的項目，需要開發人員進行性能測試，並出具標准化的 性能測試報告。
提測
自測完畢后，通過郵件方式進行提測申請，使用標准化的 申請提測郵件模板。
開發人員根據公司運維提供的發布方式，進行部署到測試環境。
4 跟進測試
測試用例評審
開發人員必須參加，避免出現測試與開發對需求理解不一致的情況。
Bug 修復
開發人員及時關注 Bug 列表，快速修復迭代發布，如果測試進度存在延期風險，需要及時通知開發經理。
5 跟進上線
開發人員首先確認 Bug 全部關閉，同時產品人員在測試環境驗收通過，然后需要主動推動相關團隊理清上線依賴和上線順序，同時確定回滾預案，最后根據公司運維提供的發布方式，進行部署到線上環境。
線上環境部署完成后，通過郵件方式進行通知產品人員和測試人員，使用標准化的 上線完畢郵件模板，同時積極推動測試人員和產品人員完成線上驗證，線上出現問題后第一時間通知開發經理。
6 線上問題復盤
需求在測試環境和正式環境，均未測試出 Bug，上線一段時候后出現 Bug，這種問題用什么制度約束？
出現問題后開發人員及時修復，修復完了就完事了。僅僅做到這些還遠遠不夠。
建議使用如下模板進行復盤。
小結
大家可以數一數上面使用到了多少規范，這時有朋友會說了，這規范也太多了吧，這和工廠工人有什么區別，我們程序員是有創造性的，我們喜歡前沿性、挑戰性的工作，我們放盪不羈愛自由...
針對這個問題，首先我不否認開發人員是有創造性的，但並不是所有的程序員都有創造性，在現實工作場景中大部分程序員不是做創造性工作的，也沒必要做創造性工作，所以必須按照規范流程執行。
團隊管理和團隊之間合作，必須要有規范，並嚴格執行。
就到這吧，以上供參考。