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

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

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

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

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

敏捷開發(fā)需要做什么適配

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

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

延伸閱讀：

二、敏捷的缺點

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

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