极限编程 - 持续演进的实践

极限编程自诞生以来一直在不断发展，其实践也被发现有效地应用于其他敏捷方法。

下表展示了极限编程实践的演进过程。

现场客户 – 完整团队

极限编程依赖于项目社区，强调以团队为中心的方法。所有参与极限编程项目的贡献者，包括客户，都属于同一个团队。

客户提供需求，设定优先级并指导项目。这使客户能够了解开发的实际细节，并相应地设定优先级和期望。这改变了从“按客户要求开发”到“客户理解并与开发合作”的方式。

项目目标是共享责任，开发是在整个团队中进行的持续对话。这是一个发明和沟通的合作游戏。实践证明，面对面的沟通是开发过程中最高效、最有效的方法，可以消除等待时间和延误。

计划游戏 – 发布和迭代计划

增量项目计划被证明是有效的，因为它促进了准确的计划。随着开发的进展，基于实际性能，会学习到更多更好的信息。首先制定一个粗略的计划，然后逐步细化。

发布计划设定长期目标，掌握整体大局。客户提出所需功能，开发人员进行估算，发布日期由双方共同商定并承诺。由于发布计划在每次发布后都会进行修订，因此随着项目的进展，它会变得越来越精确。

迭代计划设定短期时间框，包含迭代，通常为1周到1个月。迭代计划的主要目标是在每次迭代结束时获得可工作的软件。开发人员选择迭代的功能/故事，将其分解成任务，估算任务并承诺分配的任务。通过平衡团队中的负载系数，并考虑40小时工作制，确保可持续的节奏。

验收测试

客户为某个功能编写一个或多个自动化的验收测试，以确保系统正确地实现了所需的功能。验收测试与故事一起编写，并在实现之前提供。

团队自动化这些测试以验证功能是否正确实现。测试运行后，团队确保此后在回归测试时通过执行到目前为止实现的所有验收测试，使其保持正确运行。

验收测试提供了功能需求的明确规范。此外，通过的验收测试的百分比衡量了发布完成情况，避免了最后一刻的意外。

系统始终改进，永不倒退。

单元测试

开发人员编写单元测试，并具有足够的覆盖率，包含代码模块和方法的意图和用法。单元测试是自动化的，具有明确的通过/失败结果。大多数语言都有 xUnit 框架（例如，nUnit、jUnit）。

所有单元测试都非常频繁地执行，并且只有在所有单元测试通过后才能签入代码。单元测试结果也有助于重构。

测试驱动开发

测试驱动开发被认为是最具创新性的极限编程实践。

在测试驱动开发中，开发人员在编写代码之前编写单元测试。目的是使单元测试失败。由于代码尚未实现，单元测试会失败。开发人员编写足够多的代码以使单元测试通过，然后，开发人员进行重构以确保代码简洁明了（没有重复和复杂性）。

开发人员迭代直到编码完成并且验收测试通过。

所有单元测试都收集在一起，每次结对集成并将代码发布到存储库时，结对都需要确保每个测试都正确运行。如果任何测试失败，则结对知道需要纠正其代码，因为之前的集成没有出现任何缺陷。

测试驱动开发往往导致 100% 的单元测试覆盖率，并确保代码简单且最少。

重构 – 设计改进

重构允许设计逐步发展，使其保持简单，消除您注意到的重复和复杂性。它通过重构来改进现有代码的设计，而不改变其功能。

重构应该由从新的实现中学习来驱动。建议在编写新代码后立即进行重构。重构将代码导向更高层次的设计模式，并得到测试的支持。

40小时工作制 – 可持续节奏

以可以无限期维持的速度工作。可持续节奏确保了人力对项目成功的贡献，考虑到以下事实：

• 疲劳和压力会降低生产力和产品质量。它可能导致员工流失。

• 开发不会随着冲刺而停止，它应该瞄准长期目标。

• 除非团队就期望达成一致，否则不会有承诺和责任感。

• 确切的小时数不如执行能力重要。

• 应避免微观管理，同时确保在需要时提供支持。