编者按
 

iSQE对话汽车行业第二期直播活动于上周圆满落幕，本期直播邀请到了某一线豪华汽车品牌中国区总教头张敏锋老师进行了《车轮上的软件与质量》专题分享，围绕敏捷开发、软件质量是什么、车轮上的软件有何不同，汽车行业的 “最佳实践”等四个方面进行了分享，以下是张敏锋老师演讲的文字版内容。

一不得不提的敏捷开发

在软件行业，敏捷开发已经变成一种主流的开发模式，是软件行业的一个普适价值。如果一个企业、团队以及个人，都不知道敏捷开发是什么，不知道SCRUM、DevOps、好像都不好意思跟人打招呼的，所以在这里我们必须要提一提敏捷开发，提纲挈领的去看一看敏捷开发的本质到底是什么，包括要阐述一些误区。

大概在2013年或者2014年左右，德勤公司搜罗了市面上面所有的可以被纳入敏捷实践的一些框架、方法、体系以及实践，非常庞大。现在我相信，所谓的敏捷开发的范围会比这张图更大。

所以说敏捷开发是很难用一两句话去概括它到底是什么，到底有多少实践，哪些算是敏捷开发，哪些不算是敏捷开发，在我看来去探讨这个问题是非常浪费时间，且没什么价值。但是这里面的每一个方法体系都符合三个原则：第一个是目标驱动，第二个是全局思维，第三个是持续改进。这也是我归纳的敏捷开发的三大特征；SCRUM、看板、Largescale、 SAFe、 LeSS 、DevOps，都在讲这三点。随便翻看哪本书，都在围绕这三点展开，去阐述它们的思想和实践。

• 目标驱动

简单理解，目标驱动就是做什么事情都要有目标，不管你是一个大的产品、一个release、一个Sprint都需要有目标，没有目标就不要谈敏捷。

• 全局思维

举个例子，企业有开发团队，有测试团队；老板总提到，开发团队要提高效率，每个礼拜交付出多少功能出来，或者交付多少用户故事点数出来，有这么一个现象，如果测试团队1个月只能测10个功能，但是让开发团队1个月开发200个功能，剩下的190个全都是浪费，这是没有意义的；这是经济思想里面的一种典型的看问题的方式。所以敏捷所有的体系里面都是在强调全局思维，要从全局去考虑，怎样让效率最大化。

• 持续改进

这里面所有的方法都在强调持续改进，因为持续改进是投资回报回报率最高的一个行为。

 只要符合上述三大特征的，都可以算敏捷开发。

对敏捷开发的一些误区

接下来跟大家聊一聊我心目当中的我们对敏捷开发的一些误区。如果不跟大家澄清这些误解，我们就很难跳到质量这个环节上面去，这里面会充斥了大量的沟通上面的障碍。

误区一：敏捷开发不用写文档

有很多团队会把这个当做是敏捷开发最有吸引力的一个地方，其实敏捷开发从头到尾都没有说过不用写文档，他只说过一句就是Working software over comprehensive documentation，可工作的软件高于完备的文档。，事实上敏捷开发对文档也好，对代码也好，包括对产品本身也好，他的态度是够用就好（simple that works）。这（敏捷开发不用写文档）是一个典型的误区。
 

误区二：用了敏捷开发，我们就不需要做设计


 

经常有团队是这样思考或者这样去做的，有很多团队需求分析完拿来就开始写代码，然后见不到讨论，见不到思考，见不到分析，见不到设计。但这里面真正的真相是要做到“够用就好”相当不容易，需要非常扎实的开发基本功，需要大量的思考和讨论。敏捷开发提倡的不是不要设计，而是不要过度设计。
 

误区三：用了敏捷开发，我们的工作就会比以前更容易了


 

这是种幻觉，用了某种方法就能又快又好又开心的完成工作，天底下没有这种事情。越是好的东西代价越高昂。

误区四：为了赶进度我们先不管代码质量，以后再重构就行了


 

敏捷开发里面有一个事件就叫重构， Martin Fowler，敏捷宣言的奠基人，17个签署人之一，写的一本书就叫《重构》。这个误区源于我们平时项目压力很大，老板压得很紧，市场需求很迫切。我们经常听到，先上线再说，先不管代码质量，以后重构就行了。事实上不是这个样子的。Martin Fowler的书里面都写的这句话叫“逢脏必慢”。如果你允许你的开发团队写脏代码了，你的整体的进度只会变得更慢，绝对不会变得更快，无数个血淋淋的事实已经证明了这一点了。
 

真正的重构是指我们的工程师团队每天不断地去优化自己的代码和设计。这里面其实有一个非常反直觉和反人性的现象：我们工作和生活当中会遇到很多麻烦事，我们很多人都想尽了办法怎么样去逃避，去减少他的痛点。但事实上最有效的方法是更频繁地去做这件事情。比如说重构这种事情，你如果半年做一次就像褪层皮一样的，但是你每天都做一次，你就会习惯成自然。

误区五：我们不需要被管理，因为敏捷开发提倡自组织自管理


 

自管理自组织，比如SCRUM框架刚刚出来的时候，团队是要自组织（self-organized），最新的版本里面自组织好像理解起来有点难，就把它改成自管理（self-management）。反正都是在表达一个意思，就是这个团队应该是自发的自己去组织起来去完成工作，不需要别人来参与管理的，它（SCRUM）是在强调这样的一个状态。
 

这句话被很多团队就用来当做一个借口了，他们认为我们是敏捷团队，不需要被管理，因为敏捷开发提倡自主自治管理。弄KPI、Matrix来管理是不对的，这（里面）也是一个误区。自管理、自组织确实是一个产品成功的非常重要的因素，尤其在是在现在的这种频繁多变的市场环境下。任正非说“让听见炮火的人来做决定”，但它的前提是这个公司或者团队已经形成了高度统一的目标和愿景，然后大家对目标对愿景都是毫无疑问、全力以赴的；以及团队有共同认可的工作协议，我们这个实践叫working agreement或者Team Agreement。大家一起去围绕这个目标去用这些工作协议来规划我们的工作，来管理我们自己的工作，叫自主自治管理，没有目标、工作协议，又不要管理叫无政府，只会引起混乱。

误区六：敏捷开发提倡快乐工作，所以我们可以只做自己喜欢的事情


 

大家去参加过敏捷开发的培训，或者听过一些老师讲座的话，都会有这么一个印象，你用敏捷开发团队会变得非常快乐，也不会有什么压力，我们大家只要做自己喜欢的事情就行了。

真相是我们不得不承认在软件开发这个高新技术行业，里面也存在大量的重复枯燥的劳动的、那些工作内容。（然后）敏捷开发鼓励团队去通过探索尝试突破现有的一些条条框框，去把这些无趣的工作变得更有趣，或者去减少这些无趣的工作，而不是教唆大家去逃避，更不是去纵容一些不好的工作习惯。必须要说敏捷开发，为什么会让大家觉得快乐，这个快乐是通过达到目标而获得的，不是在过程当中放纵自己而获得的。

误区七：面向对象


 

20年前在软件行业，面向对象是每一家软件公司和每个工程师必须要会花很多时间去学习的一件事。现在，在这种快节奏互联网时代可能提的就不是那么多了。但事实上是，面向对象以及整洁代码，在软件开发里都是最基础、最本质的东西。
 

回归本质，高内聚、松藕合它是软件开发的最高纲领，翻开任何一本讲架构的书，翻开任何一本讲微服务的书，它都会在强调这些概念。任何团队、任何产品，只要在软件开发层面，违反最高纲领的一定会付出惨重的代价。哪怕现在勉强上线，将来的维护、升级以及线上的漏洞会让公司付出惨重的经济教训。

误区八；敏捷开发中没有失败
 

大家都听到过：“敏捷开发中没有失败，只有学习的机会。”它真正的意图是鼓励大家从失败中去学习，绝对不是在叫做大家去逃避和否认失败。
 

曾经我在辅导一个团队的时候跟大家说这个Sprint我们应该定怎么样的目标，如果达成了，我们当然会庆祝成功，如果没有达成只能说明我们（这个）Sprint失败了。有几个同学当场就跳起来说不对，敏捷开发中没有失败，教练这么说是不对的，违反敏捷精神。我后来反思了一下，可能我说的方法也有问题，但是必须要承认的是这些同学对敏捷开发存在了非常大的误解。我们工作生活当中是充满了失败的，面对失败，逃避的话永远得不到学习的机会。

其他误区
 

我们今天的第一部分就是跟大家分享一下在敏捷开发当中普遍存在的误区。只有澄清了这些误区，我们后面谈质量的时候才可以避开这些坑。事实上误区还有很多，昨天跟一个同学聊天的时候，他说“我们产品或者业务部门的同学觉得用了敏捷开发就可以随便改需求了”这也是一个非常大的误区，这里面涉及到一个软件研发的生命周期的问题。

一：瞄一眼SCRUM

SCRUM框架是敏捷开发里面所有的框架体系里市占率最高的。现在市面上的Certified Scrum Master、Certified Scrum Product Owner、各种认证包括高级的认证有很多，我相信在座很多同学都是已经拿到认证。

大家都知道SCRUM 的3355：3个角色、3个工件、5个事件和5个价值观，但是我今天真正想跟大家讲的肯定不是这些了，如果大家要听这些的话，可以去听听外面的Scrum课或者看看Scrum Guide的2020版本都是公开免费的。我自己在我们公司内部也是在推广为期一天的关于SCRUM 的一个培训。今天肯定不会去跟大家非常细节的探讨，SCRUM到底是什么，到底怎么去run这些event才会变得有效，到底去怎么样去解决 Team和Scrum Master和 Product Owner之间的一些职责边界的问题，这些都是非常实操的。

今天想跟大家讲的是透过现象看本质。我们所谓的SCRUM的3355，这都是SCRUM的表象。“表象下面是什么？”这是我们今天需要探讨的问题。它的表象下面其实就是图中右边这个圈，如果大家run过SCRUM话，就会知道它SCRUM是有5个活动串联起来的。比如：一个Sprint的第一天，我们会开迭代计划会，接下来每一天都会有一个站会，通过站会去监控和调整每天的工作。Sprint结束了之后，通过spring review去看一看我们做的结果和预期是不是一致，是不是和预期有Gap，如果有的话，通过迭代复盘会或者迭代回顾会去反思一下我们哪里做得好，应该去保留下来，哪里做的不好应该去改进。SCRUM就是这么一个过程，它表皮底下的骨骼是定一个目标，两周以后或者一个Sprint以后会拿到一个结果，然后拿结果和目标去做一下比对，通过中间的差异来制定下一次的改进计划，然后不断的重复这个过程，这是表皮底下的SCRUM的骨骼。

二、软件质量究竟是什么？

简单说一下软件质量到底是什么？质量的定义，包括软件质量从国际化标准组织来说，他们的维度是什么？
 

质量工程的概念是从五六十年代就出现了，质量在行业里面有清晰的定义，适合任何行业。Fitness for purpose，在座的如果说有同学去上过PMP、ITTO的课，或者上过别的软件工程或者ISO之类的课，讲到质量，基本上定义就是fitness for purpose，翻译成中文就是满足需求，所以质量的定义本身就是满足需求，对软件（质量）来说也是这样。

当然大家也看到在这个图上，比如：Meet or exceed customer’s expectations、do it right the first time，就是行业里面各种各样对质量的解读。（但是）Fitness for purpose是毫无争议的，所有行业都公认的对质量的一个定义。我们后面讲软件质量也会围绕这个定义出发，去分析和探讨软件质量究竟是什么，我们到底应该怎么做。

ISO和IEC25010体系对于软件质量的8个维度，这是国际标准化组织和国际电器协会，把软件的质量画成这8个领域。今天不会跟大家讲这些这8个领域，只是让大家知道有这么一个东西，比如：软件的功能性、软件的性能、软件的兼容性，软件的可用性，软件的可靠性、安全性，可维护性和可移植性，只要是软件基本上都逃不开这8个质量维度。

结合刚才说的质量的定义是Fitness for purpose，软件质量又分成8个维度。换句话说，一个软件其实在这8个维度上面，都需要把需求给提清楚。比如：你开发一个APP，我不能只看着functional Suitbility，用户看到什么界面怎么操作，然后提交什么得到什么，这都是功能性需求，后面还有一大堆非功能性需求。

但我的经验里面是我们的产品人员其实是很少考虑得到非功能性需求的；但是非功能性需求没有被满足的话，会造成大量的用户投诉、大量的用户流失，甚至是大量的金钱上面的一个损失。这样的例子其实在行业里面也是举不胜举，尤其是Maintainability。有很多甲乙方合作模式的，乙方公司会在第一期的项目里面，用一个非常低的价格拿到这个项目，他们紧赶慢赶加班996，把功能都赶出来，但是他们会牺牲大量的Maintainability，让从一期到二期到三期的需求升级的时候变得无比困难，然后变得代价高昂，大家想一想是不是这样？说到底这是Maintainability的需求没有提清楚。

现在我们回到软件的定义，Fitness for purpose（满足需求）。但凡学软件工程、读过PMP、学过测试的，应该都听到过戴明环，PDCA戴明环、戴明质量环。

Scrum这个敏捷世界里面市占率最高的一个实践框架，它本质上是一个质量框架，它不是为了快乐工作，（是）为了提高效率、为了快节奏的交付，它的内核其实是一个质量框架，它是对质量戴明环的一个完美实践，或者是一个最小、最简单的实践。

我相信很多团队都听到过产品经理或者企业老板说，我们现在用敏捷就是要快一点，交付质量可以先放一边；单元测试可以先不做，先上线再说。以后你们就可以跟老板说，SCRUM 明明就是一个质量框架，你跟我说只关注效率，不关注质量。

我们再回到质量的定义来看，“满足需求”，所以没有质量的效率其实是毫无意义的。你连需求都不能满足，你只能做一堆垃圾出来。第二就是Fitness for purpose没有需求就不存在质量了，没有需求就不存在质量，所以质量工程真正的起始点，它不是测试，质量绝对不是靠测试测出来的。别人说内建质量，内建质量还不够；你在开发团队在设计的时候、去写代码的时候就关注质量，这还不够；质量的起点是从需求开始的。这是今天想跟大家分享一个非常重要的观点：质量的起点在需求，它不是开发，更不是测试。

软件的质量其实就是跟质量的定义是一样的，就是满足需求，我们最经典最常用的一个SCRUM 的框架，它其实是对质量的一个实现，软件的质量是从需求开始的。

• 车轮上的软件有何不同？

• 车轮上的软件和汽车行业的软件的区别

我们看看车轮上的软件到底有什么不同。这里首先跟大家说明一下，我们说的车轮上的软件和汽车行业的软件还是两码事。如果我们说汽车行业的软件那是无比庞大的，其中包括生产制造体系：每一个体系你不在里面摸个5年10年，根本就摸不清里面的门道的；生产制造体系：管生产线的供应链体系，那么多一辆车上万个零件，它全都是靠供应链体系拉动起来的，中间算法好不好，调度优不优，可以导致大量的成本差异；营销服务体系：不管是传统的4S的模式，包括现在很多新势力的直销，都需要非常强大的营销服务体系去支撑，这都是汽车行业里面的软件的应用。还有在车子上面的整车电气架构和控制单元，这个也是不得了的事情。

大家应该听到过在直销行业听到过AutoSar这么一个技术标准或技术规范。你真的要啃下来的话，没有三五年这里面的框架是什么都看不清。还有现在大火特火的自动驾驶，各种传感器、各种数据、各种算法，这都是测试汽车行业里面的软件应用。还有车载娱乐系统，包括操作系统、信号系统、仪表盘，车载娱乐，包括现在有很多APP都已经加载到车上了，自动驾驶刚才上面也已经提到过了。如果说我们只是说汽车行业软件的话，它真的是五花八门，根本就是难以计数，而且每一个领域都是复杂无比庞大无比。所以有一句话，“软件定义汽车”，从这个现象来说一点都不过分。

我没办法把那么多领域都跟大家一起囊括起来，所以我们后面在汽车行业的实践分享将围绕车载系统，真的是在车轮上的，在车里面跑的那些软件，包括信号系统、仪表盘、车载娱乐、自动驾驶，进行分享。

• 软件工程三巨头

刚才说的那么多汽车行业的软件，包括车轮上的、车厂里面的，它逃不开软件行业的本质。软件行业的本质是就是软件工程三巨头。

第一个是高内聚松耦合，这是软件开发的最高纲领，违反了这个纲领，付出的代价是巨大的。

第二个是软件开发生命周期，SDLC（software development life cycle），任何一个功能，任何一个产品，一定经历过从计划从分析到设计到开发到测试到上线这个软件生命周期的，之前我提到过敏捷开发里面有一个误区：就是“需求随便提，需求随便改”。（事实上，）你提的任何需求变更都需要尊重生命周期。

第三个是质量框架PDCA，我们敏捷开发里面有很多框架其实都是在实现PDCA，像XP、 SCRUM、看板，很大程度上也是在执行PDCA。

这就是软件工程三巨头。车轮上的软件也好，别的行业的软件也好，你只要是软件都得尊重这三巨头，对三巨头保持一些敬畏和谦卑，给予足够的尊重；否则可能整个企业整个产品，甚至包括每一个工程师都会付出很惨重的代价。如果一个公司把软件开发作为自己的核心竞争力的话，在这个前提下，我们所有的组织结构、流程、制度，包括能力建设，包括人才培养，包括薪酬设计，包括招聘的一些原则，都应该围绕这三巨头来设计。

所以大家可以回去看一下，自己现在正在工作的一些流程，包括一些采购的策略，包括一些在组织里面能力认可，人才培养的一些机制，是不是围绕这三巨头在建设的；如果不是的话，在软件行业里面一定会事倍功半。这是软件行业的客观规律和内在本质，车轮上的软件也逃不开这个规律。

这个图是我自己总结出来的一个图，其实就是将产品的所有的技能链串起来了。大家知道敏捷开发其实有一个宗旨叫更早的交付商业价值，这是敏捷开发或现在软件开发的一个最高目标：更早的去交付商业价值到市场上、到用户手里。怎么去识别商业价值，需要我们一步一步来探索，探讨。这里面是有方法的，比如：设计思维、影像地图等都是可以帮助一个团队，产品经理，帮助一个研发团队等，可以一块套用这个框架，套用它的思维模式去把商业价值给识别出来。

有了商业价值以后，你肯定要做你的迭代计划发布计划：怎么一步一步把我们的构思给兑现了，发布到市场上面去，这里面需要引入到拆分和优先级排序的一些技巧和一些方法。这个方法比较典型的有用户故事地图，有这么一本书的；然后也可以用用户旅程。像我知道以前的IBM，他们都大量在用这种方法。（然后）当我们的功能需求出来了，排好序以后，迭代计划都有了，接下来怎么快速的交付到用户手里？我们可以用SCRUM的方法或者用看板的方法，或者用别的XP的方法，Crystal的方法等很多方法。SCRUM就是其中之一也是现在用的最多的（方法），这些实践都是作为一个产品研发、软件研发团队需要一点点去掌握。你在任何一个地方没有掌握，在整个链条上面是缺失了一个环节，会在后面的工序里面遇到很大的麻烦。

如果我们用SCRUM、看板，真的能快速地把一些优先级高的功能交付到市场上和用户手里了。接下来我们就会面对一个典型的问题，交付出去的功能已经开始线上运营了，开始有用户反馈了，开始有bug了，可能会有用户数据了，你要开始进入运营阶段了，但同时后面的功能还在需求池、待开发的清单里面排队，这就DevOps状态。

所以在市面上面会听到很多就是说DevOps和SCRUM，和敏捷之间的一些PK，一些争论：“到底谁属于谁更优谁更合适？”我个人我觉得这些讨论也挺无聊的，但凡是一个敏捷的产品，一个敏捷的项目，天生就有DevOps的属性的。

如果说我们假设一个团队前面都做得很顺利，到了到了产品交付出去了，进入了DevOps这样的状态了：一边要运维运营一个线上的产品，一边要根据用户的反馈和后面产品的规划去开发新的功能。到了这种阶段必须要引入自动化手段，没有自动化手段迟早是死路一条。很简单的道理，你每一次迭代都要对前面的功能进行回归测试，第一次第二次第三次迭代；如果你用手工的方法去测试的话到了第十次第二十次还受得了吗？到了第十次第二十次对之前那么多的软件功能，已经交付出去的软件功能，你还用手工的方式去做回归的话，没有哪个团队可以承受得了，这个时候必须要引入自动化实践。

自动化的实践包括包括自动构建的自动化、测试的自动化，部署的自动化，包括线上的监控的自动化。这些自动化市面上已经有大量的工具存在了，当然有工具存在，也需要团队花很多时间去学习去使用的。

这里我想重点讲一下测试自动化，测试自动化有一个非常经典的模型叫测试三角形，简单来说它是从下到上是逐渐递减，它的投资回报率是递减的。反过来它的 bug修复的成本是递增的。最下面是开发人员的基本功单元测试。如果说现在软件行业里面哪一个开发的同学还说我不会单元测试，一定不是一个合格的开发人员了，早晚被淘汰；然后往上一层，就是模块测试接口测试、然后集成测试；再往上是用户测试UAT。前几年的时候在行业里面大量存在的现象是倒过来的，三角形是倒过来的。组织也好，团队也好，花了大量的时间在用户测试，单元测试反而特别少，甚至是没有，Bug的修复成本会特别高。

这里强调单元测试有道理的，因为单元测试跟自动化是密不可分的，我们交付出去的产品没有非常健壮的单元测试，这个自动化流水线几乎是无效，最多只能节省大家大概十分之一，二十分之一的时间。有了单元测试，我们团队的收益是呈指数级增长的，越到后面收益越高，这是单元测试的重要性。

我们的单元测试是需要有稳定性的。举一个例子，如果单元测试最高收益是你写了一遍，这个单元测试放在那边再也不用动了；你每一次只要执行这个单元测试，不过就说明有问题；但是这个单元测试你是不用动的，这是收益最高的一种情况。满足哪些条件可以达到收益最高的一个状态？就是被单元测试测的那些代码是不用动的。如果被单元测试测的那些代码，你是频繁改动的，一会改一个参数，一会改一个逻辑，那你单元测试也得跟着动。现在回到被单元测试，测的那些代码在什么情况下是可以不用动的？大家如果知道面向对象，知道S O L I D的原则，就知道我在讲open close原则， S O L I D原则里面这个o就代表了open close原则，即开闭原则。我们的代码最好是对新增开放，对修改关闭：我们希望已经发布的代码不要再改了；我们通过新增代码去实现新的功能，甚至是需求变更，这叫open close原则。

如果我们的代码设计能够遵从oop里面的open closed原则，我们的单元测试的收益是最高的，我们的自动化流水线的收益是最高的，我们整个敏捷迭代交付的流程才跑得起来。这是为什么敏捷开发里面那么强调自动化，那么强调单元测试，而单元测试的依仗就是S O L I D原则里面的open close原则。

其实我想跟大家的传递的一个想法就是车轮上的软件也是软件。一方面车轮上的软件要符合那软件工程的三巨头；另外一方面车轮上的软件需要我们有扎实的基本功和超强学习能力的员工，开发人员、测试人员。没有这些东西，你后面讲的那些实践，什么敏捷开发，什么SCRUM，瀑布都没有，全都不work，这是最基本的。
 

所以如果说今天来听我分享的同学里面有高管或者有企业老板，或者说有一些领导层的朋友或者一些同事们，希望你们知道这一点：你们投资80%以上，应该是投资在围绕软件三巨头去做建设；围绕我们开发同学的基本功去做培养。后面那些实践可能也就占了20%左右的效用。

如果大家知道整车研发周期的话，一辆车型从最开始概念设计到最后的量产交付，基本上经过这5个阶段：概念设计、工程设计、原型开发和集成、测试和验证。大家在马路上有的时候看到车包装的像斑马一样的白的黑的条纹，这些都是处于测试和验证的车型，它还不能曝光在大众的视野，所以它要装上很多伪装，（直到）最后量产和交付。

在早几年的时候，一个新的车型更新换代，周期大概是5年到7年，中间3年左右会有一个中期改款，一般来说都是这样。在那么长的周期里面，可以让软件开始开发，到产出的时间周期一般来说周期有3-4年那么长。从工程设计的中段开始，就可以开始围绕这辆车做它的软件设计和开发，包括软件操作系统的定型，包括车载以太网的一些规划和设计，包括一些功能的设计开发。

如果我们再回到刚才说的软件的敏捷开发迭代交付，我们问一问稍微有点经验，能力还过得去的那些团队，我们拿到一个应用级的软件，从第一天接触到第一个版本交付出去需要三个月；再超过三个月，要么属于基本功不扎实，要么整个软件生命周期，或者对三巨头不是那么尊重，受到惩罚了。

我们就可以看得出来，实际上软件开发的节奏是要远远快于整车研发的节奏，它本质要解决的问题是整车和软件的研发生命周期的不匹配：一个是5-7年，一个只要三个月就可以完成第一个版本。这个不匹配会带来的后果，一是我们的软件不管怎么样做，都没有办法尽早地得到用户反馈。（我司现在做的很多软件都是在2025年才发布给用户的，你可以想象现在我们在为2025年的用户在做软件开发、做软件设计吗？你可以反过来想，你现在看两年之前的那些应用你还用得上吗？如果你翻出两年前的微信，翻出两年前的支付宝，还愿不愿意用，就是那么简单的道理。）

所以这是一个对软件开发团队来说是一个非常痛苦的事情：就是我们现在做的东西居然是两年甚至三年以后用户才看得到，所以我们没有办法得到用户的反馈。这对软件来说是一个非常危险的事情。

二是到了后面的测试和验证阶段，这些软件都要上车跑，测试车是一个非常瓶颈的资源，每个团队每个软件产品，包括硬件测试的一些需求，都需要在测试车上面去去测，这个时候就会形成非常明显的资源瓶颈。这个软件开发好了，在那边等着排队。可能你开发也就两个礼拜，结果要一等就等个两个月三个月你才能轮得到测试，这也是造成了大量的浪费。

其实汽车行业在软件方面，无非就是为了解决这怎么样去尽早地得到用户反馈以及怎么解决资源瓶颈的问题。这里就可以介绍一下所谓的最佳实践。

四、汽车行业的“最佳实践” —— 用软件解决硬件问题

实践很简单，一句话来说就是用软件来解决硬件问题，用软件来解决软件和硬件生命周期不匹配的问题。
 

第一个就是OTA。大家知道现在几乎所有的车都有OTA，我之前听到过一个新势力车主说：“两年之后经过了大概2~3轮还是4~5轮的远程更新，我就觉得这辆车已经不是我刚刚买的那辆车了。包括转向的手感，刹车的力度，包括油门的反应，包括它车载里面的功能都不一样。除了车壳外面长的一样，好像都已经更新过了。”所以OTA是所有的汽车行业，其实汽车厂家都在拼命跟进的一个技术。

第二个数字孪生，其实它就是仿真技术，把物理世界数字化。

两个例子

一是自动驾驶

大家知道自动驾驶要充分测试的话几乎是不可能的，你要通过一辆真实的车去完成自动驾驶，各种场景的测试几乎是不可能的。就说上海的路况那么多路，那么多路各种各样的情况，大路小路，然后高速内环路，地面道路那么多车道，然后左右变道，然后非机动车道又跟真的车道是混在一块的，这种场景你不可能通过真实的车去完成所有场景测试的。我不知道大家有没有注意过，有的时候马路上会见到一辆车，然后头顶上顶了一个黑乎乎的东西（对吧）在那跑，其实这样的车都是在记录道路数据的。他把摄像头传感器在路上跑的数据都记录下来，通过机器人的技术，然后把它转换成软件的信号，大家就会看到这个图，然后把它可视化出来，作为基本环境，或者你也可以理解为我们作为自动驾驶的测试用例。然后当你研发的自动驾驶的算法，碰到什么情况应该变道，碰到什么情况下应该转弯，碰到什么情况下该减速，扔到收集过来的数据上面去跑这些算法。这就是大家看到的自动驾驶一个测试的数字孪生的应用。

二是虚拟汽车

（一辆车里面，其实就是）一个现在的车里面就是一个小型的局域网，对吧？它里面有各种传感器，有总线，有各种控制单元；包括发动机有发动机的电脑，变速箱有变速箱的电脑，就算是现在的新能源汽车，它有电控、三电（电机、动力电池以及电控系统）的电脑。

这里面会产生大量的数据，大量的通信。虚拟汽车无非就是模拟这些信号，模拟这些交互，然后基于这上面的应用软件，可以利用这些模拟出来的信号来测试自己软件功能跑的对不对。这其实就是数字孪生的一个基本的解释，其实就是以前说的仿真。

台架，任何一个汽车企业，只要有台架的地方，必定是最高安全等级的一个地方。

因为它是下一代汽车产品的内饰或者一个仪表盘的模拟，或者一个测试的架子。如果大家在汽车行业去工作，或者去参观过，都知道你但凡来到这个地方，你的手机不能去拍照。所以道理上来讲这种台架是不会有照片留在市场上面的。我找到的是奔驰的前几代的产品，所以它也不存在保密不保密的问题。

这么一个台架大概就是30万、40万左右，就是一辆奔驰c或者一辆宝马三系的价格。这个台架是模拟车载娱乐系统、导航系统、仪表盘，（用来）做车载软件的测试。因为测试车是一个非常珍贵的资源，软件团队不可能等着测试车去测那个东西。我们希望在尽可能真实的环境下去测这些车载软件，只能依赖于这些台架。但是台架也是非常珍稀的资源，所以难免也会出现资源竞争的情况。

我司想了一个办法，花了大概两年多的时间做了一套远程台架控制系统，也是一套软件。刚才说的台架是一个非常珍贵的资源，很容易形成资源竞争。在这种情况下，我们公司在国内的北京、上海、南京等城市以及欧洲、美国都有研发中心，这些地方都分布了各种各样的台架，我们一个非常厉害的团队，把这些台架就通过一个系统，可以远程操控这些台架。我们利用时差，比如：中国的团队可以在白天预定欧洲的台架或者美洲的台架，他们那边都下班了，台架没人用了，可以去用这些台架来做我们产品的测试。

大家看到这个图，就是这里，是个摄像头对着屏幕的；然后这里就是一个模拟控制器，然后你转或者回车或者主页这上面都会响应的，就像一个真的操作一样的。这个台架是在远程的一个物理的显示屏。这是一个物理的摄像头对着它的，然后这个是模拟在WEB页面上面你就可以操作的一个设备。这样的话你要测什么软件的话，你就可以远程观察我的软件是不是按照我的预期在跑；然后它还可以远程的刷新软件版本，我们可能不同的车型用的不同的软件版本都是不一样的，对这种台架怎么区分芯片这里面肯定有方法的，通过各种配置。它不是说每一台台架你都可以用的，它也是归类的，你要跑哪种类型的软件，应该对应着哪个芯片，对应的哪个操作系统版本，然后在web页面上面就全都可以操作。

它还有一个非常厉害的功能是可以远程配置和执行自动化测试。我们在流水线上的代码你可以通过一些配置的操作，从流水线直接发布到目标台架上面，让他按照你预先定义好的脚本去跑，然后第二天给到你结果。

这套东西大概花了有两三年才做的出来，然后这也算是一个非常厉害的实践。今天的听众有友商的话，你们可以参考一下这个方案，可以自己琢磨能不能研发这么一套系统去优化非常昂贵的硬件资源的一个使用率。

最佳实践这个词是有极大的误导性的，我相信大家没少听到过这个词。大家听到最佳实践，不管是因为被各种各样的市场上面的忽悠、被各种顾问的有意的引导，都会认为最佳实践非常容易、非常简单，拿来就可以用。天底下没这种事情。大家对最佳实践的期待，就跟在期待一本高考秘籍，看了它以后就可以考上清华北大，这个性质是一样的。所以希望通过今天的分享，可以浇灭大家对最佳实践这句话的一个幻想。严格来说不存在最佳实践，如果大家把最佳实践理解成拿来就可以用，然后很简单很容易落地的话，这件事情是不存在的。这个东西我是花了两三年时间琢磨出来，一路坎坷，到现在还没有兑现它真正应该兑现的价值。

我相信任何一家企业在做这样所谓的最佳实践，都是要付出高昂的代价。这个跟软件本身也好，或者汽车行业的软件也好，你要做到一个真正优秀的产品，道理是一样的。

这是为什么我把最佳实践上面标红了，打引号了，希望以后大家在任何场合听到这个词都提高警惕，它绝对不意味着它是一个非常容易非常简单的事，往往最佳实践也是最难的实践。

“这些墙真挺有意思，一开始你非常痛恨它，然后你会慢慢的习惯它，再过段时间，你就会依赖它了”。

电影肖生克的救赎中摩根·弗里曼那个角色在放风的时候，看着监狱的高墙，他说：“这些墙真有意思，一开始你会非常痛恨他，然后你会慢慢的习惯他，再过段时间你会依赖他。”我对这句台词的印象特别深刻。我发现我们工作当中生活当中有无数堵这样的墙，一开始我们非常痛恨的，然后慢慢的会开始习惯它，再过段时间就会依赖他们。

在软件行业里面最典型的一个例子就是写脏代码，作为一个有节操的工程师，我相信刚刚开始做软件写代码的时候，看到脏代码都是恨得一塌糊涂。然后慢慢地发现，因为各种市场上面的各种压力，比如：来自产品经理的不切实际的需求、来自老板的压迫，“我们先不管质量，先上线再说”，就开始习惯写脏代码。然后再过一段时间你就发现不写脏代码不行了，就不用脏的方案，不用脏的代码去解决问题，已经找不到别的出路了，你就会非常依赖它。

希望大家以后在软件行业的工作当中，只要你是参与软件开发，都不要被这些高墙围困住自己。今天我要讲的内容就这些了，谢谢大家耐心地倾听。

演讲嘉宾

张敏峰，某一线豪华汽车品牌中国区总教头，20+ 年软件行业从业经历；

历经 开发工程师，测试工程师，项目经理，资深全球产品顾问，敏捷教练等多个角色。

资料获取

演讲PPT分享：点击：链接获取演讲PPT（百度网盘提取码：iSQE）

演讲视频回放：想了解更多精彩内容，微信识别下方二维码，查看直播回放