登陆

敏捷与ASPICE：SDV趋势下软件研发体系的挑战与思考

来源：公众号“汽车电子与软件”

2021-12-01

前言：

在软件定义汽车趋势下，一方面”快速交付”、“OTA”已成为行业的共识；另一方面“交付质量”虽可适度下降但仍要有底线；这两者的冲突已超出了传统的ASPICE研发流程体系的能力范围，“敏捷开发”是否可以解决这一切呢？这两者是否可以，或者如何结合呢？

01

软件研发体系的挑战与思考

1. 挑战与痛点

最近在公司内部做了个小的调查，大家对于软件开发过程的痛点还是不少的。以下是一个从“管理层”视角来看的“痛点”，以及相应的原因。

研发干的“不好”

· 定义了A，实现出来却变成了B: 产品定义方与实现缺乏沟通，且交付物只在最后阶段可见，再提意见就晚了

· 里程碑快到了，才发现问题仍然一堆：软件开发的过程不透明，难以管控

· 上线后，售后问题急死人：工期的压缩对非必要环节产生冲击，严重影响质量

市场变化“太快”

· 定义了A，干到一半想改成B，基本不可能：传统的瀑布式开发，流程越往后走，变更成本越高

· 定了一年上线，临时想改成8个月，困难重重：瀑布式开发，若未走完全流程则质量问题一大堆，基本无法交付。

黄花菜“凉了”

· 需求从提出到交付，周期太长：单一功能涉及多个专业部门，干系人复杂，沟通成本太高；功能开发流程链条较长，从计划到交付往往涉及10+环节；

2. Tesla和行业里是怎么干的呢？

首先，Tesla并未采用ASPICE，下面是Tesla的Software QA Engineer的职位描述，就是测试。如果采用ASPICE的话，则会有专门的人员去保证流程、优化流程。

那么Tesla是怎么干的呢？从各种渠道的证据来看，其都是通过“敏捷”来解决的。Tesla的高管团队大多来自硅谷，而硅谷的软件文化——敏捷到无须再提，所以Tesla从设计、开发、生产到组织架构都是敏捷的组织形式。

比如：Tesla的自适应空气悬架，需求从提出到交付，仅用一个迭代^[1]，按Tesla每月一小迭代的节奏来看，推测也就是1-2个月就上线了。

自适应空气悬架

又比如：Tesla的组织架构，在马斯克发了如下邮件后就荡然无存了，仅有形式上的意义："沟通应该通过最短路径来完成，而不是用“指挥链”。任何一个试图强行用指挥链方式沟通的经理，很快就会发现他得去别处工作了"

仅有形式上的意义的组织架构

那么"Tesla"很多时候属于"外星生物"，咱们不一定学的来，那么其他"正常"的公司是怎么干的呢？

敏捷相关行业实践

首先是互联网企业：

· Tesla、Apple、Google应用敏捷基本是不用去考证了，其中Apple在2012年组织架构已经是“敏捷”的^[2], Google也在2006年就成功将”敏捷”引入Adwords的开发中，并发表相关论文，被IEEE收录^[3]

然后是汽车零部件巨头：

· 至少是2020年起，Aptiv已经在全球范围内全面推广”敏捷”，且聘请咨询公司专门定制了AutoScrum的敏捷框架，在公司官网也可以看到其已经在"主动安全"、"自动驾驶"、"车辆互联"等领域应用敏捷方法了。^[4]

· Bosch在2015年宣布开始转型为敏捷组织, 管理层率先使用”敏捷”的方式开始工作^[5]^[6]

· Continental在2020年也宣布全面转向敏捷的方法与文化，其VNI部门率先开始全球试点^[7]

整车厂也不例外：

· 奔驰已经将”敏捷(Agile)的组织文化”写入公司战略^[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年起，全球整车研发开始转向敏捷开发^[9]。并从2020年开始，使用完全敏捷的方式打造新的量产车型。

· 宝马的智能座舱和IT部门也是使用敏捷方式，其中IT部门在2019年实现100%敏捷^[10]

3. 我们的思考与方向

参考行业的实践，以及对敏捷、ASPICE的理解，我们认为转向敏捷开发，并且依托DevOps与工程师文化建立软件研发体系，是解决以上痛点的方式与方法。

02

敏捷细究

既然提到“敏捷”，虽然网络上关于“敏捷”的介绍不少，我还是简单的讲一讲我的理解吧。

1. 敏捷概况

· 是一种源自“精益”的理念，始于2001年，一开始仅用于软件开发，目前已应用于生产、零售、人事资源、预算、审计，企业组织形式等领域。

· 在21世纪席卷全球，最大的5家互联网公司Amazon, Apple, Facebook, Google, Microsoft都在使用

· 全球有许多非营利组织提供相关的培训与认证服务，如Scrum联盟，Agile联盟，PMI（项目管理协会）

· 主流问题管理工具都原生的支持敏捷开发：如Jira, Teambition (阿里), TAPD (腾讯）

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

这里特别要强调最下面这句话："尽管右项有其价值，但我们更重视左项的价值", 并不是说右边没有价值，而是说如果你认同右边的价值的话，左边就更有价值。

2. 敏捷开发流程特点

· 关键角色：Product Owner(产品负责人), Scrum Master(敏捷教练)

· 跨职能团队：一个团队内要具备所有的角色

· 迭代快速：需求拆细，2-6周可交付

敏捷常用方法

敏捷有如下优点(来自2020全球敏捷报告):

下面挑选几点详细阐述一下。

3. 敏捷优点详述

1) 敏捷工程实践可以大幅提升代码质量。某金融科技集团实施1年半的数据：问题/故事数 0.4 -> 0.16

· 测试驱动开发：在编写任何代码之前，首先编写对应的测试用例；测试用例需要能完全自动化运行。根据IBM和微软的研究，BUG会少40% - 50%^[11]

· 结对编程: 两位程序员在一台电脑前工作，一个负责写代码，一个负责实时检视代码。两者角色定期更换。生产率低15%，但BUG少15%，考虑到解BUG工作量比写要大几倍，总体效率更高

测试驱动开发(TDD)流程

2) 敏捷开发可提升交付速度。某金融科技集团实施1年半的数据：交付周期由 75天-> 42天

敏捷 vs 瀑布

3) 敏捷开发通过可视化项目管理等措施，提高软件开发透明度，大大提高管理效率，进一步促进生产效率。某金融科技集团实施1年半的数据：人均用户故事数由2.6 -> 4.3

4) 敏捷与OKR：两者是天生的契合关系，有些公司直接把OKR叫做“敏捷”目标管理。这两者的团队文化都强调：

· 自组织：在完成必需工作后，团队自行决定做什么

· 自驱力：沟通更多为自下而上，充分发挥个人主动能动性

这里也进一步讲一个好处，在敏捷实行的较好的团队中，由于自驱与自组织，管理人员会变少，利于整个组织的扁平化。

4. 敏捷转型的关键挑战

敏捷虽然很好，但要转型成功，挑战不小，以下是来自敏捷年度报告中的统计。

敏捷转型中的挑战

这里我着重讲两点：

· 缺乏领导层的支持：实行敏捷，组织架构上的微调是必不可免的，这个就需要领导层的支持。很简单的说，一个SCRUM团队中，有来自产品、开发、测试、集成等各个职能团队的人，他们凭什么听指挥呢？那么至少这个SCRUM master要有考核或比较强的话语权。

· 组织对变革的阻力：三方面吧，一是接受新的观念、流程对很多人都较为困难，且在转型初期会较为痛苦；二，敏捷特别讲究量化数据，这时很多“老油条”或“摸鱼达人”就会被暴露出来，他们当然天然会反抗这种转型；三、敏捷转型后，整个组织自驱力越来越强，需要的管理人员会变少，这些人该去哪？难免又会有内部的阻力.

5. 敏捷转型中会出现的常见问题

敏捷转型中会出现的问题千奇百怪，我也讲两个：

· 生产率临时下降(2~3个Sprint)：在刚开始实行敏捷转型时，有很多新的习惯要养成，有很多新的流程要遵循，所以必然会出现临时性的生产率下降。但放心，一般来说，经过2~3个Sprint的磨合，就可以明显看到效率的提升。

· 敏捷容易退化：有些组织在实行敏捷一段时间后，比如说站会开了，KANBAN有了，Scrum也跑起来了，会慢慢的松懈，效率会掉下来。这主要因为“敏捷”是“价值观”，而不是“方法”，只用敏捷的方法是不够的。有一句名言叫“Don't do agile, be agile"，就是指这个。那么如何保证“敏捷”的价值观能够贯彻并保持下去呢？就靠“工程师文化”了，这个后面详细描述。

03

敏捷与ASPICE

前面讲了很多“敏捷”的好处，但是在汽车行业“ASPICE”才是老大哥啊。本节就讲讲把这两者放一起讲讲。

1. 敏捷与ASPICE可以结合吗？

答案是：可以。行业中把这两者结合起来用的不少，比如说Aptiv。但是，我要问一句，“为什么要结合呢”？

首先，来说为什么要用“ASPICE”？答案也很显然，客户爸爸们要求的啊。没有ASPICE认证，很多OEM压根就不会把项目给你。

然后，来说为什么要用“敏捷”？答案也很显然，被客户爸爸们逼的。没事改需求，交付周期压缩到巴不得明天就上等等，不“敏捷”怎么活？

那么，ASPICE和敏捷结合之后的结果是什么呢？在行业中，结果往往是敏捷主导着整个开发流程，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在汽车行业很多年了，它的好处大家应该都很清楚：它对工程流程覆盖的非常全面，可以帮助与指导软件开发，并提高交付的质量。我这里主要讲讲它的坏处。不过在讲这个之前，先讲一个笑话和亲身经历。

有一个软件工程师有一天遇到了上帝，上帝跟他说：“我可以满足你一个愿望”。工程师想了想，说“我想做一个好的项目”。上帝想了想，于是让这个工程师得到了“永生”。

做为“软件工程师”，想做一个好的项目实在太难，但我有幸遇到了。大概在2013年时，我和另外5个小伙伴一起做一个TBOX的项目，大概做了3个多月吧，交付给测试，质量出奇的好。好到QA跑过来说，你们项目的数据有问题，怎么没有问题的爬坡曲线？确实，我们当时总BUG就是个位数，然后就再也没有BUG了。

但是，这个项目拿去过ASPICE，没有通过...... 被提了一堆问题。

以上就是我个人对ASPICE的印象。接下来讲讲ASPICE的弊端。

弊端1: 过时的管理理念

“敏捷”，是由一群优秀的软件工程师达成的“价值观”方面的共识，更多的是激发个人的积极主动性。

“ASPICE”，是由欧洲20多家OEM共同制定，用于指导零部件厂商的。由于甲方对乙方的天然的不信任，更多的是强调“管理与约束人性的懒惰”。

孰优孰劣，一目了然。

弊端2: 沉重而不灵活

· 3~5倍工作量：一个项目，严格采用ASPICE后，是常规项目的3~5倍工作量。这个是很多Tier1实践下的结果，不信的可以自己试试

· Traceability——看上去很美的骨感现实：ASPICE几乎每个流程都会讲双向可追溯性(Traceability)，大部分项目要么就是把所有的需求全部链接到一个模块上，要么就是只拿一个小模块来做这事。因为，工程实践中，Traceability确实可以帮助发现问题，但是性价比极低，你当架构师做架构设计时是只看一遍需求吗？

· 改需求或重构时怎么办：我在上一家公司时，曾经有2个月独自做一个大模块，代码量大概4万行左右，其中还有几千行是用于生成代码的代码。然后2个月内，我一边做设计一边写代码，写不通了就重构设计，一共搞了3遍。如果按ASPICE来，我该怎么办？

弊端3：驱赶优秀人才

在这个“软件定义汽车”的时代，优秀的软件人才都是稀缺的，如何吸引都是一门学问。要是还驱赶，那怎么了得。