在當今數(shù)字化浪潮中，軟件開發(fā)不僅是技術(shù)領(lǐng)域的核心驅(qū)動力，更是企業(yè)創(chuàng)新與商業(yè)成功的戰(zhàn)略支點。特別是軟件定義汽車的時代，軟件研發(fā)的規(guī)范化管理成為車企的難言之痛：軟件版本如此多，如何測試？全量測試還是采樣測試？軟件版本發(fā)布如何管控？軟件質(zhì)量如何保障？軟件功能為什么總是趕不上造車的節(jié)奏？軟件是如何集成的？敏捷會讓車企的軟件開發(fā)一夜之間發(fā)生神奇的變化？….

  本篇文章依據(jù)《軟件研發(fā)全攻略》這份詳實的教程資料，為您揭開軟件開發(fā)的神秘面紗，以科普的方式探討其理論基礎、關(guān)鍵模型、實戰(zhàn)技巧以及組織與人才發(fā)展等重要議題，旨在為讀者提供一幅全景式的軟件研發(fā)導圖。

  一、軟件開發(fā)基石：軟件開發(fā)生命周期模型的選擇

  軟件開發(fā)生命周期模型是組織軟件研發(fā)活動的框架，它定義了開發(fā)過程中的階段、順序、迭代方式以及各階段間的關(guān)聯(lián) （見圖1）。

圖1

  軟件開發(fā)生命周期模型，大家耳熟能詳?shù)氖墙?jīng)典的瀑布模型和敏捷開發(fā)模型。

瀑布模型：

  瀑布模型遵循嚴格的線性順序，從需求分析到詳細設計，再到編碼、測試和維護，每個階段必須在前一階段完全完成后才能開始。瀑布模型適用于需求穩(wěn)定、技術(shù)路徑清晰的項目，但其僵化性可能導致應對變化的能力較弱，一旦前期需求定義有誤，后續(xù)階段修正的成本極高。

  關(guān)于瀑布模型，我們需要知道，目前看到的瀑布模型（見圖2）更多是停留在了理論模型基礎之上。實際上，在1980s, Fred Brooks, 著名的產(chǎn)品開發(fā)暢銷書《人月神話》作者，圖靈獎獲得者，在NASA內(nèi)部會議上指出，“在超過370億美金的投資項目中，只有2%的項目使用了純粹的瀑布模型，75%的項目或夭折或沒有使用.”

圖2

  在現(xiàn)實的世界里，更多的是采用了基于瀑布模型演化的進化模型，如螺旋模型，V模型等。他們都融合了瀑布模型的結(jié)構(gòu)化特點與迭代思想。螺旋模型特別適用于高風險項目，通過反復的風險評估和原型迭代降低不確定性；而V模型（見圖3）強調(diào)開發(fā)與測試的對應關(guān)系，確保每個階段的驗證與確認工作緊密相連。V模型成為了產(chǎn)品工程，特別是軟硬一體的嵌入式產(chǎn)品開發(fā)的核心骨架，也是產(chǎn)品開發(fā)使用最為廣泛的模型。像汽車行業(yè)的ASPICE標準，功能安全的ISO26262標準，信息安全的ISO21434標準，基本都是根據(jù)V模型制定了相應的規(guī)范要求。

圖3

敏捷模型：

  敏捷開發(fā)模型則以快速響應變化為宗旨，倡導迭代開發(fā)和持續(xù)集成。它強調(diào)團隊協(xié)作、用戶參與以及適應需求的靈活性，通過短周期的迭代（如Scrum中的Sprint）快速產(chǎn)出可用軟件，并根據(jù)反饋進行調(diào)整。敏捷模型更多地關(guān)注了軟件開發(fā)過程中的工程實踐，對于軟件交付后的運營提及不多。交付后的管理更多的還是采用傳統(tǒng)的軟件生命周期管理的模式。

  敏捷軟件開發(fā)模型同樣存在多種實操模型，例如XP，FDD，等。目前應用最廣的還是團隊級敏捷SCRUM模型（見圖4）

圖4

  敏捷開發(fā)在實際落地過程中有兩種具體的項目管理方式：基于時間盒的迭代計劃（見圖5）和基于流的迭代計劃（見圖6）。采用不同的迭代計劃，將決定了敏捷項目每個沖刺（SPRINT）的交付內(nèi)容。我們需要注意的是，因為產(chǎn)品形態(tài)及產(chǎn)品技術(shù)架構(gòu)的復雜度不同，組織架構(gòu)的不同，如果迭代規(guī)劃方式選擇與之不匹配，敏捷反而會引入更多的混亂和內(nèi)卷。

  例如，如果產(chǎn)品是單一架構(gòu)的（monolithic Architecture）且功能依賴多，如果采用時間盒的迭代規(guī)劃方式，會出現(xiàn)待開發(fā)的新功能不得不削足適履，進行功能分拆用戶故事，確保能在一個時間盒的窗口交付，反而導致大量的模塊之間的相互依賴，交易成本（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ā)活動的模型。

  在實際工作中，我們應該且必須學以致用，靈活適配合適的軟件開發(fā)模型，而不是簡單地照貓畫虎，仿照各種敏捷框架，站會，結(jié)對編程，…（題外話：其實，適配性（Adapability）才是業(yè)務敏捷的精髓所在）。不管選擇何種開發(fā)模型，其核心目的是更快、更好地交付客戶價值和業(yè)務價值。具體來講，可以基于Stacey矩陣，選擇合適的開發(fā)模型（圖7）。當然，除了Stacey矩陣提供的需求確定性和技術(shù)確定性的兩個維度外，還需要考慮團隊的成熟度，團隊成員的技能經(jīng)驗，工作地點分布，團隊規(guī)模以及組織文化等因素。

圖7

二、需求分析與架構(gòu)設計的藝術(shù)

  軟件開發(fā)始于需求的獲取與需求開發(fā)的過程（通常將這個過程稱為需求工程階段）。需求的獲取主要是從市場需求，用戶需求，業(yè)務等維度，理解并分析企業(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è)務與ToB業(yè)務的需求獲取方法，也存在著差異。無論是從調(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建?；蛘咂渌９ぞ邔崿F(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)設計交互迭代，最終形成產(chǎn)品的雛形；如果是基于原有產(chǎn)品架構(gòu)的功能增加，則更多的工作是基于原有架構(gòu)進行需求分配的過程。當然，不排除原有系統(tǒng)需要重構(gòu)，才能滿足客戶的功能要求的情況。

  而架構(gòu)設計則是將技術(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)設計，要考慮的不僅關(guān)乎技術(shù)實現(xiàn)，更是一種權(quán)衡藝術(shù)（Trade -Off），需要在功能、成本、時間、用戶期望等多種因素間尋求最佳平衡。如圖11，當面對客戶“過河”的需求，架構(gòu)設計可能需要考慮橋梁、船只、潛水艇，飛機等多種解決方案，每種方案背后代表了不同的技術(shù)復雜度、投資規(guī)模與時間周期，系統(tǒng)架構(gòu)就是需要在不同的解決方案中選擇最合適的，而不僅僅是技術(shù)最優(yōu)的。

圖11

  在架構(gòu)設計過程中，可以運用啟發(fā)式問題法、KJ法、QFD等工具進行評估與決策，有助于識別最合適的架構(gòu)。同時，評估軟件架構(gòu)的有效性，還可以通過創(chuàng)建原型、迭代開發(fā)、模型模擬等方式獲取直觀反饋，必要時引入量化指標進行深度分析。

  康威定律揭示了一個重要規(guī)律：軟件架構(gòu)往往反映出組織內(nèi)部的結(jié)構(gòu)。這意味著，良好的組織設計有助于催生高效、協(xié)調(diào)的軟件架構(gòu)，反之亦然。因此，在軟件開發(fā)過程中，應充分考慮組織架構(gòu)對技術(shù)實現(xiàn)的影響，確保架構(gòu)設計既能滿足功能需求，又能順應組織協(xié)作模式。

轉(zhuǎn)自汽車電子與軟件