28、敏捷软件开发中的方法与指标解析

敏捷软件开发中的方法与指标解析

1. 极限编程（XP）的关键要素

在软件开发领域，极限编程（XP）有其独特的理念和实践方法。

1.1 重构（Refactoring）

重构在 XP 中用于弥补前期架构、分析和设计工作的不足。这是一种有意的策略设计，有助于降低在制品库存。理想情况下，重构应该持续进行，并且对外部观察者来说是不可见的。对于小型、高技能且不受持续微观管理和时间压力的团队而言，这或许是可行的。但对于大多数团队，每三到四次迭代中需要专门安排一次迭代进行重构。频繁重构很重要，因为持续重构才能实现流程的顺畅。例如，每两个月中断一次开发进行重构迭代，会严重干扰流程。如果在重构前积累大量已完成的工作，会增加风险、延长前置时间，并最终对生产和财务指标产生负面影响。

1.2 40 小时工作周

XP 提倡像其他常规职业一样实行固定的工作周。这看似与提升开发者产能的观念相悖，因为若要开发者提供更多产能，似乎应要求他们延长工作时间。但 XP 将 40 小时工作周视为维持高质量的理想政策约束。XP 认为，长期加班会导致质量下降，进而使系统的整体生产率降低，这一点很容易衡量。

1.3 现场客户（On - Site Customer）

现场客户的存在可以减少因问题导致的停机时间，从而充分利用开发者这一资源。当某个故事的代码生产因需求的模糊性或问题而停止时，能迅速解决。无需维护问题日志，也无需与客户召开问题解决会议。此外，还可以向现场客户展示部分完成的代码演示，他们能快速向开发者提供纠正反馈，这充分利用了用户验收测试这一资源，提升了开发者的效率。结果是提高了质量，减少了缺陷，从而提高了系统的整体生产率。不过，客户必须有充分的决策权，并且对整个主题有全面的领域知识。否则，可能需要不止一位现场客户。在大型项目中，找到一位能每周花 40 小时与团队在一起，且有地位在不咨询同事的情况下做出权威决策的现场客户是不太可能的。而且，由于需要现场客户，采用外包开发来运行敏捷项目会很困难，因此 XP 等敏捷方法可被视为外包的有效替代方案。

1.4 通才（Generalists）

XP 消除了专家角色，没有分析师、设计师、用户界面设计师或架构师。它鼓励培养高天赋、高技能、高学历的通才。消除专家角色可以消除大量潜在的瓶颈点或约束。但这是一把双刃剑，有数据表明专家团队的表现优于通才团队，也有人认为 XP 不利于可用性。例如，客户可能更希望由专业的交互设计师和可用性工程师来设计用户界面，而非程序员。不过，消除专家角色确实消除了约束，在 PERT 图中无需安排专家，也无需用缓冲来保护专家，在 XP 中也不需要关键链法。

1.5 消除约束与其他策略

在很多情况下，XP 一方面承认传统软件开发存在约束，另一方面又试图否定约束理论。XP 只是简单地消除约束并继续推进，例如通过集体所有权和将开发者培养成通才来消除版本控制锁和技术专家的约束。这在由高天赋人员组成的小型项目中可能是合适的，因为这些人能处理好一切，不会陷入困境。但随着项目规模增大，团队成员的能力水平开始参差不齐时，可能需要考虑其他方法，即识别、利用、服从并最终提升约束，而不是忽视它们。否定约束的另一种方式是将其视为范式约束，XP 可被视为软件工程的范式转变。在新范式中，现有约束或许无需考虑，专家只是旧范式的一部分，随着向精益范式的转变而消失，版本控制锁同样是一种范式，通过将开发工作实践转变为精益模式，版本写锁可能会随着旧的大规模生产、专家范式一起消失，这些都是敏捷社区中活跃讨论的问题。

2. 极限编程（XP）的财务指标

XP 中的财务指标对于评估项目的经济可行性和效益至关重要。

2.1 库存（Inventory in XP）

XP 中库存的单位是故事点。软件生产系统中的库存是项目故事卡集合中持有的总库存，包括等待开始的故事、正在进行的故事以及已完成但尚未交付的故事。

2.2 投资（Investment in XP）

投资是获取以需求形式呈现的待开发产品创意的成本。在 XP 中，投资定义为创建故事工作集所涉及的所有成本。企业为新产品产生创意而进行的任何前期活动，以及市场研究、焦点小组、原型制作、可用性研究、用户界面设计、业务流程再造、需求工程和分析等验证活动，都应视为投资。此外，每次迭代开始时在故事细化上的额外投资，以及规划游戏所花费的时间和创建验收测试所投入的时间，也都应视为投资。如果任何上游活动外包，产生的直接成本也应计入投资。

2.3 运营费用（Operating Expense in XP）

运营费用是迭代或发布的所有成本（包括直接劳动力）减去归因于投资的任何成本。对于单个迭代，运营费用可以直接对应故事点的库存来计算。在敏捷方法如 XP 中，由于团队工作是持续且普遍的，很难区分合同劳动力和带薪员工的贡献，因此合同劳动力的成本应视为运营费用，而不是可以从吞吐量中扣除的直接成本。

2.4 吞吐量（Throughput in XP）

吞吐量定义为已交付故事的价值，即销售价格（或预算）减去直接成本，如中间件、交付和部署过程中的运营费用、数据库许可证和硬件等。对于 IT 部门的单个迭代，可以使用预算基础来计算吞吐量，即把系统预算作为转移价格，然后扣除直接成本。在多个发布中，应将软件生产系统视为一个连续过程，根据时间段进行财务评估，通过评估在给定时间段（如一个日历季度）内交付故事的真实价值来确定吞吐量，并扣除该时间段内可归因于工作软件调试的任何直接成本。

2.5 净利润（Net Profit in XP）

净利润的计算公式与之前的相关内容相似。对于多次迭代后才发布的极限编程生产系统，将其视为连续过程来计算净利润更为合适。

2.6 投资回报率（Return on Investment in XP）

可以结合之前的投资公式和净利润数据来计算极限编程系统的投资回报率。

2.7 变更核算（Accounting for Change）

在 XP 中，处理变更请求有两种可能的方式。在严格的系统中，每两周迭代交付一次有价值的工作软件时，迭代期间应不允许变更请求，此时无需核算变更。但当迭代是发布的一部分时，变更请求会被允许且必须核算。变更请求需要编写一个或多个故事，其成本应作为额外投资核算。有些变更请求会使项目的部分现有范围不再必要，产生废弃故事，在精益软件开发中，这些废弃故事是浪费，无论故事是否已编码，只要未交付给客户，就必须视为浪费，投资在这些废弃故事上的资金必须核销，投资金额应减去受变更影响的故事数量乘以每个故事的平均投资。

2.8 返工核算（Accounting for Rework）

返工通常指修复错误以及由于早期错误决策导致的设计和代码中的可能回归效应。在 XP 中，返工还包括重构。一些 XP 倡导者认为重构是持续且不可见的，这在高技能团队中可能可行，但对于其他团队，更可能是每三到四次迭代专门安排一次迭代进行重构。重构可以利用近期迭代的经验，创建更健壮、更能适应未来变化的代码，即更具敏捷性的代码。重构的成本应视为纯粹的运营费用，因为重构迭代不会交付任何对客户有价值的功能，其吞吐量为 0，因此单独来看，重构迭代只会产生负净利润和负投资回报率。由于 XP 的性质和重构迭代的特点，不适合按迭代逐个核算 XP，而应将其视为一个连续过程，通过在一段时间（如一个日历季度）内汇总核算，才能准确核算重构的真实成本并在整个期间内进行平滑处理。

2.9 变更成本曲线（The Cost of Change Curve）

XP 声称的变更成本曲线是一个备受争议的话题。Beck 提出变更成本更像 1 - log(n) 类型的曲线，这与已有的变更成本可能呈指数增长的理论相悖。Beck 曲线在每个客户有价值的功能可以单独交付且每个故事有最大成本的情况下是正确的，变更成本会根据故事是否开始以及在变更引入前的完成程度而增加。但该曲线完全忽略了系统其他部分可能出现的回归效应。典型的 XP 开发者会通过加班快速重构受影响的代码，但这会打破 XP 的 40 小时工作周实践，而且变更导致的重构会在相当长的时间内影响生产率和质量。实际上，对软件系统核心部分产生重大返工的变更不太可能仅通过加班来恢复，真实的变更成本更接近 Boehm 曲线，但 Boehm 曲线也并非完全准确，因为变更成本无限螺旋上升到无穷大的观点肯定是错误的，变更成本应该有一个最大值，即重写整个系统的成本。因此，真实的变更成本曲线实际上是一个 S 曲线。从长远来看，S 曲线类似于 Beck 曲线；从短期来看，类似于 Boehm 曲线；在微观层面，只观察单个故事的影响时，又类似于 Beck 曲线。所以，Beck 和 Boehm 的观点可能都有一定的正确性，但都不够全面，XP 并非降低变更成本的万灵药，敏捷方法通常可以降低变更所涉及的风险和暴露程度，与传统的瀑布式项目相比，敏捷项目的投资沉没成本更低，因此损失投资的影响也更小。

3. Scrum 的背景与结构

Scrum 是一种软件管理方法，可应用于其他敏捷方法，如 XP。它可以作为其他软件开发生命周期方法的管理包装器，因为它不依赖于特定的软件开发生命周期方法，即 Scrum 定义的是如何控制软件项目，而不是如何编写软件。Scrum 基于经验过程控制理论，其起源于日本制造业，适合获取和处理指标。

Scrum 包含每日站会，用于讨论影响生产力的问题。开发者需要列出正在进行的工作、已完成的工作以及可能遇到的问题。Scrum 会议成员会迅速决定采取何种行动来帮助解决问题，会议本身不进行问题辩论，且时长不超过 15 分钟。Scrum 将开发工作组织成三个层次：冲刺（Sprints）、发布（Releases）和产品（Products）。冲刺严格为 30 天（或 4 个工作周），发布通常由多个冲刺组成，可能多达 6 到 9 个冲刺，产品则是一系列发布。需求被转换为客户有价值的功能列表，即产品待办事项列表（Product Backlog），该列表可以随时间增加，不一定在项目开始时就固定。每个发布从产品待办事项列表中选取一部分形成发布待办事项列表（Release Backlog），每个冲刺再从发布待办事项列表中选取一部分形成冲刺待办事项列表（Sprint Backlog），冲刺待办事项列表一旦确定就不可更改，开发团队可以在 30 天的冲刺中放心工作，因为冲刺待办事项列表不会改变。

以下是 Scrum 工作层次的表格总结：
| 工作层次 | 时长 | 说明 |
| ---- | ---- | ---- |
| 冲刺（Sprints） | 30 天（4 个工作周） | 严格固定时长，冲刺待办事项列表确定后不可更改 |
| 发布（Releases） | 多个冲刺（6 - 9 个冲刺） | 从产品待办事项列表中选取部分形成发布待办事项列表 |
| 产品（Products） | 一系列发布 | - |

下面是 Scrum 系统的 mermaid 流程图：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px

    A(产品待办事项列表):::process --> B(发布待办事项列表):::process
    B --> C(冲刺待办事项列表):::process
    C --> D(冲刺):::process
    D --> E(发布):::process
    E --> F(产品):::process

综上所述，敏捷软件开发中的 XP 和 Scrum 方法各有特点和优势，在不同规模和场景的项目中需要根据实际情况进行选择和应用，同时要合理考虑各种指标和约束，以实现项目的成功。

4. Scrum 的生产指标应用

Scrum 作为一种强大的软件管理方法，其生产指标的应用对于项目的成功至关重要。通过对这些指标的有效分析和利用，能够更好地控制项目进度、提高生产效率和保证产品质量。

4.1 速度指标（Velocity）

速度指标是 Scrum 中一个关键的生产指标，它衡量的是团队在一个冲刺中完成的故事点数量。通过对多个冲刺的速度进行统计和分析，可以预测团队未来的生产能力，合理安排后续的冲刺计划。

例如，一个团队在过去三个冲刺中分别完成了 30、32 和 31 个故事点，那么可以大致估算该团队的平均速度为 31 个故事点。基于这个速度，在规划下一个冲刺时，就可以根据产品待办事项列表中的故事点数量来确定能够选择多少故事纳入冲刺待办事项列表。

以下是一个简单的速度指标计算表格示例：
| 冲刺编号 | 完成故事点数量 |
| ---- | ---- |
| 冲刺 1 | 30 |
| 冲刺 2 | 32 |
| 冲刺 3 | 31 |
| 平均速度 | 31 |

4.2 燃尽图（Burndown Chart）

燃尽图是 Scrum 中常用的可视化工具，用于展示冲刺或项目的进度情况。它以时间为横轴，剩余工作量（通常以故事点表示）为纵轴，通过绘制剩余工作量随时间的变化曲线，直观地反映项目的进展是否符合预期。

在一个理想的燃尽图中，曲线应该呈下降趋势，并且在冲刺结束时剩余工作量为 0。如果曲线下降过慢，说明项目进度滞后，需要及时采取措施进行调整；如果曲线下降过快，可能意味着冲刺计划过于保守，需要重新评估团队的能力和后续的工作安排。

下面是一个燃尽图的 mermaid 流程图示例：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px

    A(冲刺开始):::process --> B(剩余工作量高):::process
    B --> C(工作进行中，剩余工作量减少):::process
    C --> D(冲刺结束，剩余工作量为 0):::process

4.3 累积流量图（Cumulative Flow Diagram）

累积流量图展示了项目中不同阶段（如待办、进行中、已完成）的工作数量随时间的变化情况。通过分析累积流量图，可以发现项目中的瓶颈和阻塞点，及时调整资源分配和工作流程。

例如，如果累积流量图中“进行中”阶段的曲线持续上升，而“已完成”阶段的曲线上升缓慢，说明项目可能存在瓶颈，导致工作无法顺利完成。此时，需要深入分析原因，可能是某个环节的资源不足，或者是工作流程存在问题，然后采取相应的措施进行优化。

以下是累积流量图不同阶段的表格说明：
| 阶段 | 说明 |
| ---- | ---- |
| 待办 | 等待处理的工作数量 |
| 进行中 | 正在处理的工作数量 |
| 已完成 | 已经完成的工作数量 |

5. Scrum 与其他方法的结合

Scrum 具有很强的灵活性，可以与其他软件开发方法相结合，以发挥各自的优势，更好地适应不同项目的需求。

5.1 Scrum 与 XP 的结合

如前文所述，Scrum 可以作为管理包装器应用于 XP。Scrum 提供了项目控制和进度管理的框架，而 XP 则注重软件开发的实践和价值观，如重构、40 小时工作周、现场客户等。

在结合使用时，Scrum 的每日站会可以帮助 XP 团队及时沟通问题，确保项目的顺利进行。同时，XP 的重构实践可以在 Scrum 的冲刺中进行，提高代码的质量和可维护性。例如，在一个 Scrum 冲刺中，团队可以按照 XP 的原则进行代码的重构，以消除潜在的问题和提高系统的性能。

以下是 Scrum 与 XP 结合的优势列表：
- 利用 Scrum 的管理框架确保项目进度和控制。
- 借助 XP 的实践提高代码质量和开发效率。
- 促进团队成员之间的沟通和协作。

5.2 Scrum 与精益软件开发的结合

Scrum 与精益软件开发的理念也有很多契合之处。精益软件开发强调消除浪费、优化流程和快速交付价值，而 Scrum 通过迭代开发和对生产指标的关注，也能够实现类似的目标。

在结合使用时，可以运用精益思想对 Scrum 的流程进行优化，减少不必要的工作和浪费。例如，通过分析累积流量图发现的瓶颈，运用精益原则进行流程改进，提高工作效率。同时，Scrum 的冲刺机制也可以帮助精益软件开发更快地验证和交付价值。

以下是 Scrum 与精益软件开发结合的具体操作步骤：
1. 运用 Scrum 的框架进行项目规划和迭代开发。
2. 引入精益思想，对 Scrum 流程进行价值流分析，识别和消除浪费。
3. 根据累积流量图和其他生产指标，持续优化工作流程。
4. 在每个冲刺中快速验证和交付价值，根据反馈进行调整。

6. 敏捷方法的挑战与应对策略

虽然敏捷方法（如 XP 和 Scrum）在软件开发中具有很多优势，但在实际应用中也会面临一些挑战，需要采取相应的应对策略。

6.1 团队协作挑战

在敏捷项目中，团队成员之间的协作至关重要。但不同成员的技能水平、工作习惯和沟通方式可能存在差异，这可能导致团队协作出现问题。

应对策略：
- 加强团队建设活动，增进成员之间的了解和信任。
- 提供培训和学习机会，提高团队成员的技能水平和沟通能力。
- 建立明确的团队规则和沟通机制，确保信息的及时传递和共享。

6.2 需求变更挑战

敏捷项目通常允许需求的变更，但频繁的需求变更可能会打乱项目计划，影响项目进度和质量。

应对策略：
- 在项目开始时，与客户充分沟通，明确项目的范围和目标，尽量减少不必要的需求变更。
- 建立需求变更管理机制，对变更请求进行评估和优先级排序，确保变更的合理性和可控性。
- 在每个冲刺中预留一定的缓冲时间，以应对可能的需求变更。

6.3 技术债务挑战

随着项目的推进，可能会积累一定的技术债务，如代码质量下降、架构不合理等。这会影响系统的可维护性和扩展性，增加后续开发的成本。

应对策略：
- 定期进行代码审查和重构，及时消除技术债务。
- 在项目规划中，合理安排时间和资源用于技术债务的处理。
- 培养团队成员的技术意识，避免产生不必要的技术债务。

以下是敏捷方法挑战与应对策略的表格总结：
| 挑战 | 应对策略 |
| ---- | ---- |
| 团队协作挑战 | 加强团队建设、提供培训、建立沟通机制 |
| 需求变更挑战 | 充分沟通、建立变更管理机制、预留缓冲时间 |
| 技术债务挑战 | 定期审查重构、合理安排资源、培养技术意识 |

7. 总结与展望

敏捷软件开发中的 XP 和 Scrum 方法为软件项目的管理和开发提供了有效的解决方案。XP 通过重构、40 小时工作周、现场客户等实践，注重软件开发的质量和效率；Scrum 基于经验过程控制理论，通过每日站会、冲刺和生产指标的应用，实现对项目的有效控制和进度管理。

同时，Scrum 可以与其他方法（如 XP、精益软件开发）相结合，发挥各自的优势，更好地适应不同项目的需求。然而，敏捷方法在实际应用中也会面临团队协作、需求变更和技术债务等挑战，需要采取相应的应对策略。

在未来的软件开发中，随着项目规模的不断扩大和需求的日益复杂，敏捷方法也需要不断发展和完善。例如，进一步优化生产指标的应用，提高对项目风险的预测和应对能力；加强与其他领域（如人工智能、大数据）的融合，以提升软件开发的智能化水平。总之，敏捷方法将在不断的实践和创新中，为软件开发行业带来更多的价值和机遇。