在當今數(shù)字化(huà)浪潮中ε✘∑，軟件(jiàn)開(kāi)發不(bù)僅是(shì)技(jì)術(shù)領域的(de§★)核心驅動力，更是(shì)企業(yè)創新與商業(yè)成功的(de)戰ε>略支點。特别是(shì)軟件(jiàn)定義汽車(chē)的(de)時(s✔ >hí)代，軟件(jiàn)研發的(de)規範化(huà)管™€σ理(lǐ)成為(wèi)車(chē)企的(de)難言之痛：軟件(jiàn)∏π≠×版本如(rú)此多(duō)，如(rú)何測試？全量測試還(hái)是(shì)采樣測試？軟件(jiàn)版本發布如(rú)何管控？軟件(jiàn)質量如(rú)何保障？軟件(jiàn)功能(néng)為(wèi)什(shén)麽總×₩✔是(shì)趕不(bù)上(shàng)造♠>±§車(chē)的(de)節奏？軟件(jiàn)是(shì)如(rú)何集成的←π(de)？敏捷會(huì)讓車(chē)企的(de)軟件(jiàn)開(k↓ ♣♥āi)發一(yī)夜之間(jiān)發生(α≤↕‌shēng)神奇的(de)變化(huà)？….

  本篇文(wén)章(zhāng)依據《軟件(jiàn)研發全攻略》≈δ←★這(zhè)份詳實的(de)教程資料，為(wèi)您揭開(kāi)軟件(ji≈✘àn)開(kāi)發的(de)神秘面紗，以科(kē)普的(de)方式探×"₹討(tǎo)其理(lǐ)論基礎、關鍵模型、實戰®±↔¥技(jì)巧以及組織與人(rén)才發展•≈÷£等重要(yào)議(yì)題，旨在為(wèi$ δ)讀(dú)者提供一(yī)幅全景式的(de)軟件(jiàn)研發導圖。

  一(yī)、軟件(jiàn)開(kāi)發基石：軟件(jiàn)開(kāi)發生(shēngσφ)命周期模型的(de)選擇

  軟件(jiàn)開(kāi)發生(shēng)命周期模型是(shì)組織軟件(j₩δiàn)研發活動的(de)框架，它定義了(le)開(kāi)發過程中的(de)≥♥₽階段、順序、叠代方式以及各階段間(jiān)的(de)關聯 （見(jiàn)圖1）。

圖1

  軟件(jiàn)開(kāi)發生(shēng)命周期模型，大(dà)家(jiā​™)耳熟能(néng)詳的(de)是(shì)經典的(de)瀑布模型和(hα•↑é)敏捷開(kāi)發模型。

瀑布模型：

  瀑布模型遵循嚴格的(de)線性順序，從(cóng)需求分(fēn™‌♣★)析到(dào)詳細設計(jì)，再到(dào)編碼、測試和(hé)維護，每個(gè)階段必'←•≤須在前一(yī)階段完全完成後才能(né₩↓λ←ng)開(kāi)始。瀑布模型适用(yòng)于需求穩定、技(jì)術(shù)路(lù)徑清晰的(de)項目，但(dàn)其僵化(huà)性可(kě)能(néng)導緻應對(duì)變化(huà)的(de₩£≈∏)能(néng)力較弱，一(yī)旦前期需求₩∑定義有(yǒu)誤，後續階段修正的(de)成本極高(✔φgāo)。

  關于瀑布模型，我們需要(yào)知(zhī)道(dào)，目前看(kàn)到(dào​ε)的(de)瀑布模型（見(jiàn)圖2）更多(duō)是(shì)停留在了(le)理(l"βπ ǐ)論模型基礎之上(shàng)。實際上(shàn✔☆g)，在1980s, Fred Brooks, 著名的(de)産品開(kāi)發暢銷書(shū)《人(rén)月(yuè)神話(huà)》作Ω←δπ(zuò)者，圖靈獎獲得(de)者，在NASA內(nèi)部會(huì)議(yì)上(shàng)指出，“在超過370億美(měi)金(jīn)的(de)投資項目中，隻有(yǒu)2%的(de)項目使用(yòng)了(le)純•'₩粹的(de)瀑布模型，75%的(de)項目或夭折或沒有(yǒu)使用(yòng).”

圖2

  在現(xiàn)實的(de)世界裡(lǐ)，α¥★更多(duō)的(de)是(shì)采用(yòng)了(le)基于瀑布模型演化(huà)的(↓↑¶de)進化(huà)模型，如(rú)螺旋模型，V模型等。他(tā)們都(dōu)融合了(le)瀑布模型的(de)結構化(₩φ™huà)特點與叠代思想。螺旋模型特别适用(yòng)于高(gāo)風(fēng)險項目，↔↓¶通(tōng)過反複的(de)風(fēng)γ≈險評估和(hé)原型叠代降低(dī)不(bù)确定性；而V模型（見(jiàn)圖3）強調開(kāi)發與測試的(de)對(duì)應關系，确保每個(gè)階段的(de)驗證與确認工©©(gōng)作(zuò)緊密相(xiàn♦σΩδg)連。V模型成為(wèi)了(le)産品工(gōn&σg)程，特别是(shì)軟硬一(yī)體(•ε☆tǐ)的(de)嵌入式産品開(kāi)發的(de)核心骨架，也(yě)是(shì)産品開(kāi)發使用(yòng)最為(wèi)廣泛的(∞‍de)模型。像汽車(chē)行(xíng)業(yè)的(de)ASPICE标準，功能(néng)安全的(de)ISO26262标準，信息安全的(de)ISO21434标準，基本都(dōu)是(shì)根據V模型制(zhì)定了(le)相(xiàng)應£₹★的(de)規範要(yào)求。

圖3

敏捷模型：

  敏捷開(kāi)發模型則以快(kuài)速響應變化(huà)為(wèi<>γ)宗旨，倡導叠代開(kāi)發和(hé)持續集成。它強調團隊協作(zuò)、用(‌ε yòng)戶參與以及适應需求的(de)靈←©∞活性，通(tōng)過短(duǎn)周期的(de)叠代（如(rú)Scrum中的(de)Sprint）快(kuài)速産出可(kě)用(yòng)軟件(jiàn)，并根據反饋進↔↕φ<行(xíng)調整。敏捷模型更多(duō)地(dì)關注了(le)軟件(jiàn)開(kāi↔"​)發過程中的(de)工(gōng)程實踐，對(duì)于軟件(jiàn)交付✔δ "後的(de)運營提及不(bù)多(duō)。交付後的(₹€Ω←de)管理(lǐ)更多(duō)的(de)還(hái)是(shì)•≈≥€采用(yòng)傳統的(de)軟件(jiàn)生(shēng)命周期管理(lǐ)的(deλ‍•)模式。

  敏捷軟件(jiàn)開(kāπ i)發模型同樣存在多(duō)種實操模型‌α ≈，例如(rú)XP，FDD，等。目前應用(yòng)最廣的(de)還(hái)是(shì)團隊級敏捷£÷≠SCRUM模型（見(jiàn)圖4）

圖4

  敏捷開(kāi)發在實際落地±≠€δ(dì)過程中有(yǒu)兩種具體(tǐ)的(de)項目管理(lǐ)方式：基于時(shí)間(§ "δjiān)盒的(de)叠代計(jì)劃（見(jiàn)圖5）和(hé)基于流的(de)叠代計(jì)劃（見♣§®(jiàn)圖6）。采用(yòng)不(bù)同的(de)叠代計(jì)劃，将₽σ決定了(le)敏捷項目每個(gè)沖刺（SPRINT）的(de)交付內(nèi)容。我們需要(yào)注意的(de)是(shì)，因為(w✘≥≠≈èi)産品形态及産品技(jì)術(shù)架構的(deπ<‍€)複雜(zá)度不(bù)同，組織架構的(de)不(bù)同，如(rú)果叠代規劃方α 式選擇與之不(bù)匹配，敏捷反而會(huì)引入更多(duō)的♠×∏(de)混亂和(hé)內(nèi)卷。

  例如(rú)，如(rú)果産品是(shì∞α↔∑)單一(yī)架構的(de)（monolithic Architecture）且功能(néng)依賴多(duō)，如("α☆rú)果采用(yòng)時(shí)間(jiān)盒的(≥​>de)叠代規劃方式，會(huì)出現(xiàn)待開(kāi)發的(de)新功能(né∏☆ng)不(bù)得(de)不(bù)削足适履，進行(xíng)功能(néng)分(fēn)'∞ε©拆用(yòng)戶故事(shì)，确保能(néng)在一(yī)個(gè)時(s✘ →☆hí)間(jiān)盒的(de)窗(chuāng)口交付，反而導緻大(dà)♥λ量的(de)模塊之間(jiān)的(de)相(xiàng)互依賴，交易成本（Transaction Cost）巨升，協調工(gōng)作(zuò)冗長(cháng)，♥δ‍從(cóng)系統論的(de)維度看(kàn)下(xià)來(lái)，反而是(shì★¥✘↓)降低(dī)了(le)效率。針對(duì)這(zhè)$★種情況，要(yào)麽是(shì)改變時(shí)間(jiān)盒的(de)跨度，要(™π₽yào)麽是(shì)采用(yòng)基于流的(de)叠代工(gōng)作(↑πzuò)模式。

圖5 （來(lái)源：From Prince2 Agile）

圖6（來(lái)源：From Prince2 Agile）

軟件(jiàn)開(kāi)發的(de)模型選&¥€擇：

“There's no singular technique or ∏¥→$process that will bring a¶αbout significant improvements in software deve✘γ™÷lopment productivity”

- No Silver Bullet—Essence and Accidents of¥✔↔ Software Engineering

Gerald Weinberg, Fred Brooks£π, and Grady Booch

  面臨亂花(huā)漸欲迷人(rén)眼以及病急亂投醫(yī)的÷ σλ(de)汽車(chē)軟件(jiàn)開(kāi)發，到(dào)底如(rú)δ₹何選擇自(zì)己的(de)軟件(jiàn)開(kāi)發₹$模式呢(ne)？正如(rú)Fred Brooks所言，沒有(yǒu)單一(yī)技(jì)術(shù)或♥>模型能(néng)夠顯著提成軟件(jiàn≥←)開(kāi)發效率。我們需要(yào)的(de)是(shì)因地(dì)制(zhì)宜，選擇适"'合自(zì)己組織和(hé)産品屬性的(de)研發活動的(de)₹✘∞☆模型。

  在實際工(gōng)作(zuò)中，我們應該且必須學以緻用(yòn♠≠g)，靈活适配合适的(de)軟件(jiàn)開(kāiσ≠)發模型，而不(bù)是(shì)簡單地(dì)照(zhào)貓畫(hu∞§‍¶à)虎，仿照(zhào)各種敏捷框架，站φ (zhàn)會(huì)，結對(duì)編程，…（題外(wài)話(huà)：其實，适配性（Adapability）才是(shì)業(yè)$¶務敏捷的(de)精髓所在）。不(bù)管選擇何種開(kāi)發模型，其核心目的(de)是(≈ε←φshì)更快(kuài)、更好(hǎo)地(dì)交付客戶價值和‍≈(hé)業(yè)務價值。具體(tǐ)來(lái)講，可(kě)以基≈<于Stacey矩陣，選擇合适的(de)開(kāi)發模型（圖7）。當然，除了(le)Stacey矩陣提供的(de)需求确定性和(hé)技(jì)術(shù)确定性的(de)兩‍≠®↕個(gè)維度外(wài)，還(hái)需要(yào)考慮團隊的(de)成熟度，團隊©≥成員(yuán)的(de)技(jì)能(néng)經驗，工(gōng)作(zuò)地(dì✔×)點分(fēn)布，團隊規模以及組織文(wén)化(huà)等因素。

圖7

二、需求分(fēn)析與架構設計(jì)的(de)藝術(shù)

  軟件(jiàn)開(kāi)發始于需求的(de)獲取與需求開(kāi)發的(d€÷β€e)過程（通(tōng)常将這(zhè)個(gè)過程稱為(wèi)需求工(g•§£λōng)程階段）。需求的(de)獲取主要(yào)是(shì)從(cóng™Ωε)市(shì)場(chǎng)需求，用(yòng)戶需求，‌×≥業(yè)務等維度，理(lǐ)解并分(fēn)析企業(yè$÷♣•)所在的(de)行(xíng)業(yè)，↑¥國(guó)家(jiā)，地(dì)區(qū)，♠ •适用(yòng)的(de)法律法規等各個(gè)維度，定→∏π∑義軟件(jiàn)産品的(de)需求。 

  近(jìn)幾年(nián)來(lái)，随著(zhe)國(guó)內≥δ(nèi)互聯網造車(chē)的(de)興起，互聯網用(yòng)戶需求分( 'fēn)析的(de)工(gōng)具也(yě)逐步引入到(dào)垂€&δ直行(xíng)業(yè)，也(yě)成為(wèi)國(guó)★¥φ☆內(nèi)傳統造車(chē)企業(yè)紛紛攘攘去(qù)學習(x↑©í)的(de)重心。但(dàn)從(cóng)第一(yī)性原理(lǐ)來(↔≤₹γlái)看(kàn)，需求獲取的(de)原理(lǐ)沒有(yǒu)改變，變化(hu♥‌♦à)的(de)是(shì)傳統企業(yè)缺少(shǎo)需求獲取的(d±±e)數(shù)字化(huà)手段，缺少(shǎo)人(rén)物₽‍(wù)畫(huà)像的(de)細節管控。

  需求獲取的(de)方法手段很 ₽Ω(hěn)多(duō)，我們總結如(rú)圖 ♣↑≥8所示。

圖8

  在對(duì)軟件(jiàn)産品功能(néng)進行(xíng)定義的(d≈φ€εe)過程中，往往采用(yòng)的(de)是(shì)多(duō)種方法的(de)綜合應αεφ用(yòng)，确保功能(néng)能(néng)夠滿足最大(dà)數(sh★₽↕ù)量的(de)用(yòng)戶期望。同時(♥>&αshí)，我們要(yào)關注，對(duì)于TOC業(yè)務與ToB業(yè)務的(de)需求獲取方法，也(yě)存在著(zhe)差異。€ε‌÷無論是(shì)從(cóng)調研對(duì←≤δ)象，調研數(shù)量以及調研方法，在實際過程中，要(yào)注重理(l★ ​≈ǐ)論與實踐的(de)結合。

  這(zhè)裡(lǐ)，特 $∞别給大(dà)家(jiā)推薦一(yī)個(gè)用(yòng)來(lái)識别或改進産品可(k♣™®ě)用(yòng)性功能(néng)需求（Usability）的(de)強大(dà)工(gōng)具–用(yòng)戶曆程地(dì)圖（題外(wài)話(hu&♠à)：對(duì)于其他(tā)如(rú)非功能(néng)性需求的∞♣$(de)定義與改進，建議(yì)采用(yòng)其他(tā)工(gōng)具方法）。圖9展示了(le)對(duì)電(diàn)車(chē)用(yòng)戶充'πγ 電(diàn)活動的(de)用(yòng)戶曆程地(dì)圖，通(tōng)σπ¶過一(yī)張紙(zhǐ)，可(kě)以清晰地€¥¥(dì)将産品功能(néng)的(de)優劣以及待創新的(de)功能(néng)點描述清楚。

圖9

  需求獲取隻是(shì)開(kāi)啓了(le)整個(gè)軟件(jiàn)開&↓→®(kāi)發的(de)序幕。我們下(xià)一(yī) ↑★步要(yào)做(zuò)的(de)是(shì)需求的↓&☆¶(de)确認。需求的(de)确認，是(shì)确保軟件(jiàn)産品的☆"(de)開(kāi)發“做(zuò)正确的(de)≠™&→事(shì)”。需求确認的(de)方法包括了(le)VOC，焦糖布丁法，Y分(fēn)析法，數(shù)據分(fē™÷↕n)析法等等。

  為(wèi)什(shén)麽要(yào)進行(xíng)需求的(&★∞de)确認呢(ne)？其實，這(zhè)涉及到(₹₩ dào)了(le)人(rén)類認知(zhī)的(de)÷≥λβ過程，如(rú)圖10所示，當我們看(kàn)到(dào)現(xiàn)實的(de)人(r↑♠én)形機(jī)器(qì)人(rén)圖片€☆§時(shí)，我們會(huì)根據自(zì)己的(de)認知(zhī)(Perception)和(hé)我們個(gè)人(rén)的(de)知(zhī)識（Knowledge）對(duì)其進行(xíng)描述。然後，我們将我們自(zì)己腦(nǎ↕‍↓o)海(hǎi)裡(lǐ)，經過自(zì)己認知(♠♣≥ zhī)過濾過的(de)圖片，用(yòng)自(zìγ★✔$)己的(de)知(zhī)識，包括文(wén)字語言對( ♣duì)其進行(xíng)描述，這(zhè)個(gè)過程，将不(bù)可(kě)避免的(de)引φα¥入人(rén)為(wèi)的(de)錯(cuò)誤。所以，在專業↑<✔(yè)的(de)産品研發環境中，我們意識到(dào)這(zh¶β"εè)個(gè)人(rén)類認知(zhī)的(de)過≥±程偏差，所以需要(yào)建立規範的(de)工(gōn∏₩βg)具方法，如(rú)需求文(wén)檔的(de±>σ€)評審，需求撰寫的(de)規範，等，作(zuò)為(wèi)“獲取正确需求”的("←de)底線保障，确保最大(dà)可(kě)∑‌γ​能(néng)地(dì)不(bù)失真。而敏捷思想裡(lǐ↔Ω​δ)強調的(de)“客戶合作(zuò)勝于®>™ε客戶合同”，也(yě)正是(shì)基于這(zhè)個(gè)不(bù)可(kě)更改的×♦×♦(de)事(shì)實做(zuò)出的(de)更合理§∏ (lǐ)的(de)過程建議(yì)。

圖10

  需求的(de)開(kāi)發包&♠括需求分(fēn)析與需求的(de)分(fēn)解與分(fēn)配的(de)過程。λ•♠∏它是(shì)軟件(jiàn)産品開(kāi)發“正确做(zuò)事(shì)”的(de)過程×₹σ。這(zhè)個(gè)過程可(kě)以使用(yòng)類似FAST功能(néng)分(fēn)析圖，EFFBD圖，UML建模或者其他(tā)建模工(gōng)具實現(x₩∑iàn)。也(yě)可(kě)以使用(yòn™βg)其它不(bù)同的(de)工(gōng)具方法，如(rú)KJ法，KANO法，QFD法，Pugh 矩陣法等等，幫助我們有(yǒu)效工(gōng)作(zuò)。

  需求開(kāi)發從(cóng)産品定義語境出發，逐步細化(huà)分(fēn)解功εΩ'能(néng)，最後分(fēn)配到(dào)子(zǐ)系統和(hé)模塊。這(zhè)個(gφε∞è)過程是(shì)用(yòng)戶可(kě)見(jiàn)的(de)功能(n€λ₩éng)和(hé)可(kě)感知(zhī)的(de)非功能(néng)性期望，轉化(♥≥™δhuà)為(wèi)我們軟件(jiàn)産品能(néng)力的(de)過程。如 φ(rú)果是(shì)0到(dào)1的(de)産品開(kāi)發，這(zhè)個(gè)過程與産品架構設計(jì)交互叠代，最終形ε±★♠成産品的(de)雛形；如(rú)果是(shì)基于原有(yǒu)産品架構的(de)功‌♣÷能(néng)增加，則更多(duō)的(₹∑de)工(gōng)作(zuò)是(shìλ£')基于原有(yǒu)架構進行(xíng)需求分(fēn)配的(de)過程。當然，不(bù)排除Ω↑ ∞原有(yǒu)系統需要(yào)重構，才能(néng)滿足∞<‌客戶的(de)功能(néng)要(yào)求的(de)情況。

  而架構設計(jì)則是(shì)将技(jì)術(shù)需Ωπ求轉化(huà)為(wèi)系統的(de)藍(lán)圖，涉及功能(néng)模型定義、架構±Ω↑¶評估方法選擇、物(wù)理(lǐ)架構布局等多(duō)個(gè)環節。軟件(j"®iàn)産品常見(jiàn)的(de)技(jì)術(shù)架構包括≠¶了(le)C/S架構，MVC架構，分(fēn)層的(de)SOA架構等。但(dàn)具體(tǐ)的(de)架構設計(jì)，要(yào)考慮的(de)不£→(bù)僅關乎技(jì)術(shù)實現(xiàn​↔)，更是(shì)一(yī)種權衡藝術(shù)（Trade -Off），需要(yào)在功能(néng)、成本、時(shí)間(jiān)、•££≈用(yòng)戶期望等多(duō)種因素間(jiān)尋求最佳平衡 Ω∑®。如(rú)圖11，當面對(duì)客戶“過河(hé)”的(de)需求，架構設計(jì)可(kě)能(néng)需要(yào)≥↔考慮橋梁、船(chuán)隻、潛水(shuǐ)艇，飛(fē★δδ"i)機(jī)等多(duō)種解決方案，每種方案背後代§₽¥表了(le)不(bù)同的(de)技(jì)術(¥δβshù)複雜(zá)度、投資規模與時(shí)間(jiān)周期，系統架構就(jiù)是(shì)↑≤需要(yào)在不(bù)同的(de)解決方案中選擇最合适的(deε>)，而不(bù)僅僅是(shì)技(jì)術(shù)最優的(de)。

圖11

  在架構設計(jì)過程中，可(kě)以運用(yòng)啓發→γ式問(wèn)題法、KJ法、QFD等工(gōng)具進行(xíng)評估與決策，有(yǒu)助于識别最合适的(de₽←‌​)架構。同時(shí)，評估軟件(jiàn)架構的(de)有(yǒu)效性，還(hái)可(kě)σ≤±以通(tōng)過創建原型、叠代開(kāi)發、模型模拟等方式獲取直$£₽₩觀反饋，必要(yào)時(shí)引入量化(huà)指标進行(xíng)深度分 ​(fēn)析。

  康威定律揭示了(le)一(yī)個(gè)重要(yào)規律：軟件(jiàn)↑δ架構往往反映出組織內(nèi)部的(de)結構。這(zhè)意味著(zhe)，良好(hǎo)的(de)組織設↕♥δ計(jì)有(yǒu)助于催生(shēng)高(gāo)效、協調的(de)軟件(jiàn'✔∞)架構，反之亦然。因此，在軟件(jiàn)開(kāi)發過程中，應充分 ≠(fēn)考慮組織架構對(duì)技(jì)術(shù)實現(xi≤§↑←àn)的(de)影(yǐng)響，确保架構設計(jì) €α£既能(néng)滿足功能(néng)需求，又(yòu)能(néng)順應組←♥ 織協作(zuò)模式。

轉自(zì)汽車(chē)電(diàn)子(zǐ)與軟件(jiàn)