一、為什么汽車行業沒有敏捷開發的說法，而是ASPICE的V型開發模型

首先汽車行業沒有敏捷開發的說法是錯誤的，敏捷開發這個理念也適用于汽車軟件的開發，更有理念的堅定支持者，比如特斯拉，把敏捷開發的理念貫徹到整車的開發中（優劣先不評判）。

ASPICE里的Process reference model里有一大過程分類中包含系統工程和軟件工程的開發過程，這個過程套用的就是V型開發模型。

這里面提到的軟件工程是依據系統工程開發時所衍生出的軟件需求管理，所以也包含在系統工程的框架中。

以傳動系統中的控制軟件為例，控制軟件的前期需求是確切的，開發過程中很少有變更的需求，更多的需求在于如何完美的實現，而且軟件的開發也依托在傳動系統的開發流程上，所以自然而然地就使用V型開發模型了。

敏捷開發需要做什么適配

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

并不是用敏捷開發出來的軟件架構就會松散，臃腫，而是敏捷的環境讓工程師更容易輸出這樣的結果。所以我認為以下措施的執行能有效改善軟件質量：適當延長Sprint周期；嚴格的編碼規范與培訓；使用TDD（測試驅動開發）思路強大的devops能力作為技術保證；引入自動化單元檢查工具；滿足功能安全要求，話只有一句，其實是個悖論，因為軟件功能安全=V模型開發。可能的一個解決方案，是利用26262中FFI的思路，通過前期技術規劃，將軟件架構分解成功能：QM(D)和功能安全軟件D(D)，功能分區使用敏捷開發小步快走，功能安全分區還是按V模型進行開發（思路是這么個思路，但做軟件安全分析和安全架構設計需要非常小心，而且僅適用于SAFety goal為fail SAFe的域控，如果L4以上需要做fail operational的，又不能這么玩了）。

延伸閱讀：

二、敏捷的缺點

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

缺少統籌全局的進行軟件架構設計，導致模塊很難做到高類聚低耦合，比如Sprint A實現的一個功能，其底層模塊其實可以被Sprint B的某個功能部分復用，但由于Sprint A沒有考慮Sprint B的開發需求，所以該底層模塊并不能被完全復用，Sprint B可能就要重新開發一個底層模塊去覆蓋他自己的需求。多輪Sprint下來，可能會有重復造相似輪子的情況出現。這樣會導致軟件比較臃腫，代碼量大，執行效率低，且代碼質量不高；缺少集成測試，導致新加的功能可能對已實現的功能有潛在的影響而不能被發現；由于短平快的特性，很多時候單元測試也不能充分進行，比如動態單元測試；與FUSA的流程完全不兼容。26262也好，61508也好，34590也好，都是植根于V模型，使用敏捷開發的軟件，很難滿足功能安全的開發要求，也無法做功能安全分析，無法做FFI。