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

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

1. ASPICE：堂正之師

1.1. 簡述

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

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

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

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

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

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

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

說白了，就是：

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

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

1.2. ASPICE的缺點

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

1. 難以擁抱變化

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

2. 對人力消耗巨大

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

SWE.3 BP

隨便說幾個工作量大到離譜的：

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

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

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

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

2.1. 簡述

單次sprint流程

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

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

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

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

2.2. 敏捷的缺點

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

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

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

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

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

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

3. 誰是自動駕駛時代答案？

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

域控時代的來臨，最主要的變化有三點：

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

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

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

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

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

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

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

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

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

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

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

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

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

使用TDD（測試驅(qū)動開發(fā)）思路

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

引入自動化單元檢查工具；

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

審核編輯 ：李倩