聊聊汽車電子軟件行業(yè)目前使用的工具鏈

都在講數(shù)字化，數(shù)字化的第一層是IT工具，工具打通就是工具鏈。在數(shù)字化的進程中，我們現(xiàn)在能夠比較好落地及落得比較好的就是工具鏈，工具鏈也幾乎是能把敏捷與標準化平衡好的最佳方式。

今天，我們來聊聊汽車電子軟件行業(yè)目前使用的工具鏈，由于不同公司的工具種類紛繁復雜、不同的人使用經(jīng)驗與習慣千奇百怪、不同開發(fā)理念對工具的特有需求五花八門（如敏捷、DevOps、仿真在環(huán)等）、不同產(chǎn)品類型與不同復雜度的軟件及不同角色對于工具的需求也各有不同，而且私以為汽車軟件工程基本框架和方法論并未有顛覆性變化，所以本文嘗試整理一些常用的工具，但不追求全面不遺漏，也不會涉及太多使用方法和操作技巧的內容，而更多的是結合當前V模型的業(yè)務慣例與一些日常工作體悟進行的梳理。

1.先說點別的

開始前先說點別的。“做正確的事”和“正確地做事“這兩個概念，大家應該是耳熟能詳了，據(jù)說是德魯克在一本書上講的，沒確認過，但也不要緊，我們也就是拿過來作為參考。

認真完成本文標題的目標和把工具鏈使用得爐火純青，自然屬于正確地做事，但這是在“做正確的事“嗎？

其實，發(fā)出這個疑問，除了德魯克的啟發(fā)外，還有一個原因，我對工具的態(tài)度的轉變，也正好結合對自己想法變化原因的反思，來探討工具的意義。

早些年的一段時間，我對工具的態(tài)度大約是屬于嗤之以鼻，總覺得用工具的人缺少思考和業(yè)務能力，純粹是熟練，工具本身難以構成突出的競爭力，工具人甚至被認為是能力差的代名詞，特別是對于早期制造業(yè)中較多接觸到的CAD、CAE、SAP、ERP、PLM及一些實驗排期或庫存管理的系統(tǒng)等。

隨著在汽車電子軟件領域經(jīng)驗的積累和對數(shù)字化及敏捷開發(fā)等的理解的深入，越來越深刻地體會到充分使用工具的必要性。多說一句，制造業(yè)多會叫軟件或系統(tǒng)，不習慣叫工具，從稱呼上其實也能體會到一點定位上的差異。

細究原因，產(chǎn)品與行業(yè)的需求是一部分原因，另一部分原因也來源于自己職場或社會經(jīng)驗的疊加，工具類似于一種資源、一種手段、一個杠桿，個人加徒手能夠完成的工作是極其有限的，借力才能大力。沒有工具的話，我們所依托的其實只剩下“語言“，思考需要基于語言，溝通更離不開語言，而語言是局限的。

舉個最簡單的例子，當你用圖表這種基礎工具去描述一件事物時，你做的不是簡單的語言同態(tài)映射，而是不同邏輯和模式下的表達與展示，看這個圖表和對應的描述文字時，你獲取的信息、感受、思考與靈感均是完全不同的，這就是”圖表“這個工具能給你帶來的額外價值。

這個道理并非新穎，但在汽車電子軟件這個領域，對于多數(shù)人來說，并未邁入工具及工具鏈的門檻，當別人都還習慣于excel碼字、打電話和開會時，你用到這個杠桿，可能會幫你更容易撬起來一些你想要的東西。

2.業(yè)內常用的工具類別

按照汽車軟件的來龍去脈，基本會有這7個環(huán)節(jié)：需求、架構、開發(fā)、集成、驗證、項目管理、配置管理，對應的有相應的工具。

當然，不是每一個環(huán)節(jié)都是一個單獨的工具，很多工具開發(fā)者都希望盡可能涵蓋更廣，所以，理論上，一個工具可以支持很多環(huán)節(jié)，甚至是全生命周期的。但是，基于慣例或者各自優(yōu)勢，每一個環(huán)節(jié)又會用到比較流行的工具或某個模塊，一個工具也會交叉使用在不同環(huán)節(jié)上。

下面做一些整理，應該基本可以反映出當下汽車行業(yè)慣用的一些工具。

需求：Doors、DNG、JAMA、Polarion、TRM、Clear Quest、Reqtify……

架構：OpenAmeos、Rhapsody、Systemweaver、PREEvision、Pure:Variant、Visio、EA、Simulink、AUTOSAR Blockset……

開發(fā)：Eclipse、VS Code、Jenkins、Wind River、Perl、Green Hills、Vector、SourceInsight……

集成：Jekins、RTC、Harness、MAKEFILE……

驗證：Coverity、Polyspace、Tessy、QAC、Gerrit、Parasoft、VectorCast、dSpace、CANOE、CarMaker、Reactis、RQM、ECU-Test、JIRA、Gtest、PC-lint、Findbugs、Junit……

項目管理：JIRA、Polarion、RTC、Clear Quest、Git、Asana、飛書、Project、DTS、RDM、Redmine、禪道、PTCIntegrity……

配置管理：RTC、SVN、Sharepoint、MS Teams、MKS、Gitlab、Confluence、PlasticSCM、ClearCase、Synergy、Preforce……

3.工具鏈的“鏈“

我一直比較排斥造詞、造概念等故弄玄虛和簡單問題復雜化的行為，說起來天花亂墜且清新脫俗，做起來還是老一套。

對于工具鏈的“鏈“，我們也不要把它想得多么高深。

簡單理解，”鏈“就是建立鏈接和數(shù)據(jù)同步。再擴展一點，就是建立不同但相關數(shù)據(jù)的鏈接和相同但不同區(qū)域數(shù)據(jù)的同步，前者側重靜態(tài)關系，后者側重動態(tài)流轉。

當然，鏈條里不能忽略人，但人腦子里沒有天線，無法直接建立連接和傳輸數(shù)據(jù)，把人加進鏈條更多是把與人交互密切的載體加入鏈條，比如，手機和郵箱。

而且，人在里面的作用越小越好，人作用越小，說明自動化和智能化的程度越高。

ASPICE要求我們做追溯，追溯就是典型的建立不同但相關數(shù)據(jù)的鏈接，用文字描述、excel貼鏈接、變更履歷里加編號，甚至測試發(fā)微信給需求，這都是建立鏈接，方式有多種多樣，只不過都上系統(tǒng)后，工具里直接建立鏈接會有更多的好處，比如，穩(wěn)固、清晰、透明、歷史追溯性好等。

除了工程里的追溯，不同系統(tǒng)間可以自由跳轉訪問也是一種很實用的鏈接。

數(shù)據(jù)同步和我之前多次提到的數(shù)據(jù)同源有一定的關系，數(shù)據(jù)同源是提升透明度、效率、準確性的良好手段，良好的數(shù)據(jù)同步又是實現(xiàn)數(shù)據(jù)同源的支撐。

無論是面對頻繁變化的項目計劃、不斷迭代的軟件，還是處理成千上萬的Bug，或者完成整合數(shù)據(jù)的配置管理，或者進行不同區(qū)域和組織間文件的傳遞。通過工具的打通，讓數(shù)據(jù)流轉起來，讓數(shù)據(jù)自動同步，這都是工具“鏈“的重要需求。

此外，建立連接和傳輸數(shù)據(jù)不一定就是簡單的原始連接和源數(shù)據(jù)傳遞，可能更需要特殊的匹配、統(tǒng)計、計算等處理工作，比如，需求和測試系統(tǒng)經(jīng)過比對識別符來完成鏈接，并在此基礎上自動計算出覆蓋率。

基于多種客觀原因和主觀考量，“鏈“的建立并不容易，數(shù)據(jù)孤島和部門墻依然風行。然而，這種現(xiàn)實的弊端正是工具鏈存在的價值及大家對它的期許。

4.工具要用到什么程度？

我們多數(shù)不是專門的工具鏈公司從業(yè)者或者說本文多數(shù)受眾不是，我們不需要深入到工具開發(fā)邏輯層面，更多是在工具的應用和功能挖掘組合上。其實，當前流行的工具內嵌了很多強大的功能，實際被挖掘使用的部分卻又是非常少的。

首先呢，我認為是盡可能用出花樣來，要全面，要結構化，要美觀，要自動化，不要去依賴于傳統(tǒng)的excel、ppt，盡管Office非常強大，但非?；A和普遍，經(jīng)典的不等于未來的。

玩工具鏈也并非目的，而是手段，是顯示出你的獨特性的手段。業(yè)務能力有高低，經(jīng)驗積累有厚薄，你使用工具展示、匯報、分析的水平也是一種資源。在全面數(shù)字化和智能化到來之前，工具化是一個必經(jīng)之路。

其次，或許沒必要系統(tǒng)學習，有那么多工作在等著，我們無法投入太多精力在工具上，但應該時刻思考并尋找工具的支持，如何將自己的一些工作數(shù)字化、工具化。

未必需要自己親力親為，大一點的公司都會有工具組，要充分利用好他們。在不斷的過程中，學會用工具加速自己的工作，理解工具的運行邏輯，將自己更多的時間投放在創(chuàng)造性的思考上。

既然智能化時代終將來臨，不妨主動邁過去。

5.寫在最后

寫到這里，我同時還在反思自己行文的基準——工具是否有那么重要？我們慣常講的一句話是“這只是一個工具”。言下之意是，這沒那么重要。而這不由得讓我想起，也有很多人說過“語言只是工具”，可在我多年外企的經(jīng)歷中，深知一口流利的英語給人職業(yè)發(fā)展帶來的助力是多么大。

審核編輯：劉清