01.

為什么汽車軟件開發需要工具鏈

?“軟件定義汽車”已經達成了共識，對于汽車，軟件變得如此重要。如何在短時間之內交付出質量很高，并且又受用戶歡迎的軟件就至關重要了。汽車行業常見的標準是V字形開發，主要以 ASPICE和 ISO26262為代表。以這套標準作為汽車軟件開發的模式，已經有差不多快 20 年的時間了。

國內的新勢力造車差不多是從 14 年才開始的。有一個很明顯的現象，造車新勢力蔚小理，他們軟件開發迭代的速度一直是他們的優勢，蔚來的車型，即便在交付給車主之后，仍然可以做到每月一小迭代，每三個月一大迭代。這些優勢就是借助了軟件開發工具鏈，包括CICD（持續集成、持續交付、持續部署）、OTA等一系列技術。 這就是為什么汽車軟件需要開發工具鏈的原因。

在ASPICE的誕生地德國，咨詢公司Knüvener Mackert 楷邁德、KUGLER MAAG CIE，也在積極討論 ASPICE 和 Agile 融合的事項，并希望推動標準建立。他們是否有可能在近幾年的時間內，推出一款融合后的標準，我們拭目以待。 ?

02.

什么樣的工具鏈是不合適的？

汽車軟件對于開發效率的要求逐漸提高，但在造車新勢力之前，工具鏈的設計并沒有過多考慮效率這個需求。因為大家已經習慣了一款車型的開發需要3-5年，已經習慣了由供應商負責軟件開發，已經習慣了軟件開發只需要遵循V字形即可。

但隨著汽車行業開始逐漸接納敏捷思想，越來越多的汽車軟件公司，開始考慮那些并不是直接針對汽車行業的軟件產品，它們的產品設計上，帶有很強的敏捷開發思想，比如Jira、Ones、Pingcode等。 那么究竟什么樣的工具鏈是汽車行業想要的呢？想要搞清楚這個問題，我們首先要知道什么樣的工具鏈是汽車行業不想要的。我根據自己的工作經驗總結了以下幾點。

第一，工具設計單純只是為了滿足標準的，而不是為了便于工程師工作的

如果一款工具，在使用上不考慮用戶友好性，不管能滿足多么高大上的標準，那都沒有太大實用價值。比如權限設置得過于復雜，沒有權限的人又沒有得到任何提醒，或者也沒有去申請權限的入口，導致用戶只能被動地接受權限設置。我們觀察到一種現象，有一些汽車軟件團隊，出于ASPICE或者功能安全的認證需求，去購買某些工具，他們希望通過標準，去搭建團隊的研發流程，并最終達到步調一致。他們的本意沒問題，最后也通過了認證，但通過之后，發現工具并不高效。他們試圖把工具配置得更高效，但由于工具本身支持的流程很重，即完全按照標準流程來使用，一旦偏離了標準流程，工具反而成為了束縛。于是他們把一部分流程還放在這個工具里，另外一些流程則放到另一個工具里，組成了一個拼接的工具鏈。這違反了下面講到的第二條經驗。

第二，由過多的工具拼湊而成，感覺在使用多款不同的工具

如果我們要需要滿足ASPICE標準，那至少會包含16 個域的工作內容，包含需求分析、架構設計、詳細設計、測試用例等等。我發現有些團隊出于各種各樣的原因，使用開源工具Redmine去做問題跟蹤，然后使用其他工具（比如doors）去做需求管理，最后還使用了 Excel 做線下的測試用例管理。但工具鏈的搭建需要一個全局的視角，并不是首先滿足局部功能，再把所有工具組裝起來就行。

工具鏈的搭建，既要考慮工具能否打通，還要考慮打通之后的易用性。就算購買了一堆王牌工具，每個工具在自己的領域都是佼佼者，但工具之間如果不支持很好的打通，工程師登錄之后，完全像是在使用不同的工具。最后的結果是，每一款工具，都需要付出很高的學習成本，工具費用付了不少，但使用體驗卻大打折扣。 這塊兒我也可以舉一個例子，我之前工作過的一家公司，需求管理、任務管理、Bug管理，使用的是Jira，最開始的時候，由于團隊開發進度很快，測試管理幾乎是沒有記錄的，純靠工程師的經驗。后來逐漸地通過 Excel 做線下管理。

再后來發現測試用例實在是太多了，改為用開源工具 testlink 來管理。 但testlink 幾乎可以說是沒有任何美觀方面的設計，完全就只是為了滿足功能。測試用例需要支持和 Jira 做對接，當時我們花了比較大的力氣來打通 testlink 和Jira，但是使用體驗并不是特別友好。比如說，在 testlink 里的測試用例成功或者失敗之后，這個結果不能直接反饋到Jira那邊的需求下面，也無法在測試用例側創建bug，從需求，到測試用例，再到bug，整個追溯性建立的過程就比較別扭，最終也無法出具需求的覆蓋度報告。

第三，過多使用線下工具

在我上一篇文章里面，我舉了一個例子，說有些團隊是用 word 來實現追溯性的。有很多網友說不對，ASPICE沒有說要用 word 來實現追溯性。我同意這位網友說的，ASPICE甚至通篇都沒有告訴讀者，需要用什么工具來實現，這正是它的特點：只提出要求，不給出方案。使用線下工具有一個非常明顯的缺陷：無法作為團隊協同的工具，一旦有變更的話，無法實時反饋給團隊其他人。

有些團隊說，可以把 Word、Excel 放到公共盤里面，大家都可以進來編輯，以此實現協同。比如說直接放到公共盤里面，這種時候就要考慮到多人無法同時編輯的情況，影響編輯效率。有些團隊將公共盤換成SVN，這樣的話可以解決多人同時編輯的問題，但是這種方式，任何人是不能夠實時看到文件的，必須把它打開或者下載下來。當存儲的文件過多的時候，整個效率體驗都會受到影響。而且SVN本身的工作流并不直觀，對于非開發人員，是有較高的學習成本的。

第四，學習曲線陡峭的，設計不合理的，需要反復培訓的

這塊兒我舉一個真實的例子，有一家國外公司，專門做針對汽車行業的研發管理軟件，他們的產品本身也提供SaaS 注冊。國內有一家新手客戶問，可以注冊你們的產品試用一下嗎？銷售回答說可以，但是你們可能不會用，需要我們至少來給您培訓一個月才會使用。 如果工具需要售前培訓一個月才能使用的話，這個工具本身的設計就是不合理的。

說明他的學習曲線特別陡峭，或者它的界面的設計可能是不合理的，是違反人性的。從來沒有聽說微信需要培訓一個月才能使用的，最近傳播度很高的飛書辦公工具，一天差不多就能使用，使用一個星期，整個團隊差不多就能在上面自如的工作了。

第五，缺少線上培訓資料的，發現問題只能由原廠解決的

這點我也是深有體驗。我覺得在這塊做得非常好的公司，是澳洲的atlassion。很多人認識它，是從Jira工具開始的。Jira作為一款優秀的敏捷項目管理軟件，在國內的使用范圍也非常廣，很多人被Jira強大的功能和生態能力折服。任何時候有關于Jira的任何問題，不管使用的是哪個搜索引擎，在互聯網上隨便搜一下關鍵詞，都會有大量的視頻、論壇文章去解答你的疑惑。

與此相反，有另外一款汽車行業的研發管理工具，去互聯網上搜它，不管是在墻內還是墻外，不管在任何的視頻網站，都會發現，它的使用教學視頻非常少。如果在使用中發現問題，只能靠團隊里面已經踏過坑的人來告訴你?；蛘咭部梢韵蛟瓘S求助，但是他的原廠又在國外，在國內只有銷售代理。這種時候就會發現，整個軟件的使用體驗變得特別差。 ?

03.

理想情況下的汽車行業工具鏈

那究竟什么樣的工具鏈才是汽車行業想要的呢？這塊我基于我們自己的產品設計理念，總結了一些經驗，供大家參考。

第一，工程師滿足ASPICE標準的過程不繁瑣，同時又能讓工程師高效工作

說到高效工作，在軟件開發里面，效率比較高的必然會提到敏捷開發。雖然敏捷開發是否要引入到汽車行業還在爭論不休，但我們都無法忽視一點：敏捷開發在在開發效率方面，確實有它獨特的優勢，所以汽車行業的工具鏈，至少也必須預留出，能夠實現敏捷開發的入口。 ASPICE的標準那么復雜，超過100 頁，那么究竟要如何滿足哪些標準呢？我也總結了幾點，供大家參考。這些也是在以前的工作中，我自己覺得難度特別高的。

第一塊是追溯性。追溯性意味著，能夠從需求，追溯到架構，追溯到詳細設計，追溯到對應的所有測試用例，追溯性建立的同時，又需要考慮可操作性。像我上一篇文章舉的例子，使用word、excel，追溯性是建立了，但工程師累死了，項目越復雜，操作難度呈指數型增長。漸漸地，工程師就會放棄主動建立追溯性了。

第二塊是文檔合規性。文檔合規性意味著，需要有測試計劃的文檔，需要有測試執行相關的記錄，需要有需求分析文檔，需要有架構分析文檔等等。這就意味著，工具不僅要支持敏捷開發，能把所有的任務項都拆分成一條一條，便于跟蹤，同時也能夠支持文檔性的閱讀。在必要的時候是可以直接導出成文檔的。

第三塊是基線管理。這個我認為在汽車行業是特別需要的，在ASPICE標準里面也提到了基線管理的重要性。這塊在互聯網，并沒有像汽車行業這么重視，汽車行業的供應鏈比較長，涉及到的供應商比較多，對于變更尤其謹慎，而且變更可能意味著重新開模，代價非常大。所以基線管理和變更評審這兩塊一般來說是一起的。團隊一旦制定了一條基線，就意味著在今后可長可短的一段時間內，都是基于這條基線來開發。如果基線本身發生了變化，那么整個團隊是需要很方便地獲得通知的。如果不知道的話，整個開發測試流程都會形成障礙。最后造成開發出來的產品，和需求不一致的情況。

第四就是變更評審。由于變更會造成整個上下游和合作方都會受到影響，所以汽車行業的變更評審一般是由變更委員會來進行共同評審的。評審通過之后，才能夠正式地被放到 backlog 中，以待后面的開發。 說到變更評審，首先是需要有多人評審，其次是需要有評審記錄的。很多團隊把這個過程放到線下，但需求、開發任務、測試用例等等，一般是放在線上的，而變更又直接影響了需求、開發任務、測試用例，這就導致了線上線下的不一致，或者說從線上追溯到線下，再從線下追溯到線上，可操作性很差。

第五就是線上測試管理。一般來說，測試體系的建立，相對是比較晚的，很多團隊，最開始的時候都沒有測試用例，完全靠工程師的經驗手動隨機測試，隨著開發的進行才開始逐漸完善測試用例管理，實現測試自動化。在完善的過程中，很多團隊還是習慣于用 Excel 來管理測試用例。這也造成了一個問題，如果需求、開發任務、Bug都已經在線上系統中跟蹤，但是測試用例又放到了線下，線上的需求和開發任務會根據需求變化不斷迭代，這就意味著，測試用例也需要不斷迭代，有時候可能還需要保存測試用例的不同版本。線下管理的復雜性就會大大提高。線下管理測試用例的另一個難點就是，不方便出具測試報告。測試執行報告可能還行，但是Bug 遺留的情況， Bug 狀態的分布，需求覆蓋度、測試用例覆蓋度等報告，就非常難以提供。

第二，使用一站式的工具，或者至少使用體驗是一站式的

最佳的情況是，能夠在一個工具上執行所有過程，比如說系統需求分析、系統架構設計、軟件需求分析、軟件架構詳設計、詳細設計、代碼管理、CICD、測試管理，項目管理、質量管理、供應商管理、問題管理，變更管理等過程。 有一些工具號稱自己是汽車軟件開發全生命周期的解決方案，至少在我看來虛假宣傳的。比如說在代碼管理這塊，目前很少有可能繞開 Git、SVN 這些工具的。

如果這些工具都沒有號稱能夠提供汽車軟件開發全生命周期的解決方案的話，其他的工具就更不可能了。所以有些時候我們不得不打通幾款工具，打造出一款滿足汽車ASPICE標準的工具鏈。但是我們必須記住一點，引入的工具越多，打通的成本就越高，對于工程師來說，學習的成本越高，使用體驗上肯定是會有影響的；對于公司來說，意味著費用越高，人效越低。所以要盡可能少地使用工具，如果確實需要納入多個工具，至少在使用體驗上需要盡可能地保持一致。

第三，學習曲線是平緩的，有很多線上的學習資料和線上的交通渠道

這一點在汽車行業可能沒有那么受重視。 長期以來，雖然汽車是一個to C 端的產品，但是它的銷售方式，是先把車輛銷售給 4S 店，然后再由 4S 店銷售給具體的每一個用戶。4S 店對客戶的反饋不怎么感興趣。他們感興趣的唯一的點就是，如何在盡可能短的時間內把車輛銷售出去，減少庫存。這種傾向，似乎也傳遞到汽車軟件研發管理上。

雖然研發管理工具的銷售本身是 to B 端的，但是最終的用戶，是每一個具體的工程師，因此工具廠商需要和 C 端建立一個良好的通道。當工程師有任何問題的時候，都能夠在線上找到很多的學習資料，并且線上是有交流渠道的。

第四，能夠平滑擴展到 ISO 26262

一般來說要做滿足ASPICE標準的工具鏈，后續有極大的可能會做功能安全相關的。假如在做功能安全相關的時候，又要使用另外一套工具，這就會造成工具本身的增加。但ISO 26262和ASPICE是非常相似的，很多過程，甚至可以直接使用ASPICE的一些做法，只不過在功能安全的評級層面，有一些自己獨特的東西。



審核編輯：劉清