汽車(chē)軟件在復(fù)雜性、高可靠性、安全性要求、變更管理以及物理系統(tǒng)特性方面處理起來(lái)很復(fù)雜，因此汽車(chē)軟件開(kāi)發(fā)流程都遵循V模型模式，然而隨著汽車(chē)軟件的復(fù)雜性呈指數(shù)級(jí)增長(zhǎng)，傳統(tǒng)的V模型往往導(dǎo)致后期驗(yàn)證階段的成本非常高，并且對(duì)后期市場(chǎng)和客戶需求缺乏靈活性。在當(dāng)前行業(yè)對(duì)自動(dòng)駕駛領(lǐng)域需求還不夠明確，以及汽車(chē)的開(kāi)發(fā)周期逐漸縮短的條件下，汽車(chē)軟件開(kāi)發(fā)需要引入敏捷開(kāi)發(fā)流程，一來(lái)其可以保證產(chǎn)品更早地投放市場(chǎng)，二來(lái)快速響應(yīng)市場(chǎng)和客戶不斷變化的需求，支持汽車(chē)行業(yè)從傳統(tǒng)制造業(yè)向以"汽車(chē)客戶需求"為中心的服務(wù)型制造業(yè)轉(zhuǎn)型。

敏捷開(kāi)發(fā)是一種靈活的方法，它允許軟件的增量開(kāi)發(fā)和迭代開(kāi)發(fā)，而不是在開(kāi)發(fā)過(guò)程結(jié)束時(shí)一次性交付所有軟件【對(duì)傳統(tǒng)的汽車(chē)ECU，車(chē)輛量產(chǎn)前會(huì)進(jìn)行各ECU軟件凍結(jié)，供應(yīng)商一次性交付所有軟件，在量產(chǎn)后如果需要某個(gè)ECU增加新功能，供應(yīng)商不會(huì)再理會(huì)的，因?yàn)橹暗拈_(kāi)發(fā)合同已到期，需要重新簽開(kāi)發(fā)合同，除非是出現(xiàn)軟件bug，需要修復(fù)】。

盡管這兩種方法——敏捷和V模型——都有其優(yōu)點(diǎn)，但挑戰(zhàn)和局限性仍然存在，尤其是在汽車(chē)軟件開(kāi)發(fā)方面。接下來(lái)理一理敏捷開(kāi)發(fā)在汽車(chē)軟件開(kāi)發(fā)中的應(yīng)用、其優(yōu)點(diǎn)、挑戰(zhàn)和局限性。以及結(jié)合使用敏捷開(kāi)發(fā)和傳統(tǒng)過(guò)程V模型的效果。

將敏捷開(kāi)發(fā)集成到V模型中的第一步是分析當(dāng)前V模型面臨的主要挑戰(zhàn)，以及敏捷開(kāi)發(fā)所具有的優(yōu)勢(shì)。兩者的對(duì)比如圖1所示，它都描述了V模型與敏捷開(kāi)發(fā)不同的處理方式。

例如，就合作方式而言，在傳統(tǒng)的V模型項(xiàng)目中具有詳細(xì)而全面的客戶合同。到合同結(jié)束后會(huì)有帶來(lái)一些問(wèn)題，由于復(fù)雜項(xiàng)目的不確定性以及不斷變化的客戶需求，合同上確定的需求與實(shí)際客戶需求有出入。敏捷開(kāi)發(fā)則在整個(gè)項(xiàng)目執(zhí)行過(guò)程中保持持續(xù)的客戶互動(dòng)，持續(xù)接收客戶的反饋和變更請(qǐng)求，并在過(guò)程中共同開(kāi)發(fā)和審查軟件，就預(yù)期結(jié)果達(dá)成一致。

圖1 V模型與敏捷開(kāi)發(fā)對(duì)比

但是在復(fù)雜的汽車(chē)軟件開(kāi)發(fā)項(xiàng)目中融入敏捷開(kāi)發(fā)是一項(xiàng)艱巨的任務(wù)，如何在V模型中融入？會(huì)帶來(lái)哪些挑戰(zhàn)？效果會(huì)不會(huì)如描述的那么好？這些都是問(wèn)題。

將敏捷開(kāi)發(fā)融入到V模型的汽車(chē)軟件開(kāi)發(fā)的主要手段有以下幾個(gè)方面：

1、在模塊級(jí)別上實(shí)現(xiàn)增量開(kāi)發(fā)，以分解復(fù)雜性，允許用戶參與并支持后期更改。

2、通過(guò)就增量沖刺的目標(biāo)達(dá)成一致，而不是為軟件的完整交付而談判合同，來(lái)促進(jìn)用戶的參與。這將計(jì)劃的范圍從完整的項(xiàng)目時(shí)間規(guī)劃細(xì)分為一個(gè)個(gè)敏捷sprint規(guī)劃。

3、擺脫基于紙質(zhì)（或文檔）的規(guī)范，使用根據(jù)使用場(chǎng)景和用戶故事進(jìn)行驗(yàn)證的工作軟件。

圖2 在V模型開(kāi)發(fā)中融入敏捷開(kāi)發(fā)

下面以將敏捷開(kāi)發(fā)過(guò)程中的增量開(kāi)發(fā)融入到V模型開(kāi)發(fā)為例子，進(jìn)行詳細(xì)說(shuō)明。

在基于V模型的軟件開(kāi)發(fā)中，通過(guò)對(duì)整個(gè)軟件體系結(jié)構(gòu)的分層分解，定義了一組軟件模塊，這些模塊實(shí)現(xiàn)了客戶所需的功能。在傳統(tǒng)的V模型中，這些模塊先經(jīng)過(guò)充分的開(kāi)發(fā)和測(cè)試，然后集成到整個(gè)系統(tǒng)中，再進(jìn)行測(cè)試。這個(gè)過(guò)程的最后一步是客戶的驗(yàn)收測(cè)試。這將導(dǎo)致客戶很晚才參與到反饋中來(lái)，從而導(dǎo)致很晚才提出更改請(qǐng)求。

敏捷開(kāi)發(fā)是將模塊開(kāi)發(fā)分解為幾個(gè)增量步驟。這些步驟是作為敏捷沖刺sprint執(zhí)行的，它根據(jù)客戶要求的功能以增量方式實(shí)現(xiàn)功能。對(duì)于每個(gè) sprint（或一組 sprint），客戶都會(huì)參與每期sprint的輸出審查。這是一個(gè)挑戰(zhàn)，因?yàn)楸仨殞⒚總€(gè)sprint的開(kāi)發(fā)任務(wù)集成到整個(gè)系統(tǒng)中，如果不集成到整個(gè)系統(tǒng)中，客戶可能無(wú)法評(píng)估軟件的質(zhì)量。軟件在環(huán) (SiL)或模型在環(huán) (MiL) 可能有助于軟件的驗(yàn)證。

上述的這些想法也跟部分主機(jī)廠的工程師進(jìn)行過(guò)一些溝通，為了應(yīng)對(duì)當(dāng)前不斷變化的需求，主機(jī)廠的工程師其實(shí)也覺(jué)得在V模型開(kāi)發(fā)中融入敏捷開(kāi)發(fā)的思想是可行的。

然而這種轉(zhuǎn)變并非易事，因?yàn)槠?chē)行業(yè)幾十年來(lái)一直遵循V模型開(kāi)發(fā)流程。相關(guān)的標(biāo)準(zhǔn)是基于這些過(guò)程的，項(xiàng)目管理和客戶交互工作也相應(yīng)進(jìn)行。需要主機(jī)廠與供應(yīng)商共同努力，推進(jìn)這種改變。