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