光环：软件研发效能特征与度量——王一男

摘要：文章内容主要来源于光环国际2022年第三届中国科创者大会王一男老师的分享，原分享名称为"研发效能大数据管理与应用实际"。通过将软件研发和制造生产进行横向比较，得出软件研发是一个劳动密集型工作。软件研发也具备自己的特点，研发过程中又依赖于每一个软件人员的创作力和工匠精神，以此来达成更好的产品。
1、虽然很难通过数据去度量软件效能，但是不影响通过数据去驱动软件研发效能的提升。
2、让团队自己去上报问题，通过解决问题去提升效能，规避盲目的给一标准而围绕“标准”去提升效能。
3、软件研发效能不能度量，但是可以通过数据不断去改善方法和工具，以此从基础上整体去提升研发效率 。

什么是敏捷？敏捷是不断的变换。研发的敏捷就是迭代，在固定的周期之内，去做一些固定的事情；产品的敏捷就是在产品设计、业务发展上紧跟客户的需求，紧贴着解决客户问题去做；业务敏捷就是和客户紧密的沟通，跟着客户的需求变化而变化。只有业务敏捷起来后，才能驱动迭代，进而使产品不断的发展、不断的壮大。

在做研发敏捷、产品敏捷、业务敏捷这些都离不开数据的度量。做度量就需要用到 AI、大数据、云计算。这里分享研效大数据建设的经验和数据如何去驱动、提升研发效率。

---

一、研效大数据平台建设经验

为什么要去做数据度量，这是一个恒定的问题，仁者见仁智者见智。

1.1 研发效能度量的逻辑

研发效能的度量主要原因有，我们在研发过程中会遇到各种各样的问题，因为研发是不同人员、不同需求项组成的。所以，面临的问题也是不一样的。有的时候我们是怀疑这个研发团队有问题，有的时候是真实确认这个研发团队有问题。怎样去解决这些问题了，这个时候度量问题就是一个好的选择。

成功度量问题以后，就可以通过经验、方法、工具去解决问题。在解决问题的过程中，就会去观察这个问题有没有真正的解决，或者是缓解。这个时候就是数据驱动，用数据的方法证明问题已被解决。在问题被解决或缓解后，又会遇到新的问题，一个周而复始的循环。在循环的过程中，问题一一被解决后，就会发现组织的效能是一个螺旋上升趋势。这个过程中也沉淀了如何提升研发效能的指标、工具、平台。

研发效能的度量可以和传统行业做一个区别比较，就会发现软件研发和传统行业有相识之处和软件研发独具的特点。

• 软件研发是劳动密集型的工作
• 软件开发也依赖每一个开发人员的创造力和工匠精神，这和其他劳动密集型工作不一样

传统行业的流程问题、管理方法问题也都依然存在于软件研发里面。比如怎么管理好这一堆人，怎么让所有人目标达成一致，前后的工作项有条不絮的开展下去。

与传统行业一个很大的不同点，软件研发还依赖与每一个软件开发人员创造力和工匠精神。所以要在劳动密集和个人创造中找到一个平衡点。

1.2 研发团队度量仪表盘

在很多互联网公司，小团队（5~7人）中通过leader持续的沟通，由leader去承接上游的工作项，再依据每一个成员能力差别合理的去分配工作内容。以此做项目管理工作，通过每日站会就能推进项目达成。大团队中leader很难去对每一个人沟通了解其能力，从而去激活创新和工匠精神。这个时候leader就需要采用仪表盘去做整体度量。

在大多数软件行业的仪表盘都是如下图，度量软件研发的产出。在度量产出后，会进一步去度量效能，主流方法有：从一个需求开始到结束需要多久，中途有没有什么卡点，什么状态下出现卡点。在每一个团队的流动效率、周期时间、速度、质量都度量出来后，管理者就容易做一个团队排名，使团队“内卷”起来。

随着从事软件研发效能度量工作时间增长及工作经验的增加。产生了软件行业的报表在其他行业可以怎么运用的想法。后续发现传统行业和软件行业都是大同小异。比如麦当劳（下图左侧）客户选择食物后，就会形成一张卡片，然后开始计时，在后厨加工完成后，卡片就会右移停止计时表示完成；工厂流水线（下图中间）生产展示出不同团队、不同生产线的数量，展示同昨天、今天的速效比，成员排名；工厂流水线（下图右间）展示出月计数达成率、出勤、质量情况。

可以看出在传统行业里面度量仪表盘，也是产出、速率、质量、故障度，也做流动效率周期时间，排名。软件行业度量应该借鉴传统行业的方式方法和理念。此方法存在的问题是没有找到软件同属密集型和个人创造型的平衡点，更多是看到劳动密集型的团队管理，对个人创造能力、工匠精神没有数据体现。

1.3 研效度量系统全景图

研效数据相对较复杂一些，因为他有一些自己的特点：数据量大，数据源头多，数据结构复杂，数据归属难，数据缺少基准，数据流通有安全风险。

1、数据量大

连锁数据多，比如一个代码提交，对应会产生评审、自动化的构建、编译、扫描数据。如果关联到需求，那么需求也会有新数据产生。

2、数据源头多

按工具分类包含项目管理工具、代码管理工具、流水线工具、代码分析工具、测试工具等一系列工具。这些工具产生的数据格式不一样，采集方式不一样。

3、数据结构复杂

如果度量一个需求，这个需求在数据库表中有标题、负责人、状态，其中负责人、状态、状态变更记录、附件等等又会是新的表，相互间通过表与表的关联关系去连接。

4、数据归属难

数据如何归属到团队上、个人上，数据属于生产者还是使用者？

5、数据缺少基准

度量需求开始时，什么叫做需求？对于一个需求，不同开发团队所需要的周期是不一样的，主要因为大家对需求的理解、颗粒度的理解不一样。即使是同一个团队，在不同的时期内也不是同一个标准。这种情况下，上面在度量工作，但是下面的根基是不稳的。所以在做度量的时候，一定要做好基准，一层一层的加盖。

举例：大家是怎样去计算代码行？新增代码行 = |新增| + |删除|，或者新增代码行=|新增(去除空行、注释)| 。

6、数据流通有安全风险

国家在加强监管，当前互联网都在积极响应，对用户数据、行业数据都被标记成隐私数据，纳入监管，保证数字安全。研效数据也要绷紧弦，研效数据里面同样包含很多敏感、重要信息。比如有的可以下载代码库名称、路径，这样会导致架构、团队组成暴露。

怎样去优化上面的问题了，腾讯基于研效数据的特点做了一个产品架构图，针对性的做出了解决方案。

1.4 小结

研效数据挖掘水很深，过程中大家要多思考，持之以恒。

---

二、数据驱动研效提升的方法

软件研发效能是否可以精确度量？如果不去度量他，就无法改变他；不去度量他，就无法改进他；不去度量他，就无法管理他。

效能如何去度量，制造行业里：效能 = 投入 / 产出。

2.1 研发效能度量的2个制约因素

软件效能度量主要受限两个因素

1. 软件研发无法定义计件标准
2. 软件产品价值难以衡量

当前对软件标准有采用用户故事，对用户故事的点数、工时定义成一个标准件，但是产出在很多时候跟用户故事还是有出入。

2.2 数据提升研发效能的3条有效路径

虽然很难通过数据去度量软件效能，但是不影响通过数据去驱动研发效能的提升。

1、辅助方法和工作落地

找到一套符合自己的研发工具，围绕这套研发工具做实践。制定好对应工程规范，用数据去度量工具的落地情况。主要度量这个工具用的好不好，不是这个工具的结果好不好，再通过数据去落地，推动大家使用工具、用好工具。

2、解决团队实际问题

最好的方法是让团队自己去上报问题，通过解决问题去提升效能，规避盲目的给一标准而围绕“标准”去提升效能。

3、驱动方法和工具的持续改进

通过数据不断去改善方法和工具，以此从基础上整体去提升研发效率 。

---

三、在线答疑

1、代码质量怎么度量

答：2个维度，一个代码本身的质量，另一个是产品的质量。
代码质量：目前市面上有很多这方面的代码质量检测工具，平台。比如SonarQube、Kritika、DeepScan、Klocwork、CodeSonar、JArchitect、Bandit、Code Climate、Crucible、Fortify、Codecov。
产品质量：产品的质量更广，主要看客户反馈、产品的商业成功、竞品和竞品的比较。

2、感觉大公司的平台更完善、成熟，小公司的相对次之

答：不要迷信大公司的工具，大公司工具主要解决规模化的问题。大公司工具有很重的流程，卡点去保证大家代码一致性和可维护性。小公司相对跑得快，创新性比较高，可能更适合小公司。一切都以解决问题为主，不论采用何种方法和工具。