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