01.

為什么汽車軟件開發(fā)需要工具鏈

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

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

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

02.

什么樣的工具鏈?zhǔn)遣缓线m的？

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

但隨著汽車行業(yè)開始逐漸接納敏捷思想，越來越多的汽車軟件公司，開始考慮那些并不是直接針對汽車行業(yè)的軟件產(chǎn)品，它們的產(chǎn)品設(shè)計上，帶有很強的敏捷開發(fā)思想，比如Jira、Ones、Pingcode等。 那么究竟什么樣的工具鏈?zhǔn)瞧囆袠I(yè)想要的呢？想要搞清楚這個問題，我們首先要知道什么樣的工具鏈?zhǔn)瞧囆袠I(yè)不想要的。我根據(jù)自己的工作經(jīng)驗總結(jié)了以下幾點。

第一，工具設(shè)計單純只是為了滿足標(biāo)準(zhǔn)的，而不是為了便于工程師工作的

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

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

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

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

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

第三，過多使用線下工具

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

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

第四，學(xué)習(xí)曲線陡峭的，設(shè)計不合理的，需要反復(fù)培訓(xùn)的

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

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

第五，缺少線上培訓(xùn)資料的，發(fā)現(xiàn)問題只能由原廠解決的

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

與此相反，有另外一款汽車行業(yè)的研發(fā)管理工具，去互聯(lián)網(wǎng)上搜它，不管是在墻內(nèi)還是墻外，不管在任何的視頻網(wǎng)站，都會發(fā)現(xiàn)，它的使用教學(xué)視頻非常少。如果在使用中發(fā)現(xiàn)問題，只能靠團隊里面已經(jīng)踏過坑的人來告訴你。或者也可以向原廠求助，但是他的原廠又在國外，在國內(nèi)只有銷售代理。這種時候就會發(fā)現(xiàn)，整個軟件的使用體驗變得特別差。 ?

03.

理想情況下的汽車行業(yè)工具鏈

那究竟什么樣的工具鏈才是汽車行業(yè)想要的呢？這塊我基于我們自己的產(chǎn)品設(shè)計理念，總結(jié)了一些經(jīng)驗，供大家參考。

第一，工程師滿足ASPICE標(biāo)準(zhǔn)的過程不繁瑣，同時又能讓工程師高效工作

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

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

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

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

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

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

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

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

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

第三，學(xué)習(xí)曲線是平緩的，有很多線上的學(xué)習(xí)資料和線上的交通渠道

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

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

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

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



審核編輯：劉清