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

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

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

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

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

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

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

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

延伸閱讀：

二、敏捷的缺點(diǎn)

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

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