38、数字企业软件生产力：从传统到现代的度量转变

数字企业软件生产力：从传统到现代的度量转变

在当今数字化的时代，软件行业的发展日新月异。理解软件生产力对于整个行业至关重要，它不仅能简化系统分析过程，还能推动软件行业的增长。然而，当代软件行业在生产力度量方面面临着诸多挑战，尤其是随着版本控制系统的出现，监控提交的价值和确定软件生产力变得愈发困难。

面向业务的软件指标的需求

生产力度量系统的价值不应仅仅局限于技术层面，还必须具有业务导向。传统的软件指标虽然经典，但如果不与业务目标相结合，就毫无意义。云计算的兴起开启了数字转型的时代，使计算能力更普及，也为基于业务洞察和用户需求的项目铺平了道路。一个软件产品如果不使用业务指标，不能满足客户需求，那将是毫无用处的。好的产品应该简化任务，而不是使其复杂化。

选择生产力指标需要深思熟虑，要过滤业务需求、平衡技术要求，并研究数据中客观指标的趋势和波动。在版本控制系统中，公司在每个冲刺周期或每天都会在开发者的本地分支中提交大量数据。分析这些数据不仅可以预测代码的性质，还能预测整个冲刺周期的时间线，从而加强对软件开发过程从构思到产品交付的监控。因此，现代软件开发更注重与特定功能相关、支持特定业务目标的主观指标，将指标作为持续学习和改进的有效工具。

那些采用传统瀑布式软件开发方法的公司在行业中逐渐失去竞争力，因为我们正在向基于版本的软件过渡，通过持续集成和持续交付实现更好的产品交付，同时也能适应不断变化的客户需求。业务模型将整个项目视为雪花，产品的每个组件都是独特的，因为很少有组件具有相同的需求或功能。每个人凭借不同的技能为项目带来新的元素，包括兴趣、编程能力和沟通技巧。一个协作良好、沟通有效的团队也是独一无二的，即使团队中的个体开发者能力不强，但通过协作也能成为高效的团队。因此，任何成为产品的项目都是独特的，其需求会随着时间而演变。除了与最终业务目标相关的个人历史记录，我们无法确定精确的生产力度量指标。

这种转变在多个方面带来了好处，包括满足客户需求和在系统开发过程中获得持续反馈。这将确保后期客户支持服务的减少，与客户密切合作也有助于建立更专业的关系，从长远来看对组织有益。到目前为止，软件指标主要关注技术参数来确定程序员的生产力，现在我们需要纳入基于业务的指标，以确定开发者开发的产品是否真正对公司有益。

业务指标旨在提高组织提供的产品和服务的质量。一种简单的软件业务指标方法是研究管道程序的结构和逻辑结构。从学术角度来看，软件的易维护性、设计模式的优雅性、可靠性、吞吐量和时间效率将确保生产环境的稳定性。从业务反馈的角度来看，我们需要评级和用户满意度反馈，以评估开发的产品是否满足项目开始时设定的需求以及是否适应了变化的需求。因此，最终真正重要的指标不仅是主观的，还包括客观的成功指标，这些指标能让我们了解产品的交付情况和用户对系统的参与度。

在传统的瀑布式软件项目中，人们假设软件可以提前指定并通过估算进行量化，还假设软件规范能满足最终用户的需求，但实际情况往往并非如此。因此，我们需要更好的监控指标，这些指标应更具数据驱动性和业务导向性。团队速度就是这样一种指标，用于确定团队的协作质量，它由团队在每个冲刺周期承诺交付的成果来设定。团队速度衡量团队在前几个冲刺中完成的故事点数量，量化产品功能的数量和规模，有助于了解团队在给定时间内为客户提供的价值。为了衡量产品开发周期中完成待办任务所需的时间，我们使用燃尽图，将待完成的工作量化为发布燃尽情况，让经理大致了解完成项目并发布产品最小版本所需的时间。我们还使用逃逸缺陷来跟踪项目在首次发布前存在的缺陷数量，经理应根据客户需求跟踪并解决所有这些问题。这是用户的主要反馈机制，逃逸缺陷数量的增加可能表明开发团队遵循的流程存在问题。

测试在软件开发中的重要性

测试是开发周期中不可或缺的一部分。传统的测试方法包括单元测试和系统测试，现在需要进行发布测试，以在每个发布阶段识别系统中的缺陷，为团队提供更多关于产品开发的洞察，同时纳入更好的客户反馈和最佳实践。我们称这种指标为真实测试覆盖率，与仅衡量单元测试的常规测试覆盖率指标不同。真实测试覆盖率衡量代码库或功能集被各种测试（包括单元测试、集成测试、UI自动化测试、手动测试和端到端验收测试）覆盖的程度，有助于发现软件中无关紧要的组件。在这个时候，数据驱动的系统至关重要，机器学习可以用于实现能够有效监控产品开发周期并衡量代码生产力的智能系统。

传统软件生产力指标

传统的软件生产力指标在确定代码质量和开发者编程结构方面经久不衰。它还关注开发者为了将模块化代码交付到产品管道中应遵循的各种参数，对于预测代码的生产力是不可或缺的。每个组织都希望遵循最佳实践和敏捷方法，以加速产品开发过程。一个智能系统可以通过监控所有测试框架中的测试、收集测试执行数据，并将其与代码更改和常用功能的数据相关联，为开发经理提供可见性，帮助计算真实测试覆盖率指标，从而揭示软件产品中的质量差距。

传统指标可以分为基于过程的指标和基于产品的指标。过程指标评估开发过程的状态和资源使用情况，而产品指标评估执行软件过程产生的工件（如需求、架构、设计和实现）的状态和复杂性。软件架构领域致力于开发大规模、复杂的软件系统，软件架构提供了表示软件系统结构、行为和关键属性的高级抽象，包括系统构建元素的描述、元素之间的交互、指导其组合的模式以及对这些模式的约束。产品指标又可以分为静态和动态类型。静态指标具有结构和设计成分，而动态指标仅用于可测试性。静态指标还可以进一步分为基于规模、设计、控制、信息、加权、数据结构和软件科学的指标。

规模指标

开发者完成的软件代码中有各种规模指标。一般来说，代码行数（LOC）和标记数量是衡量程序规模的良好定量指标。近年来，随着更好的实践的出现，编写文档完善、注释丰富的代码不仅被认为是健康的，而且是必不可少的实践。因此，相对于代码行数的注释数量成为了新的规模指标。程序中的方法或函数数量也非常重要，它不仅表明了模块化程度，其调用次数还会影响内存复杂性，最终也属于规模指标的范畴。

控制指标

控制指标指的是程序流控制的变化，也通过声明的函数数量和对这些函数的调用数量来衡量。以下是一些重要的控制指标：
1. 圈复杂度（Cyclomatic Complexity） ：在编程中，代码行数与模块复杂度之间没有明显的关系，仅依赖代码行数和相关注释来评估是不明智的，因此我们需要确定程序中的控制流。任何程序性软件的控制流都可以用有向图表示，将每个可执行语句（或控制流连续的一组语句）表示为节点，控制流表示为节点之间的边。数学上，圈复杂度的计算公式为：
[M = E - N + 2P]
其中：
- (E) = 控制流图中的边数
- (N) = 控制流图中的节点数
- (P) = 连通组件的数量
2. 哈尔斯特德复杂度（Halstead Complexity） ：哈尔斯特德度量依赖于程序执行及其测量，具体从源代码中的运算符和操作数进行分析。哈尔斯特德度量可以评估测试时间、词汇量、估计值、难度、错误和工作量。它将每个程序视为运算符及其相关操作数的组合，目标是衡量某些特性，如词汇量、体积、级别、难度、编程工作量和所需的编程时间。数学上，哈尔斯特德程序长度的计算公式为：
[ \hat{N} = n_1 \log_2 n_1 + n_2 \log_2 n_2 ]
[ N = N_1 + N_2 ]
其中：
- (n_1) = 不同运算符的数量
- (n_2) = 不同操作数的数量
- (N_1) = 运算符的总出现次数
- (N_2) = 操作数的总出现次数
3. 扇入和扇出复杂度（Fan - In and Fan - Out Complexity） ：扇入和扇出复杂度是衡量程序中信息流的指标。扇入简单定义为程序中输入变量的总和，包括局部变量声明、全局变量和参数读取；扇出是数据中输出信息流的总和，包括引用参数写入、读取参数写入和全局变量写入。扇入 - 扇出指标是扇入和扇出复杂度的总和，数学表示如下：
[ \text{Fan - In Complexity} = LR + GR + PR ]
其中：
- (LR) = 局部变量读取
- (GR) = 全局变量读取
- (PR) = 参数读取
[ \text{Fan - Out Complexity} = RPW + GW + LW ]
其中：
- (RPW) = 引用参数写入
- (GW) = 全局变量写入
- (LW) = 局部变量写入
4. 方法或过程调用数量（P） ：程序中声明的函数总数以及这些函数被程序模块调用的次数，称为方法数量或更正式地称为过程调用计数（P - C）。
5. 数据抽象耦合（DAC） ：数据抽象耦合是对两个代码模块之间相关性的数学度量。高值表示代码模块之间有很强的关系和相似性，低值表示两个模块之间的依赖性较低。低DAC值的代码模块更灵活，因为代码中的错误部分更容易被检测到，开发团队可以有效地解决任何额外的依赖问题。如果代码模块的DAC值较高，错误代码就很难检测到，由于可能产生的额外依赖问题，使整个项目无缺陷且功能正常变得更具挑战性。代码隔离对于维护功能系统的健康至关重要，容器和Docker的概念就源于隔离代码及其额外依赖的需求。一种健康的工业实践是即使在小模块上也确保代码隔离，以确保维护和配置更改不会成为挑战。此外，这还能确保产品具有更好的可扩展性，也可用于使用任何执行工具（如Jenkins）有效地生成构建映像。通过传统的瀑布式方法逐步创建模块也是一种可能的解决方案。简单来说，数据耦合方法是指在过程调用中作为参数传递所有信息，并期望得到相应的返回值，可用于任何代码模块的可扩展性测试。

这些传统指标在衡量软件生产力时必须被考虑，是监控软件开发进度产品的重要组成部分。

软件工程中的生产力度量指标

业务经理通常试图通过衡量团队成员编写的代码行数（LOC）来跟踪团队成员的工作情况，但这种方法存在许多缺点。首先，仅通过代码行数无法确定程序的复杂性，而且我们还忽略了端到端的产品交付成果，这种微观管理方式对员工非常有害。任何产品的目标都是满足客户需求并提供额外的期望服务，同时应具备从安全措施到保护客户隐私等技术能力，维护组织的尊严和声誉。

因此，为了衡量员工的生产力，我们首先需要正确确定目标，使其与技术能力和客户期望相平衡。以下是一些基于目标的度量指标，用于跟踪产品开发周期中的进度：
1. 项目或已完成冲刺率（Project or Burnt Sprint Rate） ：优秀的经理会根据团队成员的技术知识和处理工作的能力分配任务。另一个常用的方法是将任务划分为故事点，每个故事点与一个缺陷、生产任务或测试工作相关。采用这种最佳实践的重要好处是可以进行风险缓解。经理可以评估交付产品所需的时间，并跟踪项目发布过程中涉及的风险。
2. 工单关闭相关性比率（Ticket Close Relevance Rate） ：它指的是开发者完成的故事点数量以及该特定任务与项目的相关性。经理在评估员工潜力时不应将其视为绝对标准，因为这是一个主观指标。任务可能从创建新管道到解决程序中的缺陷不等，因此应根据任务与临近里程碑的相关性分配加权分数。这可以作为识别项目中存在的问题并就工作进行协作讨论即将出现的问题的度量指标。
3. 代码行数（Lines of Code - LOC） ：如前所述，这是一个简单的指标，不能直接用于衡量生产力。因此，它需要与其他因素结合使用，例如注释数量（以评估开发者是否遵循指南和最佳实践），以确定开发者在单个项目中进行的代码更改数量以及对内存复杂性的影响。所有这些因素可以组合成一个有影响力的指标，与软件生产力相关联。
4. 代码变更率（Code Churn Rate） ：它主要衡量开发者的信心，是将代码推送到管道后进行的编辑、配置更改或代码库审查的数量，它表明了程序员的效率和正确性。代码变更率仅在产品需求非常明确时使用，特别是在软件开发的收尾阶段。在产品开发的早期阶段，它不是一个很好的指标，因为产品需求可能会发生变化，很多时候客户并不清楚他们想要什么，并且经理对工作的理解和客户的期望之间可能存在差距。

各指标对比分析

指标名称	定义	优点	缺点	适用场景
项目或已完成冲刺率	根据团队成员能力分配任务，以故事点衡量，评估交付时间和风险	可进行风险缓解，了解交付时间	-	项目整体规划和进度跟踪
工单关闭相关性比率	开发者完成故事点与项目相关性，加权计分	识别项目问题，促进协作讨论	主观指标	评估员工工作与项目相关性
代码行数	结合注释、代码更改、内存影响衡量	综合衡量，与生产力关联	不能直接衡量生产力	综合评估开发者工作
代码变更率	代码推送后编辑、更改、审查数量	衡量开发者信心和效率	需求不明确时不适用	需求明确的开发后期

指标应用流程

graph LR
    A[确定业务目标] --> B[选择合适指标]
    B --> C[收集数据]
    C --> D[分析数据]
    D --> E[根据结果调整]
    E --> B

总结

在当今数字企业软件领域，软件生产力的度量是一个复杂且不断演变的过程。从传统的基于技术参数的指标到现代的面向业务的指标，我们看到了度量方式的重大转变。传统的软件生产力指标，如各种规模指标和控制指标，在确定代码质量和编程结构方面发挥了重要作用，它们是软件开发过程中不可或缺的一部分。然而，随着软件行业的发展，仅仅关注技术层面已经无法满足需求，我们需要更多地考虑业务目标和客户需求。

现代软件开发强调持续集成和持续交付，项目需求不断变化，因此需要更灵活、更具数据驱动性和业务导向性的指标。团队速度、燃尽图、逃逸缺陷等指标为我们提供了更好的项目监控和管理手段，而基于目标的度量指标，如项目或已完成冲刺率、工单关闭相关性比率、代码行数和代码变更率等，则有助于我们更准确地衡量员工的生产力，确保开发的产品能够真正满足客户需求并为公司带来价值。

同时，测试在软件开发中的重要性也日益凸显，真实测试覆盖率指标的引入，让我们能够更全面地了解代码的测试情况，发现软件中无关紧要的组件，借助机器学习等技术实现更智能的产品开发周期监控。

总之，数字企业软件生产力的度量需要综合考虑技术和业务两个方面，不断适应行业的变化和发展，以确保软件开发项目的成功实施和企业的持续发展。在实际应用中，我们应根据项目的具体情况选择合适的指标，并不断优化和调整度量方法，以实现软件生产力的有效提升。