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