開寫前先嘮兩句，只要與開發(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ā)動機控制器的。到了域控時代，新的玩家入場，開發(fā)邏輯出現(xiàn)不同聲音，特斯拉，蔚小理等硅谷/互聯(lián)網(wǎng)背景出身的新玩家都使用敏捷進(jìn)行開發(fā)，做出來的產(chǎn)品用戶體驗確實讓消費者有種“諾基亞轉(zhuǎn)安卓”的感覺，難道說敏捷就有如此大的魔力？可以給軟件賦予生命力？ASPICE和敏捷的差異和思路究竟在哪？
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)每一條需求。
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ù)深深的打擊了工程師的積極性。
單次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)動工程師積極性，（相對）輕文檔，重代碼；
說完敏捷這枚硬幣的正面，下面說他的反面。
相比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。
兩種開發(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)驗，非常非常歡迎留言探討）
第一，ASPICE下對發(fā)生變更的代價是巨大的，因此需要一次把所有功能都定義，設(shè)計完美。然而在域控這種軟件復(fù)雜度下，我不認(rèn)為有哪個人或者團(tuán)隊可以在項目開發(fā)初期，就能一次把所有的需求都定到完美。不完美，后期增改功能，好嘛，又一輪完整的V迭代，所有文檔改掉，軟件配置管理做版本管理，恐怕需求沒開發(fā)完，工程師跑一大半了。
第二，退一萬步講，就算有優(yōu)秀的產(chǎn)品團(tuán)隊可以一次把所有需求縷清，肯定也需要漫長的時間，試想下，兩家公司同時開始項目，使用敏捷的小步快跑，不斷試錯，都已經(jīng)有產(chǎn)品在投放市場了，使用ASPICE的可能還在需求制定階段……
敏捷開發(fā)需要克服的困難主要在于提升軟件質(zhì)量和滿足功能安全要求。
并不是用敏捷開發(fā)出來的軟件架構(gòu)就會松散，臃腫，而是敏捷的環(huán)境讓工程師更容易輸出這樣的結(jié)果。所以我認(rèn)為以下措施的執(zhí)行能有效改善軟件質(zhì)量：
適當(dāng)延長sprint周期；
嚴(yán)格的編碼規(guī)范與培訓(xùn)；
使用TDD（測試驅(qū)動開發(fā)）思路
強大的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的，又不能這么玩了）。
聯(lián)系客服
