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