[[433271]]

最近幾年一直都有很多關(guān)于“敏捷”如何在汽車行業(yè)應(yīng)用的討論，看了一些文章，大都是說“敏捷”在IT行業(yè)如何的成功、提升了多少效率、幫助多少企業(yè)脫穎而出，因此汽車行業(yè)也應(yīng)該立即效法實施等等?？墒鞘欠駪?yīng)該實施、究竟該如何實施、現(xiàn)有的汽車軟件開發(fā)流程如何改造等等卻沒有看到任何有一點價值的東西。

我們先看看現(xiàn)在標(biāo)準(zhǔn)的汽車行業(yè)開發(fā)流程，即所謂的標(biāo)準(zhǔn)“瀑布式開發(fā)流程” 究竟是什么樣子的，為啥被全世界的OEM們用了這么多年。

瀑布是什么?

瀑布方法，也被稱為線性順序生命周期模型，是由其對項目管理的線性、結(jié)構(gòu)化方法定義的。它由一系列在軟件開發(fā)生命周期(SDLC)中按順序完成的步驟組成。這些步驟通常通過甘特圖可視化來跟蹤。溫斯頓·w·羅伊斯博士開發(fā)了這種方法，他在1970年的論文《管理大型軟件系統(tǒng)的開發(fā)》中記錄了這種方法。

自從它發(fā)表以來，各種各樣的瀑布出現(xiàn)了，但在這個過程中，人們對以下步驟達(dá)成了普遍共識:

需求的收集:這個階段需要在開發(fā)團(tuán)隊和客戶或最終用戶之間預(yù)先編寫文檔。在這個階段，項目計劃中的產(chǎn)品特性被詳細(xì)地記錄下來，使團(tuán)隊能夠確定一個明確的成本和時間表。在雙方對需求保持一致之后，在項目完成之前，開發(fā)團(tuán)隊和客戶之間不會有任何通信。

設(shè)計:設(shè)計階段包括兩個步驟:邏輯設(shè)計和物理設(shè)計。在邏輯設(shè)計中，團(tuán)隊頭腦風(fēng)暴解決客戶問題的可能方法。當(dāng)開發(fā)團(tuán)隊就解決方案達(dá)成一致意見時，這些想法將轉(zhuǎn)化為具體的技術(shù)任務(wù)，然后在整個團(tuán)隊中分發(fā)這些任務(wù)以構(gòu)建物理設(shè)計。

實現(xiàn):在下一階段，開發(fā)人員開始基于前面步驟中開發(fā)的規(guī)范進(jìn)行編碼。

驗證:此階段測試確保代碼按預(yù)期運(yùn)行，并確保范圍文檔中的需求得到滿足。開發(fā)團(tuán)隊檢查代碼中的錯誤，最終驗證由客戶端進(jìn)行，以確保功能滿足預(yù)期。

維護(hù):當(dāng)用戶使用終端產(chǎn)品時，出現(xiàn)新問題時需要持續(xù)的支持。

如果將“瀑布”的前后工作對應(yīng)起來，就得到了“V模型”。 “V模型”只是“瀑布”的變種，本質(zhì)上還是按照時間和邏輯順序的進(jìn)行開發(fā)工作。

汽車行業(yè)的流程從整個產(chǎn)品的立項到SOP（量產(chǎn)），采用的就是V模型。這種模式也被全世界的OEM普遍接受，成為了標(biāo)準(zhǔn)。只是大家在細(xì)節(jié)上各有特點。至少都會在整個開發(fā)周期內(nèi)分為：概念階段、設(shè)計開發(fā)階段和生產(chǎn)階段。大體如下圖所示。

因為汽車的設(shè)計開發(fā)中非軟件類的開發(fā)工作數(shù)量巨大、對成本的控制和性能的實現(xiàn)至關(guān)重要，而且傳統(tǒng)的汽車中軟件比重也不高，所以上述的節(jié)點（Gate）設(shè)置中首要考慮的不是軟件。汽車中的軟件開發(fā)工作即使在現(xiàn)在也只是眾多開發(fā)線中的一條。即使在“軟件定義汽車”的概念越來越火的今天，軟件開發(fā)也不是OEM的最主要工作。在所有的車型開發(fā)中，最多的錢一定還是投資在各種模具、驗證和產(chǎn)線上的，這些與軟件的關(guān)系都不大。

不得不提的一點是，由于一個車型的周期比較長，汽車上各個ECU的軟件不是一下子就需要達(dá)到SOP的狀態(tài)，而是分為多個階段交樣，每個階段都有不同的目標(biāo)并進(jìn)行相應(yīng)的驗證，可以說是迭代增長的。而不是某些人說的那種：直到最后才進(jìn)行驗收。

而且，在每個Tier1的每次交樣前，供應(yīng)商的軟件開發(fā)又會有N個小版本。

因此，我們所看到的大V模型是指整車級別的，在每個ECU的開發(fā)過程中，會有N個小V模型的迭代。

瀑布法的主要好處

1. 詳細(xì)的產(chǎn)品需求和文檔使新工程師能夠快速、輕松地進(jìn)入項目。

2. 文檔為項目提供了清晰的范圍，使項目經(jīng)理能夠與相關(guān)各方溝通預(yù)算、時間線和關(guān)鍵里程碑。

3. 為項目提供了按階段劃分的檢查點。

4. 當(dāng)前一階段完成后，您只需要去關(guān)注后續(xù)階段.

5. 它提供了一個模板，這個模板使得分析、設(shè)計、編碼、測試和支持的方法可以在該模板下有一個共同的指導(dǎo)。

瀑布法的缺點：

1. 各個階段的劃分完全固定，階段之間產(chǎn)生大量的文檔，極大地增加了工作量。

2. 由于開發(fā)模型是線性的，用戶只有等到整個過程的末期才能見到開發(fā)成果，從而增加了開發(fā)風(fēng)險。

3. 通過過多的強(qiáng)制完成日期和里程碑來跟蹤各個項目階段。

4. 瀑布模型的突出缺點是不適應(yīng)用戶需求的變化。

瀑布法的主要挑戰(zhàn)：

1. 客戶可能會發(fā)現(xiàn)在項目開始時很難概述他們的所有需求，這導(dǎo)致了文檔中的空白。

2. 如果產(chǎn)品沒有達(dá)到預(yù)期，開發(fā)過程中最小的客戶協(xié)作可能導(dǎo)致昂貴的更改。

3. 測試人員在過程的后期才能發(fā)現(xiàn)問題和bug，這可能導(dǎo)致架構(gòu)級別的更改。

值得特別指出的是，上述的挑戰(zhàn)在汽車行業(yè)并不是很突出，因為汽車行業(yè)更需要的是協(xié)調(diào)一致，所以在每個項目的前期會有充分的需求收集和確定的時間，而且車上的大部分基本功能都很清楚，很少存在要快速推出產(chǎn)品再后續(xù)更新的情況，否則上百個ECU就沒有辦法都能按時交樣了。另外，由于汽車電子的發(fā)展是漸進(jìn)式的，過去的幾十年里面已經(jīng)經(jīng)過了無數(shù)個V模型的迭代。現(xiàn)在要解決的是電子電氣系統(tǒng)的復(fù)雜性如何應(yīng)對的問題。

而對于快速變化的IT行業(yè)則完全不同，一個隊伍在開發(fā)一個APP或一個網(wǎng)站的時候根本不知道用戶的需求是不是真的像他們想象的那樣，所以就需要快速的推出原型產(chǎn)品來試水，再根據(jù)用戶的反饋來進(jìn)行相應(yīng)的調(diào)整。這就需要使用“敏捷”進(jìn)行應(yīng)對。

什么是敏捷?

與瀑布式開發(fā)相反，敏捷（agile method）是由項目管理的迭代方法定義的。敏捷團(tuán)隊不是一開始就起草冗長的項目需求，而是將產(chǎn)品分解成具體的功能，然后在特定的時間限制下處理每一個功能，這就是所謂的sprint。

敏捷項目管理需要一個跨職能、自組織的團(tuán)隊，通常由5到9個成員組成。在每個sprint期間，他們一起開發(fā)了一個可工作的軟件部分，該部分與之前迭代的其他功能代碼相結(jié)合。在“沖刺”時間框的最后，團(tuán)隊向利益相關(guān)者（Stakeholder）演示他們的工作以獲得反饋，允許他們在軟件開發(fā)方法上更加靈活。由于團(tuán)隊可以獲得頻繁的反饋，他們可以在開發(fā)生命周期中調(diào)整產(chǎn)品路線圖，以確保功能真正滿足用戶的期望。在瀑布式方法中，客戶的參與通常與最終產(chǎn)品的交付同時進(jìn)行，當(dāng)需求被錯誤地解釋或記錄時，這可能是非常昂貴的代價。

當(dāng)IT行業(yè)迅速發(fā)展的時候，有人發(fā)現(xiàn)瀑布式項目管理系統(tǒng)在某些情況下是無效的，并且在2001年，他們關(guān)于軟件開發(fā)過程的想法在一份稱為“敏捷宣言”的文章中被明確提出。他們強(qiáng)調(diào)了軟件開發(fā)工作流中優(yōu)先級的具體價值和原則，并產(chǎn)生了許多流行的敏捷框架，如Scrum、看板、功能驅(qū)動開發(fā)(FDD, Feature Driven Development)和極限編程。從那時起，敏捷軟件開發(fā)越來越受歡迎，特別是與瀑布模型相比。

簡單的說，敏捷開發(fā)以用戶的需求進(jìn)化為核心，采用迭代、循序漸進(jìn)的方法進(jìn)行軟件開發(fā)。

敏捷開發(fā)的團(tuán)隊由以下主要角色構(gòu)成：

產(chǎn)品負(fù)責(zé)人:這個團(tuán)隊成員代表了客戶和企業(yè)的需求。通過制作用戶故事，團(tuán)隊可以了解特性請求如何幫助解決特定問題，這些故事為團(tuán)隊制定了要處理的任務(wù)積壓。這個人還根據(jù)故事對客戶的價值對故事進(jìn)行優(yōu)先排序，從理論上講，這些價值應(yīng)該轉(zhuǎn)化為企業(yè)的價值。當(dāng)產(chǎn)品負(fù)責(zé)人以這種方式領(lǐng)導(dǎo)團(tuán)隊時，他們不會設(shè)定最后期限或指導(dǎo)團(tuán)隊如何交付工作。

Scrum master:這個團(tuán)隊成員促進(jìn)了整個敏捷開發(fā)過程。與項目經(jīng)理類似，這個人讓團(tuán)隊專注于任務(wù)，確保團(tuán)隊在項目期間保持專注。他們也可以作為中立的一方來調(diào)解團(tuán)隊成員之間的分歧。例如，團(tuán)隊成員可能不同意在給定的sprint中承擔(dān)多少任務(wù)。特別是產(chǎn)品負(fù)責(zé)人，可能會迫使團(tuán)隊承諾在給定的時間框架內(nèi)交付超出他們能力的內(nèi)容。在這些情況下，scrum管理員可以提醒團(tuán)隊成員他們在團(tuán)隊中的角色范圍。

敏捷團(tuán)隊的其他成員：每個團(tuán)隊的成員構(gòu)成可以不同，但通常包括來自不同領(lǐng)域的人員，如設(shè)計、分析、QA和開發(fā)。這些人一起協(xié)作決定要承擔(dān)多少工作以及如何完成它。

Agile methodologies are also defined by the ways in which the team comes together. There are specific meetings which help facilitate the workflow across the team. Some of them include the following:

敏捷方法的一個顯著特征是有一些特定的會議流程，從而可以幫助促進(jìn)整個團(tuán)隊的工作。其中包括:

Sprint計劃:在這個會議期間，團(tuán)隊聚集在一起決定哪些故事（Story）將成為當(dāng)前Sprint的一部分。產(chǎn)品所有者將對用戶故事進(jìn)行優(yōu)先級劃分，團(tuán)隊的其他成員需要就他們在設(shè)定的時間段內(nèi)可以完成多少和哪些用戶故事達(dá)成一致。

每日站立（Daily standup）:這些簡短的會議也被稱為每日scrum。在這些簽入（Check-ins）過程中，每個團(tuán)隊成員都要交流他們的個人進(jìn)展，如已完成的任務(wù)、即將到來的任務(wù)，以及可能導(dǎo)致延遲的任何障礙或?qū)ν獠康囊蕾囆浴?/p>

演示:這個會議展示了團(tuán)隊在sprint過程中完成的工作軟件，可以是兩周到四周的增量。產(chǎn)品所有者將確定用戶故事是否滿足“完成”的定義。如果沒有，將更新產(chǎn)品的待辦事項列表并補(bǔ)充所遺漏的內(nèi)容。這也是團(tuán)隊向利益相關(guān)者提供反饋的機(jī)會。

回顧:這段時間是留給團(tuán)隊自省的，團(tuán)隊在此確定如何改進(jìn)他們的工作流程，以在未來獲得更好的結(jié)果。

敏捷開發(fā)的優(yōu)點：

1. 高適應(yīng)性，以人為本，團(tuán)隊設(shè)計促進(jìn)了更多的合作。

2. 更加靈活并且更加充分的利用了每個開發(fā)者的優(yōu)勢，調(diào)動了每個人的工作熱情。

3. 由于代碼在開發(fā)階段的每個迭代中都要進(jìn)行測試，所以代碼缺陷可以迅速的列入未來的軟件的開發(fā)計劃中。

4. 往往會產(chǎn)生更高的客戶滿意度，因為頻繁的反饋會增加客戶需求的優(yōu)先級。

5. 這種精益的軟件開發(fā)可以降低成本，因為與客戶期望的不一致的風(fēng)險更小。

敏捷開發(fā)的缺點：

1. 對于文檔的重視不足。由于其項目周期很長，所以很難保證開發(fā)的人員不更換，而沒有文檔就會造成在交接的過程中出現(xiàn)很大的困難。若項目人員流動性太大，又給維護(hù)帶來不少難度。

2. 需要項目中存在經(jīng)驗較強(qiáng)的人，否則在大或復(fù)雜的項目中容易遇到瓶頸問題。

3. 只適合小團(tuán)隊作戰(zhàn)。難以應(yīng)對大規(guī)模的開發(fā)任務(wù)。

觀點：

從上述的分析中，我們可以看到：

1. 傳統(tǒng)的汽車軟件開發(fā)并不是沒有迭代的

2. 敏捷是通過不斷地設(shè)立“小目標(biāo)”的方式，實現(xiàn)小步快跑，通過不斷的從客戶處獲得反饋來保證最終的交付能夠滿足用戶的期望目標(biāo)

3. 由于汽車軟件中的基礎(chǔ)功能通常都是需求非常明確的，而且長期基本不變，不需要通過敏捷來試錯

4. 純軟件項目由于更改方便，更適合敏捷

5. 敏捷只能部分應(yīng)用于需求不明確、需要通過快速迭代來試錯的領(lǐng)域

如果人類是從現(xiàn)在才開始設(shè)計汽車軟件，那么采用敏捷也許是一個好主意，可以快速的打下基礎(chǔ)，但是相關(guān)硬件成本的投入和超大規(guī)模的不同團(tuán)隊合作的問題還是難以通過敏捷來解決。

汽車軟件中極少有由一個單一控制器獨(dú)立實現(xiàn)的，整車軟件開發(fā)需要大規(guī)模協(xié)作，如果沒有文檔作為需求的傳遞，將難以開展協(xié)同工作。

另外，汽車特殊的安全性要求和大批量的特點，決定了一切要以安全為首要目標(biāo)，因此，TS16949中對開發(fā)過程交付物有著具體而明確的存檔要求，歐美法規(guī)也有對設(shè)計過程的管控要求和責(zé)任追究制度。因此，沒有文檔支撐的開發(fā)是難以在汽車行業(yè)活下去的。至少ASPICE的部分要求還是逃不掉的。

建議和結(jié)論：

上述的分析并不是說汽車行業(yè)就完全不能實施敏捷，可以在某些領(lǐng)域進(jìn)行適當(dāng)?shù)拿艚荩?/p>

• 在快速迭代的領(lǐng)域適當(dāng)進(jìn)行：多媒體中的APP，智駕中的部分功能的原型開發(fā)都是與硬件關(guān)聯(lián)度不高的，可以結(jié)合MIL（Model In Loop，模型在環(huán)仿真）的實施來嘗試“敏捷”。
• SOA中的部分服務(wù)在接口需求明確的情況下可以在開發(fā)階段進(jìn)行敏捷的嘗試。

然而，汽車軟件敏捷團(tuán)隊中的人一定有維護(hù)文檔的職責(zé)，而且要列入績效，不能只關(guān)注結(jié)果。汽車軟件開發(fā)不是“一錘子買賣”，是一個需要有責(zé)任感的工作，而且是可能要負(fù)法律責(zé)任，對質(zhì)量和安全要有最起碼的敬畏心。不但要滿足文檔與法規(guī)的要求，還要做好Knowhow傳承，以及滿足長期維護(hù)的需求。

敏捷是為了應(yīng)對需求的不明確，那么，如果有良好的架構(gòu)設(shè)計，又有清晰正確的需求，就不需要“敏捷”。

開發(fā)中可以參考部分敏捷的做法和思想：更任務(wù)導(dǎo)向的組織機(jī)構(gòu)設(shè)計、減少管理的層級、協(xié)同工具的使用（相比于看板，我覺得好的軟件工具鏈效率更高，而且可以追溯和便于大家遠(yuǎn)程協(xié)作）、每日例會、持續(xù)集成、快速反饋等。