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