場景一：用戶需求初始模糊，隨著開發(fā)的演進，需求變更頻繁。

場景二：該產(chǎn)品由具有相同重要性的硬件和軟件組件組成（兩者都不占主導(dǎo)地位）。

場景三：該產(chǎn)品是一款涉及復(fù)雜后端和前端技術(shù)的軟件（在這種情況下，后端將使用瀑布模型開發(fā)）。

場景四：可能不是基于項目本身的特征。在通常情況下，客戶不會干擾項目的執(zhí)行方式，因此可以使用敏捷與瀑布融合的開發(fā)模型。例如，瀑布方法可用于應(yīng)用產(chǎn)品規(guī)劃、需求定義和設(shè)計，而敏捷可用于開發(fā)和測試。

如上所述，由于沒有一刀切的解決方案，實施雙態(tài)敏捷開發(fā)模型方法需要因地制宜，根據(jù)項目本身特性進行靈活部署，同時在其他人的失敗案列中吸取教訓(xùn)，作為最佳實踐指導(dǎo)。根據(jù)我們在實際項目中的推進經(jīng)驗，以下建議可供參考：

·  制定計劃，需求分析與設(shè)計階段可以通過瀑布模型完成，開發(fā)與測試階段采用敏捷開發(fā)以迭代或增量開發(fā)的方式通過短期的沖刺來完成；

·  產(chǎn)品負責人和客戶定期進行溝通，確保所有干系人都深度參與本產(chǎn)品的整個開發(fā)生命周期；

·  從設(shè)計階段開始融合標準、法律法規(guī)等要求?？梢酝ㄟ^功能強大的工作流管理工具保證整個生命周期執(zhí)行已定義的合規(guī)流程以達到加快產(chǎn)品開發(fā)的目的；

·  使用協(xié)作軟件作為支持數(shù)據(jù)共享、通信和可追溯性的解決方案，同時也需要根據(jù)新的協(xié)作工具同步更新交流方式。

(3) 汽車行業(yè)應(yīng)用解決方案

如上所述，通常認為使用瀑布進行整體項目開發(fā)是一種可靠的模型，但敏捷模型卻可以賦予軟件開 發(fā)可受益的靈活性。軟件生命周期管理工具、自動集成 CI/CD 和自動化測試系統(tǒng)的打通，能大大減少時間成本，提升軟件產(chǎn)品品質(zhì)。利用工具自動化生成符合功能安全或 ASPICE  要求的各種檢查記錄及文檔， 使得在敏捷的產(chǎn)品管理中也不會忽視瀑布模型的要求。

在汽車基礎(chǔ)軟件領(lǐng)域，有很多軟件具備可復(fù)用的特點。汽車軟件服務(wù)商要建立企業(yè)軟件產(chǎn)品庫，針 對不同客戶的不同需求可很快拿出相似產(chǎn)品的原型版本進行功能展示。這樣，不僅能提升開發(fā)的效率， 而且也符合敏捷思想。在后面的項目開發(fā)實際開始時，可基于該原型版本，采用敏捷迭代開發(fā)模式，運 用用戶故事、故事點和燃盡圖等敏捷開發(fā)工具可助力項目的正常進行。當開發(fā)開始后，同時開展測試相關(guān)流程，可及時發(fā)現(xiàn)問題，最終確保將優(yōu)質(zhì)產(chǎn)品交付給客戶。

借助軟件生命周期管理工具，可根據(jù)項目范圍、質(zhì)量要求、功能要求對開發(fā)流程做適當?shù)倪m配。此外， 該工具還可以提升問題管理、變更管理和文檔記錄管理等流程的效率。同時使用軟件生命周期管理工具也能促進工程開發(fā)活動的效率提升，如自動集成、自動測試、偽代碼和代碼框架的生成等。

(4) 意義與展望

無論是瀑布模型還是敏捷模型，都無法在當今的軟件定義汽車趨勢中完美的滿足需求。汽車行業(yè)的要求不同于一般互聯(lián)網(wǎng)行業(yè)的開發(fā)要求，需既要考慮進度，也要同時兼顧質(zhì)量和安全。

瀑布模型和敏捷模型有各自的適用場景。在傳統(tǒng)汽車軟件范圍，瀑布模型之所以能得到很好的應(yīng)用， 是因為傳統(tǒng)的汽車 ECU 功能分配趨于完善，各種功能需求已經(jīng)很明確，并且硬件平臺趨于大同，傳統(tǒng)的軟件功能不會有太多變化，因此瀑布模型很適合于傳統(tǒng)的 ECU 開發(fā)。

但是在 “軟件定義汽車”  的時代背景下，會遇到很多需求不明確的場景，項目范圍的頻繁變更更是讓傳統(tǒng)的瀑布模型無法應(yīng)對。因此引入敏捷模型的思想，借鑒它可以很好的適應(yīng)需求變化，快速打造產(chǎn)品原型，以及可靈活的在需求的變化中進行不斷迭代的特點，將其融入到傳統(tǒng)的瀑布模型中，形成了現(xiàn)在的雙態(tài)開發(fā)模型。可以讓汽車軟件開發(fā)在適應(yīng)需求變化的同時重拾對質(zhì)量追溯文檔記錄的重視。

“瀑布式計劃，敏捷執(zhí)行，并加快整個過程?！?雙態(tài)敏捷開發(fā)模型以敏捷思想的框架，在每一個迭代中融入瀑布模型，既解決了單一的瀑布模型不能適應(yīng)需求不明確的情況，也解決了單純敏捷模型帶來的文檔化不足的問題，讓項目風險可更早的被監(jiān)控到，可用的工作產(chǎn)品能更早地展示給客戶。

4.4.2  自動化編譯框架

1.  問題與挑戰(zhàn)

隨著 E/E 架構(gòu)從基于多 MCU 的分布式架構(gòu)發(fā)展至基于高性能計算中心的集中式架構(gòu)，對于軟件開發(fā)人員而言，將已有硬件平臺上的應(yīng)用進行復(fù)用或遷移是一項龐大的工作。在進行開發(fā)時，開發(fā)團隊經(jīng)常遇到的棘手問題就是如何將已有的軟件算法快速編譯和部署到不同的硬件環(huán)境或平臺上。

此外，由于全球疫情以及政治問題的影響，芯片出現(xiàn)產(chǎn)能不足或面臨斷供的問題。因此芯片的反復(fù)變更在所難免，由此導(dǎo)致集成開發(fā)環(huán)境反復(fù)切換，這極大的分散了企業(yè)聚焦新功能開發(fā)的精力。

如何提供自動化編譯框架用于解決硬件平臺的切換以及屏蔽硬件差異，更好地實現(xiàn)應(yīng)用的快速開發(fā)和部署成為一個重要的課題。下文會給出通用自動化編譯框架的解決方案以供參考，并對提供自動化編譯框架的意義進行展望。

2.  解決方案

自動化編譯框架采用基于模型的方式進行，通過模型屏蔽不同層級的細節(jié)，從而實現(xiàn)解耦以及快速復(fù)用。自動化編譯框架的組成如下圖 4.4-1：

圖4.4-1 自動化編譯框架一般組成

自動化編譯框架由 4 部分組成（即硬件層之上的部分）：

·  模型層

·  實時框架抽象層

·  目標平臺抽象層

·  第三方或遺留代碼

接下來對自動化編譯框架的組成及運行原理進行詳細介紹。

（1）自動化編譯框架組成介紹