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

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

1. ASPICE：堂正之師

1.1. 簡述

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

軟件缺陷修復的成本是隨著軟件進度的開展，成倍數級提升的，BUG越早發現，成本越低；

BUG在不同階段引入的修復成本

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

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

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

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

說白了，就是：

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

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

1.2. ASPICE的缺點

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

1. 難以擁抱變化

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

2. 對人力消耗巨大

我貼一下SWE.3（軟件詳細設計與單元開發）的BP出來給大家感受一下

SWE.3 BP

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

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

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

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

2. 敏捷開發：短平快，擁抱變化

2.1. 簡述

單次sprint流程

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

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

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

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

2.2. 敏捷的缺點

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

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

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

缺少集成測試，導致新加的功能可能對已實現的功能有潛在的影響而不能被發現；

由于短平快的特性，很多時候單元測試也不能充分進行，比如動態單元測試；

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

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

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

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

功能眾多：帶來的變化是軟件復雜度指數式上漲，相關方眾多

產業鏈合作關系改變：從一功能一盒子，由Tier1軟硬件一起交付，OEM負責集成，到所有功能集中在域控，Tier1只提供底軟和硬件，應用軟件由Tier1，Tier2，OEM聯合開發

電子電氣架構演變

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

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

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

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

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

3.2. 敏捷開發需要做什么適配？

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

并不是用敏捷開發出來的軟件架構就會松散，臃腫，而是敏捷的環境讓工程師更容易輸出這樣的結果。所以我認為以下措施的執行能有效改善軟件質量：

適當延長sprint周期；

嚴格的編碼規范與培訓；

使用TDD（測試驅動開發）思路

強大的devops能力作為技術保證；

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

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

審核編輯 ：李倩