微访谈：数据驱动的软件研发效能提升
The following article is from CodeWisdom Author CodeWisdom
（）大约（）
背景介绍
企业业务快速发展，交付质量与速度要求越来越高。与此同时，企业软件系统的规模和复杂性不断增长，开发团队也在不断扩大。在此背景下，软件研发质量与效能管理逐渐成为企业关注的一个焦点。由于软件是一种不可见的逻辑产品，因此开发人员的实际投入和产出、个人能力以及团队协作情况难以观察和评价。云化开发平台与DevOps、持续交付等实践的广泛应用使得软件研发积累了越来越多的过程和制品数据，因此数据驱动的软件研发效能分析与改进逐步成为企业的共识，但同时也在相关技术和具体实践上面临很多问题和挑战。
为此，我们邀请了多位业界知名专家，围绕数据驱动的软件研发效能提升的问题背景、实践探索、经验总结、痛点问题和技术展望开展深入交流和探讨，希望能为相关研究和实践的发展提供一些有价值的经验和启示。
主持人
彭鑫：复旦大学教授
嘉宾
朱少民：同济大学特聘教授，QECon大会发起人
茹炳晟：腾讯 Tech Lead，腾讯研究院特约研究员
林志强：华为消费者BG研发数字化产品与平台部部长
石雪峰：京东零售技术效能通道委员
夏思雨：Thoughtworks EMPC首席架构师
姚志坤：字节跳动效能平台负责人
林 帆：阿里云 云效数据洞察产品板块技术负责人
孟国军：美团工程效能技术专家
访谈主题
数据驱动的软件研发效能提升
研发效能近期成为业界热议的一个热点问题，各大技术大会上都有不少这方面的主题演讲。其中涉及的技术问题与软件工程领域的软件开发数据分析与挖掘有很强的关系。本次微访谈邀请的都是业界知名专家，有着丰富的一线经验。希望通过这次微访谈，能让学术界进一步了解业界的实践问题和技术诉求，帮助我们更好地规划未来的研究工作。同时，我们也可以了解各家企业在数据驱动的软件研发效能管理方面的实践探索和经验积累。
Q1：企业中的软件研发效能具体是什么含义？为什么研发效能提升逐渐成为企业关注的一个热点问题？
Q2：您所在的企业或者您所了解的企业针对软件效能提升进行了哪些方面的数据收集？DevOps工具流水线与相关实践以及云化开发环境对于数据的收集带来了什么样的促进作用？
Q3：您所在的企业或者您所了解的企业是如何分析和利用相关数据来进行软件效能评估和改进的？具体会将软件开发效能分析结果应用在哪些地方？
Q4：当前企业在软件开发效能评估与改进方面存在哪些误区？如何避免这些误区？
Q5：软件开发数据分析与挖掘是软件工程领域的热门研究问题。从企业软件开发效能提升的角度看，软件开发数据分析与挖掘还存在哪些问题和挑战？未来相关技术将向什么样的方向发展？对于学术界在相关方面的研究有哪些建议？
Q&A记录
Question 1
主持人：企业中的软件研发效能具体是什么含义？为什么研发效能提升逐渐成为企业关注的一个热点问题？
朱少民：
企业中的软件研发效能具体是关注有价值的长期、持续的输出。大家对研发效能的理解不一样，之前看到一个采访，被采访的专家说 “研发效能是指单位时间产出量”，将“效能”和“效率” 搞混了。其实，研发效能不等于研发效率。效率是指单位时间产出量，即效率 = 产出/所用的时间。而效能是指对业务有实际价值的效果、成效，更强调有效性、效益，效能 = 有价值的产出/所用的时间，效能公式的分子是效率公式分子中有价值的一部分——有效的成果。简单地从软件研发来看，效能 = 对客户有价值的需求 + 效率 ，在需求有效的情况下，效率越高，效能越高；效率或者说生产力不变，需求对客户的价值越高，开发效能就越高。
为什么研发效能提升逐渐成为企业关注的一个热点问题？受疫情影响，竞争越来越激烈，加之像BAT这样的大厂开发人员达到几万人，而人员薪酬又越来越高，所以企业必须要关注产出，关注有价值的产出，做有价值的事情，因此效能成为热点。
茹炳晟：
我会用“顺畅、高质量地持续交付有效价值的闭环“解释软件研发效能。
顺畅：价值的流动过程必须顺畅，没有阻碍
高质量：如果质量不行，流动越快，死的也会越快
持续：不能时断时续，小步快跑才是正道，不要憋大招
有效价值：这是从需求层面来说的，你的交付物是不是真正解决了用户的本质问题。（关于本质问题我想多说一句，女生减肥不是本质问题，女生爱美才是，可以自己体会一下。）
闭环：强调快速反馈的重要性
在这个概念的引导下，我觉得五个持续（持续开发，持续集成，持续测试，持续交付和持续运维）是这个概念能够落地的必要实践。与此同时，我们还需要从流动速度，长期质量，客户价值以及数据驱动四个维度来对研发效能进行有效的度量。
为什么研发效能提升逐渐成为企业关注的一个热点问题？我认为有以下几点原因：
从商业视角来看，现在toC产品已经趋向饱和，过去大量闲置时间等待被APP填满的红利时代已经一去不复返了，以前业务发展极快，用烧钱的方式（粗放式研发，人海战术）换取更快的市场占有率达到赢家通吃是最佳选择，当时关心的是软件产品输出，研发的效率都可以用钱填上。而现在toC已经逐渐走向红海，同时研发的规模也比以往任何时候都要大，是时候要勒紧裤腰带过日子了，当开源（开源节流中的开源）遇到瓶颈，节流就更应该发挥作用。这个节流就是研发效能的提升，同样的资源，同样的时间来获得更多的产出。
从组织架构层面看，很有企业都存在“谷仓困局“，独立来看，研发各个环节内部可能已经做了优化，但是跨环节的协作可能就会有大量的流转与沟通成本，从而影响全局效率。基于流程优化，打破各个环节看不见的墙，去除不必要的等待，能够有很大的提升
研发效能的沉淀可以实现企业级跨产品跨项目的研发能力复用，避免原来每条产品线都在做研发效能所必须的”0到1“，没人有精力去关注更有价值的”1到n“。
观点讨论
@彭鑫：说明很多大企业经过业务快速增长之后，现在更加重视稳定发展了。过了业务快速发展期之后，工程就变得愈发重要了。所以学术界明显感觉到这几年企业对于软件工程的重视程度越来越高。不能跟业界实际问题相结合，软件工程研究就变成了无源之水。
林志强：
我们没有特别规范的定义，谷歌说的工程生产力（Engineering Productivity ），业界说的持续快速交付价值的能力，用最朴素直白的表达，就是“多快好省”把业务交付出来。我们主要讲价值，质量，效率，速度。
关注的热点主要还是自身面对的挑战。
一方面，从业务视角看，产品多，形态多，场景多，需求多，业务流交互逻辑复杂，市场环境变化快，IT系统如何快速响应业务诉求及变化是研发效能提升很重要的课题；
另一方面，从IT视角看，随着功能越来越多，软件规模越来越大，复杂度越来越高，变更影响放大，牵一发动全身，修改容易引入新问题，难以演进，维护成本高，成为支撑“多快好省”的阻碍。从业界咨询公司对行业IT软件系统的分析来看，无视或者不重视软件复杂度治理，将最终带来70%以上的维护成本投入，步履维艰，也就难以快速响应业务诉求及变化，所以我们认为“软件复杂度”治理也是研发效能提升很重要的课题。
石雪峰：
研发效能没有一个明确的定义，在京东涉及到以下这些主要领域：研发效能一体化工具平台、研发效能度量、研发标准化流程、产品全景图、资源及可视化流程。可以看出研发效能的范围已经不仅仅局限于开发者范畴，而是拓展到企业效能的领域。
研发效能提升逐渐成为企业关注的一个热点问题的根本原因在于两个方面的矛盾。
首先是业务视角：
第一、企业数字化转型对于研发交付能力带来了更高的要求；
第二、同行竞争角度来说企业的竞争就是效率的竞争，各大公司都在加大这方面的投入；
第三、产研作为核心竞争力，也占据了大量的运营成本，效率提升的撬动比较高。
其次是开发者视角：
无论是工具建设、流程管理、产品需求、还是前沿技术红利、开发者体验、开发者的感受和归属感等等方面，都是研发效能领域的火爆的原因。
观点讨论
@朱少民：其实殊途同归，所以效能也不是新东西，只是今天更受到关注，采用的技术/工具、流程、方式/方法不一样了。
@彭鑫：数字化转型现在是个热词。我们看到以数字化的方式开发软件的IT企业本身也在谈数字化转型，这是一个很有意思的现象。
夏思雨：
我觉得效能两个字，跟DevOps如今一样难定义了。每个企业都把自己看中的软件研发的能力抽取成指标，作为研发效能的度量，在企业内部提效能的时候也就意味着把对应的这些指标做好，就叫做效能提升了。通用含义上看，效能指的就是效率和有效性，在别的行业里面已经提了很多年了。简单说，做得快和做得好。还得是长期持续的。短期的那叫峰值。
研发效能之所以成为关注热点，在我看来这是行业发展到一个阶段的必然。参考各种行业发展历史，都是到一定的成熟度之后，就开始琢磨如何做得更快更好来满足外界的需求。
从现状来看，第一，软件交付的能力目前已经到了一个相对成熟的阶段，各种技术框架、基础设施、平台型产品的出现，使得我们比较容易能够实现各类业务需求，满足性能等要求。第二，很同意前面腾讯专家的观点，2C产品的市场竞争已经接近饱和了，需要更好的软件能力来锦上添花，比如更快的响应需求变化的速度，更好的性能，更流畅的体验等。第三，目前软件系统的复杂度和规模已经远超可控的范围了，比如多样化的技术选型，团队规模扩大，业务复杂度不断提升等。将所有这些因素看成一个整体系统，在没有外力作用下，必然是快速失控以及恶化的结果。
基于外部环境的变化以及软件系统自身的这些因素，研发效能成为关注热点是个必然的趋势。
姚志坤：
研发效能关注价值交付的效率，在各个研发活动环节，保证合理的质量下最大限度地交付尽可能大的产品价值。
效能一直是软件工程的研究热点，只不过通常效能的改进提升是渐进的，实施和见效周期长，而企业侧的热度慢于研究领域，大环境起到了催化作用：
大环境下互联网企业的增量红利变少，业务的粗放式管理走向精细化的过程管理，要求效能管理加强，原来有20%的利润，1%效能提升并没有足够吸引力，但现在利润只有5%，这时效能价值就很大了；
国内厂商对toB业务日趋重视，而toB业务的特点就是慢工出细活，重视ROI、重视质量，要求业务团队降本增效才有利润；
团队也是顺应着业务的变化日趋规模化、角色分工专业化，协作多了自然对于整体提效的诉求也变多了；
DevOps持续交付等效能理念在一些先行企业的长期实践落地，也催生更多企业尝试和落地，形成了良性循环。
对一些企业来说，想办法投入最少的时间和成本，得出最多的成果，要做到这么几点：
产品的需求定义的足够精准，投入少收益大；
研发的架构合理，迭代效率和质量高，技术债务少；
整体CICD的交付环节顺畅，协作流程返工阻塞少；
产品稳定性高事故少恢复快。
林帆：
效能既包括效率，也包括效用、效果的含义，是对一个事物产出情况的综合评价。而我们现在所说的研发效能，通常指的是软件研发场景下的效能，如果非要给一个定义的话，可以说它是聚焦于软件研发产出和提效的一整套实践，包含用于指导研发过程的理论方法、用于辅助提效的流程工具，以及用于评价研发结果的度量指标。
现在随着DevOps这些思想的普及，在一些场景下，阿里也会将与运维运营相关的活动纳入研发效能的范围，比如观测线上的故障情况、新功能发布后给业务的带来的流量和价值等等。
其实在很长时间以来，研发效能一直都是软件企业、尤其是中大型软件企业关注的方向，因为效能的一端链接着成本，另一端链接着质量，研发效能的提升会带来软件企业效益的直接获益，而对研发效能的评估也可以作为判断企业技术管理是否到位，发展方向是否正确的一把标尺。
x10效能是阿里提出的，不过和业界的x10程序员之类一样，只是一个概数，不过我们确实有不少效能提升方面的数据，如果看最好的Top团队，x10是有可能达到的。现在随着DevOps这些思想的普及，在一些场景下，我们也会将与运维运营相关的活动纳入研发效能的范围，比如观测线上的故障情况、新功能发布后给业务的带来的流量和价值等。
观点讨论
@彭鑫：这个是把DevOps做到极致了，运维数据反馈到研发效能环节。
@朱少民：DevOps 其实就是一个闭环。
孟国军：
研发效能是指持续提升产研过程效率问题，同时会更加关注效率提升的正确性或者价值体现，价值体现包含两层的含义，第一层为输出提升效率的产品或者服务；第二层为在正确的方向持续建设。研发效能需要结合团队现状和线上化数据，深入分析资源、效率、成本之间的关系，建立有效评估指标、开发提效产品或者服务，持续改进研发效率。美团更加关注价值。
研发效能成为目前企业关注热点原因：
对外，互联网行业进入”寒冬”，同时不断曝出“996”等负面性舆论，迫使企业选择更加高效方式提升生产效率；
对内，企业尤其互联网企业发展到一定规模，随着人员扩充，多产品快速迭代，业务复杂度和链路关系越来越复杂，协同开发成本增加阻碍业务快速迭代，同时人力成本野蛮生长会带来更大的研发成本；
人工智能的快速发展，促进开发模式、开发能力、部署能力、监控能力等快速迭代，产研交付更加自动化和智能化。
Question 2
主持人：您所在的企业或者您所了解的企业针对软件效能提升进行了哪些方面的数据收集？DevOps工具流水线与相关实践以及云化开发环境对于数据的收集带来了什么样的促进作用？
朱少民：
我很早看过ThoughtWorks张松老师写的书《精益软件度量——实践者的观察与思考》，这是软件度量出的比较早、写的比较好的一本书。书中首先提出5大目标：交付价值、响应速度、产能、质量和能力，我认为今天它们依旧有效。本书从目标出发，然后讨论决策场景、指标框架，再讨论度量对象模型 等等。这有点类似Google的GSM模型，从目标出发，看哪些现象、特征、信息和目标关联，然后再确定度量指标，也就是能从不同维度衡量与目标的距离。有了度量指标，然后就清楚要采集哪些数据。像质量模型、能力模型比较成熟，容易设计度量指标，响应速度也比较容易度量，但交付价值、产能相对比较困难，今天连软件规模的度量都不够成熟，业界应用也不多，或者说应用效果不佳。
度量数据的采集能贯穿整个生命周期，越全面越好，其次，度量数据尽可能非手工输入，应该由系统自动生成、工具自动采集，所以DevOps工具流水线和云化开发环境对数据的采集都是有利的。
观点讨论
// 效能、价值与数据分析 //@彭鑫：如果把效能与价值联系在一起，那么相关的数据分析和度量就困难了很多，因为这要求超越表面的代码行、缺陷数等指标，能够在时空方面延展与长期、广域的价值建立起联系。
// 数据获取自动化 //@茹炳晟：数据的获取必须依赖DevOps工具打点来自动获取，否则如果是需要通过人工上报，这样的度量数据必定会失真。
@彭鑫：看来埋点不仅是软件运维的需要，研发效能管理同样需要。
@朱少民：最近可观测性流行，管理越透明越好。
@彭鑫：微服务的可观测性的三大支柱trace、log、metrics好像也能在效能分析中找到对应。
@夏思雨：数据采集方面来说，除了前面大家提到的DevOps埋点的思路，另外一种方式是，我们从现有的数据状况以及别的团队或者客户的成功案例出发，驱动团队关注效能提升这件事本身，从而愿意为有效的数据产生做出一些改变。我们做度量的时候一般会采取一种低成本无侵入的方式，收集现有数据，挖掘能挖掘的信息，给团队指明一些改进的方向，再不断收集新的数据，对比之前的指标和添加新的增量，形成一个改进的闭环。对研发流程成熟度比较低的团队相对友好一些，当然也需要建立在长期的基础上。
林志强：
我们主要还是面向交付件，沿着Dev，Ops交付流，需求，设计，开发，测试，发布，上线等所产生的需求、文档、API、代码，页面等软件对象的全生命周期演化记录数据。
DevOps打通多角色多系统，减少等待，中断，切换，提升了研发协同交付流效，同时，基于交付流，沉淀固化实践经验，减少了重复犯错。但并没有解决功能多，代码臃肿，架构腐化，重复造轮子，知识浪费的问题。
石雪峰：
软件效能数据收集的边界和工具平台覆盖或者说统一的边界是一致的，对于不同公司而言存在显著的差异。对于数字化能力做的足够优秀的公司而言，他们已经能够做到数据收集，信息整理，知识沉淀，并且正在迈向决策辅助领域，这对于决策成本的降低和信息流动的加速方面的影响将形成竞争的代际差异。
第二个问题，从工具链的层面来说，随着一体化平台的建设，一定程度上降低了数据收集的成本，当企业中的工具链平台比较松散也没有整合的时候，通过一套模型对接所有平台采集必要数据是有相当成本的工作。同时随着环境向研发过程的深入，比如云端开发环境，WebIDE等使得过往难以收集，或者成本很高，效率很低的收集工作都成为了可能。研发效能自身就是一个大数据的问题，平台的建设打通了数据生产和消费的环节，这使得大规模精细化的研发度量成为了可能。为此，研发工具也越发类似业务产品，强调开发者体检的同时，从埋点数据收集，AB测试，灰度发布等领域越发专业化，这就意味着数据需求反过来推进了工具平台能力的迭代升级。
观点讨论
// 精准获取数据 //
@茹炳晟：不要在没有任何明确改进目标的前提下开展大规模的度量，因为度量是有成本的，而且这个成本还不低。很多大型组织往往会花大成本去建立研发效能度量数据中台，指望通过研效大数据的分析来获取改进点。这种“广撒网”的策略虽然看似有效，实则收效甚微。事实证明，度量数据中台的建设成本往往会大幅度高于实际取得的效果。比较理想的做法应该是通过对研发过程的深度洞察，发现有待改定的点，然后寻找能够证实自己观点的度量集合并采取相应的措施，最后再通过度量数据来证实措施的实际价值，这种“精准捕捞”的策略往往更具实用价值。
// 数据驱动 //
@彭鑫：软件开发数据分析现在实实在在是大数据问题了。这就意味着数据需求反过来推进了工具平台能力的迭代升级。可观测性需求推动工具升级。软件研发过程的数字化一方面有自己的优势，因为软件开发是个逻辑加工过程，天然就是数字化的。但另一方面，软件研发过程的数字化也有独特的挑战，那就是所涉及的数据模型和数据采集受软件本身的复杂性（如需求、设计和任务分解等）的很大影响。
@石雪峰：是的，我一直认为研发效能专家未来的方向一定是数据分析方面的专家。有一个很实际的问题，比如对于工具开发来说，到底我们应该做哪个需求，这个需求的必要性是我们根据经验臆想出来的，还是通过数据证明真实存在的场景。现在很多公司做内部的效能平台，其实还是个人经验去主导的，慢慢过渡到数据驱动的话，我相信这也是未来发展的常态。
@朱少民：目标驱动数据，数据驱动效能。前面一句不能省。
@夏思雨：其实还可以做的一件事，是数据辅助制定目标。
夏思雨：
Thoughtworks自身是一家IT咨询服务公司。我们为客户提供了数据驱动的效能度量和架构治理的服务。在数据采集方面借鉴了标品+扩展能力的‘思路’，设置了最低的数据采集门槛，比如代码版本管理仓库的提交记录，需求管理数据等。扩展的部分，结合企业自身流程中所使用的的工具，尽量构建从需求的提出，实现，构建，部署，运行环境的监控的全流程数据采集。这中间一般会采用两条主线，一个是需求，一个是开发人员。
在我们所遇到的客户的各种场景中，有按需使用开源工具自己搭建运维的，有采购成熟的DevOps产品平台的，也有基于开源产品封装自建DevOps的平台的。DevOps工具平台一定程度上能够提供更连贯的数据流，比如需求到实现到部署过程的流转信息，能够更好地串联研发过程数据，运维数据，在全局视角形成流动的视图。但是由于限制了团队在工具以及流程上的自由度，能够采集到的数据维度比较有限，想要尝试从数据挖掘更深层次原因的时候，需要对平台的工具使用，数据记录提出更高的要求。
观点讨论
@彭鑫：版本库确实是最重要的数据来源之一。同时版本历史数据的质量也很重要，这个需要企业开发管理的保障，例如commit的原子性以及与开发任务（缺陷、特性等）等追踪关系。
@夏思雨：git的信息其实非常细节，能深入分析出来很多东西。
姚志坤：
字节这边从数据源来看，分别从需求、代码、制品、测试、发布、运维几个环节对应的内部平台收集数据，对于效能提升来说，代码、制品、测试、发布是标准化程度最高，也最容易落地的数据度量环节。每个环节的数据通常包含标准活动名称、时间节点、需求号、相关人。通过这些原子数据采集到的节点数据，可以刻画出丰富的的场景数据，分为客观的质效结果数据和推动质效改进的过程数据。
研发效能是一个整体的提升，看孤立的环节数据并不能表达整体的价值流效率，因此打通各个研发流程环节的数据非常关键，流水线在数据收集中起到了打通脉络的作用，字节在流水线能够集成代码、制品、测试、发布的关键节点，获取需求(也就是价值)的上下文，从流水线角度能够观测实实在在的价值流动，因此大大降低各个环节的平台数据打通的成本；云化的开发IDE和调试环境可以进一步收集研发过程中的数据，数据内嵌而不用研发人员感知，提高数据准确性。
观点讨论
@彭鑫：打通各个研发流程环节的数据就是建立追溯关系。
@朱少民：反馈过来，形成闭环。
@姚志坤：能通过流水线采集的效能节点数据，尽量不要只打点。在规模化下的场景下，微服务规模化程度高，业务组件解耦，需求和发布是多对多的关系，只能通过流水线刻画出来。
@彭鑫：打通各个研发流程环节的数据就是建立追溯关系。
@夏思雨：所以这个角度看，需求的实现涉及多少服务的修改，哪些服务的修改最频繁，也可以成为效能度量覆盖的一部分。毕竟架构也是影响效能很重要的一个因素。
@姚志坤：微服务其实对于效能度量复杂度是提高的，一个需求可以需要多个微服务上线，而同时一次微服务的上线也可以携带多个需求，再加上多个服务整体要做测试封版、批次发布。
孟国军：
数据采集最大的问题为标准化和准确性问题，通过工具进行数据采集可以起到数据采集的标准统一、准确、自动，同时避免了人工填写方式成本高、填写率低、错误率高等问题；另外云开发环境提供了有效代码（包括工程、分支、接口、函数、代码块等）采集分析能力，比如确定编码时间就可以通过开发工具进行检测分支checkout时间点（假如定义编码开始时间为checkout）。
数据线上化是非常重要的环节，奠定了整个研发效能基础。线上化主要包含：
产品交付整个生命周期的关键数据，立项、评审、排期、研发、提测、测试、上线、灰度、全量各个环节时间点、人力、资源投入等数据；
研发过程链路线上化，采集需求、任务、工程、分支、代码（细化到接口、函数、代码块）、部署等数据并建立关联关系；
测试过程线上化，采集需求、测试任务、测试计划、测试用例、缺陷、自动化用例、覆盖情况（页面、接口、代码等）等数据并建立关联关系；
线上问题、故障等数据；
其他方向也可以采集组织结构、研发成本等。
林帆：
问题里提到的流水线和云化，这两项确实可以看做是促进研发数据采集的两类方法的代表，但它们背后的机制有所不同。
就实际的实践而言，各企业当前采集的数据的种类大同小异，要发现等待、阻滞、响应速度那就要采集需求任务的产生以及流动情况数据，要分析交付速度、产能就要采集发布的频率和时长数据，要知道软件的质量状况就要采集代码和测试相关的数据，所以普遍做法是围绕软件研发的全流程，项目管理、代码开发、上线发布、还包括线上稳定性相关的各类数据都会囊括。
流水线、敏捷迭代、云原生等等都可以被看做是软件研发过程规范化的机制，以流水线为例，它能够以一种标准而确定的方式将各项研发活动环节串联起来，实现流程统一，会使得采集到的数据更加易用和有意义，对于后期分析的帮助尤其大。
而平台化、云化本身都隐含了一个数据集中化的过程，将过去分散在诸多工具和线下系统里的信息孤盘，从源头上聚合到一起，从而也能使得数据本身变得口径一致、容易前后贯通。
观点讨论
// 微服务所倡导的自治团队和服务间独立开发在业界实践中到底如何 //
@彭鑫：微服务所倡导的自治团队和服务间独立开发在业界实践中到底如何？看起来很多时候业务变更还是需要协调多个服务一起进行修改和发布？还是服务划分做的不好？
@夏思雨：这是个好问题，我们也在帮很多客户做微服务架构治理的事情。有非常多实际的场景中，大家其实都没有享受到微服务本来应该带来的解耦、独立自治的好处，但是承担了微服务架构带来的复杂度提升的弊端。这个跟建模有非常大的关系。绝大部分都是业务建模的问题。没找到业务上天然联系少的地方作为服务边界。
@姚志坤：目前字节除了传统的单服务变更CICD，会引入团队协同场景（类似多服务的火车发布），通过一定的手段管理多个服务的修改和发布，使得这些聚类的微服务看起来像一个整体。
@彭鑫：嗯，服务也要聚类。也许相关度高的服务可以集中在一个团队里维护。
@姚志坤：是的，这个聚类可以作为团队管理，至于微服务到底怎么划分粒度的问题，如果团队内能达成共识最好，越小越灵活，越大越好管理。
@彭鑫：看来微服务之上还可以考虑更大粒度的“模块”。
@姚志坤：一些大规模使用微服务的公司是有这样“服务域”的概念了，做整体的管理。
Question 3
主持人：您所在的企业或者您所了解的企业是如何分析和利用相关数据来进行软件开发效能评估和改进的？具体会将软件开发效能分析结果应用在哪些地方？
朱少民：
如何分析和利用相关数据来进行软件开发效能评估和改进的？简单回答，还是从目标出发，回到目标，为业务目标、研发目标服务，来衡量和目标的差距，以及向目标努力的过程中存在哪些问题？如同刚才说的，反馈回来，形成闭环，这中间也包括根因分析，通过数据（现象）看本质。数据也可能会给出错误信息，需要洞察进去，了解是数据问题，还是研发的问题。基于数据，相对客观地发现问题，而且是量化的，问题的大小、进步是否显著，相对准确，这样更有利于衡量行动或策略的效果，更有利于效能的评估与改进。
如何分析？如果谈起来，会很长，之前有老师写了几万字的文章。简单说，加强数据多维度、多层次分析，如溯源分析、因果分析、聚合/分类分析，不断下钻深入细节。
具体会将软件开发效能分析结果应用在哪些地方？来自哪里就应用到哪里，并向上游延伸，下游的数据往往能反映出上游的问题。需求、设计、代码、测试、运维 各个环节采集到的数据，一方面可以用于自身环节的改进，另方面也能反映出其它环境相关的问题，这取决于构建了怎样的质量模型、效能模型......
茹炳晟：
主要还是围绕Google DevOps Dora报告的四个指标，同时结合一些过程指标，最终目的是发现问题，而不是为了数字上的度量。质量数据用来判断当前的测试策略是否有效，效能数据主要用来判断系统研发过程中的瓶颈点。
观点讨论
// 深入数据分析 //
@彭鑫：数据分析维度越多、联系越多、挖掘越深，数据越难被操控，结果更能体现效能和价值。
林志强：
就软件效能提升来看，一般可以基于生产力三要素来看的，即生产者，生产过程，生产对象，那么数据驱动能否让“开发者”更好？让“交付过程”更好？让交付件更好？比如，交付件我们定义了32个软件对象，我们的方法叫OPAG（欧佩克，
object/presentation/analysis/governance）。首先得有目标，先定义好评估与改进的方向、目标、场景。然后是表征，基于对象建模（比如API这个对象的调用量、质量、总量等），分析对象演进过程，最后是治理（优胜劣汰），形成价值闭环。
我们认为数据驱动的核心是“驱动认知，知行合一”。
石雪峰：
软件开发效能评估本身是个比较宽泛的话题，从不同视角切入，或者从满足不同用户需求的层面来说，得到的结果也不尽相同。比如从管理者视角来说，他们更加关注资源投入的有效性，资源投入的分布，资源投入产出比，并且根据某几个核心度量指标来衡量团队的效能水平。那么自然效能评估的管理对象典型的就是需求、工时、收益达成率等，或者是某些符合当前业务场景下的效能指标，比如单位订单成本等。
从团队管理者视角出发，他们更加关注团队的交付能力，交付效率，交付质量等，这往往就导向了几个业界经典的结果指标，比如变更前置时长，部署频率，交付周期，部署失败率，线上缺陷密度等。这些指标被量化后，往往就代表了团队效能水平，也容易导致内卷。
从开发者视角出发，效能评估的关注点可能是如何提升和改进一线开发者效率和体验，比如典型的开发打断率，开发平台使用率，甚至开发者辅助，沉淀企业智库等等，这里有很多有想象力的空间。举个小例子，比如我们就做了函数方法命名的插件，逻辑上也是基于数据的分析统计，简化函数方法命名的历史难题。
观点讨论
// 开发者视角的效能提升 //
@石雪峰：我们做了函数方法命名的插件，逻辑上也是基于数据的分析统计，简化函数方法命名的历史难题。
@彭鑫：函数方法命名的插件：这个推荐的方法名采用率高吗？
@石雪峰：是的，出乎意料的接受度很高，这样也能降低研发的认知负荷。
夏思雨：
我们在做效能评估的时候，会尝试收集尽可能多的数据，包括代码，提交记录，持续集成/持续部署流水线，需求管理，运维指标，运行时的追踪数据， 甚至大家的会议，汇报邮件的信息等等。分析的核心思想在于从构建一个高效能团队的角度出发，结合团队的人员结构，分工方式，工程实践，软件架构，日常活动等，系统性地看待软件开发中涉及到的各种因素。这其中，开发人员是非常重要的一个因素。任何忽略开发人员体验的措施，对软件研发团队都是不可挽回的打击。
效能分析的结果，包含工程实践的评估，团队产能的趋势，软件架构的问题发现，团队结构和沟通结构等。在这个结果中，我们会更看重结构性的分析结果，原因是第一数据不容易被操控，不容易跟KPI关联，第二更能覆盖全局。将易于获得和统计计算得出的过程指标作为辅助改进的手段。
这些分析结果主要用于团队结构调整，分工模式，架构调整，工程实践改进，运维策略制定等等。
姚志坤：
作为平台团队，我们做到：
构建了相对统一开放式的研发数仓的中台能力，定义了标准的原子数据集，形成了星座型的多维数仓，负责管理这些数据的时效性和准确性，
提供了相对全局、通用、抽象的数据度量表单，例如价值流模型视图、通用Leadtime视图、构建成功率视图。而各个业务线团队可以根据业务实际的需求来生产和消费这些数据，再封装一些业务专用的数据视图。
一般来说，我们的业务会根据实际的需要来构建一些自己的度量数据看板，最终都是需要做一些改进为目的，分为效率导向和质量导向的数据。效率常见的有需求leadtime、各阶段leadtime，用来驱动一些研发流程协作效率的改进，通常项目经理推动大家调整合理的角色协作流程、需求流转的节奏、发布周期等；质量导向常见的有覆盖率、拦截率、回滚率、稳定性，用来驱动增加一些质量卡点，通常QA推动大家调整一些质量管理的准入标准、策略和卡点。
孟国军：
我这边补充也是闭环和迭代：数据线上化后进行效能评估，需要根据关注方向制定有效评估模型，评估模型一般会选取直接影响因素或导向性因素，然后进行数据加工，不断迭代输出评价指标。在实践过程中常常会选取合适的值作为基线指标，以基线目标规划目标或关注效能改进期间提升的幅度。研发效能具体应用包括评估交付质量、交付效率、过程质量、协同问题等等方面，更多通过指标感知变化->挖掘产生变化的深层次原因->针对性优化->观察效果，闭环提升研发效能。
林帆：
我认为正如朱老师所说，研发效能改进的关键是在于及时反馈和场景闭环。比方说研发的场景，我们开发了一款Cosy代码智能补全插件（https://developer.aliyun.com/tool/cosy），它能在开发者写代码的时候，感知编码结构和上下文，从而自动推荐最合适的代码段，这就是一种非常及时的效能提升方式。
再比如各类研发数据报表，除了自己去看报表，我们有一种内部做法就是数据订阅和钉钉推送，以及邮件推送，具体推送的内容就非常丰富了，团队近期的研发活动情况、项目的进展情况、经常翻一翻邮箱就会有一些及时的惊喜。
Question 4
主持人：当前企业在软件开发效能评估与改进方面存在哪些误区？如何避免这些误区？
朱少民：
这可以参考张乐老师写的文章：《软件研发效能度量之十大反模式》，感觉比较全了。
茹炳晟：
我之前写了一篇文章：研发效能度量引发的血案：
https://www.infoq.cn/article/bd47xfxWLfFf6GfNg0U0
姚志坤：
有以下误区：
1. 数据源采集的问题，早期字节存在各研发过程的平台数据口径不统一、噪音多的问题，数据度量最需要避免源数据不准、上下游不对齐，错误的数据把度量变得无效。后来我们通过统一数仓解决了这一问题。
2. 局部优化的问题，这是常见的问题，效能DevOps都强调全局最优，而且很难构建一个全局最优的效能指标来衡量效能，所以很多团队经常就是看一个问题定一个指标，过度优化它，结果影响了其他指标，比如发布频率或测试覆盖度。针对该问题，我们最近也在构建VSM价值流模型，来尝试从全局视角、以需求为视角来刻画价值过程中的损耗漏斗模型，来回答全局优化的问题，尝试解释很多效能改进的此消彼长的难题；还有一个办法就是制定多个指标来平衡局部优化的难题。
3. 改进项不明确的问题，本来是为了达到某个改进的目的而制定的评估数据，变成考核的工具后，这个数据也会变得无意义了，解决方案更多是倡导业务灵活制定合理的数据度量，保障数据度量都有改进措施，关注趋势而不是绝对值。
林志强：
结合前面大家谈的：
误区1. 指标驱动，度量用于考核；结果是度量什么，得到什么。
误区2. 没想清楚就干，陷入所谓的“大数据”，却说不清目标、应用场景；同时，低效收集大量数据，对开发人员工作形成干扰。
误区3. 数据质量问题；可以追溯到数据的产生过程，比如代码中存在大量模糊的概念、定义，命名不规范的问题，检视意见缺失或者文本描述不清晰的问题；这类问题想要通过后期的数据挖掘、分析、处理，或者建立知识图谱等去尝试理解语义，因为系统中大量无效的信息和知识，费了很大力却不一定能解决问题。
石雪峰：
我来跑个题，类似的效能度量避坑指南应该有很多，各位专家也都提供了一些思路，我想从数字化的思路分享我过往的一些看法。首先，数字化让很多事情变得可量化，当一件事情可以被数字描述的时候，就具备了可比较的基础，无论人是否嘴上说什么，实际上每个人都会被数字吸引，暗自里进行比较。往往那些无法比较的区域，反而是一种安全区，就像是小朋友童话中的树洞一样，可以让人进去躲藏一段时间，回复一些能量，再出来作战。这可能就是心灵的港湾，也是心中的城堡。
那么，如果一个人的生活中只有数字，或者只追求数字，那么他就会非常焦虑，打破这种焦虑的方法，可以是创造一个新的赛道，从另外一个赛道来获得认同感，自信心和能量。比如，一个人可以学习不好，但是在篮球、情商等方面非常出色，他也能很容易的融入集体之中。那么创造这个赛道的能力，一方面来源于自身，另外一方面也来源于外部环境。在过往物质生活没有那么丰富的年代，人们的方向性很明确，就是要改善生活水平，但是路径不清晰，但这也就意味着有无限的可能和机会，所以人整体上是昂扬向上的。但是现代人面临的情况是，路径很清晰，比如毕业后就要公务员、大公司、创业，可选择空间和赛道非常窄，而人们在追求赛道的时候往往又失去了方向和意义，导致了内心的压抑和空虚，进而带来心理上的问题。
观点讨论
@石雪峰：我比较担心的还是数字化带来的开发者心理健康问题，可能想的有点多，但是在这个内卷的时代，每个参与研发效能度量的人都需要找到自己的初心吧。
@彭鑫：一个问题是，数据分析只能产生数字吗？是否可以产生更加丰富多元的结果？就像医生看病后得出的可能是一个综合治疗方案，甚至包括心理安慰。具体到研发数据分析，有时候雷达图可能就比单纯的数字更能反映问题。
@朱少民：初心很重要，价值看得准，目标务实有效，是避坑指南。
@茹炳晟：度量的本质是发现和暴露问题，不是数字游戏，这样想是不是会缓解焦虑。
@石雪峰：这需要一个过程吧，就像那句话，不看数字是可怕的，只看数字更可怕，所以避坑指南就是不忘初心。
夏思雨：
我觉得最值得一提的是，效能度量中出现的量化结果和KPI的关联，导致了开发人员操控数据问题的出现。往大了说，这是文化问题。管理上的懒政，在改进措施上忽略了开发人员的体验和团队认知负载。导致了“上有政策下有对策”的又一经典场景。
我们始终支持的方式是通过长期趋势和结构性的度量，来判断改进措施的有效性。通过度量这个动作，促使团队在工具使用，代码规范上，流程上形成轻量级的标准，一方面有助于知识传承和系统的可维护性，另一方面提供了根据有效数据分析改进再度量的闭关的能力。我所说的结构性度量中，包含了由于分工所形成的团队结构，由流程决定的沟通结构，以及代码中实际出现的软件架构的边界，构成的三角形，三角形的核心就是认知负载。这个概念在高效能团队一书中有提到。
观点讨论
@林帆：其实最大的误区就是滥用。要么是贪多，没重点什么都想囊括，要么是过度依赖，尤其是用于对人进行评价的时候。
@彭鑫：是的，主要问题是滥用。所以研发效能分析有时候可能像医生看病，检查指标很重要，但也要结合病人生活背景和病史等方面做出综合判断。
@石雪峰：这就涉及到统计学的典型问题了，TypeI error以及TypeII error，也就是假阳性和假阴性，当我们追求一个指标最大化的时候，往往另外一个指标的误报率就会很高。比如医生看你的指标判断你得了重病，本因是他想降低TypeII的假阴性概率，最后结果就提升了假阳性的比例，结论就是数字是会骗人的。
林帆：
就目前而言，可供用于效能评估的研发活动主要是编码、发布以及项目管理这些“可数字化”的部分，它们占整个研发生产活动的比重其实不算高。而且指标反映的大多是表面结果，比如代码写得好不好、发布频率高不高、完成的需求多不多等，而背后的价值体现并不容易量化，结果往往只会导致大家一起内卷。我们需要去了解每个指标背后的含义，以及适用范围。
孟国军：
跟大家认知差不多：
1. 指标论，指标用于考核而非治理，导致一线同学认知上走极端，举例：千行代码缺陷覆盖率作为考核指标，研发对提交缺陷会比较抵触，出现互相推诿等现象。需要明确效能指标更多是风向标，用于反馈实际的情况，挖掘潜在问题，不断迭代优化；
2. 短期论，研发效能治理是一个持续过程，随着业务、研发架构、产品架构变化，研发效能问题更加复杂，短期治理不能解决根本上问题，需要针对性持久化治理。
3. 简单论，主要体现在管理者对于研发效能不重视，只关注数据变化，缺少体系化治理实践。
Question 5
主持人：软件开发数据分析与挖掘是软件工程领域的热门研究问题。从企业软件开发效能提升的角度看，软件开发数据分析与挖掘还存在哪些问题和挑战？未来相关技术将向什么样的方向发展？对于学术界在相关方面的研究有哪些建议？
夏思雨：
相对于商业数据分析来说，可使用的研发数据的维度，数量都偏小型。小样本数据中如何提取出更精确的结论，是对数据分析能力的挑战。而且对研发效能问题的洞见，目前来看即使通过数据分析的手段，也依然需要很多的先验知识和经验来识别问题。这些经验如何能够固化下来。通过算法或者模型分析结果，直接提供洞察结果和改进建议给团队管理者或者技术负责人。对人的挑战在于，熟悉数据分析技术的人不了解软件工程，而软件工程领域的具备专家知识的人又不熟悉数据分析与挖掘的技术。这个其实来自于跨学科的技术应用的普遍问题。
对未来软件开发数据分析和挖掘方向，我个人有一个不成熟的想法，比如过程挖掘这种技术，是否能够用于挖掘研发过程的流程，做相关性分析，对基于流程挖掘的模型对研发过程的流程进行改进。按照过程挖掘之父Wil van der Aalst 的说法，process mining是指从现有事件日志中挖掘知识以发现、监控和改进实际流程。那这种技术，是否有助于我们通过各种事件日志，活动记录，来建立研发过程模型，给出更有深度的关于流程提升的建议。
观点讨论
@彭鑫：从现有事件日志中挖掘知识以发现、监控和改进实际流程：个人感觉，软件研发过程中的事件日志是围绕复杂的软件需求和设计以及人的行为产生的，这就使得这些数据的分析比物理设备或软件系统运行产生的日志更复杂。
@夏思雨：是的，从原理上来说，简单系统控制不了比自身复杂度高的系统。所以对数据分析技能有很高的挑战，实现方式倒不一定需要过重的平台。
朱少民：
业务非关联性（如开源代码）的研究比较多，学术界在需求、设计等研究很少，但这更重要。如何结合需求或业务来推荐代码、发现缺陷、缺陷定位，很有挑战。希望能和企业一起合作，研究：
业务价值模型、（设计/代码/测试）技术负债模型；
新应用领域、新架构下应用软件规模度量方法；
效能预测模型。
林志强：
软件领域的主要挑战和40年前没有根本性变化，仍然是布鲁克斯说的：复杂度，一致性，可变性，不可见性的问题。特别是软件应用，软件服务，软件规模越来越庞大，需要重点关注软件架构，软件标准化，软件可视化等方面的能力建设。每一次增量开发，不只是增量功能，更重要的是增量设计，形成可演进的软件知识架构。
未来方向建议以下几点：
以开发者为中心的精益协同服务；
面向对象的软件知识图谱；
软件知识的演化和复用；
数据驱动“生长型架构”。
林帆：
我觉得核心挑战还是现实研发活动的信息量巨大，目前普遍被利用的信息主要还是被高度抽象过后的指标，但如果只是简单的统计代码行数、完成的需求数这些数值，往往就只能发现很表面的问题。
比如对代码的分析，既然每行代码是具有特定作用和含义的，我们完全可以深入到语法的层面对每位开发者所承担的功能模块、编码的习惯进行探索，从而更全面的了解开发者之间的分工是否合理、质量是否稳定等等。再比如对项目交付过程的分析，除了基于统计方法的进展、趋势曲线图以外，如果能对更多的中间过程以及每个人的角色进行分解，也能发掘出更多的信息，比如项目流程是否规范、各个项目成员的成长、成员的流动性和补位情况等等。
但这就需要大量专业领域知识和算法知识来完成，这些都是产业界和学界可以共同努力的方向。
观点讨论
@彭鑫：开发者画像。这个可能比消费者画像更难。
@林帆：是的，代码本身包含的信息量比像购物行为流程这些要大得多。
@林志强：古代的书同文，文同义太了不起了。是高效解决软件数据之道。数据到知识是个艰难的过程。
孟国军：
1. 挑战：（1）产研流程复杂性，数据线上化标准会有差异；（2）很多数据仍然依赖手工填写，成本和填误率比较高；（3）底层数据获取能力有待提升（如代码维度）；（4）指标反馈可解释性不强，深层挖掘能力不足，缺乏指导向性。
2. 技术方向：自动化、智能化。
3. 学术研究：代码智能（源码分析能力、源码质量）、智能化测试、智能化运维、智能化度量。
石雪峰：
很现实的说，目前业界非常欠缺这样一类人才，他们一方面既精通研发效能领域，对于工程实践、工具、研发过程等有深厚的知识，同时另外一方面，他们对于数字有极高的敏感度，兼具数据分析，数据测试，甚至算法能力，大数据能力，智能化能力。可是反过来说，我们是否真的需要这种全能型人才，或者是否只要这种人才才能搞定这个事情呢，答案显然不是这样的。
姚志坤：
1. 我们最近在实践VSM价值流模型，其实也是要解决如何全面通用地刻画研发效能的难题，我觉得是一个方向。
2. 另外，因为效能数据的复合性，是否可以借助AI智能的手段去辅助决策，难点可能是训练样本不一定足够多，毕竟定义高效能和低效能的标准就比较模糊（这点比较像AI医疗）。
参考链接：