软件开发生效团队的效率评估与提升是每个技术团队管理者面临的难题。这里有两个关键点：
- 意识：团队当前处于什么状态？
- 改进：如何让团队变得更好？
测量与监控：不测量就无法改进
在尝试改变之前，最关键的一步是确定从何处开始。效率不仅仅是完成大量工作或编写更多代码，而是在生产环境中交付高性能、无缺陷的产品；编写简洁且易于维护的代码，并提供可持续的开发环境。当我们专注于效率时，可以在以下四个主要类别下跟踪指标：
- 开发质量与效率
- 测试质量与效率
- 部署流程
- 生产质量
您可以在下表中的主要类别下找到可参考的示例指标。
通过这些指标，可以衡量开发方式、使用的实践方法、测试覆盖范围及其效率、部署流程的健康程度以及产品在生产环境中的稳定性。您可以根据所使用的工具和方法论来增加这些指标的使用。
指标与示例
开发指标
开发过程越好，测试和运维团队承担的工作量就越少；应用程序的测试和生产错误也会相应减少。此外，善于运用软件开发实践的团队能够拥有可持续的代码、易于维护和管理的系统。
代码行数（Line of Code）：指开发人员在特定时间内编写的代码量。该指标单独使用时意义有限，但与其他指标结合时，可成为有价值的评估工具；若将代码行数与复杂度一同考量，便能得出更具意义的结论。
示例值：两周的开发周期产生800行代码。
复杂度（Complexity）：可视为独立于代码行数的算法对应度量。代码中每出现一个 if、else、for、while 或其他方法调用，复杂度值便增加一。因此，编写了 500 行代码的开发人员其复杂度值可能为 100，而另一位开发人员则可能高达 200，这表明后者在算法实现上更为密集。
示例值：1000行代码中可存在200的复杂度值。
技术债务（Technical Debt）：指修复代码中缺陷所需耗费的时间。这些缺陷通常通过 SonarQube 等静态分析工具发现，相应的努力程度也由这些工具自动计算得出。
例如，将使用System.out.println代替日志记录的一处问题定义为轻微错误，并由Sonarqube给予2分钟的修复时间。这些用于修复错误的给定时间的总和即表示技术债务。
示例值：18小时22分钟的技术债务值
单元测试覆盖率（Unit Test Coverage）：以百分比形式表示已编写单元测试的代码比例。此处使用“行覆盖率（Line Coverage）”和“分支覆盖率（Branch Coverage）”两个定义。行覆盖率显示测试实际执行的代码行数占比；例如，若对 500 行代码中的 400 行编写了单元测试，则单元测试覆盖率为 80%。分支覆盖率则关注是否涵盖了 if、else、for 等内部逻辑分支，而非单纯统计行数。
示例值：单元测试覆盖率为60%
圈复杂度（Cyclomatic Complexity）：在提供复杂度大小值的同时，圈复杂度给出的是复杂性数值。复杂性越高，阅读或维护代码就越困难。业界公认的一个事实是：圈复杂度较高的代码出错概率也更高。每个 if、case、for 等代码块都会使圈复杂度值增加一。圈复杂度通常按函数级别给出，且业界普遍认为圈复杂度超过 10 是不可接受的。
示例值：0–10被认为是可接受的圈复杂度（Cyclomatic Complexity）值。
重复率（Duplication）：指已编写代码的相似程度，也可被视为复制粘贴代码的比例。该值过高会在可重用性和维护性方面带来劣势，导致高重复率应用的替换变得困难。同时，高重复率会负面影响代码行数统计；例如，若 1,000 行代码的重复率为 40%，则表明其中大量内容是通过复制粘贴而非原创编写完成的。
示例值：重复率为26.5%
代码审查（Code Review）：虽然我们可以让代码经过静态分析，但由于规则存在局限且难免有疏漏，因此仍需由其他开发人员或团队进行审查并发表评论。通常，代码审查过程会准备一份审查检查清单（review check-list）。
重构实践是指在不影响代码功能的前提下，通过重新组织代码使其更易于阅读和维护；它有助于我们识别在快速编码过程中容易遗漏或难以理解的步骤，而制定重构检查清单则是预期中的首要步骤。
安全缺陷指的是在DevOps或SDLC流程中使用的安全工具所报告的安全漏洞数量；除了编写正确、可读且符合预期功能的代码外，编写安全代码同样重要，该过程有助于我们了解哪些人导致了安全错误。
测试指标
测试环境具备足够的成熟度意味着产品在进入生产环境之前具有足够的质量。此外，通过持续且数量充足的测试运行，反馈越频繁，团队就能越早发现潜在错误并采取预防措施。
测试覆盖率是指功能测试覆盖产品所有功能的比例；该比例并非仅由自动化测试构成，手动测试也可纳入其中，但应以风险百分比而非数值来呈现。
例如，在1000个场景中运行300个场景，可能为您提供70%的覆盖率。风险计算可以表示为“错误概率 × 严重程度”，或直接表示为“错误成本”。在这种情况下，一个场景可能具有4个风险值，而另一个场景可能具有20个风险值。
自动化覆盖率显示有多少测试是通过测试自动化执行的，期望的是尽可能将测试自动化以频繁执行并提供持续反馈。
CI/CD集成：指测试过程的CI/CD集成情况，由于该过程若依赖人工操作且需持续运行则较为困难，因此更期望实现其CI/CD集成而非仅靠人工纪律。
性能测试表明应用程序不仅应从功能角度进行测试，还应从性能角度进行评估，并在关键绩效指标（KPI）达到预期水平后才应部署上线；即使代码编写精良且在功能上无任何错误的产品，在高负载下也可能无法响应，这会阻碍您实现预期的收入目标和保证的客户体验。
集成测试也被称为系统集成测试，在此阶段应测试与产品集成的所有产品的场景。
测试执行次数：测试的目的是在客户察觉之前，就潜在的功能性和非功能性错误向团队提供反馈；反馈越早，行动就越迅速，从而防止错误扩大；每两周执行一次的测试对于提供反馈而言过于缓慢，因此如果错误超出预期，您可能没有足够的时间来解决它们；目标应是首先每日执行测试，随后按提交次数执行测试。
测试数据管理指出仅使用固定数据执行测试不足以发现错误，应使用不同的数据集测试可能出现的不同情况，并通过使测试数据动态化来管理一次性数据。
部署指标
DevOps 指标用于提升 DevOps 流程中每个步骤的成熟度。随着 DevOps 成熟度的提高，能够产生更可靠且无故障的产品。如果将这些过程完全交由个人自行决定，可能会导致流程中的任何步骤被跳过，或者当拥有决策权的团队成员离职时引发问题。
自动部署：表示严格按顺序执行每个步骤而不跳过任何环节，这要求执行该流程的团队具备较高的成熟度。
部署次数：部署次数高的团队在DevOps流程中持续执行步骤，从而实现持续的产品发布，这既为业务部门提供了持续的反馈，也赋予了他们在出现潜在错误时采取早期行动的选择权。
部署时间：较长的部署时间会导致反馈延迟，同时迫使团队将精力用于跟踪流程而非开展其他工作，因此期望采取相应措施将这些时间降至最低。
生产环境指标
从开发环境的改进到测试成熟度的提升，这些投资最重要的成果是改善提供给客户的服务。我们的建议是：有效利用 New Relic、Dynatrace、Appdynamics 等 APM（应用性能监控）工具。通过这种方式，您可以对生产环境进行度量，以趋势形式跟踪变化并进行优化。
平均响应时间：指应用程序的响应速度，可通过APM进行测量，尤其建议用于分析服务器端所花费的时间；对于性能良好的应用，期望响应时间在1.2秒以下，而低于4秒则被视为平均水平可接受。
错误率：表示应用程序在服务器端的错误比例，可从APM获取，该比率较高表明服务器端持续出错，期望通过APM定位并解决这些问题，将错误率降至最低水平。
业务事务：指应用程序中的重要操作，通常由APM提取，如购买、完成预订等重要业务流程，期望其成功率接近100%，建议对其进行单独报告以进行跟踪。
漏斗：指代一个流程，并能帮助我们报告导致成功率降低的错误或问题，例如可以端到端地审查订单场景，从而发现任何阻碍流程完成的问题。
渲染时间：即使应用程序的响应时间达到足够的性能水平，页面在浏览器上的处理时间也可能过长或出现错误，在这种情况下我们可能会忽略用户看到的页面加载缓慢现象，这可以通过APM的客户端模块或不同的客户端分析工具进行分析并优化，最常见的问题包括：
- 尺寸过大且未优化的图片
- 过多的 DOM 迭代操作
- CSS选择器和文件体积异常偏大
- 过度依赖第三方库
- 项目未针对移动端进行适配设计
- 算法设计不当的循环结构
- 未及时更新过时技术
崩溃率：指移动应用中导致应用程序关闭的错误所占的比例，期望将这些错误控制在最低水平。
Apdex评分：是一个介于0.0到1.0之间的生产质量评分，根据响应时间和错误计算得出，计算公式如下：（良好响应时间 x 1.0）+（可接受响应时间 x 0.5）+（不可接受响应时间 x 0.0）+ 错误事务 x 0.0，然后除以总事务数。
指标监控
指标应对开发团队、管理人员及团队成员保持透明。最关键的一点是团队能够就指标进行讨论。对于敏捷团队，可使用燃尽图；对开发人员，可使用Sonarqube仪表盘；对运维和团队整体，可使用APM仪表盘等替代方案。那么，与其使用多个不同的仪表盘分别跟踪各项指标，不如将所有指标整合到单一产品中统一监控，您觉得如何？通过QA Dashboard，您可以将所有这些指标在同一个仪表盘中进行跟踪。
通过QA仪表盘，您可以连接到Sonarqube、Git、Jira、Azure DevOps、New Relic、Dynatrace等多种工具，为项目、团队和个人创建仪表盘；并通过针对团队和管理层采取沟通行动，使他们保持最新状态。
我们特别建议采用敏捷模式的团队将此类仪表盘和指标纳入每日站会和回顾会议中。
例如，上述仪表盘中展示了来自Sonarqube、Git、Azure DevOps、New Relic等工具的信息。这使得您能够在同一屏幕上查看所有信息，从而实现更有针对性的工作。
仪表盘左侧显示了来自Sonarqube的技术债务（Technical Debt）和单元测试覆盖率（Unit Test Coverage）信息。下方则展示了来自New Relic的平均响应时间（Average Response Time）和错误率（Error Rate）信息。通常情况下，在回顾会议上，您需要从不同的仪表盘中单独查看并报告所有这些指标。您可以以每周或每个冲刺（Sprint）为单位讨论这些指标并与团队交流。目的是在每两周的开发、测试和生产环节中，讨论做得好的地方以及可以改进的地方。
监控指标的目的并非给团队施加工作压力；相反，它是用数值来明确团队当前所处位置以及期望达到的目标。例如，当团队开始思考“我们的应用质量应该达到什么水平”时，能够访问相关指标并看到目标至关重要。否则，各团队可能会只关注那些适合自己或最容易达成的数值。如果没有单元测试覆盖率的明确目标，大多数团队成员可能就不愿意编写单元测试。
应确保团队明确其目标位置，并在规划中确定需要将这些指标提升至何种水平，以及在回顾会议上检查实现了多少目标。我们建议在此类流程中引入QA Dashboard等产品，这将带来显著益处。
这些仪表板中另一个重要功能是开发者记分卡（Developer Scorecard）。记分卡为团队成员提供了一个客观的环境，使他们能够监控自身绩效并查看与目标的接近程度。例如，在与开发人员经理交谈时，可以利用自己的记分卡；团队领导也可以基于记分卡清晰传达其下属开发人员的效率及需要改进的方面。
提升质量
提升产品质量确实可以通过这些指标来衡量。我们在这方面还有几项行动建议。我们该如何提升团队的质量？
不要放弃敏捷流程
由于向敏捷流程的转变需要文化上的变革，因此这一过程并不容易。尽管团队初期可能会表现出抵触情绪，但打破这种阻力并确保顺利过渡至关重要。这将帮助您在短时间内获得成果，并使您能够运营更具可操作性的流程。
将您的项目迁移到 Git
尝试从传统的代码仓库环境（如 SVN 和 TFS）迁移到功能更强大的 Git 环境，以增强通信和集成能力。这还将使您更高效地使用许多工具。
成熟您的 DevOps 流程
DevOps 不仅是为了自动且快速地执行某项任务。它还能确保您以可靠的方式运营流程。构建包含全套工具的 DevOps 流程，并努力提升其中的成熟度。
进行代码审查（Code Review）
由不同人员对编写的代码进行检查并给出评论，可以极大地提高代码质量。同时，这也确保了能从团队成员那里获得反馈。始终拥有第二双眼睛对提升质量至关重要。代码审查流程必须成为您开发过程的一部分。
实施 TDD
TDD（测试驱动开发）不仅仅是编写单元测试。测试优先的代码开发应成为软件团队文化的一部分。尽管初期可能会有抵触，但随后在代码质量以及重构等流程带来的益处方面，TDD 将成为不可或缺的过程。
引入重构流程
重构是指在不影响代码功能的前提下对其进行修改。在重构后的代码中，我们最常看到的是代码初始状态与最终状态之间的巨大差异。如果一个开发人员难以阅读自己的代码，那么他阅读其他开发人员的代码也会很困难。
使用 Sonarqube 等静态代码分析工具
在代码审查之前，利用静态分析工具检查内部确定的标准非常重要。同时，您还可以借助 SonarLint 等工具将这一过程融入开发流程中。Sonarqube 等工具最重要的要求是进行正确的配置并使用规则集（rule-sets）。因此，将这些工具纳入流程时，获得良好的配置支持是非常有益的。
转向测试自动化
如果不实现测试自动化，就很难建立高质量的 DevOps 流程或实现持续部署目标。此外，我们很少对等待手动执行的回归测试套件所耗费的时间和精力感到惋惜。因此，将测试在一定范围内实现自动化至关重要。
使用 APM 监控生产环境
生产环境意味着正在运行的产品与客户之间的互动。如果不监控和衡量这两者，就很难看清我们所提供的服务。为此，您可以使用 APM（应用性能监控）工具。最常见的包括 New Relic、Dynatrace、Appdynamics 和 Riverbed 等工具。通过这些工具，您可以实时查看最终用户在您的应用中经历的体验、遇到的错误以及系统的响应时间。
确定 KPI（关键绩效指标）
遵循“无法衡量就无法改进”的理念，确定 KPI 以明确我们当前的状态和未来的方向非常重要。在没有 KPI 的地方，尤其是在测试方面，我们往往会遇到自我管理的团队。您可以通过 QA Dashboard 查看 KPI，并跟踪其趋势。
通过游戏化（Gamification）和 OKR（目标与关键结果）提升质量
我们用于提升质量的方法是 OKR（目标与关键结果）。OKR 首先通过可衡量的目标展示我们将去向何方，以及最终将获得什么成果。目前存在可以在团队和个人层面应用的 OKR 模型的游戏化方法。特别是为了了解哪个团队当前处于什么位置、进展如何、目标是什么以及做出了哪些承诺，将这些数值数据汇总并提供持续反馈非常重要。
作为游戏化方法，我们为团队和个人设立了一个联赛。每个联赛都拥有可以获取积分的 OKR 项目。未完成这些 OKR 项目的得 0 分，开始完成的得 1 分，全部完成的得 3 分，从而在联赛中排名靠前。
您可以在下方看到 QA Dashboard 游戏化模块中的联赛结果。
如上所示，Platform Team 以 56 分位居最高等级，而最右侧显示的成熟度等级值为 3。最后一个团队 Mobile Team 由于许多项目未开放，其成熟度等级显示为 0。
我们使用联赛的原因实际上是创造一个竞争环境，并展示各团队在 OKR 中的位置。
如下所示，我们有标识这些 OKR 项目的具体数值。
您可以对这些条目进行多样化处理，并添加新的条目。此处列出的成熟度等级本身并无直接含义。可以参照TMMI标准，或设定共同目标来进行评估。最终，这些模型会根据各团队所采用的技术和方法论的不同而有所差异。