在當今數字化浪潮中，軟件開發(fā)不僅是技術領域的核心驅動力，更是企業(yè)創(chuàng)新與商業(yè)成功的戰(zhàn)略支點。特別是軟件定義汽車的時代，軟件開發(fā)的規(guī)范化管理成為車企的難言之痛：軟件版本如此多，如何測試？全量測試還是采樣測試？軟件版本發(fā)布如何管控？軟件質量如何保障？軟件功能為什么總是趕不上造車的節(jié)奏？軟件是如何集成的？敏捷會讓車企的軟件開發(fā)一夜之間發(fā)生神奇的變化？….
本篇文章以科普的方式探討軟件開發(fā)理論基礎、關鍵模型、實戰(zhàn)技巧以及組織與人才發(fā)展等重要議題，旨在為讀者提供一幅全景式的軟件開發(fā)導圖。
一、軟件開發(fā)基石：軟件開發(fā)生命周期模型的選擇
軟件開發(fā)生命周期模型是組織軟件開發(fā)活動的框架，它定義了開發(fā)過程中的階段、順序、迭代方式以及各階段間的關聯(lián)（見圖1）。
圖1
軟件開發(fā)生命周期模型，大家耳熟能詳的是經典的瀑布模型和敏捷開發(fā)模型。
瀑布模型：
瀑布模型遵循嚴格的線性順序，從需求分析到詳細設計，再到編碼、測試和維護，每個階段必須在前一階段完全完成后才能開始。瀑布模型適用于需求穩(wěn)定、技術路徑清晰的項目，但其僵化性可能導致應對變化的能力較弱，一旦前期需求定義有誤，后續(xù)階段修正的成本極高。
關于瀑布模型，我們需要知道，目前看到的瀑布模型（見圖2）更多是停留在了理論模型基礎之上。實際上，在1980s, Fred Brooks, 著名的產品開發(fā)暢銷書《人月神話》作者，圖靈獎獲得者，在NASA內部會議上指出，“在超過370億美金的投資項目中，只有2%的項目使用了純粹的瀑布模型，75%的項目或夭折或沒有使用.”
圖2
在現實的世界里，更多的是采用了基于瀑布模型演化的進化模型，如螺旋模型、V模型等。他們都融合了瀑布模型的結構化特點與迭代思想。螺旋模型特別適用于高風險項目，通過反復的風險評估和原型迭代降低不確定性；而V模型（見圖3）強調開發(fā)與測試的對應關系，確保每個階段的驗證與確認工作緊密相連。
V模型成為了產品工程，特別是軟硬一體的嵌入式產品開發(fā)的核心骨架，也是產品開發(fā)使用最為廣泛的模型。像汽車行業(yè)的ASPICE標準、功能安全的ISO26262標準、信息安全的ISO21434標準，基本都是根據V模型制定了相應的規(guī)范要求。
圖3
敏捷模型：
敏捷開發(fā)模型則以快速響應變化為宗旨，倡導迭代開發(fā)和持續(xù)集成。它強調團隊協(xié)作、用戶參與以及適應需求的靈活性，通過短周期的迭代（如Scrum中的Sprint）快速產出可用軟件，并根據反饋進行調整。敏捷模型更多地關注了軟件開發(fā)過程中的工程實踐，對于軟件交付后的運營提及不多。交付后的管理更多的還是采用傳統(tǒng)的軟件生命周期管理的模式。
敏捷軟件開發(fā)模型同樣存在多種實操模型，例如XP、FDD，等。
目前應用最廣的還是團隊級敏捷SCRUM模型（見圖4）
圖4
敏捷開發(fā)在實際落地過程中有兩種具體的項目管理方式：基于時間盒的迭代計劃（見圖5）和基于流的迭代計劃（見圖6）。采用不同的迭代計劃，將決定了敏捷項目每個沖刺（SPRINT）的交付內容。我們需要注意的是，因為產品形態(tài)及產品技術架構的復雜度不同，組織架構的不同，如果迭代規(guī)劃方式選擇與之不匹配，敏捷反而會引入更多的混亂和內卷。
例如，如果產品是單一架構的（monolithic Architecture）且功能依賴多，如果采用時間盒的迭代規(guī)劃方式，會出現待開發(fā)的新功能不得不削足適履，進行功能分拆用戶故事，確保能在一個時間盒的窗口交付，反而導致大量的模塊之間的相互依賴，交易成本（Transaction Cost）劇升，協(xié)調工作冗長。從系統(tǒng)論的維度看下來，反而是降低了效率。針對這種情況，要么是改變時間盒的跨度，要么是采用基于流的迭代工作模式。
圖5 （來源：From Prince2 Agile）
圖6（來源：From Prince2 Agile）
軟件開發(fā)的模型選擇：
“There's no singular technique or process that will bring about significant improvements in software development productivity”
- No Silver Bullet—Essence and Accidents of Software Engineering
Gerald Weinberg, Fred Brooks, and Grady Booch
面臨亂花漸欲迷人眼以及病急亂投醫(yī)的汽車軟件開發(fā)，到底如何選擇自己的軟件開發(fā)模式呢？正如Fred Brooks所言，沒有單一技術或模型能夠顯著提成軟件開發(fā)效率。我們需要的是因地制宜，選擇適合自己組織和產品屬性的研發(fā)活動的模型。
在實際工作中，我們應該且必須學以致用，靈活適配合適的軟件開發(fā)模型，而不是簡單地照貓畫虎，仿照各種敏捷框架，如站會、結對編程......（題外話：其實，適配性（Adapability）才是業(yè)務敏捷的精髓所在）。
不管選擇何種開發(fā)模型，其核心目的是更快、更好地交付客戶價值和業(yè)務價值。具體來講，可以基于Stacey矩陣，選擇合適的開發(fā)模型（圖7）。當然，除了Stacey矩陣提供的需求確定性和技術確定性的兩個維度外，還需要考慮團隊的成熟度，團隊成員的技能經驗，工作地點分布，團隊規(guī)模以及組織文化等因素。
圖7
二、需求分析與架構設計的藝術
軟件開發(fā)始于需求的獲取與需求開發(fā)的過程（通常將這個過程稱為需求工程階段）。需求的獲取主要是從市場需求、用戶需求、業(yè)務等維度展開，理解并分析企業(yè)所在的行業(yè)、國家、地區(qū)適用的法律法規(guī)等，綜合定義軟件產品的需求。
近幾年來，隨著國內互聯(lián)網造車的興起，互聯(lián)網用戶需求分析的工具也逐步引入到垂直行業(yè)，也成為國內傳統(tǒng)造車企業(yè)紛紛攘攘去學習的重心。但從第一性原理來看，需求獲取的原理沒有改變，變化的是傳統(tǒng)企業(yè)缺少需求獲取的數字化手段，缺少人物畫像的細節(jié)管控。
需求獲取的方法手段很多，我們總結如圖8所示。
圖8
在對軟件產品功能進行定義的過程中，往往是綜合采用多種方法，確保功能能夠滿足最大數量的用戶期望。同時，我們要關注，對于ToC業(yè)務與ToB業(yè)務的需求獲取方法，也存在著差異。無論是從調研對象，調研數量以及調研方法，在實際過程中，要注重理論與實踐的結合。
這里，特別給大家推薦一個用來識別或改進產品可用性功能需求（Usability）的強大工具–用戶歷程地圖（題外話：對于其他如非功能性需求的定義與改進，建議采用其他工具方法）。圖9展示了對電車用戶充電活動的用戶歷程地圖，通過一張紙，可以清晰地將產品功能的優(yōu)劣以及待創(chuàng)新的功能點描述清楚。
圖9
需求獲取只是開啟了整個軟件開發(fā)的序幕。我們下一步要做的是需求的確認。需求的確認，是確保軟件產品的開發(fā)“做正確的事”。需求確認的方法包括了VOC，焦糖布丁法，Y分析法，數據分析法等等。
為什么要進行需求的確認呢？其實，這涉及到了人類認知的過程，如圖10所示，當我們看到現實的人形機器人圖片時，我們會根據自己的認知(Perception)和我們個人的知識（Knowledge）對其進行描述。然后，我們將我們自己腦海里，經過自己認知過濾過的圖片，用自己的知識，包括文字語言對其進行描述，這個過程，將不可避免的引入人為的錯誤。所以，在專業(yè)的產品研發(fā)環(huán)境中，我們意識到這個人類認知的過程偏差，所以需要建立規(guī)范的工具方法，如需求文檔的評審、需求撰寫的規(guī)范等，作為“獲取正確需求”的底線保障，確保最大可能地不失真。而敏捷思想里強調的“客戶合作勝于客戶合同”，也正是基于這個不可更改的事實做出的更合理的過程建議。
圖10
需求的開發(fā)包括需求分析與需求的分解與分配的過程。它是軟件產品開發(fā)“正確做事”的過程。這個過程可以使用類似FAST功能分析圖、EFFBD圖、UML建模或者其他建模工具實現，也可以使用其它不同的工具方法，如KJ法、KANO法、QFD法、Pugh矩陣法等等，幫助我們有效工作。
需求開發(fā)從產品定義語境出發(fā)，逐步細化分解功能，最后分配到子系統(tǒng)和模塊。這個過程是用戶可見的功能和可感知的非功能性期望，轉化為我們軟件產品能力的過程。如果是0到1的產品開發(fā)，這個過程與產品架構設計交互迭代，最終形成產品的雛形；如果是基于原有產品架構的功能增加，則更多的工作是基于原有架構進行需求分配的過程。當然，不排除原有系統(tǒng)需要重構，才能滿足客戶的功能要求的情況。
而架構設計則是將技術需求轉化為系統(tǒng)的藍圖，涉及功能模型定義、架構評估方法選擇、物理架構布局等多個環(huán)節(jié)。軟件產品常見的技術架構包括了C/S架構、MVC架構、分層的SOA架構等。但具體的架構設計，要考慮的不僅關乎技術實現，更是一種權衡藝術（Trade-Off），需要在功能、成本、時間、用戶期望等多種因素間尋求最佳平衡。
如圖11，當面對客戶“過河”的需求，架構設計可能需要考慮橋梁、船只、潛水艇，飛機等多種解決方案，每種方案背后代表了不同的技術復雜度、投資規(guī)模與時間周期，系統(tǒng)架構就是需要在不同的解決方案中選擇最合適的，而不僅僅是技術最優(yōu)的。
圖11
在架構設計過程中，可以運用啟發(fā)式問題法、KJ法、QFD等工具進行評估與決策，有助于識別最合適的架構。同時，評估軟件架構的有效性，還可以通過創(chuàng)建原型、迭代開發(fā)、模型模擬等方式獲取直觀反饋，必要時引入量化指標進行深度分析。
康威定律揭示了一個重要規(guī)律：軟件架構往往反映出組織內部的結構。這意味著，良好的組織設計有助于催生高效、協(xié)調的軟件架構，反之亦然。因此，在軟件開發(fā)過程中，應充分考慮組織架構對技術實現的影響，確保架構設計既能滿足功能需求，又能順應組織協(xié)作模式。
三、軟件編碼與測試：質量之盾
軟件編碼是將設計轉化為可執(zhí)行代碼的過程，需要遵循相應的編程語言規(guī)范和組織內部編碼標準（例如，谷歌C++代碼規(guī)范：Google_Cpp_Style_guide_CN.pdf (sosohu.github.io)），輔以靜態(tài)代碼掃描、動態(tài)測試及代碼評審等工作，確保代碼質量。
伴隨著AIGC的泛化，AI 輔助編碼和代碼評審也逐步成為現實，比如Github Copilot X，可以協(xié)助程序員實現結對編程。同樣，類似ChatGPT，也可以幫助我們實現代碼評審的工作。例如，我們把下面這段冒泡算法的C代碼（圖12）輸送給ChatGPT，GPT會給出非常中肯的評審建議以及重構后的代碼，大大減少了代碼評審的工作量。
圖12
圖13是ChatGPT重構后的代碼。GPT的反饋如下。他不僅僅反饋了代碼的邏輯錯誤，對程序的性能也給出了建議（第2條反饋）
-
冒泡排序算法的內層循環(huán)條件for (j = 0; j < len - 1 - i; j++)中的len - 1 - i可能會導致數組越界。應該將內層循環(huán)條件修改為for (j = 0; j < len - 1; j++)。
- 在冒泡排序算法中，如果數組已經是有序的，仍會執(zhí)行完所有的比較和交換操作，造成了性能上的浪費。可以在內層循環(huán)中增加一個判斷條件，如果沒有發(fā)生交換，即可提前退出循環(huán)。
圖13
需要注意的是目前GPT仍然是概率算法，他的反饋需要一定的人工復核，確保剔除AI給出的噪音反饋。
圖14
測試則是軟件質量的守護神，涵蓋單元測試、集成測試、功能測試、系統(tǒng)測試及驗收測試等不同層次，目的是盡早發(fā)現問題、減少后期修復成本、確保軟件符合客戶需求與期望。無論是在V模型或者敏捷開發(fā)模型中，軟件測試活動的目的是一致的，而測試活動貫穿整個開發(fā)周期（圖14所示的V模型）。早期集成測試能有效縮短交付周期，提高客戶滿意度。
圖15
測試執(zhí)行過程從時間順序上可以分為三大部分：單元測試，集成與功能測試和系統(tǒng)驗證與驗收測試（圖15）。單元測試聚焦單個代碼單元的功能正確性；集成與功能測試檢查模塊間交互與整體功能完整性；系統(tǒng)與驗收測試則驗證軟件系統(tǒng)在真實環(huán)境下的表現是否滿足需求。
通過及早發(fā)現問題，測試不僅能節(jié)約成本，還能提升軟件的穩(wěn)定性和可靠性，為市場成功奠定堅實基礎。在實際操作過程中，無論是敏捷或是V模型，測試過程并沒有這么嚴格的順序區(qū)分，往往是循環(huán)迭代的反復過程。對于如何確保已經驗證的功能仍然是可信的，往往是需要經驗和智慧的積累。
關于軟件測試，我們必須清晰地認識到“測試不是銀彈。窮盡測試是不可能也不現實的”。所以，端到端的軟件質量保障，從需求到設計，從編碼到測試，全鏈路的保障才是我們需要竭盡全力的目標。
圖16
伴隨著AGI及數字化技術的發(fā)展，測試技術手段也在日益改進，新的測試技術開始逐步開始向RPA，AI賦能的測試手段方向發(fā)展（見圖16）。
而對汽車行業(yè)軟件開發(fā)而言，自動化測試技術、RPA、AI、新的應用場景的測試也慢慢開始滲透，成為測試團隊的新挑戰(zhàn)。
四、軟件發(fā)布：舞動的韻律
軟件發(fā)布的全過程是一個嚴謹有序且不斷迭代前行的。進入開發(fā)階段后，采用CI/CD（持續(xù)集成/持續(xù)部署）的實踐，包括代碼提交、規(guī)則檢查、代碼評審、預編譯、軟件包構建、內部發(fā)布、測試驗證以及對外發(fā)布等一整套流程，確保軟件質量的持續(xù)性和穩(wěn)定性。在這一過程中，構建Sanity、自動化測試以及各類環(huán)境下的驗證是必不可少的環(huán)節(jié)（見圖17）。CICD在軟件開發(fā)全生命周期中體現的核心思想是快速反饋、頻繁交付和可靠質量。通過自動化構建和部署流水線，讓開發(fā)團隊能夠迅速響應變化，減少人工干預帶來的延誤和錯誤，確保軟件在各個階段都能高效地完成集成、測試和部署，最終達到高質量、高效率的產品交付目標。
圖17
在軟件的維護階段，針對存在的問題和錯誤進行及時修復，根據用戶反饋和市場需求持續(xù)進行功能改進與性能優(yōu)化。對于汽車行業(yè)的嵌入式軟件而言，還涉及到與硬件結合的復雜集成測試，以及類似FOTA，SOTA（空中下載技術）更新等特殊的軟件升級場景。此外，汽車行業(yè)軟件發(fā)布遵循項目生命周期的各個階段，如工程樣車（EP）、產品及過程驗證（PPV）、預試生產（PP）、試生產（P），直至正式投產（SOP）。在整個過程中，項目質量管理扮演著關鍵角色，不僅要保證軟件產品的質量和性能，還要確保軟件開發(fā)與發(fā)布過程符合既定的質量標準和國標、企標。
五、研發(fā)基礎：技術研發(fā)與產品研發(fā)的“雙輪驅動”
技術研發(fā)與產品研發(fā)雖同屬創(chuàng)新范疇，但各有側重。
- 技術研發(fā)著眼于長遠，追求技術先進性與知識積累，目標是開發(fā)出具有競爭優(yōu)勢的技術成果，為未來的市場化產品提供技術支持（TPF過程）。
- 產品研發(fā)更直接面向市場，關注產品創(chuàng)新與商業(yè)化進程，旨在快速推出符合用戶需求的新產品，創(chuàng)造價值與利潤（PMF過程）。
如圖18所示，技術研發(fā)和產品研發(fā)在生命周期、市場定位、技術難度、管理手段等方面存在顯著差異，但均需緊密圍繞用戶需求展開。技術研發(fā)往往領先數年，承擔探索未知、孵化前沿技術的角色；產品研發(fā)則緊跟市場脈搏，力求在短期內實現產品的更新?lián)Q代。二者相互依賴，共同推動企業(yè)技術創(chuàng)新與產品迭代的良性循環(huán)。當然，因為技術研發(fā)與產品研發(fā)的定位不同，企業(yè)在實際管理過程中，不能把產品研發(fā)的管理手段，比如某款車型研發(fā)，簡單地套用到技術研發(fā)管理中（比如，某款新材料、新動力電池或平臺架構等）。
圖18
六、研發(fā)基礎：組織與人才發(fā)展的軟實力構建
軟件開發(fā)的成功離不開強大的組織支撐與人才隊伍建設。
研發(fā)組織應注重能力建設，涵蓋組織架構設計、業(yè)務流程梳理、數字化工具鏈集成（如禪道管理軟件，CICD工具鏈，云端軟件DevOPS工具鏈等）、知識管理、信息安全等多個維度。同時，建立健全績效考核與激勵機制，確保人才的成長與發(fā)展與組織戰(zhàn)略目標相一致。
人才發(fā)展方面，提供管理與專業(yè)技術兩條晉升通道，滿足不同類型人才的職業(yè)發(fā)展需求。管理路線涵蓋研發(fā)主管、經理、總監(jiān)等。專業(yè)技術路線包括了高級項目經理、產品經理、質量經理等專業(yè)角色；專業(yè)技術路線還包括了技術專家、高級專家、資深專家等技術精英。通過明確的職業(yè)發(fā)展路徑，激發(fā)人才潛能，形成穩(wěn)定且富有活力的人才梯隊，避免“重技術，輕職業(yè)化”的問題。根據PRTM的產品開發(fā)能力成熟度評估模型（圖19），軟件開發(fā)組織的成熟度可以分為5級。
建議優(yōu)秀的車企應該向成熟度4級（Stage 3）努力，提升組織的核心競爭力，確保打贏汽車智能化和汽車產業(yè)數字化這一仗！
圖19 （Source：PRTM 產品開發(fā)能力）
結束：本文為我們勾勒出一幅從理論到實踐、從模型選擇到組織構建的全景圖。無論是初涉軟件行業(yè)的新人，還是尋求優(yōu)化研發(fā)流程的企業(yè)管理者，都可以從中汲取寶貴的知識與經驗，助力在瞬息萬變的科技浪潮中穩(wěn)操勝券。軟件開發(fā)并非孤立的編程活動，而是涵蓋了需求分析、架構設計、編碼實踐、測試保障、技術研發(fā)、產品研發(fā)、組織管理與人才培育等多元要素的系統(tǒng)工程。唯有深入理解并妥善駕馭這些要素，方能在激烈的市場競爭中立于不敗之地。
轉自水輕言
