一、為什么汽車行業(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。