以基線產品開發過程為例
一般情況下，企業開發軟體時會按照基線和定製兩塊並行方式執行專案開發工作。無論什麼公司，都需要遵從一套成熟的產品研發過程體系，才能做出質量較好的產品。因此，如果出現專案較多的情況，應該合理地安排基線和定製之前的里程碑，讓基線產品能夠儘量多地收集使用者的通用型需求，為定製專案進度實現技術支撐，減少定製專案中大量更改程式碼、需要新增模組情況發生。此外，產品研發過程體系也需要按照業務實際時間要求變化，不要拘泥於一定要按照瀑布方式，或是敏捷方式進行管理，凡事都需要找到契合自己的方式。鞋合不合腳，只有腳知道。
我們這裡以一個基線產品開發過程作為流程解釋基礎，需要注意的是，以下所描述的各個階段，在專案執行前要明確各個階段的目標、指定計劃、及時溝通，並確保各個時期所有成員對專案理解一致。
專案啟動會
專案啟動會的目標是明確該產品開發專案的目標。目標不是孤立存在的，目標與計劃相輔相成，目標指導計劃，計劃的有效性影響著目標的達成。所以在執行目標的時候，考慮清楚自己的行動計劃，怎麼做才能更有效地完成目標，是每個人都要詳情清楚的問題，否則，目標越是不清晰或是過高，都會影響專案的實際結果。
專案啟動會需要說明專案目標、階段劃分、組織結構、管理流程等關鍵事項，並將這些內容寫入 PPT（最好是有固定格式和範文，讓團隊內部或者公司內部共同遵守規範），需要大家達成一致。對於關鍵角色任命，事前也需要聽取相關領導和專案主要干係人的意見。
使用者需求
軟體開始開發前需要確定代價和所獲得價值的對比，也就是 ROI（Return On investment），一旦確定需要建立，就需要安排一系列的資源來支撐這個軟體的生存。這是需求的最原始描述。
為什麼既要有使用者需求，也要有產品需求？
因為兩者是有差異的，使用者需求由使用者提出，對技術一般不描述，只描述產品目標。產品需求是根據使用者需求轉化而來的技術實現需求，需要針對使用者提出的產品目標進行細分，總結出具體的每一個功能點，再針對每一個功能點細分為各種不同的操作流程，對每一個操作流程進行技術化定義。
使用者需求和產品需求容易發生不一樣，這是因為雖然大家都在談需求，但是出發點可能不同，造成了雙方關注點和思維方式不同。使用者需求關注的是系統如何支援業務流程，背後的需求是“實現業務目標”。技術人員關注的是合理技術方案，背後的需求是“工作量”、“實現難度”和“系統效能”。
產品需求
我們需要弄清楚產品經理或專案需求提出者為什麼要做這個專案？這是最本質的業務需求。需求分析確定的業務需求，都是從業務需求推匯出來的，都必須為業務需求服務。
產品需求一般包括產品需求規格說明書和產品需求矩陣。產品需求矩陣一般按照子系統、功能集、執行單元的結構列出所有的功能需求，每列則對應每項功能的工作步驟以及每個步驟的工作量。
產品需求寫完後，需要進行評審。在需求評審會上，產品、技術詳細評審需求是否完整，產品功能的正常場景是什麼？是否形成閉環？異常場景是什麼？是否考慮周全？
需求評審後，開發和測試負責人，分別編寫技術方案和測試用例。
技術方案評審，開發負責人拉上涉及到其他系統的負責人一起討論，技術方案中必須要有業務流程圖和時序圖，業務流程圖是為了梳理開發對業務的理解，是否和需求一致。時序圖是了梳理本次需求涉及的系統互動。技術方案評審透過後，確認工作量和交付時間，反饋給產品。
設計階段的目標主要是對待開發系統的構架進行分析和設計，並建立系統構架的基線，以便為之後的實施工作提供一個穩定的基礎。
設計階段包括了系統架構的輸出，一個好的系統架構設計可以幫助人類梳理業務邏輯且抓住核心需求，設計穩定可擴充套件的業務系統，評估業務開發週期和開發成本，有效的規避風險。例如蓋房子的時候得有建築圖紙，有了圖紙，才能核算施工週期。
總體設計是整個系統的框架型設計，意義及其重大，一般情況下不能省略（只有維護專案可以省略總體設計，因為基準專案已經設計完畢），所有的產品開發專案均需要首先進行總體設計，它是設計首要步驟，決不允許本末倒置，不能出現先編碼後設計的情況，這是軟體開發的第二大痛點（第一大是需求不明確、任意變更需求！）。
總體設計分為三個階段：
第一階段：初始設計。在對給定的資料流圖進行復審和精化的基礎上，將其轉化為初始的模組結構圖。
第二階段：精化設計。依據模組“高內聚低耦合”的原則，精化初始的模組結構圖，並設計其中的全域性資料結構和每一模組的介面。
第三階段：設計複審階段，對前兩個階段得到的高層軟體結構進行復審，必要時還可能需要對軟體結構做一些精化工作。
概要設計
概要設計的目的是描述系統的每個模組的內部設計，對總體設計和詳細設計承擔承上啟下的作用。
概要設計按照結構化設計方法進行設計。結構化設計方法的基本思路是：按照問題域，將軟體逐級細化，分解為不必再分解的的模組，每個模組完成一定的功能，為一個或多個父模組服務（即接受呼叫），也接受一個或多個子模組的服務（即呼叫子模組）。模組的概念，和程式語言中的子程式或函式是對應的。
概要設計階段把軟體按照一定的原則分解為模組層次，賦予每個模組一定的任務，並確定模組間呼叫關係和介面。
在這個階段，設計者會大致考慮並照顧模組的內部實現，但不過多糾纏於此。主要集中於劃分模組、分配任務、定義呼叫關係。模組間的介面與傳參在這個階段要制定得十分細緻明確，需要編寫嚴謹的資料字典，避免後續設計產生不解或誤解。概要設計一般不是一次就能做到位，而是反覆地進行結構調整。典型的調整是合併功能重複的模組，或者進一步分解出可以複用的模組。在概要設計階段，應最大限度地提取可以重用的模組，建立合理的結構體系，節省後續環節的工作量。
概要設計文件最重要的部分是分層資料流圖、結構圖、資料字典以及相應的文字說明等。以概要設計文件為依據，各個模組的詳細設計就可以並行展開了。
詳細設計
詳細設計階段就是依據概要設計階段的分解，設計每個模組內的演算法、流程，為每個模組完成的功能進行具體的描述，要把功能描述轉變為精確的、結構化的過程描述。
詳細設計這個階段，各個模組可以分給不同的人去並行設計。設計者的工作物件是一個模組，根據概要設計賦予的區域性任務和對外介面，設計並表達出模組的演算法、流程、狀態轉換等內容。這裡要注意，如果發現有結構調整（如分解出子模組等）的必要，必須返回到概要設計階段，將調整反應到概要設計文件中，而不 能就地解決，不打招呼。詳細設計文件最重要的部分是模組的流程圖、狀態圖、區域性變數及相應的文字說明等。一個模組對應一篇詳細設計文件。
概要設計階段通常得到軟體結構圖，詳細設計階段常用的描述方式有：流程圖、N-S 圖、PAD 圖、虛擬碼等。而詳細設計的目的是描述某一個模組內部的處理流程、開發方法和編碼技巧。一般來說，詳細設計由專案簡介、模組說明（具體說明每一個模組內部的流程、功能、邏輯、消耗以及未解決問題）、介面設計（包括內部介面和外部介面）、資料結構設計（包括物理結構和邏輯結構）、特殊處理等幾個部分構成。軟體的詳細設計，最終是將軟體系統的各個部分的具體設計方法、邏輯、功能採用文字方式進行表述。這樣在實現過程中，編碼人員原則上嚴格按此進行程式碼實現即可。
編寫程式碼
編寫程式碼可以遵循以下幾點原則：
先做核心模組的壓測：很多程式設計師，習慣把東西做完，然後等著快上線的時候才做效能測試，那麼如果前面設計出了問題，這個就很頭大了。當然，後期快上線的時候也要做效能測試，但前期的我認為還是很重要的。當然，做好這一點，需要懂一些業務，你要知道業務壓力在哪裡，業務請求的重心在哪裡，很多時候，產品經理不講，你也要問清楚。
確保過程可控：程式碼執行時一定要保持中間的輸出，比如說，每處理 10 萬條日誌，寫一條狀態日誌，記錄處理的日誌條目數和當前的執行時間。
多打日誌：很多時候，程式碼寫的自己也不是很滿意，比如某個處理效率不夠最佳化，某個處理的方法不夠簡潔，或者擴充套件性比較差，程式碼寫的很弱智，但可能短時間沒有辦法想清楚最合理的解決方案，考慮到上線初期這裡並不是重心所在，所以也不會特意去最佳化它，但這種情況下我往往會留下注釋，並說明下一步最佳化的可能思路是什麼，或者想到的可行方案是什麼。
簡單易懂的邏輯：千萬不要把自己繞進去了，時間一長，誰都看不明白你的邏輯。如果邏輯真的很難在一個函式內完成，嘗試切分。
不要沉迷於框架：框架最大的問題是什麼？是過於繁冗的巢狀。為什麼我一直很煩框架？因為經常遇到需要一秒鐘幾千次請求的處理場景，那麼調優的時候，要從數不清的框架中尋找資料處理的邏輯，尋找效能卡點，可能改動程式碼只有兩行，但是找問題需要兩天。程式設計師記住，你的技術能力絕對不能被框架約束住。
使用熟悉、成熟的技術：很多人根本沒搞明白自己的障礙和問題在哪裡，根本不知道相關技術產品的優勢和劣勢在哪裡，看一堆第三方的資料測評，腦子一熱，去學新技術，然後，掉進坑裡出不來，如果是創業公司，可能專案就死在裡面了。使用新技術前，建議全面瞭解該技術的特徵，適用範圍，以及不適用的範圍。
程式碼稽核
眾所周知，在團隊中進行程式碼審查（Code Review）可以提升程式碼質量，分享專案知識、明確責任，最終達到構建更好的軟體、更好的團隊。
程式碼稽核及其重要，一般來說每週都要做一次程式碼稽核。首先，程式碼稽核有利於你跟蹤專案進展情況，我們能真實地看到手下的人進展如何，並且更早發現他們是否誤入歧途。有時候，手下人會說“完成得差不多了！”，你去看程式碼時發現什麼都沒有或者只是一堆垃圾，諸如此類，總之離完成還很遙遠。在管理中，這種情況是最讓人討厭的，所以我認為程式碼審查是避免這種麻煩的最佳途徑。
單元測試
要認識單元測試，首先要明白什麼是“單元（Unit）”。所謂“單元”指的是程式碼呼叫的最小單位，實際上指的是一個功能塊（Function）或者方法（Method）。所以單元測試指的就是對這些程式碼呼叫單元的測試。
單元測試是一種白盒測試，就是必須要對單元的程式碼細節很清楚才能做的測試。所以，單元測試的編寫和執行都是由軟體工程師來做的。相對於單元測試，還有整合測試。整合測試基本都是黑盒測試，主要是由測試人員根據軟體的功能手冊來進行測試，需要有專門的測試環境配合。整合測試又分功能測試、迴歸測試等。
需要單元測試的程式碼實際上是開發人員自己寫的邏輯，測試邏輯所依賴的環境是否正常不是單元測試的目的。在環境訪問程式碼中引入邏輯，只會讓邏輯更難測試，導致邏輯程式碼無法進行單元測試。因此，可單元測試的程式碼，才能夠採用單元測試。判斷可測試的程式碼還有一個方法，就是看這個方法能否用一個 main 函式直接執行，如果可以的話就是可單元測試的程式碼。可測試的程式碼還有另一個特徵，就是該方法單元的引數，開發人員可以自由模擬，不需要依賴外部環境。
整合測試
整合測試，也叫組裝測試或聯合測試。在單元測試的基礎上，將所有模組按照設計要求組裝成為子系統或系統，進行整合測試。實踐表明，一些模組雖然能夠單獨地工作，但並不能保證連線起來也能正常的工作。一些區域性反映不出來的問題，在全域性上很可能暴露出來。
整合測試是在軟體系統整合過程中所進行的測試，其主要目的是檢查軟體單位之間的藉口是否正確。它根據整合測試計劃 ，一邊將模組或其他模組組合成越來越大的系統，一邊執行該系統，以分析所組成的系統是否正確，各個組成部分是否合拍。整合測試的策略主要有自頂向下和自底向上兩種。也可以理解為在軟體設計單元、功能模組組裝、整合為系統時，對應用系統的各個部件（軟體單元、功能模組介面、連結等）進行的聯合測試，以決定他們能否在一起共同工作，部件可以是程式碼塊、獨立的應用、網路上的客戶端或伺服器端程式。
系統測試
系統測試階段包括系統測試方案及用例編寫、功能性測試、效能測試、穩定性測試。
為了驗證需求分析確定的功能是否齊全並被正確實現，同時還要對安裝、部署、適應性、安全性、介面等非功能性需求進行測試。系統測試也有測試人員負責，應該在需求分析完成後進行設計，在整合測試完成後進行實施。
功能性測試
一般由獨立測試小組採用黑盒方式來測試，主要測試系統是否符合“需求規格說明書”。在經過以上各階段測試確認之後，把系統完整地模擬客戶環境來進行的測試。系統測試是將已經確認的軟體、計算機硬體、外設、網路等其他元素結合在一起，進行資訊系統的各種組裝測試和確認測試，其目的是透過與系統的需求相比較，發現所開發的系統與使用者需求不符或矛盾的地方，從而提出更加完善的方案。
效能測試
驗證系統的穩定性和效率，檢查系統是否滿足規定的效能要求。效能測試通常選擇一些典型的功能，檢驗這些功能在大量使用者同時使用系統時系統是否穩定。效能測試由測試人員負責，可以在系統測試完成後進行，也可以對重要模組先進行效能測試，可以貫穿整個測試周期，目的是儘早發現系統的效能瓶頸並提早解決。
穩定性測試和效能測試都必須等到系統基本沒問題、趨於穩定時再進行才有效果，否則很難順利測下去，出現異常也不能定位究竟是系統架構的問題，還是功能上的缺陷。
穩定性測試（亦可稱可靠性測試）
透過給系統載入一定的業務壓力，讓系統持續執行一段時間（一般為 7x24 小時），檢測系統是否能夠穩定執行。
產品釋出
產品釋出是系統測試結束後的最後一步，通常在軟體產品開發過程中不需要產品試製環節，可以直接上線，只需要系統測試員輸出系統測試報告並批准產品釋出（上線）就可以了。
產品釋出前需要透過產品釋出說明會形式，對整個產品開發過程從立項開始回溯過程，指出整個過程中的不足點，總結經驗，為下一個專案提供經驗案例。這一會議可以透過正式會議形式召開，需要召集產品經理、主要開發人員、測試人員、上級領導等參與，準備充分，盡最大可能說清楚這個產品釋出之後的效果、效益，為上線後的價值評估做準備。這一環節不可缺少，即便在網際網路公司，迭代速度很快的情況下，這一環節也需要滿足。
開發過程覆盤
其實開發過程體系裡並沒有這一過程，但是我個人認為它非常重要。
所有的總結，只有帶著問題去思考才會有收穫，這就是覆盤。不論我說多少，如果沒有過類似的經驗，就很難有很強的共鳴。我覺得看清一個問題最好的方式，就是你曾經處在一個問題的兩個不同的角色中。
總結專案經驗教訓的目的，在於總結問題、分析原因，避免以後犯同樣的錯誤，而不是追究誰的責任。
假設一個需求理解的缺陷，如果在需求階段發現，修改一下可能只要一個小時，但是如果到了設計完成時發現這個缺陷，因為涉及的人員、文件增多，估計要一天時間，而如果等到程式碼都編寫完成時才發現這個缺陷，可能需要十天八天了。如果缺陷沒被發現，而是直接到了生產系統中呢？這就不是工作量的問題了，估計損失就難以估計了。在質量管理的理論中，缺陷每延遲一個階段被發現，修復的代價就要乘上十倍。
寫在最後
敏捷開發、極限開發等等模型是為了解決需求不明確、時間緊迫情況下的快速迭代，而不是為了從根本上否定研發流程，該設計還是要設計，只是將生命週期進行切分，將過程橫向切分為若干個週期。軟體開發是一門工程性要求很嚴謹的學科，讓我們堅持嚴謹的態度、高效的工作方式，打造高可用、高質量的軟體產品。
本作品採用《CC 協議》，轉載必須註明作者和本文連結