來源 |  汽車電子與軟件

知圈 |  進“車載芯片社群”請加微信13636581676，備注芯片

前言： 在軟件定義汽 車趨勢下，一方面”快速交付”、“OTA”已成為行業(yè)的共識；另一方面“交付質量”雖可適度下降但仍要有底線；這兩者的沖突已超出了傳統(tǒng)的ASPICE研發(fā)流程體系的能力范圍，“敏捷開發(fā)”是否可以解決這一切呢？這兩者是否可以，或者如何結合呢？

軟件研發(fā)體系的挑戰(zhàn)與思考

1. 挑戰(zhàn)與痛點

最近在公司內部做了個小的調查，大家對于軟件開發(fā)過程的痛點還是不少的。以下是一個從“管理層”視角來看的“痛點”，以及相應的原因。

研發(fā)干的“不好”

• 定義了A，實現出來卻變成了B:  產品定義方與實現缺乏溝通，且交付物只在最后階段可見，再提意見就晚了

• 里程碑快到了，才發(fā)現問題仍然一堆：軟件開發(fā)的過程不透明，難以管控

• 上線后，售后問題急死人：工期的壓縮對非必要環(huán)節(jié)產生沖擊，嚴重影響質量

市場變化“太快”

• 定義了A，干到一半想改成B，基本不可能：傳統(tǒng)的瀑布式開發(fā)，流程越往后走，變更成本越高
• 定了一年上線，臨時想改成8個月，困難重重：瀑布式開發(fā)，若未走完全流程則質量問題一大堆，基本無法交付。

黃花菜“涼了”

• 需求從提出到交付，周期太長：單一功能涉及多個專業(yè)部門，干系人復雜，溝通成本太高；功能開發(fā)流程鏈條較長，從計劃到交付往往涉及10+環(huán)節(jié)；

2. Tesla和行業(yè)里是怎么干的呢？

首先，Tesla并未采用ASPICE，下面是Tesla的Software QA Engineer的職位描述，就是測試。如果采用ASPICE的話，則會有專門的人員去保證流程、優(yōu)化流程。

那么Tesla是怎么干的呢？從各種渠道的證據來看，其都是通過“敏捷”來解決的。Tesla的高管團隊大多來自硅谷，而硅谷的軟件文化——敏捷到無須再提，所以Tesla從設計、開發(fā)、生產到組織架構都是敏捷的組織形式。

比如：Tesla的自適應空氣懸架，需求從提出到交付，僅用一個迭代[1]，按Tesla每月一小迭代的節(jié)奏來看，推測也就是1-2個月就上線了。

自適應空氣懸架

又比如：Tesla的組織架構，在馬斯克發(fā)了如下郵件后就蕩然無存了，僅有形式上的意義："溝通應該通過最短路徑來完成，而不是用“指揮鏈”。任何一個試圖強行用指揮鏈方式溝通的經理，很快就會發(fā)現他得去別處工作了"

僅有形式上的意義的組織架構

那么"Tesla"很多時候屬于"外星生物"，咱們不一定學的來，那么其他"正常"的公司是怎么干的呢？

敏捷相關行業(yè)實踐

首先是互聯(lián)網企業(yè)：

• Tesla、Apple、Google應用敏捷基本是不用去考證了，其中Apple在2012年組織架構已經是“敏捷”的[2], Google也在2006年就成功將”敏捷”引入Adwords的開發(fā)中，并發(fā)表相關論文，被IEEE收錄[3]

然后是汽車零部件巨頭：

• 至少是2020年起，Aptiv已經在全球范圍內全面推廣”敏捷”，且聘請咨詢公司專門定制了AutoScrum的敏捷框架，在公司官網也可以看到其已經在"主動安全"、"自動駕駛"、"車輛互聯(lián)"等領域應用敏捷方法了。[4]

• Bosch在2015年宣布開始轉型為敏捷組織, 管理層率先使用”敏捷”的方式開始工作[5][6]
• Continental在2020年也宣布全面轉向敏捷的方法與文化，其VNI部門率先開始全球試點[7]

整車廠也不例外：

• 奔馳已經將”敏捷(Agile)的組織文化”寫入公司戰(zhàn)略[8],并且其子公司Mbition也開始用敏捷的方式生產整車，并要求其供應商也使用敏捷的方式。其主頁http://mbtion.io上有一段話
  "The essence of our Way-of-Working (WoW) is being agile when it comes to applied values and principles"

• 沃爾沃自2017年起，全球整車研發(fā)開始轉向敏捷開發(fā)[9]。并從2020年開始，使用完全敏捷的方式打造新的量產車型。
• 寶馬的智能座艙和IT部門也是使用敏捷方式，其中IT部門在2019年實現100%敏捷[10]

3. 我們的思考與方向

參考行業(yè)的實踐，以及對敏捷、ASPICE的理解，我們認為轉向敏捷開發(fā)，并且依托DevOps與工程師文化建立軟件研發(fā)體系，是解決以上痛點的方式與方法。

敏捷細究

既然提到“敏捷”，雖然網絡上關于“敏捷”的介紹不少，我還是簡單的講一講我的理解吧。

1. 敏捷概況

• 是一種源自“精益”的理念，始于2001年 ，一開始僅用于軟件開發(fā)，目前已應用于生產、零售、人事資源、預算、審計，企業(yè)組織形式等領域。
• 在21世紀席卷全球，最大的5家互聯(lián)網公司Amazon, Apple, Facebook, Google, Microsoft都在使用
• 全球有許多非營利組織提供相關的培訓與認證服務，如Scrum聯(lián)盟，Agile聯(lián)盟，PMI（項目管理協(xié)會）
• 主流問題管理工具都原生的支持敏捷開發(fā)：如Jira, Teambition (阿里), TAPD (騰訊）

敏捷的核心"理念"如下：

這里特別要強調最下面這句話："盡管右項有其價值，但我們更重視左項的價值", 并不是說右邊沒有價值，而是說如果你認同右邊的價值的話，左邊就更有價值。

2. 敏捷開發(fā)流程特點

• 關鍵角色：Product Owner(產品負責人), Scrum Master(敏捷教練)
• 跨職能團隊：一個團隊內要具備所有的角色
• 迭代快速：需求拆細，2-6周可交付

敏捷常用方法

敏捷有如下優(yōu)點(來自2020全球敏捷報告):

下面挑選幾點詳細闡述一下。

3. 敏捷優(yōu)點詳述

1) 敏捷工程實踐可以大幅提升代碼質量。 某金融科技集團實施1年半的數據：問題/故事數 0.4 -> 0.16

• 測試驅動開發(fā)：在編寫任何代碼之前，首先編寫對應的測試用例；測試用例需要能完全自動化運行。根據IBM和微軟的研究，BUG會少40% - 50%[11]
• 結對編程: 兩位程序員在一臺電腦前工作，一個負責寫代碼，一個負責實時檢視代碼。兩者角色定期更換。生產率低15%，但BUG少15%，考慮到解BUG工作量比寫要大幾倍，總體效率更高

測試驅動開發(fā)(TDD)流程

2) 敏捷開發(fā)可提升交付速度。 某金融科技集團實施1年半的數據：交付周期由 75天-> 42天

敏捷 vs 瀑布

3) 敏捷開發(fā)通過可視化項目管理等措施，提高軟件開發(fā)透明度，大大提高管理效率，進一步促進生產效率。 某金融科技集團實施1年半的數據：人均用戶故事數由2.6 -> 4.3

4) 敏捷與OKR： 兩者是天生的契合關系，有些公司直接把OKR叫做“敏捷”目標管理。這兩者的團隊文化都強調：

• 自組織：在完成必需工作后，團隊自行決定做什么
• 自驅力：溝通更多為自下而上，充分發(fā)揮個人主動能動性

這里也進一步講一個好處，在敏捷實行的較好的團隊中，由于自驅與自組織，管理人員會變少，利于整個組織的扁平化。

4. 敏捷轉型的關鍵挑戰(zhàn)

敏捷雖然很好，但要轉型成功，挑戰(zhàn)不小，以下是來自敏捷年度報告中的統(tǒng)計。

敏捷轉型中的挑戰(zhàn)

這里我著重講兩點：

• 缺乏領導層的支持：實行敏捷，組織架構上的微調是必不可免的，這個就需要領導層的支持。很簡單的說，一個SCRUM團隊中，有來自產品、開發(fā)、測試、集成等各個職能團隊的人，他們憑什么聽指揮呢？那么至少這個SCRUM master要有考核或比較強的話語權。
• 組織對變革的阻力：三方面吧，一是接受新的觀念、流程對很多人都較為困難，且在轉型初期會較為痛苦；二，敏捷特別講究量化數據，這時很多“老油條”或“摸魚達人”就會被暴露出來，他們當然天然會反抗這種轉型；三、敏捷轉型后，整個組織自驅力越來越強，需要的管理人員會變少，這些人該去哪？難免又會有內部的阻力.

5. 敏捷轉型中會出現的常見問題

敏捷轉型中會出現的問題千奇百怪，我也講兩個：

• 生產率臨時下降(2~3個Sprint)：在剛開始實行敏捷轉型時，有很多新的習慣要養(yǎng)成，有很多新的流程要遵循，所以必然會出現臨時性的生產率下降。但放心，一般來說，經過2~3個Sprint的磨合，就可以明顯看到效率的提升。
• 敏捷容易退化：有些組織在實行敏捷一段時間后，比如說站會開了，KANBAN有了，Scrum也跑起來了，會慢慢的松懈，效率會掉下來。這主要因為“敏捷”是“價值觀”，而不是“方法”，只用敏捷的方法是不夠的。有一句名言叫“Don't do agile, be agile"，就是指這個。那么如何保證“敏捷”的價值觀能夠貫徹并保持下去呢？就靠“工程師文化”了，這個后面詳細描述。

敏捷與ASPICE

前面講了很多“敏捷”的好處，但是在汽車行業(yè)“ASPICE”才是老大哥啊。本節(jié)就講講把這兩者放一起講講。

1. 敏捷與ASPICE可以結合嗎？

答案是：可以。行業(yè)中把這兩者結合起來用的不少，比如說Aptiv。但是，我要問一句，“為什么要結合呢”？

首先，來說為什么要用“ASPICE”？答案也很顯然，客戶爸爸們要求的啊。沒有ASPICE認證，很多OEM壓根就不會把項目給你。

然后，來說為什么要用“敏捷”？答案也很顯然，被客戶爸爸們逼的。沒事改需求，交付周期壓縮到巴不得明天就上等等，不“敏捷”怎么活？

那么，ASPICE和敏捷結合之后的結果是什么呢？在行業(yè)中，結果往往是敏捷主導著整個開發(fā)流程，ASPICE流于形式。因為，兩者從“價值觀”上就是沖突的。

了解ASPICE的人就該明白：

• ASPICE更加注重文檔：這里的文檔泛指可被第三方檢查的證據。ASPICE Level1的認證就是根據你的文檔輸出(outcome)來倒推你是否有按Base Practice干的。如果你沒有這些，Level 1過不了。
• ASPICE更加注重流程和計劃，GP(Generic Practice)2.1.1~2.1.6基本講的就是流程、計劃。如GP2.1.6里面寫明了：必須識別、準備、安排合適的資源來保證流程按計劃的進行。要知道，你想通過ASPICE Level 2的認證，GP2.1.1~2.1.6是必要條件。

另外，實行“敏捷”的一大好處就是“提高客戶滿意度”，你沒事就給客戶交點東西，讓他提意見，然后按他的意見改，他能不滿意嗎？在客戶滿意了之后，還要啥ASPICE啊？

2. ASPICE的種種弊端

ASPICE在汽車行業(yè)很多年了，它的好處大家應該都很清楚：它對工程流程覆蓋的非常全面，可以幫助與指導軟件開發(fā)，并提高交付的質量。我這里主要講講它的壞處。不過在講這個之前，先講一個笑話和親身經歷。

有一個軟件工程師有一天遇到了上帝，上帝跟他說：“我可以滿足你一個愿望”。工程師想了想，說“我想做一個好的項目”。上帝想了想，于是讓這個工程師得到了“永生”。

做為“軟件工程師”，想做一個好的項目實在太難，但我有幸遇到了。大概在2013年時，我和另外5個小伙伴一起做一個TBOX的項目，大概做了3個多月吧，交付給測試，質量出奇的好。好到QA跑過來說，你們項目的數據有問題，怎么沒有問題的爬坡曲線？確實，我們當時總BUG就是個位數，然后就再也沒有BUG了。

但是，這個項目拿去過ASPICE，沒有通過...... 被提了一堆問題。

以上就是我個人對ASPICE的印象。接下來講講ASPICE的弊端。

弊端1: 過時的管理理念

“敏捷”，是由一群優(yōu)秀的軟件工程師達成的“價值觀”方面的共識，更多的是激發(fā)個人的積極主動性。

“ASPICE”，是由歐洲20多家OEM共同制定，用于指導零部件廠商的。由于甲方對乙方的天然的不信任，更多的是強調“管理與約束人性的懶惰”。

孰優(yōu)孰劣，一目了然。

弊端2: 沉重而不靈活

• 3~5倍工作量：一個項目，嚴格采用ASPICE后，是常規(guī)項目的3~5倍工作量。這個是很多Tier1實踐下的結果，不信的可以自己試試
• Traceability——看上去很美的骨感現實：ASPICE幾乎每個流程都會講雙向可追溯性(Traceability)，大部分項目要么就是把所有的需求全部鏈接到一個模塊上，要么就是只拿一個小模塊來做這事。因為，工程實踐中，Traceability確實可以幫助發(fā)現問題，但是性價比極低，你當架構師做架構設計時是只看一遍需求嗎？
• 改需求或重構時怎么辦：我在上一家公司時，曾經有2個月獨自做一個大模塊，代碼量大概4萬行左右，其中還有幾千行是用于生成代碼的代碼。然后2個月內，我一邊做設計一邊寫代碼，寫不通了就重構設計，一共搞了3遍。如果按ASPICE來，我該怎么辦？

弊端3：驅趕優(yōu)秀人才

在這個“軟件定義汽車”的時代，優(yōu)秀的軟件人才都是稀缺的，如何吸引都是一門學問。要是還驅趕，那怎么了得。

“你寫出了tb的搜索引擎？不好意思，你單元測試是不是沒做？”

上圖是阿里大神“多隆”，p11，2003-2007年獨自一人維護tb的搜索引擎，程序員的天花板。像“多隆”這樣的優(yōu)秀工程師，其價值觀是這樣的：

• 成就感：實現了某個復雜功能，解決了某個疑難問題
• 以自己代碼的健壯性、可維護性、可擴展性為榮
• 吹牛：老子10年前寫的代碼他們現在還在用呢

但ASPICE后，要求優(yōu)秀工程師的價值觀是這樣：

• 成就感：我所有的文檔（泛指）都寫完啦
• 以嚴格遵守流程，不給QA添麻煩為榮
• 吹牛：（想不出來了...）

結果呢：“抱歉，我還是離開這家公司吧”

3. ASPICE vs 敏捷 總結

面對第一章的“痛點”，ASPICE確實可以解決質量問題，但對市場變化“很快”毫無貢獻，反而還會延長交付的周期。而“敏捷”可以解決所有的“痛點”。

工程師文化與DevOps

1. 工程師文化

在公司建立“工程師文化”是“敏捷”不退化的根本保障。“工程師文化”的根本，是以“工程師”為中心的文化。

個人理解，主要有以下幾點：

• 質量為導向：充分信任工程師，在不達交付標準時不上線，且不追責. 優(yōu)秀的工程師的自我要求都是非常高的，到了交付時間點若未達心中的交付標準，其實是不愿意上線的。這時要尊重工程師的意愿，且不追責，因為他往往已經盡力了。
• 追求新技術：使用和關注最新的技術和工具，并允許因嘗試新技術而帶來的時間成本。嘗試新技術就有失敗的風險，一味只想提高效率而不愿承擔可能的后果就是耍流氓。
• 專注的時間：盡量減少不必要的會議與其他打擾，否則工程師的“靈感”可能就被打斷了。這里的小提示就是，在非必要時，盡量留言，而不是打電話或者直接找過去。
• 內部技術論壇：內部建立技術的充分溝通與交流的氛圍。這里，有個簡單粗暴的辦法來判斷公司是否有技術氛圍，就是看那幾百人的大群里，都在聊什么？是經常有技術的交流和分享呢？還是都是些行政類的通知？

2. DevOps

DevOps的敏捷快速迭代的技術保證，本身也是個大話題，這里就不展開了，大概有以下幾點：

• 代碼的提交直接觸發(fā)：消除等待時間，快速反饋

• 每個變化對應一個交付管道：使問題定位和調試變得簡單

• 全開發(fā)流程高效自動化：穩(wěn)定，快速，交付結果可預測

• 持續(xù)進行自動化回歸測試：提升交付質量

• 設施共享并按需提供：資源利用最大化

結語

敏捷正在吃掉全世界，可能你還不知道，汽車行業(yè)也不會例外！

參考

1. ^1 https://www.36kr.com/p/847294138930688
2. ^2https://www.forbes.com/sites/stevedenning/2012/02/03/is-apple-truly-agile/?sh=d209df6641e6
3. ^3 https://www.agilearena.net/google-case-study-agile-software-development/
4. ^https://www.aptiv.com/en/careers/competencies/join-our-agile-revolution
5. ^4 https://flyntrok.com/2020/07/07/agile-owl-edition-3/
6. ^5 https://hbr.org/2018/05/agile-at-scale
7. ^6https://www.continental.com/en/press/press-releases/2020-10-21-new-project-organisation-vni-238392
8. ^7 https://www.daimler.com/company/strategy/
9. ^https://www.forbes.com/sites/stevedenning/2020/01/26/how-volvo-embraces-agile-at-scale/?sh=50690f454cf0
10. ^https://www.itpro.co.uk/agile-development/31552/how-bmw-embraced-agile-to-hit-new-speeds
11. ^https://zhuanlan.zhihu.com/p/257174601

閱讀原文|  關注作者知乎：Peter 李成仙 | 軟件架構師