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

2021年11月21日汽车技术评论104阅读模式

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

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

研发干的“不好”

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

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

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

市场变化“太快”

  • 定义了A,干到一半想改成B,基本不可能:传统的瀑布式开发,流程越往后走,变更成本越高
  • 定了一年上线,临时想改成8个月,困难重重:瀑布式开发,若未走完全流程则质量问题一大堆,基本无法交付。

黄花菜“凉了”

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

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

首先,Tesla并未采用ASPICE,下面是Tesla的Software QA Engineer的职位描述,就是测试。如果采用ASPICE的话,则会有专门的人员去保证流程、优化流程。
敏捷与ASPICE:SDV趋势下软件研发体系的挑战与思考
那么Tesla是怎么干的呢?从各种渠道的证据来看,其都是通过“敏捷”来解决的。Tesla的高管团队大多来自硅谷,而硅谷的软件文化——敏捷到无须再提,所以Tesla从设计、开发、生产到组织架构都是敏捷的组织形式。
比如:Tesla的自适应空气悬架,需求从提出到交付,仅用一个迭代[1],按Tesla每月一小迭代的节奏来看,推测也就是1-2个月就上线了。
敏捷与ASPICE:SDV趋势下软件研发体系的挑战与思考
自适应空气悬架
又比如:Tesla的组织架构,在马斯克发了如下邮件后就荡然无存了,仅有形式上的意义:"沟通应该通过最短路径来完成,而不是用“指挥链”。任何一个试图强行用指挥链方式沟通的经理,很快就会发现他得去别处工作了"
敏捷与ASPICE:SDV趋势下软件研发体系的挑战与思考
仅有形式上的意义的组织架构
那么"Tesla"很多时候属于"外星生物",咱们不一定学的来,那么其他"正常"的公司是怎么干的呢?
敏捷与ASPICE:SDV趋势下软件研发体系的挑战与思考
敏捷相关行业实践
首先是互联网企业:
  • Tesla、Apple、Google应用敏捷基本是不用去考证了,其中Apple在2012年组织架构已经是“敏捷”的[2], Google也在2006年就成功将”敏捷”引入Adwords的开发中,并发表相关论文,被IEEE收录[3]
然后是汽车零部件巨头:
  • 至少是2020年起,Aptiv已经在全球范围内全面推广”敏捷”,且聘请咨询公司专门定制了AutoScrum的敏捷框架,在公司官网也可以看到其已经在"主动安全"、"自动驾驶"、"车辆互联"等领域应用敏捷方法了。[4]
敏捷与ASPICE:SDV趋势下软件研发体系的挑战与思考
  • 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"
敏捷与ASPICE:SDV趋势下软件研发体系的挑战与思考
  • 沃尔沃自2017年起,全球整车研发开始转向敏捷开发[9]。并从2020年开始,使用完全敏捷的方式打造新的量产车型。
  • 宝马的智能座舱和IT部门也是使用敏捷方式,其中IT部门在2019年实现100%敏捷[10]

3. 我们的思考与方向

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

二、敏捷细究

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

1. 敏捷概况

  • 是一种源自“精益”的理念,始于2001年 ,一开始仅用于软件开发,目前已应用于生产、零售、人事资源、预算、审计,企业组织形式等领域。
  • 在21世纪席卷全球,最大的5家互联网公司Amazon, Apple, Facebook, Google, Microsoft都在使用
  • 全球有许多非营利组织提供相关的培训与认证服务,如Scrum联盟,Agile联盟,PMI(项目管理协会)
  • 主流问题管理工具都原生的支持敏捷开发:如Jira, Teambition (阿里), TAPD (腾讯)
敏捷的核心"理念"如下:
敏捷与ASPICE:SDV趋势下软件研发体系的挑战与思考
这里特别要强调最下面这句话:"尽管右项有其价值,但我们更重视左项的价值", 并不是说右边没有价值,而是说如果你认同右边的价值的话,左边就更有价值。
2. 敏捷开发流程特点
  • 关键角色:Product Owner(产品负责人), Scrum Master(敏捷教练)
  • 跨职能团队:一个团队内要具备所有的角色
  • 迭代快速:需求拆细,2-6周可交付
敏捷与ASPICE:SDV趋势下软件研发体系的挑战与思考
敏捷常用方法
敏捷有如下优点(来自2020全球敏捷报告):
敏捷与ASPICE:SDV趋势下软件研发体系的挑战与思考
下面挑选几点详细阐述一下。
3. 敏捷优点详述
1) 敏捷工程实践可以大幅提升代码质量。某金融科技集团实施1年半的数据:问题/故事数 0.4 -> 0.16
  • 测试驱动开发:在编写任何代码之前,首先编写对应的测试用例;测试用例需要能完全自动化运行。根据IBM和微软的研究,BUG会少40% - 50%[11]
  • 结对编程: 两位程序员在一台电脑前工作,一个负责写代码,一个负责实时检视代码。两者角色定期更换。生产率低15%,但BUG少15%,考虑到解BUG工作量比写要大几倍,总体效率更高
敏捷与ASPICE:SDV趋势下软件研发体系的挑战与思考
测试驱动开发(TDD)流程
2) 敏捷开发可提升交付速度。某金融科技集团实施1年半的数据:交付周期由 75天-> 42天
敏捷与ASPICE:SDV趋势下软件研发体系的挑战与思考
敏捷 vs 瀑布
3) 敏捷开发通过可视化项目管理等措施,提高软件开发透明度,大大提高管理效率,进一步促进生产效率。某金融科技集团实施1年半的数据:人均用户故事数由2.6 -> 4.3
敏捷与ASPICE:SDV趋势下软件研发体系的挑战与思考
4) 敏捷与OKR:两者是天生的契合关系,有些公司直接把OKR叫做“敏捷”目标管理。这两者的团队文化都强调:
  • 自组织:在完成必需工作后,团队自行决定做什么
  • 自驱力:沟通更多为自下而上,充分发挥个人主动能动性
这里也进一步讲一个好处,在敏捷实行的较好的团队中,由于自驱与自组织,管理人员会变少,利于整个组织的扁平化。

4. 敏捷转型的关键挑战

敏捷虽然很好,但要转型成功,挑战不小,以下是来自敏捷年度报告中的统计。
敏捷与ASPICE:SDV趋势下软件研发体系的挑战与思考
敏捷转型中的挑战
这里我着重讲两点:
  • 缺乏领导层的支持:实行敏捷,组织架构上的微调是必不可免的,这个就需要领导层的支持。很简单的说,一个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:SDV趋势下软件研发体系的挑战与思考
了解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在汽车行业很多年了,它的好处大家应该都很清楚:它对工程流程覆盖的非常全面,可以帮助与指导软件开发,并提高交付的质量。我这里主要讲讲它的坏处。不过在讲这个之前,先讲一个笑话和亲身经历。
敏捷与ASPICE:SDV趋势下软件研发体系的挑战与思考
有一个软件工程师有一天遇到了上帝,上帝跟他说:“我可以满足你一个愿望”。工程师想了想,说“我想做一个好的项目”。上帝想了想,于是让这个工程师得到了“永生”。
做为“软件工程师”,想做一个好的项目实在太难,但我有幸遇到了。大概在2013年时,我和另外5个小伙伴一起做一个TBOX的项目,大概做了3个多月吧,交付给测试,质量出奇的好。好到QA跑过来说,你们项目的数据有问题,怎么没有问题的爬坡曲线?确实,我们当时总BUG就是个位数,然后就再也没有BUG了。
但是,这个项目拿去过ASPICE,没有通过...... 被提了一堆问题。
以上就是我个人对ASPICE的印象。接下来讲讲ASPICE的弊端。
弊端1: 过时的管理理念
敏捷与ASPICE:SDV趋势下软件研发体系的挑战与思考
“敏捷”,是由一群优秀的软件工程师达成的“价值观”方面的共识,更多的是激发个人的积极主动性。
“ASPICE”,是由欧洲20多家OEM共同制定,用于指导零部件厂商的。由于甲方对乙方的天然的不信任,更多的是强调“管理与约束人性的懒惰”。
孰优孰劣,一目了然。
弊端2: 沉重而不灵活
敏捷与ASPICE:SDV趋势下软件研发体系的挑战与思考
  • 3~5倍工作量:一个项目,严格采用ASPICE后,是常规项目的3~5倍工作量。这个是很多Tier1实践下的结果,不信的可以自己试试
  • Traceability——看上去很美的骨感现实:ASPICE几乎每个流程都会讲双向可追溯性(Traceability),大部分项目要么就是把所有的需求全部链接到一个模块上,要么就是只拿一个小模块来做这事。因为,工程实践中,Traceability确实可以帮助发现问题,但是性价比极低,你当架构师做架构设计时是只看一遍需求吗?
  • 改需求或重构时怎么办:我在上一家公司时,曾经有2个月独自做一个大模块,代码量大概4万行左右,其中还有几千行是用于生成代码的代码。然后2个月内,我一边做设计一边写代码,写不通了就重构设计,一共搞了3遍。如果按ASPICE来,我该怎么办?
弊端3:驱赶优秀人才
在这个“软件定义汽车”的时代,优秀的软件人才都是稀缺的,如何吸引都是一门学问。要是还驱赶,那怎么了得。
敏捷与ASPICE:SDV趋势下软件研发体系的挑战与思考
“你写出了淘宝的搜索引擎?不好意思,你单元测试是不是没做?”
上图是阿里大神“多隆”,p11,2003-2007年独自一人维护淘宝的搜索引擎,程序员的天花板。像“多隆”这样的优秀工程师,其价值观是这样的:
  • 成就感:实现了某个复杂功能,解决了某个疑难问题
  • 以自己代码的健壮性、可维护性、可扩展性为荣
  • 吹牛:老子10年前写的代码他们现在还在用呢
但ASPICE后,要求优秀工程师的价值观是这样:
  • 成就感:我所有的文档(泛指)都写完啦
  • 以严格遵守流程,不给QA添麻烦为荣
  • 吹牛:(想不出来了...)
结果呢:“抱歉,我还是离开这家公司吧”

3. ASPICE vs 敏捷 总结

敏捷与ASPICE:SDV趋势下软件研发体系的挑战与思考
面对第一章的“痛点”,ASPICE确实可以解决质量问题,但对市场变化“很快”毫无贡献,反而还会延长交付的周期。而“敏捷”可以解决所有的“痛点”。

四、工程师文化与DevOps

1. 工程师文化

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

2. DevOps

敏捷与ASPICE:SDV趋势下软件研发体系的挑战与思考
DevOps的敏捷快速迭代的技术保证,本身也是个大话题,这里就不展开了,大概有以下几点:
  • 代码的提交直接触发:消除等待时间,快速反馈

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

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

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

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

五、结语
敏捷正在吃掉全世界,可能你还不知道,汽车行业也不会例外!
敏捷与ASPICE:SDV趋势下软件研发体系的挑战与思考

参考

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

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

weinxin
扫码关注公众号
关注公众号领精彩彩蛋!

发表评论