[[433271]]

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

我們先看看現在標準的汽車行業開發流程，即所謂的標準“瀑布式開發流程” 究竟是什么樣子的，為啥被全世界的OEM們用了這么多年。

瀑布是什么?

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

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

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

設計:設計階段包括兩個步驟:邏輯設計和物理設計。在邏輯設計中，團隊頭腦風暴解決客戶問題的可能方法。當開發團隊就解決方案達成一致意見時，這些想法將轉化為具體的技術任務，然后在整個團隊中分發這些任務以構建物理設計。

實現:在下一階段，開發人員開始基于前面步驟中開發的規范進行編碼。

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

維護:當用戶使用終端產品時，出現新問題時需要持續的支持。

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

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

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

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

而且，在每個Tier1的每次交樣前，供應商的軟件開發又會有N個小版本。

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

瀑布法的主要好處

1. 詳細的產品需求和文檔使新工程師能夠快速、輕松地進入項目。

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

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

4. 當前一階段完成后，您只需要去關注后續階段.

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

瀑布法的缺點：

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

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

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

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

瀑布法的主要挑戰：

1. 客戶可能會發現在項目開始時很難概述他們的所有需求，這導致了文檔中的空白。

2. 如果產品沒有達到預期，開發過程中最小的客戶協作可能導致昂貴的更改。

3. 測試人員在過程的后期才能發現問題和bug，這可能導致架構級別的更改。

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

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

什么是敏捷?

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

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

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

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

敏捷開發的團隊由以下主要角色構成：

產品負責人:這個團隊成員代表了客戶和企業的需求。通過制作用戶故事，團隊可以了解特性請求如何幫助解決特定問題，這些故事為團隊制定了要處理的任務積壓。這個人還根據故事對客戶的價值對故事進行優先排序，從理論上講，這些價值應該轉化為企業的價值。當產品負責人以這種方式領導團隊時，他們不會設定最后期限或指導團隊如何交付工作。

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

敏捷團隊的其他成員：每個團隊的成員構成可以不同，但通常包括來自不同領域的人員，如設計、分析、QA和開發。這些人一起協作決定要承擔多少工作以及如何完成它。

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:

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

Sprint計劃:在這個會議期間，團隊聚集在一起決定哪些故事（Story）將成為當前Sprint的一部分。產品所有者將對用戶故事進行優先級劃分，團隊的其他成員需要就他們在設定的時間段內可以完成多少和哪些用戶故事達成一致。

每日站立（Daily standup）:這些簡短的會議也被稱為每日scrum。在這些簽入（Check-ins）過程中，每個團隊成員都要交流他們的個人進展，如已完成的任務、即將到來的任務，以及可能導致延遲的任何障礙或對外部的依賴性。

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

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

敏捷開發的優點：

1. 高適應性，以人為本，團隊設計促進了更多的合作。

2. 更加靈活并且更加充分的利用了每個開發者的優勢，調動了每個人的工作熱情。

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

4. 往往會產生更高的客戶滿意度，因為頻繁的反饋會增加客戶需求的優先級。

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

敏捷開發的缺點：

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

2. 需要項目中存在經驗較強的人，否則在大或復雜的項目中容易遇到瓶頸問題。

3. 只適合小團隊作戰。難以應對大規模的開發任務。

觀點：

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

1. 傳統的汽車軟件開發并不是沒有迭代的

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

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

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

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

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

汽車軟件中極少有由一個單一控制器獨立實現的，整車軟件開發需要大規模協作，如果沒有文檔作為需求的傳遞，將難以開展協同工作。

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

建議和結論：

上述的分析并不是說汽車行業就完全不能實施敏捷，可以在某些領域進行適當的敏捷：

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

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

敏捷是為了應對需求的不明確，那么，如果有良好的架構設計，又有清晰正確的需求，就不需要“敏捷”。

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