目前汽車電子產品，特別是汽車幾大域控（如：智能座艙、智能駕駛、智能網聯、車身控制），市場競爭激烈：隨著科技的發展，越來越多的企業開始進入這些領域。傳統車企、互聯網公司、初創企業都在這個領域進行布局，使得市場競爭異常激烈。
另外用戶需求變化：隨著消費者對汽車的需求逐漸多元化和個性化，用戶對座艙和智駕產品的要求也越來越高。他們不僅要求產品具有創新性和科技感，還要求產品能夠提供更加優質、便捷的駕駛體驗。
在上述因素的加持下，無論是設計方還是軟件實現方，均對現狀不滿意。主要體現在以下幾個方面：
1.需求的不斷更改
為了能吸引用戶，在汽車研發初期，設計方會提出很多新穎的概念，往往這些概念不太成熟，隨著時間的積累，設計方通過用戶調研、競爭對手分析，會不斷地更改和追加新需求來完善想法，提高產品質量和用戶體驗。但產品的最終交付時間并不會變更。
2. 最終實現和最初期望背離
汽車電子產品具有復雜性的特點，這種復雜性不僅來自于產品軟件本身的功能需求，還來自于與汽車各個子系統的交互，以及對于安全性和可靠性的嚴格要求，一個汽車電子產品需要與多種硬件設備進行集成，如傳感器、執行器、控制器等。這些硬件設備的多樣性增加了軟件的復雜性和開發難度。因為這種復雜性存在，在產品的最終實現和最初的預期往往存在較大的偏差：
3. 整車開發周期越來越短
國內汽車主機廠，特別是新能源車企，整車開發周期越來越短，配套的電子產品的開發周期也相應的被壓縮。
#02 當前汽車電子產品研發流程
V 模型由如下的幾個特點：
1、嚴謹的階段劃分
V 模型將軟件開發劃分為一系列嚴謹的階段，包括需求分析，系統設計，編程，系統測試等。每個階段都有明確的輸入和輸出，以及嚴格的驗收標準。
2、 早期驗證和驗證
V 模型強調在軟件開發的早期階段進行驗證和驗證，以便盡早發現和修復錯誤。
3、文檔驅動
V 模型強調文檔的重要性，每個階段都需要產生詳細的文檔，用于記錄決策，傳遞信息，以及后續的維護和支持。
它的優勢主要體現在
1、 提高客戶滿意度
它是標準化軟件開發流程，是客戶和產品開發方的共同語言，通過實施 V 模型，方便客戶進行評審和管控供應商開發質量。
2、提高產品質量
通過規范和標準化軟件開發流程，有助于降低產品缺陷率和提高產品質量。
3、 促進持續改進
V 模型重視文檔管理，強調持續改進和優化，有利于在開發過程中不斷發現問題、分析問題并采取措施解決問題。并且有利于將其他項目或者上一個項目的經驗教訓展開到現有項目。
它的不足之處體現在
- 實施成本高
- 開發周期長
- 無法及時評審過程產物
#03 產品敏捷開發流程管理
作為汽車電子產品開發流程的方案優化，將敏捷開發和 V 模型結合使用。敏捷開發是一種迭代式、增量式的開發方法，強調對需求變化的快速響應和持續交付有價值的軟件，將其用于產品的開發，實現敏捷迭代。同時，針對具體產品的特點，強調功能安全的重要性，利用 V 模型的需求管理方法來確保需求的準確性和完整性。通過結合敏捷開發和 V 模型，可以實現對汽車軟件開發過程的全面評估和改進，提高產品研發質量和可靠性。
1. 產品敏捷迭代
持續開發、持續集成和持續部署共同構成了敏捷開發過程。通過持續開發，可以快速響應客戶需求的變化，提高軟件的質量和可靠性；通過持續集成和持續部署，可以確保軟件的完整性和穩定性，并最終實現軟件的快速上市。
1） 持續開發（Continuous Exploration）
首先，敏捷開發起始于一個敏捷團隊和一個計劃會議：敏捷團隊是跨職能的，每兩周一次的協作交付工作系統，這些系統被稱為迭代。
迭代開始于一個計劃會議，這個會議由產品負責人主持，并負責迭代的工作庫（User Stories）。
敏捷團隊在會議上決定他們可以在迭代結束時交付哪些用戶故事。每天團隊需要討論他們的進展，并在迭代結束時向產品負責人演示結果，以確保他們已經交付了他想要的。
然后他們會聚在一起回顧他們可以在下一個迭代中改進什么，然后再開始一個新的計劃會議。
項目級別和團隊級別的工作流程非常相似，是一個由多個團隊組成的更大的團隊，共同交付一個更大的系統，人數范圍從50到125人不等。這個更大團隊被稱為敏捷發布列車或ART，其工作產出稱為項目增量或 PI，一般默認由五個迭代完成，每個 PI 的內容由程序待辦事項中的產品經理以特性的形式確定，并提供大部分團隊待辦事項的內容。列車由 RTE 或發布列車工程師管理，他充當列車 Scrum Master，確保主干平穩并確保行駛在正確的軌道上，他是項目級別的產品經理。
2）持續集成（Continuous Integration）
持續集成要求團隊開發成員經常集成他們的工作，通常每個成員每天至少集成一次，也就意味著每天可能會發生多次集成。每次集成都通過自動化的構建（包括編譯，發布，自動化測試）來驗證，從而盡快地發現集成錯誤。許多團隊發現這個過程可以大大減少集成的問題，讓團隊能夠更快的開發內聚的軟件。持續集成指的是，頻繁地（一天多次）將代碼集成到主干。它的好處主要有兩個：
快速發現錯誤。每完成一點更新，就集成到主干，可以快速發現錯誤，定位錯誤也比較容易。
防止分支大幅偏離主干。如果不是經常集成，主干又在不斷更新，會導致以后集成的難度變大，甚至難以集成。
持續集成的目的，就是讓產品可以快速迭代，同時還能保持高質量。它的核心措施是，代碼集成到主干之前，必須通過自動化測試。只要有一個測試用例失敗，就不能集成。
3）持續部署（Continuous Deployment）
持續部署是持續交付的下一步或者說更高階段，指的是代碼通過評審以后（或者是通過自動化測試以后），自動部署到生產環境。這意味著，所有通過了一系列的自動化測試的改動都將自動部署到生產環境。它也可以被稱為“Continuous Release”。
持續部署的目標是代碼在任何時刻都是可部署的，可以進入生產階段。它的核心措施是，代碼通過評審以后，自動部署到生產環境。如果沒有制度的約束或其它條件的影響，每個改動都應該盡快地部署到生產環境。持續部署是否適合某個公司是基于該公司的業務需求，而不是技術限制。
在持續部署的實踐過程中，一個最小化的持續集成系統需要包含以下幾個要素：版本管理系統、構建腳本&工具以及自動化測試。
2. 敏捷開發在汽車軟件開發上的應用
2.1 需求驅動
減少需求層級，適應快速敏捷的需求：傳統 V 模型的開發流程中有 4-5 級的需求文檔，每層均對應一個團隊，每層均需要文檔編寫、上下游對齊時間，阻礙了敏捷開發。在運用了敏捷模型的汽車軟件開發團隊，將需求層級減少為 1-2 級，最終完成從產品需求到軟件需求。這些需求編寫同樣采取敏捷迭代的方式進行。
產品負責人驅動產品&軟件開發：傳統V 模型的開發流程中是由項目經理驅動軟件開發，在運用了敏捷模型的汽車軟件開發團隊，產品經理負責產品和軟件需求，由產品經理將需求下派到軟件開發團隊，并確定開發計劃、驗證計劃等，最終完成產品的驗收。
2）功能和安全事項不同的開發管理方法
對于不涉及汽車安全的功能或產品，采用快速迭代的敏捷開發方式：對于不涉及汽車安全的功能或產品，強調的是快速回應用戶需求和滿足用戶體驗，允許在軟件系統魯棒性方面進行迭代改善（包含量產后的迭代改善—OTA）對于功能安全需求，采用 V 模型進行開發：對于功能安全需求，強調的開發受控，達到減少用戶危害、同時滿足嚴苛的（對內&對外）審核的要求，需要重視流程和文檔管理，采取 V 模型進行開發。
#04 總結與展望
隨著智能汽車的蓬勃發展，汽車功能日新月異，軟件代碼量日益增加，傳統 V 模型下的瀑布式開發已經不堪重負，為了快速交付給客戶最迫切需要的功能，軟件開發流程的轉變至關重要。目前，越來越多的開發公司轉向了敏捷開發。但在實際工作中，要實現敏捷轉型，也面臨不小的挑戰。
根據敏捷年度報告中的統計，敏捷轉型中面臨的挑戰主要有以下方面：
從占比最高的前三項可以看出，對于很多組織來說，內部文化仍然是敏捷轉型的巨大阻礙。
因此，汽車軟件開發流程向敏捷開發轉變的過程，也是內部組織架構調整的過程。主要需要解決以下問題：
1.缺乏領導層的支持：
實行敏捷，組織架構上的微調是必不可免的，例如，一個SCRUM 團隊，需要產品、開發、測試、集成等各個職能人員，而這些人員通常分屬不同部門管理，SCRUM 團隊管理者想要有序推進工作，就需要領導層的支持才能保證團隊各成員的配合。
2.組織對變革的阻力：
- 接受新的觀念、流程對很多人都較為困難，且在轉型初期會較為痛苦；
- 敏捷特別講究量化數據，這會使得一些渾水摸魚、工作量較少的員工暴露出來，他們天然會反抗這種轉型；
- 敏捷轉型后，整個組織自驅力越來越強，需要的管理人員則會變少，造成的人員冗余問題又會導致內部產生阻力。
綜上所述，敏捷開發將會是汽車軟件開發流程的轉變趨勢，但轉向敏捷的過程仍面臨組織內部的巨大阻力。同時，目前汽車行業仍然要求軟件開發必須符合 ASPICE 認證要求，這導致軟件開發團隊無法徹底擺脫傳統開發模式的束縛。當前 ASPICE 與敏捷開發的結合，往往也是敏捷主導著整個開發流程，而 ASPICE 流于形式。轉向敏捷開發，不僅需要軟件開發企業內部管理的調整，也依賴于未來行業標準的轉變。
轉自汽車電子與軟件
