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

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

 

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

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与工程师文化建立软件研发体系，是解决以上痛点的方式与方法。

二、敏捷细究

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

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"，就是指这个。那么如何保证“敏捷”的价值观能够贯彻并保持下去呢？就靠“工程师文化”了，这个后面详细描述。

三、敏捷与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：驱赶优秀人才

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

“你写出了淘宝的搜索引擎？不好意思，你单元测试是不是没做？”

上图是阿里大神“多隆”，p11，2003-2007年独自一人维护淘宝的搜索引擎，程序员的天花板。像“多隆”这样的优秀工程师，其价值观是这样的：

• 成就感：实现了某个复杂功能，解决了某个疑难问题
• 以自己代码的健壮性、可维护性、可扩展性为荣
• 吹牛：老子10年前写的代码他们现在还在用呢

但ASPICE后，要求优秀工程师的价值观是这样：

• 成就感：我所有的文档（泛指）都写完啦
• 以严格遵守流程，不给QA添麻烦为荣
• 吹牛：（想不出来了...）

结果呢：“抱歉，我还是离开这家公司吧”

3. ASPICE vs 敏捷 总结

面对第一章的“痛点”，ASPICE确实可以解决质量问题，但对市场变化“很快”毫无贡献，反而还会延长交付的周期。而“敏捷”可以解决所有的“痛点”。

四、工程师文化与DevOps

1. 工程师文化

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

个人理解，主要有以下几点：

• 质量为导向：充分信任工程师，在不达交付标准时不上线，且不追责. 优秀的工程师的自我要求都是非常高的，到了交付时间点若未达心中的交付标准，其实是不愿意上线的。这时要尊重工程师的意愿，且不追责，因为他往往已经尽力了。
• 追求新技术：使用和关注最新的技术和工具，并允许因尝试新技术而带来的时间成本。尝试新技术就有失败的风险，一味只想提高效率而不愿承担可能的后果就是耍流氓。
• 专注的时间：尽量减少不必要的会议与其他打扰，否则工程师的“灵感”可能就被打断了。这里的小提示就是，在非必要时，尽量留言，而不是打电话或者直接找过去。
• 内部技术论坛：内部建立技术的充分沟通与交流的氛围。这里，有个简单粗暴的办法来判断公司是否有技术氛围，就是看那几百人的大群里，都在聊什么？是经常有技术的交流和分享呢？还是都是些行政类的通知？

2. DevOps

DevOps的敏捷快速迭代的技术保证，本身也是个大话题，这里就不展开了，大概有以下几点：

• 代码的提交直接触发：消除等待时间，快速反馈

• 每个变化对应一个交付管道：使问题定位和调试变得简单

• 全开发流程高效自动化：稳定，快速，交付结果可预测

• 持续进行自动化回归测试：提升交付质量

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

五、结语

敏捷正在吃掉全世界，可能你还不知道，汽车行业也不会例外！

参考

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 李成仙 | 软件架构师

说明：文章来源网络；文中观点仅供分享交流，不代表本公众号立场，转载请注明出处，如涉及版权等问题，请您告知，我们将及时处理。