關(guān)于復雜汽車軟件bug管理的簡單思考和探索

項目逐漸上線，最近我又深陷在bug中，不能自拔。

這種不能自拔有兩層意思，第一層是難以自拔，因為尤其在后期，大多數(shù)人的大多數(shù)精力都集中在bug上，寫bug，測bug，分bug，數(shù)bug，解bug，而第二層是不愿自拔，畢竟，追著條理分明的bug去做事，相對簡單，也相對體現(xiàn)價值......

如果要問，現(xiàn)如今的汽車軟件項目的top 5關(guān)鍵詞是哪些？其中，必然少不了bug，甚至在項目中后期，說bug牽引著項目的運轉(zhuǎn)，都不算過分。

這篇文章會做一個簡單思考和探索。

1

最好的過程——bug管理

雖然不能自拔，但從研發(fā)管理的角度，我對bug的評價和印象都還算不錯，bug的管理基本算是目前汽車軟件開發(fā)過程的最好典型，無論是過程規(guī)范度上，還是數(shù)字化程度上，或者協(xié)同合作度上。

總結(jié)下來，原因大抵有以下3個：

1.1 前景效應(yīng)與軟件增多

前景效應(yīng)是一種行為心理學模型，就是說大多數(shù)人面對獲利時是風險規(guī)避的，所謂落袋為安，見好就收。

對于bug，早期規(guī)范管理、優(yōu)化設(shè)計及測試前移可能會降低后期bug的發(fā)生概率，這是潛在的獲利，但不做這些活動就能立馬減少工作量和加快交付速度，這是明確的獲利。

也就是說，對比當下明確的獲利和未來即便更多的潛在獲利，大家還是傾向于前者，這在當下這種“長期主義者”有可能活不過今年的內(nèi)卷環(huán)境里，尤其如此。自然而然，bug會在中后期暴露不少。

此外，汽車上的軟件越來越多，軟件bug也自然越來越多，體現(xiàn)在實際項目中數(shù)量也是非常明顯的，以前傳統(tǒng)ECU的開發(fā)，量產(chǎn)交付時，bug清零似乎是一個常規(guī)要求，但現(xiàn)在，遺留幾十、幾百、上千的bug逐漸成為不可避免的常態(tài)。

大量的bug就為bug管理提供了充足的原料。

1.2?汽車軟件bug很復雜

汽車軟件不是單一的，bug經(jīng)常也就不是單一問題，尤其在如今各種跨模塊、跨系統(tǒng)、跨域功能定義的架構(gòu)下，一個bug可能是多個ECU共同造成的，至少需要調(diào)查多個ECU之后才能有定論。

即便聚焦到一個ECU，還會分多個軟件模塊，仍然需要層層分析。此外，汽車軟件有時涉及的不單是軟件問題，還會有來自算法、標定、硬件甚至機械結(jié)構(gòu)的耦合影響。

這種技術(shù)復雜性又給了好好管理bug的必要性。

1.3?汽車軟件bug涉眾多

bug的復雜主要是技術(shù)層面的復雜，技術(shù)復雜的簡化方式就是打散與拆分，但拆分后一定會涉及到眾多的人，眾多不同職能的人。

諸如工程、質(zhì)量、生產(chǎn)、市場等，不同職能就會有不同立場，不同立場就會將技術(shù)問題推波助瀾為政治問題，而一旦成為政治問題，如何解決就有了多種思路。

這種涉眾復雜性繼續(xù)給bug順暢流轉(zhuǎn)與信息透明提出了要求。

這是汽車軟件bug管理目前的背景，似乎被迫促成了bug管理成為一個比較好的典范。

但是，這不妨礙bug依然是開發(fā)的痛點，所以，我們?nèi)匀挥斜匾^續(xù)深入探討一些優(yōu)化的方向。

2

problem與bug

考慮到以上所講的汽車軟件的特點，我們可以嘗試另外一種更系統(tǒng)化且更精細化的思路。

首先，我們先建立兩個概念：problem（問題）與bug（缺陷）。

probIem是指產(chǎn)品發(fā)生了與預期不符合的行為，面向項目、面向系統(tǒng)、面向整車、面向發(fā)現(xiàn)問題者，還處于汽車管理維度。

bug是指技術(shù)層面的偏差，面向組件、面向子系統(tǒng)、面向軟件、面向解決問題者，已經(jīng)落于軟件工程維度。

bug作為細化子項來服務(wù)于粗化的父項problem，二者可以是n對n的關(guān)系。

這種拆分至少有3個好處，主要體現(xiàn)在解耦上：

將造車與軟件解耦，讓學科復雜的造車活動與學科單純的軟件互不干涉。

將管理與工程解耦，讓心思復雜的管理者與心思單純的工程師各司其職。

將軟件與軟件解耦，讓負責不同軟件但都與這個problem相關(guān)的人員并行推進（有時也涉及硬件等）。

當然，這種拆分也是有前提的：

組織足夠大

problem足夠復雜

角色拆分足夠細

ALM工具足夠友好

如果只是解決一個小開發(fā)團隊自己測試發(fā)現(xiàn)的問題，去區(qū)分problem與bug的意義就弱了很多。

3

有一天，problem發(fā)生了......

理論上，所有人都可能遇到與預期不符的產(chǎn)品表現(xiàn)，例行測試自然會遇到，開發(fā)、驗收、試駕、生產(chǎn)、售后等環(huán)節(jié)也都會，相應(yīng)地，所有發(fā)現(xiàn)問題的人都可以去提problem。

當然，基于項目經(jīng)驗，基本會集中在PM、測試這兩類領(lǐng)外面問題和提內(nèi)部問題的角色上。

還要注意，problem 的提出還要盡量滿足兩個原則：顆粒度要大（涵蓋范圍廣）、視角要面向價值，以避免提出太多瑣碎且信息重復的小問題，讓人陷入這問題戰(zhàn)爭的汪洋大海中，problem的存在就是要具備牽引作用，這在如今功能與問題都多的座艙類產(chǎn)品里頗有必要，一種思路是面向大的feature來識別problem。

當問題需要提出時，其具體內(nèi)容的撰寫及流轉(zhuǎn)也并不容易，一般至少要反映如下基礎(chǔ)內(nèi)容：

問題整體描述：這多少有點考驗語文功底，最好一句話能說完，而且僅從一句話中能理解應(yīng)該怎么樣實際怎么樣，也就是準確的問題點是什么?；驹瓌t是描述便于在組織內(nèi)、項目內(nèi)傳遞。

問題發(fā)生組織：現(xiàn)在很多汽車軟件都是多方跨組織協(xié)同開發(fā)的，如果站在供應(yīng)鏈的維度看一個復雜問題，就有必要知道問題所處的組織層級，是主機廠，是Ter1，是第三方軟件，還是芯片，或者軟件平臺提供方。當問題跨組織時，往往會涉及不同的流程體系要求。

問題發(fā)現(xiàn)階段：這個是從V鏈條的角度看的，看問題是在從代碼到整車售后的整個開發(fā)周期中的哪個階段，不同階段的問題自然面對不同的相關(guān)方，也有不同的處理策略。

問題等級：通常，我們可以從產(chǎn)品本身嚴重度（如涉及法規(guī)、政治、功能安全、客戶高抱怨的都算比較嚴重）和項目推進的時間優(yōu)先級這兩個視角來評價等級，但實際判斷時基本是糅合在一起的，高嚴重度問題經(jīng)常也就是高優(yōu)先級。一般會有3~5個級別劃分，這在統(tǒng)一組織溝通語言和標準化流程上多有裨益。比如，不同嚴重度的問題需要不同的分析反饋周期。

責任方：責任方可以區(qū)分為團隊和個人兩個顆粒度，團隊責任方用于團隊績效整體評價或者打包管理，個人責任方是一個問題具體推進的負責人。因為problem經(jīng)常面向交付，所以由PM類角色主要負責是一種選擇。

時間信息：各類時間要求或時間戳對于定義問題目標和分析問題都有幫助，一般有截止日期、計劃日期，發(fā)生日期，提出日期等等。

輔助信息：對于proplem，重點放在提出上，重點也就是講清楚、講完整，除了常規(guī)的預期結(jié)果、實際結(jié)果、發(fā)生環(huán)境、軟硬件版本信息，還可以提供整車表現(xiàn)或模式（如儀表燈、電源模式等）。另外，總線或ECU內(nèi)部的日志數(shù)據(jù)以及視頻、錄音、照片也都是后續(xù)分析的重要資料。

分析與解決信息：針對一個problem，整體的分析情況和最終結(jié)論當然也是關(guān)鍵信息，可能分析后認為不是problem要拒絕，或者雖然是 problem但可以偏差許可，再或者確實是problem也需要修復。無論如何，都要有較為明確的書面記錄。

狀態(tài)變更：problem的狀態(tài)沒必要設(shè)置得非常復雜，整體分為新建、分析中、solution已獲取、solution已導入、已關(guān)閉這幾大類即可。

其他驅(qū)動：在汽車行業(yè)，有時候也會驅(qū)動出8D、DFMEA、LLs等其他工作，具體要視problem本身的重要性與復雜性來決定。

總體來說，我們可以把problem視為與汽車軟件有關(guān)的問題，側(cè)重于通過管理的手段解決汽車或者說系統(tǒng)的問題。

4

從problem進入bug

當系統(tǒng)性問題problem被提出后，就非常需要系統(tǒng)架構(gòu)師、系統(tǒng)工程師、軟件專家或者具備系統(tǒng)知識經(jīng)驗的角色對其進行初步分析和任務(wù)分配。

當然，有時將problem第一分析人交給受直接影響的某具體軟件模塊或feature owner，或許效率會更高。

而具體的分析與分配結(jié)果就可以通過一到多個bug 來體現(xiàn)，bug就會開始作為子項服務(wù)父項proplem的解決，從這里開始真正進入軟件bug的解決。在這里，有時候也需要將已有的其他bug與problem建立聯(lián)系，以聚攏問題與資源。

從提出者來對比，problem屬于問題發(fā)現(xiàn)者提出，bug則為問題（缺陷）解決者提出。

此外，在bug的具體推進上，除了和problem類似的信息類別，bug需要在root cause分析與solution識別上著墨更多，也要更技術(shù)、更軟件、更翔實，包括但不限如下內(nèi)容：

缺陷產(chǎn)生的細節(jié)：什么狀態(tài)機階段、什么模式、哪個配置、什么特定手順用例、違背了哪一條需求或設(shè)計要求以及底層技術(shù)機理是什么......

缺陷影響到的工件：諸如軟件組件、各類文件版本等，這些都屬于缺陷的一部分，都需要統(tǒng)一維護并服務(wù)于problem的關(guān)閉。

缺陷帶來的影響：評估的維度可能包括法規(guī)、安全、功能、下游測試、產(chǎn)線下線、消費者抱怨以及相關(guān)項目或產(chǎn)品線等，盡管這塊內(nèi)容本身不算那么軟件，但只有深入到一定的軟件技術(shù)深度，才能對影響有較深的理解，這些內(nèi)容也將決定problem的應(yīng)對策略，所以，在bug分析階段，更high-level的系統(tǒng)層級角色仍然需要參與或提供信息。

臨時與長期措施：面臨項目或下游客戶的壓力，有時需要給出臨時的權(quán)宜之計，或者叫臨時措施，以解決當下交樣、造車、測試等緊急需求。隨后，在相對寬裕的時間里再完成長期措施的導入。

缺陷驗證情況：驗證方式、測試用例、測試結(jié)果等相關(guān)信息也應(yīng)有所體現(xiàn)，以明確缺陷確實被修復。

缺陷引入階段：這部分信息算是經(jīng)驗復盤，識別出到底是需求沒澄清，還是設(shè)計不合理，或者程序員碼代碼粗心，又或者是平臺問題的傳遞，這都有助于后續(xù)的持續(xù)改善。

詳細風險評估：如果該bug面向的problem很嚴重且無法及時修復集成，詳細的風險評估或許是必要的，這可能會涉及到FMEA的詳細評估、PPM的計算、特定用例的測試等等。

狀態(tài)變更：不同于problem，bug的狀態(tài)可以更軟件些，通?？梢园凑哲浖_發(fā)的過程來標記，比如，新建、分析中、root cause已識別、編碼中、代碼評審、已集成、已測試、已關(guān)閉等。

當所有子項 bug被關(guān)閉后，父項problem就可以被關(guān)閉交付了。

5

可能的挑戰(zhàn)

挑戰(zhàn)無處不在，對于以上的想法，在如今的現(xiàn)實中，我們更可能面臨如下挑戰(zhàn)：

問題太多，沒有精力去進行這類層級梳理。

項目緊急，沒有時間去做這種規(guī)范操作。

產(chǎn)品復雜，沒有能力整體分析problem的定義及與bug的關(guān)系。

信息雜亂，沒有渠道串聯(lián)對齊各級信息。

問題簡單，沒有必要搞這么復雜。

6

設(shè)想一個場景

面對此間種種挑戰(zhàn)，我們可以多想一步。當然，也不局限在problem或bug上了，我們設(shè)想一個理想的、包含bug管理在內(nèi)的汽車軟件開發(fā)場景：

經(jīng)過精心研究的客戶需求形成統(tǒng)一的整車feature。

整車軟件feature與其他feature從管理上解耦。

整車軟件feature與各域、各子系統(tǒng)、各ECU通過各級sub-feature串聯(lián)。

各sub-feature與各域、各子系統(tǒng)、各ECU形成準確映射關(guān)系。

各problem面向各feature。

各bug面向ECU中的軟件module。

以上內(nèi)容形成多個平臺，各車型或各項目從這個維護良好的“綠色”與“透明”的平臺上衍生釋放分支。

7

寫在最后

在如今汽車向軟件轉(zhuǎn)型的過程中，bug是個重頭戲，大家沒得抓的時候，就抓bug，不知道該怎么辦了，還是抓bug，多少有些無奈......

審核編輯：劉清