关于软件研发的效能提升方法论和实践不绝于耳,从二十年前的敏捷开发到十多年前的 DevOps,研发效能的话题似乎一直是技术领域的热点,也占据着各种技术大会的主要席位。各大公司都在积极地推进研发效能的提升,阿里巴巴、腾讯、蚂蚁集团等大厂也沉淀出了很多落地实践的经验和指南。
我们都说研发效能提升不是银弹,那它究竟适合什么场景,又如何能在实际落地过程中有效地避免踩坑呢?研发效能发展的这么多年来,它的含义是一成不变的吗?在新时代下,我们应该如何理解研发效能,它又会将如何发展呢?
出于对以上问题的好奇,我们特地采访了阿里巴巴的研发效能专家洪永潮老师。他是阿里云混合云的解决方案架构师,有着 10 年以上敏捷精益方法的实践和落地经验,专注于赋能企业实现研发效能的提升,在阿里集团先后负责天猫、淘宝、阿里云、饿了么、新零售等多个事业部的敏捷转型和效能提升。
洪永潮老师也在 5 月初即将上线的 QCon+ 案例研习社「研发效能提升的避坑指南」专题中带来了关于研发效能提升的实施策略与路径案例的分享。因此我们针对研发效能如何高效开展相关的话题对洪永潮老师进行了采访,让我们一起来看看老师的实践和思考吧。
洪永潮:我最近的工作主要聚焦在这几个方面:首先,辅导阿里之外的企业做效能提升。走出阿里,走向外部企业,发现很多企业在提升研发效能方面投入了相当大的资源,尤其是得到了公司高层(CXO)的重点关注。我们通过沉淀阿里内部的最佳实践,形成了解决方案,帮助企业解决产研过程中碰到的问题,实现交付效率和质量的双提升,以此来促进客户的业务成功。
其次是进一步沉淀和优化解决方案与产品,解决方案和产品之间需要互相融合,解决方案通过产品来落地,而产品上各个环节形成的价值链也能比较好地体现解决方案。我们一直在努力中,让解决方案能更低门槛地落地,让产品更易上手和有更好的体验。
第三,进一步探索研发效能度量领域,很多企业做研发效能的提升,往往会从设定研发效能的度量指标开始。这是个好事,但也是坏事。“好”指的是很多企业都开始关注效能的提升,出发点和初心都很好,因为他们期望通过提升指标来提升企业的效能。但“坏”指的是把研发效能指标当做鞭子来抽团队,而忽略了具体的场景目标和核心问题,导致问题百出,最后的结果不尽如人意。所以我们期望进一步探索研发效能度量领域,指导企业或团队的具体行动,保障项目或产品的交付过程能被有效执行,并促进团队的持续改进。
洪永潮:最让我印象深刻是我服务过的一家电力公司,他们其中一个技术团队的分支模式。
先介绍一下背景,该团队跑双周迭代,每周发布一次,周五的时候测试同学把要发布的软件包准备好,然后连同相关的配置文件一起发给运维同学来发布。
但是,该团队采用的是一个迭代一个分支的方式,也就是该迭代的所有需求都会合入到这一个迭代分支上。由于没有持续集成和自动化测试来保障质量,于是只能全部依赖手工测试,风险就会很大。另外如果该迭代其中一个需求的缺陷太多,且修复时间过长,就会导致整个迭代的需求都会延期发布上线。
一个迭代一个分支的方式(简化版)
对于这样的情况,我们建议这个技术团队采用一个需求一个分支或是一小批需求(有强关联性的)一个分支的方式,这样可以满足按需求发布和剥离质量差的需求。但是他们并不采纳,认为这种方式会导致分支数量过多,增加管理成本。
一个需求一个分支或一小批需求一个分支
一旦遇到这种情况,其实就不好处理了,因为不能霸王硬上弓。但是要补上足够多的自动化测试用例也会需要比较长的时间,所以我们只能等待时机。按照以往的经验来看,时机很快就会到来,也就是最近一次发布后的下一个工作日。
该团队是在周六发布,所以下个周一就是机会,所以我们参加了该团队周一早上的站会,准备了以下几个问题:
1. -上周六咱们有需求发布吗?
-成功发布了。
2. -哪些需求发布了?
-迭代中需求状态为已发布的需求都已发布上线了。(这个看起来很正常,没什么问题)
3. -那还在开发中、测试中的需求呢?
-(有人用很小的声音说到)也发布上线了。
这时大家用惊讶的眼神看着我,好像在说,那不是风险很大,没有开发完成和没有测试过的需求也一起发布上线了……
补充一下背景知识:由于团队是一个迭代一个分支的分支模式,各个需求的代码都合在一起了,是很难剥离的,所以不管开发中的需求还是可发布的需求,代码都是在一起的。当然,发布包内既包含了可发布的需求,也包含了不可发布(开发中和测试中)的需求。
4. -那我们要怎么办?
-需要把可发布需求的代码单独剥离出来,怎么剥离?需要改变分支模式,切换到一个需求一个分支或是一小批需求一个分支的模式上来。
其实这个团队不是不想改进,而是在看不到问题或看不到改进项能带来好处的时候,改进的意愿度就不强,所以我们需要让团队能清晰地看到问题,而且能及时地给出建议、实践和好处,团队自然就会采纳了。经过了上面四个问题后,团队中有人站出说,自愿来写团队的分支模式,命名规范等。于是这个问题就被这样很好地解决了。
洪永潮:开展研发效能提升的必要条件我认为只有一个,那就是产研团队的需求交付速度与质量是否能满足业务快速发展的需要。
如果满足了,就不一定需要开展。如果不满足,那需要对企业或团队的现状进行摸底,明确当前阶段碰到的问题,然后需要明确业务快速发展对产品团队的诉求是什么。明确这两个问题后,再来看要怎么提升研发效能。
洪永潮:大型企业往往会更加容易开展研发效能的提升,这个其实和专业分工有比较大的关系,越专业,分工就越细,参与的人数就会越多,当然协作的难度也会随着人数的增加而增加。
当企业达到一定规模后,会按照岗位的不同,设立不同的部门,譬如业务部、产品部、研发部、测试部和运维部等等。成立各个部门之后,部门墙就应声而出。部门墙的产生,我们也称为效率竖井的形成,可以看到各个环节和部门“繁忙而高效”,但总体的效率和对外的响应速度却很低。效率竖井通常是由局部优化导致的,是研发效能提升的普遍症结所在。所以对于大型企业来说,打破效率竖井是很关键的一步。
效率竖井
那对于中小企业来说,在避免效率竖井产生的同时,可以引入大厂或其他企业已经验证过的最佳实践,并结合企业的现状进行适配。这样可以让中小企业少走很多弯路,不但能减少自己在探索过程中的浪费,还可以为业务节省大量时间。
不管是大型企业还是中小型企业,研发效能的提升首先都需要从全局出发,就是要关注需求交付的完整链路,避免局部优化,其次要从企业当前的问题和目标出发,先以解决问题为主。
洪永潮:在研发效能的具体实践中,首先需要解决上下同欲的问题,个人认为这是个核心点。什么是上下同欲呢?即管理层和实施研发效能提升的主体要上下一条心。
研发效能的提升往往是由管理层发起的。发起的时候,管理层一般已经看到一些问题了,不仅心里可能有了一些改进的想法,而且有可能连改进的目标都有了,也就是上层有了明确的目标。对于实施研发效能提升的主体来说,解决工作上的具体问题才是根本,否则他们不一定会完全配合。所以一方面要能切实解决团队的实际问题,另一方面也要对齐管理的目标,做到上下同欲。
其次是解决局部优化的问题,很多问题都是局部优化导致的,要打破这个竖井模式,从全局和端到端的视角去优化整个协作过程,比较理想的是成立全功能团队。
第三是解决互相博弈问题,团队在发展过程中,会出现产品方和技术团队之间互相博弈的问题,互相博弈很多时候是由不信任导致的,所以要打破博弈问题,就是要重新建立信任。这个过程可以从技术团队的效能提升先开始,譬如透明化整个研发交付过程、建立产品协作的明确机制和节奏、提升研发团队的需求交付速度和质量等等。要让业务方或产品方对技术团队有信心,持续正向地反馈闭环。
接下来有很多实践就会持续落地,譬如:测试左移、实例化需求、分支模式、定期验收、持续集成、持续发布和效能度量等。
洪永潮:关于研发效能,在阿里云云效是这样定义的:让团队具备持续、顺畅高质量地交付有效价值的能力。为什么是这个?怎么理解呢?
这个要回到初心来讲,提升研发效能的目的是为了什么?前面讲到,提升研发效能是为了能满足业务快速发展的需要。从业务的视角来说,他们期望提出的方案或想法能快速上线进行验证,同时从技术团队的视角来说,需要把业务和产品提的需求在最短的时间内高质量地交付上线,甚至在业务提需求的时候,可以一行代码不写就能实现。
首先,从业务的视角来看,他们期望提出的需求是有用的需求,也就是说在需求上线后,要能实现当初设定的目标,我们称为“有效价值”,这需要以用户价值为核心来探索、分析和规划产品。
其次,从协作视角来看,业务提出的需求,产研团队需要能快速高质量地上线。这就需要打破效率竖井,从关注资源效率转变到关注流动效率,即关注需求的快速高质量的流动。我们要从提升局部效率走向高效交付,以流动效率为核心,提升团队的持续交付能力。
最后,从工程和技术的视角来看,既需要高质量的领域模型和架构,还需要卓越的自动化测试、持续集成、持续部署、持续交付等自动化实践。高质量的领域模型和架构可以提升业务的响应能力,卓越的持续交付能力可以提升软件的交付质量和速度。
所以从上面这三个方面来看,总结起来就是:让团队具备持续、顺畅高质量地交付有效价值的能力。
阿里云云效的定义
洪永潮:说起研发效能的发展,很多人会想到敏捷开发、DevOps、持续集成、持续交付等等的发展。敏捷开发一开始把主要关注点放在开发阶段,关注的是整个需求交付价值链中的一环。DevOps 出现后,打破了开发和运维之间的墙,让需求交付价值链向后往运维方向得以延伸,而现在很多企业在打破业务和开发之间的墙,让需求交付价值链得以更加完整,通过研发效能的提升促进业务敏捷。在阿里,这个我们叫做 BizDevOps。这是第一个,也是现在基本上都可以看到的。
第二个是数字化研发,很多研发工具平台的产生,譬如阿里云云效,让研发数字化变得更加容易,让开发人员和团队能更专注和高效地进行协作,持续不断地提升研发效能,赋能业务的快速验证和持续创新。
洪永潮:研发效能的提升不会一蹴而就,它不是银弹,需要理念、方法、实践和工具相结合,需要从企业的实际情况出发,解决企业当前和不久将来会面临的问题,持续不断地解决问题和提升研发效能。
对于想从事研发效能的小伙伴来说,需要脚踏实地去学习研发效能提升背后的理念和方法,推荐学习何勉老师的畅销书《精益产品开发:原则、方法与实施》。同时针对企业面临的问题,采用合适的实践去解决问题来提升研发效能,这个过程中也要不断地学习、实践和总结来提升个人能力。
对于想要尝试提升研发效能的管理者们,还是要结合企业的现状,把提升研发效能的初心和目标讲清楚,持续不断地优化验收流程和架构模型,建立持续反馈的机制。避免采用一些研发效能的指标去考核团队,当把这些指标作为考核指标,就已经不是好指标了。我们需要用初心和目标做牵引,用相关的指标去观察团队的落地执行情况,最终让团队走上自我驱动的持续改进之路。
洪永潮
阿里巴巴 阿里云混合云 解决方案架构师
阿里巴巴研发效能专家,10 年以上敏捷精益方法的实践和落地经验,专注于赋能企业实现研发效能的提升,在阿里集团先后负责天猫、淘宝、阿里云、饿了么、新零售等多个事业部的敏捷转型和效能提升。目前主要负责阿里外部合作伙伴的研发效能提升,成功辅导的企业涉及电商、金融、游戏、速递、电力、地产和零售等行业。
企业在业务层面寻找增量,团队层面提高人效。对于技术团队,研发效能是不断探索、重点关注的话题。研发效能的本质是尊重“人性”,还是敬畏“物性”?哪些方案对于效能提升切实有效?将于 5 月 12-14 日举办的 QCon 全球软件开发大会(北京站)策划【研发效能提升】专题,由华为云 DevSecOps 生态专家徐毅担任出品人,邀请美团、金山办公、华泰证券、德邦快递、京东数科等知名企业一线专家分享技术团队研发效能提升路径。
更多演讲内容可点击底部【阅读原文】查看。QCon 北京站现场门票优惠即将结束,感兴趣的同学可扫描图中二维码或直接联系票务经理咨询:17310043226。
点个在看少个 bug 👇