极限编程 VS Scrum

极限编程（XP）是一个敏捷软件开发框架，旨在帮助开发团队达成更高质量的开发节奏，开发更高质量的软件。XP是描述软件开发工程具体实践的敏捷框架。

Scrum是一个能够解决复杂适应性问题的敏捷开发框架，同时以富有创造力的方式交付最高价值的产品，帮助团队在复杂产品上进行有效协作。

作为敏捷方法论，Scrum和XP共享迭代式开发、发布和迭代计划、每日会议、回顾会议及其他敏捷过程涉及到的元素。在很大程度上，这两种方法是一致的，甚至有时很难将采用XP的团队和采用Scrum的团队区分。

（极限编程）

（Sprint周期）

不过两种敏捷方法并非完全一致，它们之间也有一些细微的差异，主要在以下4个方面：

1.迭代长度

Scrum：

• 通常为两周到一个月。

XP：

• 通常是一到两周。

2.是否允许在迭代中修改需求

Scrum：

• 不允许更改sprint；
• 一旦sprint计划会议完成，并做出了交付一组产品待办事项的承诺，那么在这一Sprint结束之前，这组待办事项将不会再变。

XP：

• 更容易在迭代中进行更改；
• 只要团队尚未开始研究某个特定功能，就可以将同等大小的新功能交换到XP团队的迭代中。

3.是否严格按照迭代的优先级实现用户故事

Scrum：

• Scrum产品负责人为产品待办事项安排优先级，但团队决定他们开发待办事项的顺序。
• Scrum团队很可能会选择从事第二重要的工作。

XP：

• 严格按照优先顺序工作。
• 要开发的特性由客户（或Scrum的产品负责人）确定优先级，团队需要按照这个顺序对其进行处理。

4.是否采用严格的工程方法来保证软件实施过程中的进度或质量

Scrum：

• 没有规定任何工程实践。

XP：

• 极限编程有十二个工程实践：现场客户、代码规范、每周40小时工作制、计划游戏、系统隐喻、简单设计、测试驱动开发、重构、代码集体所有、持续集成、小型发布、结对编程。

我们将XP和Scrum之间的区别总结如下：

从中，我们不难发现，XP与敏捷的结合出现了一个悖论，因为XP的思想加上敏捷模式，最终向团队传达了这样的信息：“敏捷要求团队自管理，但团队又被测试驱动开发、结对编程等工程实践约束。”

结论

Scrum作为一个敏捷软件开发框架，可以在Scrum框架的基础上添加其他实践。而极限编程的工程实践也完全适应Scrum开发框架，因此，与其在XP和Scrum之间进行选择，不如将Scrum和XP进行融合。对于刚开始实践Scrum并努力实践敏捷的团队来说，在Scrum中添加XP的工程实践可能是一条合适的道路。