汽車行業(yè)的軟件開發(fā)標(biāo)準(zhǔn)，最著名的應(yīng)該是V模型。以V模型為代表的有ASPICE、 ISO 26262 和 ISO/SAE 21434。今天我們主要以ASPICE為基礎(chǔ)，探討V模型在當(dāng)前汽車軟件變革時(shí)代的特點(diǎn)。

傳統(tǒng)的V模型標(biāo)準(zhǔn)在當(dāng)前這個(gè)階段，有點(diǎn)使不上勁兒。

這個(gè)要怎么理解呢？首先我們要明確ASPICE的一個(gè)特點(diǎn)。ASPICE標(biāo)準(zhǔn)采用的是一種“命題提綱”式的寫法。十幾年了，還在使用，并且我們一直沒有聽說，有什么大的錯(cuò)誤，因?yàn)閷懙米銐驅(qū)挿骸?/p>

我們舉幾個(gè)例子。在 ASPICE 的供應(yīng)商監(jiān)控部分，他寫了 5 條BP，分別是：

第一個(gè)BP是，要和供應(yīng)商之間達(dá)成并且維護(hù)一個(gè)聯(lián)合開發(fā)的措施或接口，使得信息可以進(jìn)行交換（至于聯(lián)合的過程，或者接口應(yīng)該是什么樣的，在ASPICE 里面并沒有進(jìn)行描述）。

第二個(gè) BP 是，交換所有經(jīng)過雙方同意的信息。

第三個(gè)BP是，和供應(yīng)商一起評審技術(shù)開發(fā)過程。

第四個(gè) BP 是，評審供應(yīng)商的進(jìn)度。

第五個(gè) BP 是。對偏差有所行動(dòng)。

可以看到，這些BP，實(shí)際上是一種非常寬泛的行為描述。至于這個(gè)行為應(yīng)該怎么做，在標(biāo)準(zhǔn)里面是沒有體現(xiàn)的。

所以ASPICE的標(biāo)準(zhǔn)，有非常大的靈活度去進(jìn)行解讀。這也是為什么，在十幾年的過程中，它一直沒有什么大的錯(cuò)誤的原因。它所說的這些過程，其實(shí)是一個(gè)正常的產(chǎn)品開發(fā)或者項(xiàng)目管理的通用過程。但是在當(dāng)前這個(gè)汽車軟件變革的階段，我們需要的是，標(biāo)準(zhǔn)告訴我們怎么做，而不再是給我們一個(gè)命題作文。

從傳統(tǒng)汽車向智能網(wǎng)聯(lián)汽車轉(zhuǎn)型的時(shí)代，所有人對這種新模式，都是處在一個(gè)探索的過程。這種探索既包括軟件供應(yīng)商，還有主機(jī)廠。如果ASPICE真是一劑神藥，那標(biāo)準(zhǔn)的制訂方之一，德國大眾的新車，就不至于在停車場趴窩幾個(gè)月了。

所以，這就是我的結(jié)論：傳統(tǒng)的V模型開發(fā)標(biāo)準(zhǔn)，在當(dāng)前這個(gè)階段使不上勁兒，單純的命題作文，在這個(gè)階段不奏效，還需要實(shí)際的解題方法。

在當(dāng)前這個(gè)階段，越來越多的主機(jī)廠和新勢力，采取了另外一種開發(fā)模式，敏捷開發(fā)。

敏捷開發(fā)尚未形成一個(gè)標(biāo)準(zhǔn)，而只是一些思想、工具和實(shí)踐。敏捷開發(fā)，更多的好像是一個(gè)非常優(yōu)秀的“考生”，寫的一份備考指南，里面講到了很多方法。這個(gè)考生上來就說：你不要想著一次就把事情做對、做完（因?yàn)槭虑樘珡?fù)雜了），你先去做就好了，做出一個(gè)原型，通過快速驗(yàn)證，你很快就能發(fā)現(xiàn)其中的問題，再去改，保證你的每一次，都比上次做得好，而且你的每一次，都是當(dāng)前這個(gè)階段最想要的。然后他開始告訴你，這個(gè)過程中，你的武器庫里面有多少武器可以使用，比如敏捷看板、需求優(yōu)先級的排序、敏捷報(bào)表、功能回顧會(huì)、每日站會(huì)等等。正是由于這位“考生”寫作的出發(fā)點(diǎn)，導(dǎo)致了很多爭議。因?yàn)槲覀冎溃瑯右环菘季?，同樣一個(gè)應(yīng)用題，不同的人去做，可以采用不同的方法，并且大家都能夠做對。這就像，市面上有黃岡老師的答題技巧，也有人大附中的答題技巧，但是高考出題提綱只有一份。

敏捷開發(fā)這套思想的推動(dòng)者，最開始并沒有太大野心。他們想做的只是告訴程序員，告訴項(xiàng)目管理者，怎樣去管理一個(gè)項(xiàng)目，怎樣在不同的角色之間進(jìn)行協(xié)作。它沒有對行業(yè)做什么要求，它也并不是針對汽車行業(yè)的。所以這樣的一種方法，在被汽車行業(yè)運(yùn)用的時(shí)候，必然會(huì)產(chǎn)生很多的爭論。

我之前也寫過了一篇文章《ASPICE 還值得做嗎？》，從評論中也可以看得出來，敏捷開發(fā)在汽車行業(yè)充滿了爭論。有些人對敏捷開發(fā)保持了冷嘲熱諷的態(tài)度。實(shí)際上包括特斯拉以及國內(nèi)的造車新勢力，基本上都在采用一種小步快跑，持續(xù)迭代的的方式來做軟件開發(fā)。特斯拉的FSD功能，在已交付的車輛上，以肉眼可見的速度進(jìn)化和升級。當(dāng)汽車行業(yè)很多頭部企業(yè)，都已經(jīng)在或多或少嘗試敏捷開發(fā)的思想時(shí)，還有一些人仍然停留在自己的看法里。

當(dāng)然，我們不得不承認(rèn)的一個(gè)事實(shí)是，敏捷開發(fā)在汽車行業(yè)尚未得到大規(guī)模的認(rèn)可，我覺得這個(gè)也很正常，當(dāng)前汽車行業(yè)正在進(jìn)行一場變革，在變革的過程中肯定是百家爭鳴，大家都有各自方式。而且也未形成變革后的統(tǒng)一標(biāo)準(zhǔn)，在這個(gè)時(shí)候產(chǎn)生比較多的爭論，是有益于行業(yè)進(jìn)步的。

今天文章的主題，我想預(yù)測一下，汽車行業(yè)的軟件開發(fā)標(biāo)準(zhǔn)，將向一個(gè)什么樣的方向進(jìn)行演進(jìn)。

我預(yù)測的第一點(diǎn)是，V模型將吸納敏捷開發(fā)的特點(diǎn)，形成新的標(biāo)準(zhǔn)。

雖然敏捷開發(fā)并未形成汽車行業(yè)的標(biāo)準(zhǔn)，但卻有非常多的團(tuán)隊(duì)以此種方法來進(jìn)行實(shí)踐。

有很多公司找我們咨詢汽車行業(yè)敏捷開發(fā)相關(guān)的工具鏈，我們發(fā)現(xiàn)他們或多或少都已經(jīng)開始使用敏捷項(xiàng)目管理工具。業(yè)界對這種趨勢應(yīng)該有更加明顯的感受。

在汽車行業(yè)新的軟件標(biāo)準(zhǔn)中，我預(yù)計(jì)，一定會(huì)是接納并且認(rèn)可小步快跑、持續(xù)迭代這樣一種思想的。V模型也不應(yīng)該簡單地被看作是瀑布流。V模型的編寫方式，并未提到它是一個(gè)瀑布流。但是我們從它上下文的行文中，很容易把它理解成一個(gè)瀑布流。比如，在我們做軟件架構(gòu)設(shè)計(jì)的時(shí)候，一定是對軟件需求分析已經(jīng)經(jīng)過了大量的討論，經(jīng)過了大家的認(rèn)可，但是并未提到，如果需求本身不全會(huì)怎樣？如果需求沒有理清楚，沒有經(jīng)過充分的討論，我們是否能夠去做架構(gòu)方面的設(shè)計(jì)？是否可以并行？需求是逐漸完善的過程、架構(gòu)也是逐漸完善的過程，在完善的過程中，再逐漸去建立追溯性，是否可行？

變更在開發(fā)過程中，是不可避免的，但在ASPICE中，變更管理是一個(gè)支持性流程，好像變更并不是在每個(gè)過程中進(jìn)行的，而像是項(xiàng)目做到一定階段之后，反過來進(jìn)行的、偶爾的偏差改動(dòng)。但實(shí)際上，變更管理應(yīng)該被提到一個(gè)更重要、更頻繁的位置，因?yàn)樵谄囎兏锏倪^程中，我們所做的很多技術(shù)和產(chǎn)品，不確定性是非常高的，我們會(huì)面臨更加頻繁的變更。

在產(chǎn)品的初期，我們可能沒有辦法考慮到方方面面，我們擁有的是一個(gè)產(chǎn)品的Roadmap。但是針對 Roadmap 里面的每一個(gè)功能點(diǎn)，可能并不是在最開始的時(shí)候，就去詳細(xì)地寫出所有需求的細(xì)節(jié)，而是在做的過程中不斷完善。通過不斷地交付出一些可工作的產(chǎn)物，對需求也會(huì)不斷做出調(diào)整。

第二點(diǎn)，我預(yù)計(jì)新的標(biāo)準(zhǔn)，會(huì)對 BP 進(jìn)行更多的細(xì)化，并且也會(huì)推薦一些敏捷開發(fā)方法。

前面我們已經(jīng)舉過例子，在ASPICE里面，BP一般寫的都比較粗。具體怎么做，其實(shí)沒有很多的方法推薦。我估計(jì)新的標(biāo)準(zhǔn)中，會(huì)比較多的推薦敏捷開發(fā)的方法。如果某種解題方法是比較好的，我們需要把這種方法在標(biāo)準(zhǔn)里面體現(xiàn)出來，雖然這并不是強(qiáng)制性要求，但至少給我們提供了一些參考。這樣才能讓標(biāo)準(zhǔn)能夠逐漸融合敏捷開發(fā)。

第三點(diǎn)是，如何與第三方進(jìn)行合作，將會(huì)是標(biāo)準(zhǔn)的重要組成部分。

在ASPICE原來的標(biāo)準(zhǔn)中，針對如何與第三方進(jìn)行合作，其實(shí)篇幅很少，有一塊叫做供應(yīng)商管理。

但是，在新的標(biāo)準(zhǔn)中，如何與第三方合作，應(yīng)該有大量的篇幅去解讀它。在當(dāng)前的汽車軟件開發(fā)過程中，我們發(fā)現(xiàn)，聯(lián)合開發(fā)變成了一種常態(tài)，導(dǎo)致了像 Tier 0. 5 這樣一些合作方式出現(xiàn)。

在傳統(tǒng)的標(biāo)準(zhǔn)中，我們一般只是強(qiáng)調(diào)，需要和供應(yīng)商之間進(jìn)行溝通，需要有與供應(yīng)商之間進(jìn)行信息交換的渠道，需要與供應(yīng)商達(dá)成統(tǒng)一等等。

但在新的開發(fā)過程中，我們需要意識(shí)到，我們不僅與供應(yīng)商之間會(huì)進(jìn)行聯(lián)合開發(fā)，與甲方客戶之間也需要進(jìn)行聯(lián)合開發(fā)。而且聯(lián)合開發(fā)的過程相比于原來會(huì)更加頻繁和緊密，它不再是一個(gè)交鑰匙的工程。對于一個(gè)軟件或系統(tǒng)的開發(fā)，不同的軟件組件可能是由不同的參與方來執(zhí)行的。這個(gè)時(shí)候就要求我們在需求管控、問題管理上擁有更加實(shí)時(shí)的交流渠道，互相可以對對方提需求、提bug，并且大家好像是在一個(gè)管理系統(tǒng)上進(jìn)行工作。這對于提升軟件的開發(fā)效率是非常有必要的。

第四點(diǎn)是，CICD 將成為 BP 之一，缺少 CICD 的基礎(chǔ)設(shè)施，意味著產(chǎn)品不具備持續(xù)迭代的屬性。

在 ASPICE原來的標(biāo)準(zhǔn)中，對于持續(xù)集成、持續(xù)交付、持續(xù)部署，并沒有特地強(qiáng)調(diào)。只是描述了針對軟件的驗(yàn)證過程，需要有軟件單元測試、軟件集成測試、軟件功能測試等等。更多還是強(qiáng)調(diào)，針對需求、架構(gòu)、詳細(xì)設(shè)計(jì)的可追溯性和完全覆蓋。至于驗(yàn)證的過程要怎么做，并未提出要求。可以預(yù)見，未來甲方的需求會(huì)越來越多，且越來越頻繁，CICD基礎(chǔ)設(shè)施將是響應(yīng)這一變化的關(guān)鍵。我們有一家做氣體傳感器的客戶，其德方客戶明確提出要求，研發(fā)過程必須上系統(tǒng)，且必須擁有統(tǒng)一的代碼倉庫和持續(xù)集成的能力（雖然這家客戶本身的代碼量不多，之前的代碼全部放在工程師的電腦里進(jìn)行管理）。但德方客戶考慮到，后續(xù)市場或法規(guī)對于車內(nèi)空氣的更高要求，可能需要在更短時(shí)間內(nèi)，提供更新迭代的產(chǎn)品。