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

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

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

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

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

1

最好的過程——bug管理

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

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

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

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

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

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

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

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

1.2?汽車軟件bug很復(fù)雜

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

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

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

1.3?汽車軟件bug涉眾多

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

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

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

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

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

2

problem與bug

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

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

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

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

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

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

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

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

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

當(dāng)然，這種拆分也是有前提的：

組織足夠大

problem足夠復(fù)雜

角色拆分足夠細(xì)

ALM工具足夠友好

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

3

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

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

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

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

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

問題整體描述：這多少有點(diǎn)考驗(yàn)語文功底，最好一句話能說完，而且僅從一句話中能理解應(yīng)該怎么樣實(shí)際怎么樣，也就是準(zhǔn)確的問題點(diǎn)是什么。基本原則是描述便于在組織內(nèi)、項(xiàng)目內(nèi)傳遞。

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

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

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

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

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

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

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

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

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

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

4

從problem進(jìn)入bug

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

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

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

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

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

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

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

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

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

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

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

詳細(xì)風(fēng)險(xiǎn)評估：如果該bug面向的problem很嚴(yán)重且無法及時修復(fù)集成，詳細(xì)的風(fēng)險(xiǎn)評估或許是必要的，這可能會涉及到FMEA的詳細(xì)評估、PPM的計(jì)算、特定用例的測試等等。

狀態(tài)變更：不同于problem，bug的狀態(tài)可以更軟件些，通常可以按照軟件開發(fā)的過程來標(biāo)記，比如，新建、分析中、root cause已識別、編碼中、代碼評審、已集成、已測試、已關(guān)閉等。

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

5

可能的挑戰(zhàn)

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

問題太多，沒有精力去進(jìn)行這類層級梳理。

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

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

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

問題簡單，沒有必要搞這么復(fù)雜。

6

設(shè)想一個場景

面對此間種種挑戰(zhàn)，我們可以多想一步。當(dāng)然，也不局限在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形成準(zhǔn)確映射關(guān)系。

各problem面向各feature。

各bug面向ECU中的軟件module。

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

7

寫在最后

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

審核編輯：劉清