在當今數字化浪潮中，軟件開發不僅是技術領域的核心驅動力，更是企業創新與商業成功的戰略支點。特別是軟件定義汽車的時代，軟件研發的規范化管理成為車企的難言之痛：軟件版本如此多，如何測試？全量測試還是采樣測試？軟件版本發布如何管控？軟件質量如何保障？軟件功能為什么總是趕不上造車的節奏？軟件是如何集成的？敏捷會讓車企的軟件開發一夜之間發生神奇的變化？….
本篇文章依據《軟件研發全攻略》這份詳實的教程資料，為您揭開軟件開發的神秘面紗，以科普的方式探討其理論基礎、關鍵模型、實戰技巧以及組織與人才發展等重要議題，旨在為讀者提供一幅全景式的軟件研發導圖。
一、軟件開發基石：軟件開發生命周期模型的選擇
軟件開發生命周期模型是組織軟件研發活動的框架，它定義了開發過程中的階段、順序、迭代方式以及各階段間的關聯 （見圖1）。
圖1
軟件開發生命周期模型，大家耳熟能詳的是經典的瀑布模型和敏捷開發模型。
瀑布模型：
瀑布模型遵循嚴格的線性順序，從需求分析到詳細設計，再到編碼、測試和維護，每個階段必須在前一階段完全完成后才能開始。瀑布模型適用于需求穩定、技術路徑清晰的項目，但其僵化性可能導致應對變化的能力較弱，一旦前期需求定義有誤，后續階段修正的成本極高。
關于瀑布模型，我們需要知道，目前看到的瀑布模型（見圖2）更多是停留在了理論模型基礎之上。實際上，在1980s, Fred Brooks, 著名的產品開發暢銷書《人月神話》作者，圖靈獎獲得者，在NASA內部會議上指出，“在超過370億美金的投資項目中，只有2%的項目使用了純粹的瀑布模型，75%的項目或夭折或沒有使用.”
圖2
在現實的世界里，更多的是采用了基于瀑布模型演化的進化模型，如螺旋模型，V模型等。他們都融合了瀑布模型的結構化特點與迭代思想。螺旋模型特別適用于高風險項目，通過反復的風險評估和原型迭代降低不確定性；而V模型（見圖3）強調開發與測試的對應關系，確保每個階段的驗證與確認工作緊密相連。V模型成為了產品工程，特別是軟硬一體的嵌入式產品開發的核心骨架，也是產品開發使用最為廣泛的模型。像汽車行業的ASPICE標準，功能安全的ISO26262標準，信息安全的ISO21434標準，基本都是根據V模型制定了相應的規范要求。
圖3
敏捷模型：
敏捷開發模型則以快速響應變化為宗旨，倡導迭代開發和持續集成。它強調團隊協作、用戶參與以及適應需求的靈活性，通過短周期的迭代（如Scrum中的Sprint）快速產出可用軟件，并根據反饋進行調整。敏捷模型更多地關注了軟件開發過程中的工程實踐，對于軟件交付后的運營提及不多。交付后的管理更多的還是采用傳統的軟件生命周期管理的模式。
敏捷軟件開發模型同樣存在多種實操模型，例如XP，FDD，等。目前應用最廣的還是團隊級敏捷SCRUM模型（見圖4）
圖4
敏捷開發在實際落地過程中有兩種具體的項目管理方式：基于時間盒的迭代計劃（見圖5）和基于流的迭代計劃（見圖6）。采用不同的迭代計劃，將決定了敏捷項目每個沖刺（SPRINT）的交付內容。我們需要注意的是，因為產品形態及產品技術架構的復雜度不同，組織架構的不同，如果迭代規劃方式選擇與之不匹配，敏捷反而會引入更多的混亂和內卷。
例如，如果產品是單一架構的（monolithic Architecture）且功能依賴多，如果采用時間盒的迭代規劃方式，會出現待開發的新功能不得不削足適履，進行功能分拆用戶故事，確保能在一個時間盒的窗口交付，反而導致大量的模塊之間的相互依賴，交易成本（Transaction Cost）巨升，協調工作冗長，從系統論的維度看下來，反而是降低了效率。針對這種情況，要么是改變時間盒的跨度，要么是采用基于流的迭代工作模式。
圖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
面臨亂花漸欲迷人眼以及病急亂投醫的汽車軟件開發，到底如何選擇自己的軟件開發模式呢？正如Fred Brooks所言，沒有單一技術或模型能夠顯著提成軟件開發效率。我們需要的是因地制宜，選擇適合自己組織和產品屬性的研發活動的模型。
在實際工作中，我們應該且必須學以致用，靈活適配合適的軟件開發模型，而不是簡單地照貓畫虎，仿照各種敏捷框架，站會，結對編程，…（題外話：其實，適配性（Adapability）才是業務敏捷的精髓所在）。不管選擇何種開發模型，其核心目的是更快、更好地交付客戶價值和業務價值。具體來講，可以基于Stacey矩陣，選擇合適的開發模型（圖7）。當然，除了Stacey矩陣提供的需求確定性和技術確定性的兩個維度外，還需要考慮團隊的成熟度，團隊成員的技能經驗，工作地點分布，團隊規模以及組織文化等因素。
圖7
二、需求分析與架構設計的藝術
軟件開發始于需求的獲取與需求開發的過程（通常將這個過程稱為需求工程階段）。需求的獲取主要是從市場需求，用戶需求，業務等維度，理解并分析企業所在的行業，國家，地區，適用的法律法規等各個維度，定義軟件產品的需求。
近幾年來，隨著國內互聯網造車的興起，互聯網用戶需求分析的工具也逐步引入到垂直行業，也成為國內傳統造車企業紛紛攘攘去學習的重心。但從第一性原理來看，需求獲取的原理沒有改變，變化的是傳統企業缺少需求獲取的數字化手段，缺少人物畫像的細節管控。
需求獲取的方法手段很多，我們總結如圖8所示。
圖8
在對軟件產品功能進行定義的過程中，往往采用的是多種方法的綜合應用，確保功能能夠滿足最大數量的用戶期望。同時，我們要關注，對于TOC業務與ToB業務的需求獲取方法，也存在著差異。無論是從調研對象，調研數量以及調研方法，在實際過程中，要注重理論與實踐的結合。
這里，特別給大家推薦一個用來識別或改進產品可用性功能需求（Usability）的強大工具–用戶歷程地圖（題外話：對于其他如非功能性需求的定義與改進，建議采用其他工具方法）。圖9展示了對電車用戶充電活動的用戶歷程地圖，通過一張紙，可以清晰地將產品功能的優劣以及待創新的功能點描述清楚。
圖9
需求獲取只是開啟了整個軟件開發的序幕。我們下一步要做的是需求的確認。需求的確認，是確保軟件產品的開發“做正確的事”。需求確認的方法包括了VOC，焦糖布丁法，Y分析法，數據分析法等等。
為什么要進行需求的確認呢？其實，這涉及到了人類認知的過程，如圖10所示，當我們看到現實的人形機器人圖片時，我們會根據自己的認知(Perception)和我們個人的知識（Knowledge）對其進行描述。然后，我們將我們自己腦海里，經過自己認知過濾過的圖片，用自己的知識，包括文字語言對其進行描述，這個過程，將不可避免的引入人為的錯誤。所以，在專業的產品研發環境中，我們意識到這個人類認知的過程偏差，所以需要建立規范的工具方法，如需求文檔的評審，需求撰寫的規范，等，作為“獲取正確需求”的底線保障，確保最大可能地不失真。而敏捷思想里強調的“客戶合作勝于客戶合同”，也正是基于這個不可更改的事實做出的更合理的過程建議。
圖10
需求的開發包括需求分析與需求的分解與分配的過程。它是軟件產品開發“正確做事”的過程。這個過程可以使用類似FAST功能分析圖，EFFBD圖，UML建?；蛘咂渌９ぞ邔崿F。也可以使用其它不同的工具方法，如KJ法，KANO法，QFD法，Pugh 矩陣法等等，幫助我們有效工作。
需求開發從產品定義語境出發，逐步細化分解功能，最后分配到子系統和模塊。這個過程是用戶可見的功能和可感知的非功能性期望，轉化為我們軟件產品能力的過程。如果是0到1的產品開發，這個過程與產品架構設計交互迭代，最終形成產品的雛形；如果是基于原有產品架構的功能增加，則更多的工作是基于原有架構進行需求分配的過程。當然，不排除原有系統需要重構，才能滿足客戶的功能要求的情況。
而架構設計則是將技術需求轉化為系統的藍圖，涉及功能模型定義、架構評估方法選擇、物理架構布局等多個環節。軟件產品常見的技術架構包括了C/S架構，MVC架構，分層的SOA架構等。但具體的架構設計，要考慮的不僅關乎技術實現，更是一種權衡藝術（Trade -Off），需要在功能、成本、時間、用戶期望等多種因素間尋求最佳平衡。如圖11，當面對客戶“過河”的需求，架構設計可能需要考慮橋梁、船只、潛水艇，飛機等多種解決方案，每種方案背后代表了不同的技術復雜度、投資規模與時間周期，系統架構就是需要在不同的解決方案中選擇最合適的，而不僅僅是技術最優的。
圖11
在架構設計過程中，可以運用啟發式問題法、KJ法、QFD等工具進行評估與決策，有助于識別最合適的架構。同時，評估軟件架構的有效性，還可以通過創建原型、迭代開發、模型模擬等方式獲取直觀反饋，必要時引入量化指標進行深度分析。
康威定律揭示了一個重要規律：軟件架構往往反映出組織內部的結構。這意味著，良好的組織設計有助于催生高效、協調的軟件架構，反之亦然。因此，在軟件開發過程中，應充分考慮組織架構對技術實現的影響，確保架構設計既能滿足功能需求，又能順應組織協作模式。
轉自汽車電子與軟件
