IDCF荐书 | 《软件研发效能提升实践》(文末赠书)
这些年,由于一直在拥有数万名研发人员的大型互联网公司做DevOps和研发效能的相关工作,做过敏捷和持续交付实践的大规模推广,组建并带领团队从零开始建设服务于全公司的、一体化的、一站式的DevOps平台,发起公司级效能度量委员会并制定度量指标体系;而且在技术社区持续活跃,在各类综合性/专业性技术大会中担任出品人等角色,对互联网大厂的研发效能提升思路和做法有一定的理解,因此,把这些经验总结起来,形成了一个具有增强回路效果的研发效能提升体系,我们称之为研发效能的“黄金三角”,如图1所示。
研发效能的“黄金三角”由三部分组成,分别是效能实践、效能平台和效能度量,它们彼此独立,又相互关联。
其关联关系如下。
图1 研发效能的“黄金三角”
效能实践中的优秀实践可以固化、沉淀到效能平台;反过来,效能平台支撑效能实践的落地。
效能平台产生的大量研发数据形成了效能度量中的效能洞察;反过来,效能度量可以持续观测效能平台中产生的数据,进行下钻和深入分析。
效能度量中的洞察和分析结果可用于针对性地优化效能实践;反过来,效能实践可以给效能度量更多的输入,帮助其完善度量指标集和分析方法。
因此,效能实践、效能平台和效能度量形成了一个彼此增强、迭代优化的回路,有效利用好这个增强回路可以帮助企业持续提升研发效能。
下面我们分别从目标、价值主张、实践分类和实施建议几个维度展开讨论。
效能实践
研发效能实践地图如图2所示。
图2 研发效能实践地图
目标:提炼和采纳与上下文匹配的DevOps及效能提升实践。
价值主张:产品导向+工程卓越。
产品导向:区别于项目导向的交付模式(在特定时间内,以相对确定的预算和人力交付预先计划的内容),我们更倾向于以产品导向的交付模式组织相关效能实践。产品导向可以让我们面向长期的业务价值,组织长期稳定的敏捷团队,持续迭代和优化产品。我们承认需求的不确定性,要持续改进产品,而不是简单地遵从既定计划;我们要考虑长期产品和团队能力的建设,而不是把短期项目做完了事;我们要考虑持续为客户创造价值,而不是看项目有没有超过预算;我们要面向工作结果进行响应,而不是盯着一些局部的工作产出。
工程卓越:我们必须持续关注工程和技术的卓越性,而不仅仅是交付了多少需求或特性。比起多完成几个小功能,也许工程和技术上的提升所带来的价值会更大。就像微软CEO萨蒂亚·纳德拉所说:“每一天我都在开发新特性和提升我们的生产力之间进行权衡。”我们要追求用工程化的方法持续把确定性、重复性、机械性的任务自动化,从而在提升效率的同时让工程师有更多时间花在有创造性的事情上。用工程化的思路解决问题,追求工程卓越就是一种“反内卷”的表现。
实践分类:业务敏捷创新实践、敏捷精益协作实践、持续交付工程实践、云原生技术实践、组织和团队拓扑等。
实施建议:业界一致认为,DevOps领域和研发效能领域从来没有“一刀切”的解决方案,不要迷信某个成熟模型或某种规模化框架就一定能对你有帮助。正确的实践选择一定要基于上下文,找出价值流中最大的障碍,选取工具箱中适当的实践,从小范围开始,纵向进行实验,应用敏捷思维来提升组织效能,逐个解决瓶颈问题,循环往复。
效能平台
效能平台框架如图3所示。
图3 效能平台框架
目标:打造一站式、一体化的效能平台,支撑软件交付全生命周期。
价值主张:自动化+自助化、场景化+生态化。
自动化:自动化很好理解,DevOps讲究“自动化一切”,这正是DevOps的精髓“CALMS”中的A(Automation),研究表明高效能的企业在自动化构建、自动化测试、自动化环境创建和部署、自动化监控和可观测性等方面要远远好于中低效能的企业。
自助化:自助化代表上下游角色可以通过平台紧密衔接,在工具平台被某种角色创建出来之后,上下游的其他角色应该都可以按需、自助地使用,降低了对某种角色或者某个人的依赖,这样组织协作效率才能提升。
场景化:我们经常看到很多所谓的“一站式、一体化”,是按功能领域进行划分并展现相关能力的,或者说是一个“拼凑”起来的平台。而真正让管理者和工程师使用顺手的、易用的平台一定是按研发场景进行组织的。比如,以某一产品为主线贯穿DevOps流程,方便用户管理产品的相关需求,创建特性分支,迭代开发和交付。同样,以应用为主线对运维人员来讲会更加友好。
生态化:在互联网大厂搭建效能平台时,遇到的普遍难点是业务复杂、规模庞大、业务独特、场景众多,很难通过一个团队的努力满足整个公司的需求。但是如果各个业务部门什么都自己做、重复造“轮子”,甚至相互进行恶性竞争就更不好了。因此,平台建设者应该更加开放,分离平台底座和原子能力的建设,即通过生态合作伙伴关系,促进公司效能平台的良性发展。从公司角度来看,减少重复建设和避免内耗,也都是“反内卷”的表现。
实施建议:效能平台的建设切忌开始就追求“大而全”,所谓的“一站式、一体化”只是手段,不是目的,最终以能满足研发场景的诉求为主。尤其是在平台建设初期,不妨以支持To B客户的思维来运营平台,深度绑定和跟进种子团队,深刻理解业务痛点和需求,这样做出来的平台马上就会有人用,然后收集反馈,像滚雪球一样越做越完善。另外,还要注重需求价值流和工程价值流之间的联动,而不要将其分裂成毫无关联的两个系统。
效能度量
目标:在正确的方向上开展研发效能度量和数据洞察,指导和驱动效能改进和提升。
价值主张:数据驱动+实验思维。
数据驱动:我们经常遇到的现象是,一个组织或者团队在消耗了大量的“变革”时间成本和人力资源后,却无法回答一些看似本质的问题。比如,你们的研发效能到底怎么样?比别的公司或团队的好还是差?瓶颈和问题是什么?采纳了敏捷或DevOps实践之后有没有效果?下一步应该采取什么行动?我认为,效能度量的目标就是让效能可量化、可分析、可提升,通过数据驱动的方式更加理性地评估和改善效能,而不要总是凭直觉感性地说“我觉得……”。用真实和有效的数据说话,勇于挑战现有流程和规则,直指研发痛点和根本原因,也是一种“反内卷”的表现。
实验思维:研发效能提升没有“一招鲜,吃遍天”的万能招式,而是要基于上下文进行有针对性的实验和探索。比如,想提升线上质量,降低缺陷密度,经验告诉我们应该去加强单元测试的覆盖,完善代码评审机制,做好自动化测试案例的补充。但是,这真的有效吗?我们通过数据来看,很可能没有任何效果!并不是说这些实践不该做,而是可能做得不到位。比如,只是为了指标好看,编写缺少断言的单元测试,找熟人走过场通过代码评审,覆盖一些非热点代码来硬凑测试覆盖率目标等。因此,我们需要实验思维,找到真正有用的改进活动及其与结果之间的因果关系,有的放矢才会更有效率和效果。
实施建议:效能度量本身也是一个比较复杂的体系,包含自动采集效能数据、度量指标体系、度量分析模型、度量产品建设、数据驱动和实验思维等多个方面,将它们整理后,称为“研发效能度量的五项精进”,如图4所示。图4 研发效能度量的五项精进
1.构建自动采集效能数据的能力。
通过系统分层处理好数据接入、存储计算和数据分析。
2.设计效能度量指标体系。
选取结果指标用于评估能力,选取过程指标用于指导分析改进。
3.建立效能度量分析模型。
这里的模型是指对研发效能问题、规律进行抽象后的一种形式化的表达方式。
模型有很多种,如组织效能模型(战略资源投入分布和合理性)、产品/团队效能模型、工程师效能模型等。
我们还要合理采用趋势分析、相关性分析、诊断分析等方法,分析效能问题,指导效能改进。
4.设计和实现效能度量产品。
首先将数据转化为信息,然后将信息转化为知识,让用户可以自助消费数据,主动进行分析和洞察。
5.实现有效的效能数据运营体系。
要避免不正当使用度量而产生的负面效果,避免将度量指标KPI化而导致“造数据”的短视行为。
效能改进的运作模式也很重要,如果只是把数据报表放在那里,效能不会自己变好,需要有团队或专人负责推动改进。
与研发效能相关的话题是不是很有意思?这里还有很多值得展开和深度思考的内容,比如:
研发效能提升的实践应该如何选择?管理和工程技术实践都有哪些?
研发效能度量指标体系应该如何设计?效能数据如何分析?
促进高效能的组织、结构和个人能力提升的模型是怎样的?
研发效能如何进行规模化扩展?
研发效能的支撑工具如何选择和落地?
各个行业研发效能提升的综合案例有哪些?
以上每个问题都值得单独探讨,我们会在《软件研发效能提升实践》一书中一一分享。
关于软件研发效能,你们有怎样的思考?欢迎在评论区回复。
我们将为评论区回复中点赞最多的前3名读者分别赠送一本《软件研发效能提升实践》。
识别下方二维码,前往商品页查看详情。
- 相关阅读 -
我的敏捷学习书单 | IDCF
书名很烂却很好看的15本书,强推!| IDCF
大连站6月11-12日,北京站7月23-24日将举办线下公开课挑战赛,36小时内从0到1打造并发布一款产品。
企业组队参赛&个人参赛均可,赶紧上车~👇
关于软件研发效能,你们有怎样的思考?欢迎在评论区回复。
我们将为评论区回复中点赞最多的前3名读者分别赠送一本《软件研发效能提升实践》。