Scrum + 极限编程
极限编程是最早出现的敏捷方法之一，并且不断发展。极限编程的发明者 Kent Beck 以使用最佳编程实践并将其发挥到极致为前提开发了极限编程。
当前情况下的极限编程专注于目前行业中盛行的最佳实践，并将其发挥到极致。最常见的例子是测试驱动开发、全团队方法、可持续步伐等。
XP – 灵活性作为技术
极限编程如此受欢迎的原因之一是其灵活性。此外，极限编程更多的是关于技术而不是过程，因此与以过程为中心的方法很好地融合在一起。因此，您可以轻松地将极限编程的功能与其他想法结合起来，无论在哪里
一些极限编程实践在过程中是互补的。
极限编程本身并不适合实施。
但是，请记住，您选择的任何极限编程实践都应实施到其核心。否则，您不能声称您正在使用极限编程。
事实上，对于您采用的任何过程都是如此。允许混合搭配，但前提是您使用的是互补功能，并且您不会损害所使用功能的价值。
目前使用的最流行的极限编程混合是 Scrum + 极限编程混合。我们将从基本且仍然流行的软件开发方法——瀑布模型开始。
瀑布模型
在瀑布模型中，开发分阶段进行，在早期阶段完成之前不能开始任何阶段。
瀑布模型仍在一些组织中使用，尽管有些人认为它是一种传统方法。如果在开发开始之前完全了解需求，它是一种成熟且有效的方法。该过程很简单，不需要任何培训或指导。
您需要记住的是，没有一种方法适用于每种情况，每种方法都有自己的优点和缺点。因此，您必须了解哪种方法适合您的上下文、环境和客户利益。
让我们来看看瀑布方法的缺点 −
由于所有需求都必须在开发开始之前了解，因此当需求不完整或模糊时，该方法并不适用。
由于该方法是面向未来的，因此任何阶段的反馈都无法带回到任何早期阶段，尽管可以获得有关最终产品的更多清晰度。
仅在开发完成后才进行测试，由未参与早期阶段(例如需求收集或开发)的开发人员团队进行。这种最后测试方法通常会导致缺陷控制、高缺陷率、交付缺陷被客户发现的概率高。
工作产品直到开发结束才会可用，因此虽然开发正确，但没人知道是否构建了正确的东西。
缺陷修复和需求变更很难被吸收，因为很有可能破坏设计，而且产生的成本也很高。
如果您预测开发中会出现这种情况，敏捷方法最适合。
敏捷方法
敏捷方法提倡 −
频繁发布工作产品增量，使反馈能够及时流入。
以团队为中心的方法，让每个人都对最终结果负责产品。
灵活的规划，专注于向客户交付价值、满足客户期望、实现投资回报。
随时准备在开发的任何阶段接受变更，以便交付的最终产品不会过时。
出现了几种敏捷方法，其中 Scrum 变得越来越流行，并被广泛使用。
Scrum 如何与众不同?
在 Scrum 中，项目被分解为发布和时间限制的短冲刺。对于每个冲刺，您只需要处理客户优先考虑的、您可以在冲刺中交付的必需和足够的功能。在每个冲刺结束时，您将拥有一个可以发布的工作产品。
需求称为待办事项，迭代称为冲刺。将采用测试优先方法进行持续测试。开发人员和测试人员也参与编写用户故事，即待办事项。这样可以让团队中的每个人都提前了解产品的行为，也有助于在冲刺开始时就达到验收标准。
正如我们之前所说，Scrum 的定义在某些情况下是有效的，但与任何其他开发方法一样，它也有自己的缺点。
时间限制的冲刺不会在发布计划中提供任何灵活性，这会妨碍开发和测试。
Scrum 本身并不提供开发方向。
因此，Scrum 通常与其他更注重开发策略的敏捷方法相结合。
Scrum + 极限编程混合
Scrum 的使用频率相当高结合互补的极限编程实践，极限编程侧重于工程方面，例如持续沟通、频繁反馈循环、重构、集体所有权、持续集成、测试驱动开发等，而 Scrum 侧重于冲刺、燃尽图等的固定范围。
由于 Scrum 是一种定义好的方法，因此从项目的第一天开始就更容易适应。
由于极限编程更注重沟通和团队凝聚力，因此团队更专注于开发。
因此，Scrum + 极限编程混合被发现是有效的。
Scrum + XP 混合项目的工具
SpiraTeam 和 Rapise 等工具适用于 Scrum + 极限编程混合项目。SpiraTeam 在一个为 Scrum 和极限编程量身定制的统一视图中提供关键项目质量和进度指标的报告仪表板项目。
一些指标是−
- 需求测试覆盖率
- 任务进度
- 项目速度
- 主要风险和问题
Rapise 工具是一种测试自动化解决方案，可以完全集成到您的开发过程中，并适应您不断变化的需求。您可以使用它来测试桌面、Web 和移动应用程序。开发人员、测试人员和业务用户可以使用此工具来生成验收测试。
