01  汽車電子產(chǎn)品研發(fā)的痛點

目前汽車電子產(chǎn)品，特別是汽車幾大域控（如：智能座艙、智能駕駛、智能網(wǎng)聯(lián)、車身控制），市場競爭激烈：隨著科技的發(fā)展，越來越多的企業(yè)開始進入這些領(lǐng)域。傳統(tǒng)車企、互聯(lián)網(wǎng)公司、初創(chuàng)企業(yè)都在這個領(lǐng)域進行布局，使得市場競爭異常激烈。

另外用戶需求變化：隨著消費者對汽車的需求逐漸多元化和個性化，用戶對座艙和智駕產(chǎn)品的要求也越來越高。他們不僅要求產(chǎn)品具有創(chuàng)新性和科技感，還要求產(chǎn)品能夠提供更加優(yōu)質(zhì)、便捷的駕駛體驗。

在上述因素的加持下，無論是設(shè)計方還是軟件實現(xiàn)方，均對現(xiàn)狀不滿意。主要體現(xiàn)在以下幾個方面：

1.需求的不斷更改

為了能吸引用戶，在汽車研發(fā)初期，設(shè)計方會提出很多新穎的概念，往往這些概念不太成熟，隨著時間的積累，設(shè)計方通過用戶調(diào)研、競爭對手分析，會不斷地更改和追加新需求來完善想法，提高產(chǎn)品質(zhì)量和用戶體驗。但產(chǎn)品的最終交付時間并不會變更。

2. 最終實現(xiàn)和最初期望背離

汽車電子產(chǎn)品具有復(fù)雜性的特點，這種復(fù)雜性不僅來自于產(chǎn)品軟件本身的功能需求，還來自于與汽車各個子系統(tǒng)的交互，以及對于安全性和可靠性的嚴格要求，一個汽車電子產(chǎn)品需要與多種硬件設(shè)備進行集成，如傳感器、執(zhí)行器、控制器等。這些硬件設(shè)備的多樣性增加了軟件的復(fù)雜性和開發(fā)難度。因為這種復(fù)雜性存在，在產(chǎn)品的最終實現(xiàn)和最初的預(yù)期往往存在較大的偏差：

3. 整車開發(fā)周期越來越短

國內(nèi)汽車主機廠，特別是新能源車企，整車開發(fā)周期越來越短，配套的電子產(chǎn)品的開發(fā)周期也相應(yīng)的被壓縮。

02  當(dāng)前汽車電子產(chǎn)品研發(fā)流程

目前汽車產(chǎn)業(yè)研發(fā)，特別是軟件研發(fā)，主要采用 V 模型，其是由瀑布模型演變而來的，也是目前汽車行業(yè)運用最廣的軟件開發(fā)模型。一種自上而下，過程驅(qū)動的開發(fā)方法，它強調(diào)在項目開始階段就對需求進行詳細的分析和定義，然后依次進行設(shè)計、編碼、測試等流程，直到項目完成。這種方法著重于規(guī)劃和質(zhì)量控制，以確保項目的需求、設(shè)計和實現(xiàn)的一致性。因此，V 模型開發(fā)方法更適用于需求明確、需求穩(wěn)定的項目。

V 模型由如下的幾個特點：

1、嚴謹?shù)碾A段劃分

V 模型將軟件開發(fā)劃分為一系列嚴謹?shù)碾A段，包括需求分析，系統(tǒng)設(shè)計，編程，系統(tǒng)測試等。每個階段都有明確的輸入和輸出，以及嚴格的驗收標準。

2、 早期驗證和驗證

V 模型強調(diào)在軟件開發(fā)的早期階段進行驗證和驗證，以便盡早發(fā)現(xiàn)和修復(fù)錯誤。

3、文檔驅(qū)動

V 模型強調(diào)文檔的重要性，每個階段都需要產(chǎn)生詳細的文檔，用于記錄決策，傳遞信息，以及后續(xù)的維護和支持。

它的優(yōu)勢主要體現(xiàn)在

1、 提高客戶滿意度

它是標準化軟件開發(fā)流程，是客戶和產(chǎn)品開發(fā)方的共同語言，通過實施 V 模型，方便客戶進行評審和管控供應(yīng)商開發(fā)質(zhì)量。

2、提高產(chǎn)品質(zhì)量

通過規(guī)范和標準化軟件開發(fā)流程，有助于降低產(chǎn)品缺陷率和提高產(chǎn)品質(zhì)量。

3、 促進持續(xù)改進

V 模型重視文檔管理，強調(diào)持續(xù)改進和優(yōu)化，有利于在開發(fā)過程中不斷發(fā)現(xiàn)問題、分析問題并采取措施解決問題。并且有利于將其他項目或者上一個項目的經(jīng)驗教訓(xùn)展開到現(xiàn)有項目。

它的不足之處體現(xiàn)在

實施成本高

開發(fā)周期長

無法及時評審過程產(chǎn)物

03  產(chǎn)品敏捷開發(fā)流程管理

作為汽車電子產(chǎn)品開發(fā)流程的方案優(yōu)化，將敏捷開發(fā)和 V 模型結(jié)合使用。敏捷開發(fā)是一種迭代式、增量式的開發(fā)方法，強調(diào)對需求變化的快速響應(yīng)和持續(xù)交付有價值的軟件，將其用于產(chǎn)品的開發(fā)，實現(xiàn)敏捷迭代。同時，針對具體產(chǎn)品的特點，強調(diào)功能安全的重要性，利用 V 模型的需求管理方法來確保需求的準確性和完整性。通過結(jié)合敏捷開發(fā)和 V 模型，可以實現(xiàn)對汽車軟件開發(fā)過程的全面評估和改進，提高產(chǎn)品研發(fā)質(zhì)量和可靠性。

1. 產(chǎn)品敏捷迭代

持續(xù)開發(fā)、持續(xù)集成和持續(xù)部署共同構(gòu)成了敏捷開發(fā)過程。通過持續(xù)開發(fā)，可以快速響應(yīng)客戶需求的變化，提高軟件的質(zhì)量和可靠性；通過持續(xù)集成和持續(xù)部署，可以確保軟件的完整性和穩(wěn)定性，并最終實現(xiàn)軟件的快速上市。

1） 持續(xù)開發(fā)（Continuous Exploration）

首先，敏捷開發(fā)起始于一個敏捷團隊和一個計劃會議：敏捷團隊是跨職能的，每兩周一次的協(xié)作交付工作系統(tǒng)，這些系統(tǒng)被稱為迭代。

迭代開始于一個計劃會議，這個會議由產(chǎn)品負責(zé)人主持，并負責(zé)迭代的工作庫（User Stories）。

敏捷團隊在會議上決定他們可以在迭代結(jié)束時交付哪些用戶故事。每天團隊需要討論他們的進展，并在迭代結(jié)束時向產(chǎn)品負責(zé)人演示結(jié)果，以確保他們已經(jīng)交付了他想要的。

然后他們會聚在一起回顧他們可以在下一個迭代中改進什么，然后再開始一個新的計劃會議。

項目級別和團隊級別的工作流程非常相似，是一個由多個團隊組成的更大的團隊，共同交付一個更大的系統(tǒng)，人數(shù)范圍從50到125人不等。這個更大團隊被稱為敏捷發(fā)布列車或ART，其工作產(chǎn)出稱為項目增量或 PI，一般默認由五個迭代完成，每個 PI 的內(nèi)容由程序待辦事項中的產(chǎn)品經(jīng)理以特性的形式確定，并提供大部分團隊待辦事項的內(nèi)容。列車由 RTE 或發(fā)布列車工程師管理，他充當(dāng)列車 Scrum Master，確保主干平穩(wěn)并確保行駛在正確的軌道上，他是項目級別的產(chǎn)品經(jīng)理。

2）持續(xù)集成（Continuous Integration）

持續(xù)集成要求團隊開發(fā)成員經(jīng)常集成他們的工作，通常每個成員每天至少集成一次，也就意味著每天可能會發(fā)生多次集成。每次集成都通過自動化的構(gòu)建（包括編譯，發(fā)布，自動化測試）來驗證，從而盡快地發(fā)現(xiàn)集成錯誤。許多團隊發(fā)現(xiàn)這個過程可以大大減少集成的問題，讓團隊能夠更快的開發(fā)內(nèi)聚的軟件。持續(xù)集成指的是，頻繁地（一天多次）將代碼集成到主干。它的好處主要有兩個：

快速發(fā)現(xiàn)錯誤。每完成一點更新，就集成到主干，可以快速發(fā)現(xiàn)錯誤，定位錯誤也比較容易。

防止分支大幅偏離主干。如果不是經(jīng)常集成，主干又在不斷更新，會導(dǎo)致以后集成的難度變大，甚至難以集成。

持續(xù)集成的目的，就是讓產(chǎn)品可以快速迭代，同時還能保持高質(zhì)量。它的核心措施是，代碼集成到主干之前，必須通過自動化測試。只要有一個測試用例失敗，就不能集成。

3）持續(xù)部署（Continuous Deployment）

持續(xù)部署是持續(xù)交付的下一步或者說更高階段，指的是代碼通過評審以后（或者是通過自動化測試以后），自動部署到生產(chǎn)環(huán)境。這意味著，所有通過了一系列的自動化測試的改動都將自動部署到生產(chǎn)環(huán)境。它也可以被稱為“Continuous Release”。

持續(xù)部署的目標是代碼在任何時刻都是可部署的，可以進入生產(chǎn)階段。它的核心措施是，代碼通過評審以后，自動部署到生產(chǎn)環(huán)境。如果沒有制度的約束或其它條件的影響，每個改動都應(yīng)該盡快地部署到生產(chǎn)環(huán)境。持續(xù)部署是否適合某個公司是基于該公司的業(yè)務(wù)需求，而不是技術(shù)限制。

在持續(xù)部署的實踐過程中，一個最小化的持續(xù)集成系統(tǒng)需要包含以下幾個要素：版本管理系統(tǒng)、構(gòu)建腳本&工具以及自動化測試。

2. 敏捷開發(fā)在汽車軟件開發(fā)上的應(yīng)用

2.1 需求驅(qū)動

減少需求層級，適應(yīng)快速敏捷的需求：傳統(tǒng) V 模型的開發(fā)流程中有 4-5 級的需求文檔，每層均對應(yīng)一個團隊，每層均需要文檔編寫、上下游對齊時間，阻礙了敏捷開發(fā)。在運用了敏捷模型的汽車軟件開發(fā)團隊，將需求層級減少為 1-2 級，最終完成從產(chǎn)品需求到軟件需求。這些需求編寫同樣采取敏捷迭代的方式進行。

產(chǎn)品負責(zé)人驅(qū)動產(chǎn)品&軟件開發(fā)：傳統(tǒng)V 模型的開發(fā)流程中是由項目經(jīng)理驅(qū)動軟件開發(fā)，在運用了敏捷模型的汽車軟件開發(fā)團隊，產(chǎn)品經(jīng)理負責(zé)產(chǎn)品和軟件需求，由產(chǎn)品經(jīng)理將需求下派到軟件開發(fā)團隊，并確定開發(fā)計劃、驗證計劃等，最終完成產(chǎn)品的驗收。

2.2 功能和安全事項不同的開發(fā)管理方法

對于不涉及汽車安全的功能或產(chǎn)品，采用快速迭代的敏捷開發(fā)方式：對于不涉及汽車安全的功能或產(chǎn)品，強調(diào)的是快速回應(yīng)用戶需求和滿足用戶體驗，允許在軟件系統(tǒng)魯棒性方面進行迭代改善（包含量產(chǎn)后的迭代改善—OTA）對于功能安全需求，采用 V 模型進行開發(fā)：對于功能安全需求，強調(diào)的開發(fā)受控，達到減少用戶危害、同時滿足嚴苛的（對內(nèi)&對外）審核的要求，需要重視流程和文檔管理，采取 V 模型進行開發(fā)。

04  總結(jié)與展望

隨著智能汽車的蓬勃發(fā)展，汽車功能日新月異，軟件代碼量日益增加，傳統(tǒng) V 模型下的瀑布式開發(fā)已經(jīng)不堪重負，為了快速交付給客戶最迫切需要的功能，軟件開發(fā)流程的轉(zhuǎn)變至關(guān)重要。目前，越來越多的開發(fā)公司轉(zhuǎn)向了敏捷開發(fā)。但在實際工作中，要實現(xiàn)敏捷轉(zhuǎn)型，也面臨不小的挑戰(zhàn)。

根據(jù)敏捷年度報告中的統(tǒng)計，敏捷轉(zhuǎn)型中面臨的挑戰(zhàn)主要有以下方面：

從占比最高的前三項可以看出，對于很多組織來說，內(nèi)部文化仍然是敏捷轉(zhuǎn)型的巨大阻礙。

因此，汽車軟件開發(fā)流程向敏捷開發(fā)轉(zhuǎn)變的過程，也是內(nèi)部組織架構(gòu)調(diào)整的過程。主要需要解決以下問題：

1.缺乏領(lǐng)導(dǎo)層的支持：

實行敏捷，組織架構(gòu)上的微調(diào)是必不可免的，例如，一個SCRUM 團隊，需要產(chǎn)品、開發(fā)、測試、集成等各個職能人員，而這些人員通常分屬不同部門管理，SCRUM 團隊管理者想要有序推進工作，就需要領(lǐng)導(dǎo)層的支持才能保證團隊各成員的配合。

2.組織對變革的阻力：

接受新的觀念、流程對很多人都較為困難，且在轉(zhuǎn)型初期會較為痛苦；

敏捷特別講究量化數(shù)據(jù)，這會使得一些渾水摸魚、工作量較少的員工暴露出來，他們天然會反抗這種轉(zhuǎn)型；

敏捷轉(zhuǎn)型后，整個組織自驅(qū)力越來越強，需要的管理人員則會變少，造成的人員冗余問題又會導(dǎo)致內(nèi)部產(chǎn)生阻力。

綜上所述，敏捷開發(fā)將會是汽車軟件開發(fā)流程的轉(zhuǎn)變趨勢，但轉(zhuǎn)向敏捷的過程仍面臨組織內(nèi)部的巨大阻力。同時，目前汽車行業(yè)仍然要求軟件開發(fā)必須符合 ASPICE 認證要求，這導(dǎo)致軟件開發(fā)團隊無法徹底擺脫傳統(tǒng)開發(fā)模式的束縛。當(dāng)前 ASPICE 與敏捷開發(fā)的結(jié)合，往往也是敏捷主導(dǎo)著整個開發(fā)流程，而 ASPICE 流于形式。轉(zhuǎn)向敏捷開發(fā)，不僅需要軟件開發(fā)企業(yè)內(nèi)部管理的調(diào)整，也依賴于未來行業(yè)標準的轉(zhuǎn)變。