引言

戰國·鄒·孟軻《孟子·離婁上》：“離婁之明，公輸子之巧，不以規矩，不能成方圓。”

每一個行業都有自己行之有效的規矩，同樣軟件行業也有自己一套的開發流程，今天就來跟大家聊一聊咱們公司的開發流程，讓大家品評下，有興趣的可以把自家的公司流程放到評論中哦，相互學習，相互進步。

需求確定

需求提出人（運營、財務、銷售、人事等）會提出自己的訴

產品經理會按照訴求，梳理出需求文檔和原型并最終和需求提出人確定最終版。

確定技術方案

產品經理、項目經理和架構師會按照上面出的需求進行技術評審，結合人力、成本、時間、風險等因素，確定合理的技術方案，并制定開發計劃，確定開發周期。

組織需求評審

確定好需求及技術方案后，產品經理會組織所有的開發童鞋和測試童鞋，開發童鞋了解需要做什么，測試童鞋需要按照需求評審編寫測試用例文檔。

編寫概要設計

開發人員按照需求評審中的內容及項目經理分配的開發計劃中分配的開發內容，編寫概要設計文檔，文檔中包含關鍵業務邏輯、業務流程圖、數據庫表設計等。

建議：文檔內容力求能說出關鍵點，圖表多一些，文字少一些。

概要評審

等開發人員編寫完概要設計文檔后，項目經理組織概要設計的評審，來確認從技術層面和業務層面是否滿足需求功能。

注意：評審可以進行多次，務必要保證開發明確自己的開發目標，不能有含糊的字樣。

功能開發

等概要文檔評審后，開發童鞋按照文檔中的內容進行開發，其中如果發現開發過程中有異議，也需要同步到文檔中，用做記錄。

功能演示

在迭代版本中，項目經理可以組織一定次數的功能演示，來檢驗開發的功能是否滿足需求。

注意：可以按照需求維度、或者按照時間維度進行演示。

代碼review

在迭代版本中，架構師（或技術大牛）可以組織一定次數的代碼走查，用于發現代碼中的壞味道，確保代碼規范。

建議：不要等功能開發完畢后再進行代碼review，因為迭代開發完后再改動成本大，就像建大樓到樓頂的時候，發現地基有問題，涼涼~

測試用例評審

在轉測前，測試童鞋會組織一次全員的測試用例評審，看是否有對于功能的遺漏，進行補全。

冒煙測試

在轉測前，開發童鞋根據評審后的測試用例評審，找到高優先級的測試用例在測試環境進行自測，確定是否成功。

測試環境轉測

當代碼review、冒煙測試、功能演示并在測試環境部署完成后，項目經理發送轉測郵件，申請轉測。

測試童鞋在測試環境進行測試，驗證功能是否滿足需求。

驗收環境轉測

當測試童鞋確定測試環境驗證通過后，需要運維童鞋把測試環境的系統部署到驗收環境。

測試童鞋、產品經理在測試環境進行測試，驗證功能是否滿足需求。

注意：驗收環境是模擬生產環境，測試數據力求與生產環境保持一樣。

壓力測試

當整體功能測試完畢后，如果該功能有性能指標的話，測試童鞋會對功能進行壓力測試（壓力測試工具例如：jmeter等），如有問題可以協調運維童鞋和開發童鞋來處理。

迭代上線

當功能測試和壓力測試都通過后，測試童鞋發送測試結果郵件，項目經理發送上線郵件，郵件包括：上線時間點、上線內容、上線計劃、上線人員、值班人員等。