開寫前先嘮兩句，只要與開發(fā)工程師多聊兩句，你就會(huì)很容易地發(fā)現(xiàn)，開發(fā)工程師幾乎是一邊倒的支持敏捷開發(fā)，筆者曾完整地參與過(guò)一次ASPICE認(rèn)證項(xiàng)目，也在敏捷模式下進(jìn)行過(guò)較長(zhǎng)時(shí)間開發(fā)。從開發(fā)工程師的角度出發(fā)，使用敏捷進(jìn)行開發(fā)的體驗(yàn)吊打ASPICE（或者V模型）九條街，但我們今天討論的話題是哪種模式更適合“更快更高質(zhì)量”地輸出產(chǎn)品，而不是哪個(gè)模式對(duì)工程師更友好。那么我們就來(lái)探討一下這兩種開發(fā)模式在域控時(shí)代的適應(yīng)性。

當(dāng)汽車電子電器架構(gòu)還處于分布式的年代，ASPICE（或V模型）可以說(shuō)是唯一的答案，就沒(méi)聽說(shuō)過(guò)哪家Tier 1或者OEM是使用敏捷去開發(fā)一個(gè)發(fā)動(dòng)機(jī)控制器的。到了域控時(shí)代，新的玩家入場(chǎng)，開發(fā)邏輯出現(xiàn)不同聲音，特斯拉，蔚小理等硅谷/互聯(lián)網(wǎng)背景出身的新玩家都使用敏捷進(jìn)行開發(fā)，做出來(lái)的產(chǎn)品用戶體驗(yàn)確實(shí)讓消費(fèi)者有種“諾基亞轉(zhuǎn)安卓”的感覺(jué)，難道說(shuō)敏捷就有如此大的魔力？可以給軟件賦予生命力？ASPICE和敏捷的差異和思路究竟在哪？

1. ASPICE：堂正之師

1.1. 簡(jiǎn)述

ASPICE的核心思想就是DRIFT（Do things right in first time），ASPICE認(rèn)為：

軟件缺陷修復(fù)的成本是隨著軟件進(jìn)度的開展，成倍數(shù)級(jí)提升的，BUG越早發(fā)現(xiàn)，成本越低；

BUG在不同階段引入的修復(fù)成本

在關(guān)鍵控制器上（比如動(dòng)力總成的ECU），某些Bug可能是致命的（字面意義上的）且難以被發(fā)現(xiàn)的，因此，對(duì)代碼的態(tài)度必須慎之又慎；

傳統(tǒng)的合作關(guān)系上，通常是Tier1供控制器（Turn-key or Customer-sharing），OEM集成到車上，對(duì)于軟件這種無(wú)形的資產(chǎn)，又是閉源交付，OEM管控是很難的，唯一的監(jiān)管方式就是交付物，所以ASPICE既是開發(fā)過(guò)程，也是質(zhì)量證據(jù)。

因此，ASPICE講究走一條最康莊平坦的大道：

一份不偏離相關(guān)方（stakeholder）意圖的工程需求----》按照意圖，考慮所有corner case，基于選型芯片資源，設(shè)計(jì)考慮完備的軟件架構(gòu)----》將軟件架構(gòu)進(jìn)一步細(xì)化到模塊與函數(shù)級(jí)別的詳細(xì)設(shè)計(jì)----》與詳細(xì)設(shè)計(jì)思路一模一樣的編碼----》驗(yàn)證是否與詳細(xì)設(shè)計(jì)一致的單元測(cè)試----》驗(yàn)證是否與軟件架構(gòu)設(shè)計(jì)一致的集成測(cè)試----》驗(yàn)證是否與軟件需求一致的合格性測(cè)試。

說(shuō)白了，就是：

V左半邊：保證每一行代碼都能知道是為哪一條需求服務(wù)的。

V右半邊：保證每一行代碼都在正確的實(shí)現(xiàn)每一條需求。

1.2. ASPICE的缺點(diǎn)

ASPICE統(tǒng)治了汽車軟件這么多年，自然有他的必要性與優(yōu)勢(shì)，但ASPICE的缺點(diǎn)也非常致命：

1. 難以擁抱變化

從上文可以看出，一套V模型擼下來(lái)，都是一環(huán)套一環(huán)的，下一步的輸出完全依賴上一步的輸入，如果需求發(fā)生了變更，而且需求還是與原需求互斥的，那整個(gè)項(xiàng)目的改動(dòng)量將是災(zāi)難性的。所以有些OEM的DRE可能會(huì)很疑惑，為什么看起來(lái)一個(gè)小小的CR（change request）發(fā)下去，會(huì)被Tier1告知一大筆的開發(fā)費(fèi)用，甚至是拒絕？流程可能就是其中一個(gè)原因。只要代碼需要變更，好嘛，相應(yīng)的設(shè)計(jì)文檔作廢，重新設(shè)計(jì)，測(cè)試重新做……想想都頭疼。而國(guó)內(nèi)的項(xiàng)目氛圍又是“最愛(ài)”擁抱變化的，hmmm……

2. 對(duì)人力消耗巨大

我貼一下SWE.3（軟件詳細(xì)設(shè)計(jì)與單元開發(fā)）的BP出來(lái)給大家感受一下

SWE.3 BP

隨便說(shuō)幾個(gè)工作量大到離譜的：

BP3：很多時(shí)候模塊間交互是很難窮盡描述的，特別是大型軟件，應(yīng)用層，或者高聚低耦做得沒(méi)那么好的模塊，在不同場(chǎng)景，不同條件下，都可能走不同邏輯，整個(gè)交互路徑都窮舉一遍是很難的，畫出來(lái)的seq圖也很難閱讀

BP5：每一步的流程都要求這個(gè)，做過(guò)的dddd（懂的都懂），有DOORS相對(duì)好點(diǎn)，用excel去管理這玩意就是個(gè)災(zāi)難，還感覺(jué)沒(méi)什么卵用

其實(shí)每個(gè)BP要求的工作量都很大，我做過(guò)大概的統(tǒng)計(jì)，執(zhí)行ASPICE的人力需求是不執(zhí)行的3倍，除此以外，就像我之前說(shuō)的，這個(gè)流程既是開發(fā)流程，也是質(zhì)量證據(jù)，屬于監(jiān)管與被監(jiān)管的關(guān)系，繁重的文檔任務(wù)深深的打擊了工程師的積極性。

2. 敏捷開發(fā)：短平快，擁抱變化

2.1. 簡(jiǎn)述

單次sprint流程

敏捷開發(fā)的核心邏輯是解構(gòu)，把軟件需求分解成Epic or story，通過(guò)一輪開發(fā)迭代（sprint）實(shí)現(xiàn)相應(yīng)的功能。一輪sprint包含：需求確認(rèn)-》方案制定-》coding-》臺(tái)架驗(yàn)證-》實(shí)車驗(yàn)證-》rolling candidate版本驗(yàn)證-》代碼合入 敏捷的優(yōu)點(diǎn)在于：

擁抱不確定性，發(fā)生需求變更，那就直接來(lái)一輪sprint，如果還不夠，那就來(lái)兩輪；

出活快，一個(gè)sprint的迭代以周為單位；

充分調(diào)動(dòng)工程師積極性，（相對(duì)）輕文檔，重代碼；

2.2. 敏捷的缺點(diǎn)

說(shuō)完敏捷這枚硬幣的正面，下面說(shuō)他的反面。

相比ASPICE或者V模型，敏捷少做的事情：

缺少統(tǒng)籌全局的進(jìn)行軟件架構(gòu)設(shè)計(jì)，導(dǎo)致模塊很難做到高類聚低耦合，比如Sprint A實(shí)現(xiàn)的一個(gè)功能，其底層模塊其實(shí)可以被Sprint B的某個(gè)功能部分復(fù)用，但由于Sprint A沒(méi)有考慮Sprint B的開發(fā)需求，所以該底層模塊并不能被完全復(fù)用，Sprint B可能就要重新開發(fā)一個(gè)底層模塊去覆蓋他自己的需求。多輪sprint下來(lái)，可能會(huì)有重復(fù)造相似輪子的情況出現(xiàn)。這樣會(huì)導(dǎo)致軟件比較臃腫，代碼量大，執(zhí)行效率低，且代碼質(zhì)量不高；

缺少集成測(cè)試，導(dǎo)致新加的功能可能對(duì)已實(shí)現(xiàn)的功能有潛在的影響而不能被發(fā)現(xiàn)；

由于短平快的特性，很多時(shí)候單元測(cè)試也不能充分進(jìn)行，比如動(dòng)態(tài)單元測(cè)試；

與FUSA的流程完全不兼容。26262也好，61508也好，34590也好，都是植根于V模型，使用敏捷開發(fā)的軟件，很難滿足功能安全的開發(fā)要求，也無(wú)法做功能安全分析，無(wú)法做FFI。

3. 誰(shuí)是自動(dòng)駕駛時(shí)代答案？

兩種開發(fā)流程各擅勝場(chǎng)，也有其出現(xiàn)的背景，在傳統(tǒng)汽車時(shí)代，各個(gè)控制器沒(méi)有花哨的功能，但要求軟件穩(wěn)定可靠，這種情況下，使用ASPICE或者V模型進(jìn)行開發(fā)無(wú)疑是非常正確的。

域控時(shí)代的來(lái)臨，最主要的變化有三點(diǎn)：

功能眾多：帶來(lái)的變化是軟件復(fù)雜度指數(shù)式上漲，相關(guān)方眾多

產(chǎn)業(yè)鏈合作關(guān)系改變：從一功能一盒子，由Tier1軟硬件一起交付，OEM負(fù)責(zé)集成，到所有功能集中在域控，Tier1只提供底軟和硬件，應(yīng)用軟件由Tier1，Tier2，OEM聯(lián)合開發(fā)

電子電氣架構(gòu)演變

我的觀點(diǎn)是：ASPICE不適合用于開發(fā)智駕域控軟件，敏捷相對(duì)更合適，但必須根據(jù)汽車軟件的特點(diǎn)，進(jìn)行適配

（一家之言，如果有使用ASPICE完整開發(fā)過(guò)智駕域控到SOP的經(jīng)驗(yàn)，非常非常歡迎留言探討）

3.1. 為什么ASPICE不合適用于開發(fā)域控？

第一，ASPICE下對(duì)發(fā)生變更的代價(jià)是巨大的，因此需要一次把所有功能都定義，設(shè)計(jì)完美。然而在域控這種軟件復(fù)雜度下，我不認(rèn)為有哪個(gè)人或者團(tuán)隊(duì)可以在項(xiàng)目開發(fā)初期，就能一次把所有的需求都定到完美。不完美，后期增改功能，好嘛，又一輪完整的V迭代，所有文檔改掉，軟件配置管理做版本管理，恐怕需求沒(méi)開發(fā)完，工程師跑一大半了。

第二，退一萬(wàn)步講，就算有優(yōu)秀的產(chǎn)品團(tuán)隊(duì)可以一次把所有需求縷清，肯定也需要漫長(zhǎng)的時(shí)間，試想下，兩家公司同時(shí)開始項(xiàng)目，使用敏捷的小步快跑，不斷試錯(cuò)，都已經(jīng)有產(chǎn)品在投放市場(chǎng)了，使用ASPICE的可能還在需求制定階段……

3.2. 敏捷開發(fā)需要做什么適配？

敏捷開發(fā)需要克服的困難主要在于提升軟件質(zhì)量和滿足功能安全要求。

并不是用敏捷開發(fā)出來(lái)的軟件架構(gòu)就會(huì)松散，臃腫，而是敏捷的環(huán)境讓工程師更容易輸出這樣的結(jié)果。所以我認(rèn)為以下措施的執(zhí)行能有效改善軟件質(zhì)量：

適當(dāng)延長(zhǎng)sprint周期；

嚴(yán)格的編碼規(guī)范與培訓(xùn)；

使用TDD（測(cè)試驅(qū)動(dòng)開發(fā)）思路

強(qiáng)大的devops能力作為技術(shù)保證；

引入自動(dòng)化單元檢查工具；

滿足功能安全要求，話只有一句，其實(shí)是個(gè)悖論，因?yàn)檐浖δ馨踩?V模型開發(fā)。可能的一個(gè)解決方案，是利用26262中FFI的思路，通過(guò)前期技術(shù)規(guī)劃，將軟件架構(gòu)分解成功能：QM（D）和功能安全軟件D（D），功能分區(qū)使用敏捷開發(fā)小步快走，功能安全分區(qū)還是按V模型進(jìn)行開發(fā)（思路是這么個(gè)思路，但做軟件安全分析和安全架構(gòu)設(shè)計(jì)需要非常小心，而且僅適用于safety goal為fail safe的域控，如果L4以上需要做fail operational的，又不能這么玩了）。

審核編輯 ：李倩