傳統的V模型標準在當前這個階段，有點使不上勁兒。
這個要怎么理解呢？首先我們要明確ASPICE的一個特點。ASPICE標準采用的是一種“命題提綱”式的寫法。十幾年了，還在使用，并且我們一直沒有聽說，有什么大的錯誤，因為寫得足夠寬泛。
我們舉幾個例子。在 ASPICE 的供應商監控部分，他寫了 5 條BP，分別是：
可以看到，這些BP，實際上是一種非常寬泛的行為描述。至于這個行為應該怎么做，在標準里面是沒有體現的。
所以ASPICE的標準，有非常大的靈活度去進行解讀。這也是為什么，在十幾年的過程中，它一直沒有什么大的錯誤的原因。它所說的這些過程，其實是一個正常的產品開發或者項目管理的通用過程。但是在當前這個汽車軟件變革的階段，我們需要的是，標準告訴我們怎么做，而不再是給我們一個命題作文。
從傳統汽車向智能網聯汽車轉型的時代，所有人對這種新模式，都是處在一個探索的過程。這種探索既包括軟件供應商，還有主機廠。如果ASPICE真是一劑神藥，那標準的制訂方之一，德國大眾的新車，就不至于在停車場趴窩幾個月了。
所以，這就是我的結論：傳統的V模型開發標準，在當前這個階段使不上勁兒，單純的命題作文，在這個階段不奏效，還需要實際的解題方法。
在當前這個階段，越來越多的主機廠和新勢力，采取了另外一種開發模式，敏捷開發。
敏捷開發尚未形成一個標準，而只是一些思想、工具和實踐。敏捷開發，更多的好像是一個非常優秀的“考生”，寫的一份備考指南，里面講到了很多方法。這個考生上來就說：你不要想著一次就把事情做對、做完（因為事情太復雜了），你先去做就好了，做出一個原型，通過快速驗證，你很快就能發現其中的問題，再去改，保證你的每一次，都比上次做得好，而且你的每一次，都是當前這個階段最想要的。然后他開始告訴你，這個過程中，你的武器庫里面有多少武器可以使用，比如敏捷看板、需求優先級的排序、敏捷報表、功能回顧會、每日站會等等。正是由于這位“考生”寫作的出發點，導致了很多爭議。因為我們知道，同樣一份考卷，同樣一個應用題，不同的人去做，可以采用不同的方法，并且大家都能夠做對。這就像，市面上有黃岡老師的答題技巧，也有人大附中的答題技巧，但是高考出題提綱只有一份。
敏捷開發這套思想的推動者，最開始并沒有太大野心。他們想做的只是告訴程序員，告訴項目管理者，怎樣去管理一個項目，怎樣在不同的角色之間進行協作。它沒有對行業做什么要求，它也并不是針對汽車行業的。所以這樣的一種方法，在被汽車行業運用的時候，必然會產生很多的爭論。
我之前也寫過了一篇文章《ASPICE 還值得做嗎?》，從評論中也可以看得出來，敏捷開發在汽車行業充滿了爭論。有些人對敏捷開發保持了冷嘲熱諷的態度。實際上包括特斯拉以及國內的造車新勢力，基本上都在采用一種小步快跑，持續迭代的的方式來做軟件開發。特斯拉的FSD功能，在已交付的車輛上，以肉眼可見的速度進化和升級。當汽車行業很多頭部企業，都已經在或多或少嘗試敏捷開發的思想時，還有一些人仍然停留在自己的看法里。
當然，我們不得不承認的一個事實是，敏捷開發在汽車行業尚未得到大規模的認可，我覺得這個也很正常，當前汽車行業正在進行一場變革，在變革的過程中肯定是百家爭鳴，大家都有各自方式。而且也未形成變革后的統一標準，在這個時候產生比較多的爭論，是有益于行業進步的。
今天文章的主題，我想預測一下，汽車行業的軟件開發標準，將向一個什么樣的方向進行演進。
我預測的第一點是，V模型將吸納敏捷開發的特點，形成新的標準。
雖然敏捷開發并未形成汽車行業的標準，但卻有非常多的團隊以此種方法來進行實踐。
有很多公司找我們咨詢汽車行業敏捷開發相關的工具鏈，我們發現他們或多或少都已經開始使用敏捷項目管理工具。業界對這種趨勢應該有更加明顯的感受。
在汽車行業新的軟件標準中，我預計，一定會是接納并且認可小步快跑、持續迭代這樣一種思想的。V模型也不應該簡單地被看作是瀑布流。V模型的編寫方式，并未提到它是一個瀑布流。但是我們從它上下文的行文中，很容易把它理解成一個瀑布流。比如，在我們做軟件架構設計的時候，一定是對軟件需求分析已經經過了大量的討論，經過了大家的認可，但是并未提到，如果需求本身不全會怎樣？如果需求沒有理清楚，沒有經過充分的討論，我們是否能夠去做架構方面的設計？是否可以并行？需求是逐漸完善的過程、架構也是逐漸完善的過程，在完善的過程中，再逐漸去建立追溯性，是否可行？
變更在開發過程中，是不可避免的，但在ASPICE中，變更管理是一個支持性流程，好像變更并不是在每個過程中進行的，而像是項目做到一定階段之后，反過來進行的、偶爾的偏差改動。但實際上，變更管理應該被提到一個更重要、更頻繁的位置，因為在汽車變革的過程中，我們所做的很多技術和產品，不確定性是非常高的，我們會面臨更加頻繁的變更。
在產品的初期，我們可能沒有辦法考慮到方方面面，我們擁有的是一個產品的Roadmap。但是針對 Roadmap 里面的每一個功能點，可能并不是在最開始的時候，就去詳細地寫出所有需求的細節，而是在做的過程中不斷完善。通過不斷地交付出一些可工作的產物，對需求也會不斷做出調整。
第二點，我預計新的標準，會對 BP 進行更多的細化，并且也會推薦一些敏捷開發方法。
前面我們已經舉過例子，在ASPICE里面，BP一般寫的都比較粗。具體怎么做，其實沒有很多的方法推薦。我估計新的標準中，會比較多的推薦敏捷開發的方法。如果某種解題方法是比較好的，我們需要把這種方法在標準里面體現出來，雖然這并不是強制性要求，但至少給我們提供了一些參考。這樣才能讓標準能夠逐漸融合敏捷開發。
第三點是，如何與第三方進行合作，將會是標準的重要組成部分。
在ASPICE原來的標準中，針對如何與第三方進行合作，其實篇幅很少，有一塊叫做供應商管理。
但是，在新的標準中，如何與第三方合作，應該有大量的篇幅去解讀它。在當前的汽車軟件開發過程中，我們發現，聯合開發變成了一種常態，導致了像 Tier 0. 5 這樣一些合作方式出現。
在傳統的標準中，我們一般只是強調，需要和供應商之間進行溝通，需要有與供應商之間進行信息交換的渠道，需要與供應商達成統一等等。
但在新的開發過程中，我們需要意識到，我們不僅與供應商之間會進行聯合開發，與甲方客戶之間也需要進行聯合開發。而且聯合開發的過程相比于原來會更加頻繁和緊密，它不再是一個交鑰匙的工程。對于一個軟件或系統的開發，不同的軟件組件可能是由不同的參與方來執行的。這個時候就要求我們在需求管控、問題管理上擁有更加實時的交流渠道，互相可以對對方提需求、提bug，并且大家好像是在一個管理系統上進行工作。這對于提升軟件的開發效率是非常有必要的。
第四點是，CICD 將成為 BP 之一，缺少 CICD 的基礎設施，意味著產品不具備持續迭代的屬性。
在 ASPICE原來的標準中，對于持續集成、持續交付、持續部署，并沒有特地強調。只是描述了針對軟件的驗證過程，需要有軟件單元測試、軟件集成測試、軟件功能測試等等。更多還是強調，針對需求、架構、詳細設計的可追溯性和完全覆蓋。至于驗證的過程要怎么做，并未提出要求?？梢灶A見，未來甲方的需求會越來越多，且越來越頻繁，CICD基礎設施將是響應這一變化的關鍵。我們有一家做氣體傳感器的客戶，其德方客戶明確提出要求，研發過程必須上系統，且必須擁有統一的代碼倉庫和持續集成的能力（雖然這家客戶本身的代碼量不多，之前的代碼全部放在工程師的電腦里進行管理）。但德方客戶考慮到，后續市場或法規對于車內空氣的更高要求，可能需要在更短時間內，提供更新迭代的產品。
轉自汽車電子與軟件
