引言

戰(zhàn)國·鄒·孟軻《孟子·離婁上》：“離婁之明，公輸子之巧，不以規(guī)矩，不能成方圓?！?/span>

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

需求確定

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

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

確定技術方案

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

組織需求評審

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

編寫概要設計

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

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

概要評審

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

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

功能開發(fā)

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

功能演示

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

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

代碼review

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

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

測試用例評審

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

冒煙測試

在轉測前，開發(fā)童鞋根據評審后的測試用例評審，找到高優(yōu)先級的測試用例在測試環(huán)境進行自測，確定是否成功。

測試環(huán)境轉測

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

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

驗收環(huán)境轉測

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

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

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

壓力測試

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

迭代上線

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