Scrum + 极限编程

极限编程是最早出现并不断发展的敏捷方法之一。Kent Beck 是极限编程的倡导者，他开发极限编程的前提是使用最佳编程实践并将其发挥到极致。

当前场景中的极限编程侧重于目前业界流行的最佳实践，并将其发挥到极致。最常见的例子是测试驱动开发、整体团队方法、可持续步伐等。

XP – 灵活性作为技术

极限编程如此受欢迎的原因之一是它的灵活性。此外，极限编程更多的是关于技术而不是过程，因此与以过程为中心的方法很好地融合。因此，无论身在何处，您都可以轻松地将极限编程的功能与其他想法结合起来

但是，请记住，您选择的任何极限编程实践都应该实施其核心。否则，你不能声称你正在使用极限编程。

事实上，对于您采取的任何流程都是如此。混合搭配是允许的，但前提是您使用互补功能并且不损害所使用功能的价值。

目前使用的最流行的极限编程混合是 Scrum + 极限编程混合。我们将从基本且仍然流行的软件开发方法论——瀑布模型开始。

在瀑布模型中，开发分阶段进行，在前一阶段完成之前，任何阶段都不能开始。

瀑布模型仍在一些组织中使用，尽管有些组织将其视为传统方法。如果在开发开始之前完全了解需求，那么这是一种既定且有效的方法。该过程非常简单，不需要任何培训或指导。

您需要记住的是，没有一种方法适合所有情况，并且每种方法都有其自身的优点和缺点。因此，您必须了解哪种方法适合您的背景、环境和客户兴趣。

让我们看看瀑布方法的缺点 -

由于所有的需求都是在开始开发之前就知道的，所以当需求不完整或模糊时就不适合。
由于该方法是朝一个方向前进的，因此任何阶段的反馈都不能返回到任何早期阶段，尽管最终产品会更加清晰。
仅在开发完成后才由未参与早期阶段（例如需求收集或开发）的开发人员团队进行测试。这种最后测试的方法通常会导致缺陷遏制、高缺陷率、高交付缺陷，而这些缺陷却被客户发现。
工作产品直到开发结束才可用，因此没有人知道是否正在构建正确的产品，尽管它正在正确开发。
缺陷修复和需求变更很难被吸收，因为破坏设计的可能性很高，而且产生的成本也很高。

如果您预测开发中存在此类情况，那么敏捷方法是最合适的。

敏捷方法论倡导者 -

多种敏捷方法论应运而生，其中 Scrum 变得更加流行并被广泛使用。

在 Scrum 中，项目被分解为版本和有时间限制的短期冲刺。对于每个冲刺，您将仅采用客户确定优先级并且可以在冲刺中交付的所需且足够的功能。在每个 Sprint 结束时，您将拥有一个可以发布的工作产品。

需求称为积压项目，迭代称为冲刺。将采用测试优先方法的连续测试。开发人员和测试人员还参与用户故事的编写，即积压项目。这可以为团队中的每个人提供产品Behave的预先视图，并且还有助于在冲刺本身开始时达到验收标准。

正如我们之前所说，Scrum 根据其定义在某些情况下是有效的，但与任何其他开发方法一样也有其自身的缺点。

因此，Scrum 通常与其他更关注开发策略的敏捷方法相结合。

Scrum 经常被用来结合互补的极限编程实践，极限编程侧重于工程方面，如持续沟通、频繁的反馈循环、重构、集体所有权、持续集成、测试驱动开发等，而 Scrum 则侧重于工程方面冲刺、燃尽图等的固定范围

因此，Scrum + 极限编程混合被认为是有效的。

SpiraTeam 和 Rapise 等工具适用于 Scrum + 极限编程混合项目。SpiraTeam 在专为 Scrum 和极限编程项目量身定制的综合视图中提供关键项目质量和进度指标的报告仪表板。

一些指标是 -

Rapise 工具是一种测试自动化解决方案，可以完全集成到您的开发流程中，并适应您不断变化的需求。您可以使用它来测试桌面、Web 和移动应用程序。开发人员、测试人员和业务用户可以使用该工具来生成验收测试。