“軟件定義汽車”逐漸在汽車行業(yè)達成共識，大家紛紛意識到軟件相比于硬件，對于汽車行業(yè)重要性的比重逐漸提升。我們看到傳統(tǒng)的主機廠紛紛轉(zhuǎn)型，也涌入了越來越多的造車新勢力，出現(xiàn)了越來越多的汽車軟件供應(yīng)商。

不管是有造車經(jīng)驗，還是沒有造車經(jīng)驗的，開始造車之后，首先都需要問一個問題：汽車行業(yè)的軟件開發(fā)是什么樣的？比如說小米來造車，是否能夠按照小米之前開發(fā)手機軟件的流程和步驟來直接開發(fā)車載軟件？

面對這個問題，我們?nèi)ふ疫@個問題的答案。就會發(fā)現(xiàn)在汽車行業(yè)有兩個比較重要的軟件開發(fā)標準，一個叫 ASPICE， 一個叫功能安全ISO26262。這兩個標準都是基于 V 字型的開發(fā)模式。

01.ASPICE誕生的時間、背景和目的

那么ASPICE標準誕生的背景是什么呢？在05 年的時候——注意這個時間是 05年， 現(xiàn)在已經(jīng)是 17 年之后了——德國的十幾家主機廠和比較強勢的供應(yīng)商一起制定了一個汽車軟件流程的評價框架，后來他們背靠VDA（德國汽車工業(yè)協(xié)會）發(fā)布了這套框架。制定這套框架的目的是什么呢？因為他們的軟件供應(yīng)商，不可能把軟件以白盒形式交付給他們。這時候他們想到了一個招：雖然我不能看你的代碼，但是我要求你的整個軟件或者系統(tǒng)的研發(fā)流程是按照特定的流程。這個流程就是汽車行業(yè)非常有名的 V字型開發(fā)流程。它的主體部分，是系統(tǒng)工程和軟件工程部分。具體來說，就是針對一個系統(tǒng)的開發(fā)需要包括：系統(tǒng)需求分析、系統(tǒng)架構(gòu)設(shè)計、軟件需求分析、軟件架構(gòu)設(shè)計、軟件詳細設(shè)計，這是V字型的左邊，以及對應(yīng)的右邊驗證測試的過程。

這十幾家主機廠和供應(yīng)商的邏輯是這樣的：雖然我看不到你的詳細代碼，但是假如你的整個開發(fā)是流程是基于這個我定義的這個流程來開發(fā)的，那么我就認為你的質(zhì)量是基本達標的。但這其實只是進入主機廠和強勢供應(yīng)商的供應(yīng)鏈體系的敲門磚。只是代表你遵循了這樣一個流程，并不代表你的產(chǎn)品好壞。至于最終是否能進入供應(yīng)鏈體系，產(chǎn)品優(yōu)劣、價格、交付速度、售后，其實更加重要。所以如果我們深入理解這個邏輯的話，我們就會發(fā)現(xiàn)，它是強勢的甲方，對于乙方的要求。這個框架的要求和細節(jié)，是非常繁雜的。

具體來說，ASPICE對兩塊地方的要求特別高，一塊叫做追溯性，一塊叫做合規(guī)性。所謂的追溯性，簡單的理解就是，從任何一個細節(jié)，比如說一個 bug，我可以追溯到它的測試用例，追溯到它的測試計劃，追溯到它的軟件需求，追溯到它的軟件架構(gòu)，追溯到它的系統(tǒng)架構(gòu)、系統(tǒng)需求等等。

另外一塊是叫做合文檔的合規(guī)性。比如說我要做一個測試，測試的時候首先需要制定一個測試計劃，我的測試策略是什么？我的測試目標是什么？我這次測試是針對什么東西的測試，然后有哪些人參與，然后測試的過程怎么進行結(jié)果的記錄，bug如何進行追蹤，以及 bug 的解決過程，bug 的原因分析，它的影響分析等等。

那么具體追溯性和合規(guī)性如何實現(xiàn)呢？這套評價框架是沒講的，主機廠也不關(guān)心，或者就算他想關(guān)心，他那些供應(yīng)商也不可能完全按照他的要求來做。那么既然主機廠不關(guān)心，那么他們怎么來把控他們的供應(yīng)商真的能滿足這套評價框架呢？這時候就出現(xiàn)了叫做 ASPICE評審的活動，是由對ASPICE標準比較熟悉的評審師，來針對某家公司的流程來做評價的。你通過了，就能給你發(fā)個證。有些評審師非常有經(jīng)驗，他不僅知道怎么評價，還知道你通過什么方式、什么工具能快速通過評價；還有一些評審師，他只知道標準的要求是什么，至于“怎么做”才能通過標準，“怎么做”才能高效地通過這個標準，提供不了什么幫助。

那么這塊就出現(xiàn)了一個問題，既然標準都是一樣的，但是具體的實現(xiàn)過程不一樣，我們就會發(fā)現(xiàn)有些公司實現(xiàn)追溯性的過程非常高效，還有一些公司就非常繁雜。舉個例子，有些公司基本上全部是用 word 的方式來管理他所有的文檔。有一份需求用 word 來書寫有 20 頁，有一份軟件架構(gòu)用 word 來書寫有 50 頁。你可以看到有一個需求，比如叫需求1，我問你它的架構(gòu)是什么，你就會發(fā)現(xiàn)需求 1 下面寫了是架構(gòu)3.2，然后你就去架構(gòu)的word文檔里面翻到架構(gòu)3.2。那么到了架構(gòu)的時候，我問你架構(gòu)有沒有測試用例，然后你就會在架構(gòu)那看到，對應(yīng)的測試用例是5.3，然后你就去翻到對應(yīng)的測試用例word里面，有一條5.3。你說這家公司有沒有建立追溯性呢？它確實建立了追溯性。但是我們剛剛舉的這個例子非常簡單，它只涉及到三步，我們確實可以通過翻閱文檔的方式來進行追溯。

但是大家想象一下，一般來說在一家公司里面，需求、軟件架構(gòu)、測試用例都是由不同的工程師來完成的。那么不同的工程師可能把這些文檔放在不同的地方，不同的工程師也會實時地更新它的文檔。比如說我們剛剛把軟件需求和軟件架構(gòu)聯(lián)系起來了，這時候，軟件架構(gòu)word更新了一點東西，它能否通知到軟件需求，這里有一處更新呢？以及架構(gòu)師是否知道去通知誰呢？

假如我的系統(tǒng)中有 30 份軟件需求文檔，50份軟件架構(gòu)文檔，100 份測試用例文檔，這個時候你再去尋找它，這個尋找過程的復雜程度，就是指數(shù)級增長了。可以看到，確實建立了追溯性，但是這個追溯性的實用性很差。這也是為什么很多團隊在ASPICE評審的過程中怨聲載道，一旦評審通過，立刻拋棄這套“追溯性”和“合規(guī)性”過程。

總結(jié)一下：ASPICE誕生的背景是強勢的主機廠和供應(yīng)商，對于它下級供應(yīng)商的要求，誕生的原因是甲方看不到乙方的白盒交付，所以至少要保證你的流程是按照我定義的標準流程來實施的。乙方通過這種方式拿到甲方供應(yīng)鏈體系的敲門磚。但并不代表通過了這個標準，就能開發(fā)出好的產(chǎn)品，這兩者之間是沒有根本性的聯(lián)系的。

02.ASPICE 適合和不適合哪些公司

基于這個背景，我們來想一下，ASPICE或者說 V 字型開發(fā)，適合和不適合哪些公司呢？

我們首先說它適合的公司。

如果這家公司，比如說是一家傳統(tǒng)的主機廠，之前沒有做過軟件開發(fā)，學習ASPICE開發(fā)模型對于它來說是合適的。因為它可以通過一套標準流程的建立，大體知道汽車軟件是怎么開發(fā)的，它的系統(tǒng)，它的需求，它里面需要完成哪些步驟。可以快速地幫他建立起這個團隊的流程，然后也可以讓他快速找到對應(yīng)的人。因為根據(jù)不同的事情，你就需要找對應(yīng)的軟件系統(tǒng)工程師、軟件架構(gòu)工程師、軟件測試工程師等等。

如果是針對其他行業(yè)，比如說小米汽車，他轉(zhuǎn)型過來做汽車。這個時候?qū)τ谒麄儊碚f也是有用的，因為他們同樣可以快速地熟悉汽車行業(yè)。

那么它不適合哪些公司呢？

如果有一家做汽車軟件的公司，它本身的軟件已經(jīng)做得非常好了，它已經(jīng)有一套自有的軟件體系來保證軟件質(zhì)量。另外它也不需要對它的甲方供貨，比如說它本身就是一家主機廠，他不需要對他的供應(yīng)商詳細解釋，他的整個軟件開發(fā)流程是什么樣的。舉個例子，比如在做測試計劃的時候，詳細的測試策略是什么，測試計劃是怎么安排的，出現(xiàn)什么情況，才會進行回歸測試。這些東西在團隊內(nèi)部，已經(jīng)是約定俗成的。比如說蔚來汽車，蔚來汽車的智能座艙基本上是完全自研的。整個團隊非常清楚測試策略是什么。這個測試策略一旦形成下來，比如說通過六個月、一年搭建好了，整個團隊都知道怎么做了。這個時候，就不需要花大力氣，在每一份測試計劃里面，都去寫詳細的測試策略、測試流程、回歸策略等等。

像這類公司，它其實是不適合反過頭來做ASPICE，這個反而會降低他們的軟件開發(fā)速度。但是并不是說ASPICE對于像蔚來這樣的公司完全不可用，它其實是可以給它們作為一個參考的。因為有些團隊一旦敏捷之后，很多文檔就沒有了。舉個例子，軟件需求有 100 條，對應(yīng)的軟件測試用例有 1000 條。他們之間沒有建立追溯性關(guān)系，但是我知道這 1000 條測試用例就是針對這 100 條需求來測的。這當然沒有問題。但是不可能每次測試的時候，都把這 1000 條測完。根據(jù)不同的開發(fā)階段，有時候可能只選擇其中的 500 條。這個時候，如果問你這十條需求在這次的測試計劃里面，測試用例覆蓋率是多少。如果沒有建立一個追溯性的關(guān)系，這個問題就非常難以回答。

所以對于像蔚來汽車這樣的團隊，他們同樣需要去借鑒 ASPICE的一些經(jīng)驗和方法，來讓他們的整個流程，既保證有一定的敏捷效率，同時又能做到合規(guī)性和高效化。另外蔚來汽車本身是一家新造車，所以它招聘的人里面既有傳統(tǒng)的軟件開發(fā)團隊，也有從手機行業(yè)過來的，從互聯(lián)網(wǎng)行業(yè)過來的。怎么能讓這些人用共同的語言說話，怎么能讓這些人遵循一個共同的流程？在前期去借鑒ASPICE流程的思想和方法，也是有必要的。

總結(jié)一下：

如果你的團隊以前沒有做過汽車行業(yè)的軟件開發(fā)，那么ASPICE的整個流程，作為快速搭建軟件研發(fā)體系，是有用的；

如果你的團隊是一個混合型的團隊，從各行各業(yè)招人，那么為了讓你的團隊在短時間之內(nèi)形成一個一致的開發(fā)習慣和開發(fā)流程，那么ASPICE也是有借鑒和參考意義的

但是如果你的團隊本身沒有向外交付軟件的需求，你們整個內(nèi)部流程也特別清晰，追溯性已經(jīng)建立起來了，軟件質(zhì)量很高。這種情況下，ASPICE對你的重要性會大大降低。這個時候，反而是你需要通過升級你的工具鏈，升級你的管理方式，來讓整個研發(fā)過程更高效。

舉個例子，從我家到汽車公司的路線，我已經(jīng)知道了 3 條很快的步行路徑。接下來我要做的就不再是用步行的方式，尋找一條新的路徑。因為最短的路線已經(jīng)尋找出來了，而且我已經(jīng)很熟悉了，再去尋找新的路線已經(jīng)沒有意義了。這個時候我就需要考慮，能否使用什么交通工具，進一步縮短上班時間。 ?

03.ASPICE與敏捷開發(fā)融合

?接下來我們就要談?wù)凙SPICE和敏捷開發(fā)的結(jié)合了。剛剛已經(jīng)講了很多ASPICE，它其實是軟件流程的評價框架，是甲方對乙方的要求。那么敏捷是什么呢？敏捷其實是一種軟件開發(fā)的理念、價值觀和一系列工具的融合。它的出發(fā)點和 ASPICE完全不一樣。 ASPICE的出發(fā)點是甲方對乙方的要求，而敏捷的出發(fā)點其實是站在乙方的角度，討論如何快速地實現(xiàn)軟件開發(fā)。所以敏捷實際上是來告訴大家怎么樣真正地來實現(xiàn)這個過程的。

ASPICE是一個要求，甲方要求乙方做什么。敏捷是說，乙方怎么來快速地做這個東西。這個其實就是目前汽車行業(yè)轉(zhuǎn)型的困境：大家都知道要轉(zhuǎn)型，但沒有人知道該怎么轉(zhuǎn)，沒有人知道該怎么融合，標準也還沒出來。 敏捷里面講到了很多理念，比如說可工作的軟件，高于詳細的文檔。敏捷里面也提供了很多理論化的工具，比如說 scrum、Kanban、燃盡圖、敏捷回顧會議等等。我們可以看到有很多軟件公司就是基于這樣一套方法來設(shè)計他們的軟件，比如說澳洲的 Atlassion 公司。 我們談完了ASPICE和敏捷，我們知道ASPICE是對于汽車行業(yè)軟件開發(fā)流程的標準。

雖然它誕生于2005年，已經(jīng)有17 年的歷史了，但汽車軟件開發(fā)（中國的），真正發(fā)生革命性的變化，是在2014年前后，在汽車行業(yè)還沒有誕生一個新的軟件開發(fā)標準之前，它還是有它存在的意義的。 我覺得這個新的軟件開發(fā)標準，應(yīng)該會在近幾年誕生，因為最近幾年整個汽車行業(yè)的變革是非常快的，可以說是顛覆性的，整個汽車行業(yè)變得非常有活力。這個時間點，特別適合產(chǎn)生新的軟件開發(fā)流程。這個新的軟件開發(fā)流程或者標準，也很有可能是在中國誕生的。因為中國的電動車或者說智能車的生產(chǎn)比例，占全球總數(shù)的40%以上。在這塊我們是有優(yōu)勢的。

筆者曾在造車新勢力及傳統(tǒng)車企的軟件中心從事軟件質(zhì)量與工具鏈的工作，在深入接觸并應(yīng)用ASPICE之后，覺得ASPICE不是一顆銀彈，不要認為它能夠解決所有的問題，它只是一個老師對于學生或者甲方對于乙方的要求。如果你去深入地挖掘這個要求，然后自己想出一套方法來做，當然也可以，但是你的效率會特別慢，因為整個汽車軟件的研發(fā)過程比較復雜。 基于前文提到的問題，去年，我和幾個小伙伴一起出來創(chuàng)業(yè)了，我們產(chǎn)品的設(shè)計思路是，基于ASPICE的開發(fā)理念，進行工具設(shè)計，通過工具來實現(xiàn)高效的追溯性和合規(guī)性的建立。如果滿足標準本身并不繁瑣，那么工程師會更樂意去滿足標準，同時又能實現(xiàn)敏捷。 舉個例子，在 ASPICE里面有非常強的追溯性要求。我們通過思維導圖的方式來建立追溯性，因為思維導圖天生具有上下文的追溯性。不同的思維導圖之間，也能通過關(guān)聯(lián)透視圖的方式來建立追溯性。

再舉一個例子，比如在ASPICE里面，我們經(jīng)常提到評審的概念。也就是說，不管是你的軟件需求還是軟件架構(gòu)，一個人做好之后，需要和團隊其他成員進行評審。那么在敏捷開發(fā)里面這個評審可能就是現(xiàn)場的評審。這種討論相對來說比較開放式的，它其實沒有很好的記錄。我們把這樣一個評審融入到了工具里面，比如說基于思維導圖，我可以向多個人或者指定的評審委員會發(fā)送評審請求。他看到這個思維導圖，直接對它進行評審，通過還是不必通過，不通過他可以寫一些評論。我們會自動計算所有人的評論結(jié)果，最后來決定這個評審是通過還是不通過。整個過程也會在工具里面留下記錄。

總結(jié)一下：ASPICE不是銀彈，滿足了ASPICE標準，并不代表你能開發(fā)出好的產(chǎn)品。如果實現(xiàn)標準的過程不繁瑣，工程師也樂于去實現(xiàn)標準。既能滿足標準，又能快捷高效，是工具鏈搭建的方向。

審核編輯：劉清