本文共 4846 字，大约阅读时间需要 16 分钟。

Differences Between Scrum and Extreme Programming

Scrum and Extreme Programming (XP) are definitely very aligned. In fact, if you walked in on a team doing one of these processes you might have hard time quickly deciding whether you had walked in on a Scrum team or an XP team. The differences are often quite subtle, but they are important. I think there are four main differences between Scrum and XP:

1. Scrum teams typically work in iterations (called sprints) that are from two weeks to one month long. XP teams typically work in iterations that are one or two weeks long.

   Scrum团队典型地工作在一个从2周到4周为长度的迭代周期中（也被称为Sprints）。而XP团队典型地工作在从1周到2周为长度的迭代周期中。

2. Scrum teams do not allow changes into their sprints. Once the sprint planning meeting is completed and a commitment made to delivering a set of product backlog items, that set of items remains unchanged through the end of the sprint. XP teams are much more amenable to change within their iterations. As long as the team hasn’t started work on a particular feature, a new feature of equivalent size can be swapped into the XP team’s iteration in exchange for the unstarted feature.

   Scrum团队在Sprints迭代周期中不允许发生变更。一旦Sprint计划会议已经完成并且一份已经承诺交付的Product backlog items列表已经确定，这份列表中的内容在整个Sprint迭代结束之前不允许变更。XP团队经常在他们的迭代周期中进行变更。只要XP团队还没有开始开发一个特定的功能，在XP团队的迭代中可以使用与之前功能规模等价的新的功能来替换还没有开始开发的功能。

3. Extreme Programming teams work in a strict priority order. Features to be developed are prioritized by the customer (Scrum’s Product Owner) and the team is required to work on them in that order. By contrast, the Scrum product owner prioritizes the product backlog but the team determines the sequence in which they will develop the backlog items. I’ve never seen a Scrum team not choose to work on the highest-priority item. And a Scrum team will very likely choose to work on the second most important. However, at some point one of the high priority items may not be a good fit for the sprint being planned—maybe a key person who should work on it will be swamped by work on higher priority items. Or maybe it makes sense to work on a slightly lower priority item (let’s say #10 on the product backlog instead of #6) because the team will be working in the code where #10 would be implemented.

   XP团队的工作严格遵守优先级顺序。被开发的功能（价值）被客户（像Scrum团队中的产品所有者，Product Owner）按照优先级进行排序，XP团队将遵守这样的优先级开发。但相比之下，Scrum团队中产品负责人对Product Backlog进行优先级排序但由Scrum开发团队来确定它们将开发Product Backlog Items的顺序。我从来没有见过一个Scrum团队
   不经过选择而在具有最高优先级的Product Backlog Item上工作。Scrum团队将很有可能选择开发次要的（按照重要程度排序后的第二个）。然而，在某些时候，最高优先级的条目之一可能在本次迭代中（Sprint）不是一个适合的——可能是在优先级最高的条目上工作的一个关键的人物也难以招架。或者可能是有意义的但优先级稍低的Product Backlog（让我们说是#10 Product backlog而不是#6），因为团队将为#10 Product Backlog编码而去实现它。

4. Scrum doesn’t prescribe any engineering practices; XP does. I love the XP engineering practices, particularly things like test-driven development, the focus on automated testing, pair programming, simple design, refactoring, and so on. However, I think it’s a mistake to say to the team “you’re self-organizing, we trust you, but you must do these specific engineering practices… ” This sends a mixed message to the team that causes confusion. I love the XP practices but don’t like mandating them. I want teams to discover the value on their own.

   Scrum没有规定任何具体的实践；但是XP却有。我喜欢XP的实践，特别是像测试驱动开发，专注于自动化测试，结对编程，简单的设计，重构等等。然而，我认为对团队来说“你是自组织的，我们相信你，但你必须做这些具体的实践…”这是错误的。这会给团队带来一个混乱的信息。我喜欢XP的实践但不喜欢强制他们。我希望团队能够发现他们自己的价值。

These are small and often subtle differences between Scrum and XP. However, they can have a profound impact on the team. My typical advice to teams is “start with Scrum and then invent your own version of XP.” The XP practices are wonderful but they work best and teams commit to them the most stridently if they discover them themselves rather than having them mandated. I help teams do this in my coaching by asking questions like, “Would this bug have happened if we’d been doing test-driven development?” and “Would we have made that mistake if we were pairing?” I find true XP to be a small target off in the distance. If a team can aim at that and hit the bull’s eye, wonderful. If not, however, they are likely hacking (e.g., refactoring without any automated testing or TDD). Scrum is a big bull’s eye that on its own brings big improvements simply through the additional focus and the timeboxed iterations. That’s a good starting point for then adding the XP practices.

在Scrum和XP之间常常有细小的微妙的区别。但是，这些不同对于团队却有深刻的影响。我对于团队的建议是“先从Scrum开始然后再创建你自己的XP版本”。XP的实践很精彩但他们最好的工作和团队致力于他们最刺耳的如果他们发现他们自己，而不是强制的。我作为教练在我的指导下，帮助团队做这件事时，经常被问到：“如果我们使用测试驱动开发，这个缺陷会存在吗？””如果我们使用结对编程，我们会犯错误 ?”“我找到真正的XP是远处的一个小的目标。如果一个团队能够瞄准并打到公牛的眼睛，那就太棒了。如果不是，然而，他们可能像黑客（例如，重构但是没有采用任何自动化测试或TDD）。Scrum是一个大的靶心，对自身带来了很大的改善是通过额外的重点和时间盒。然后加入XP的实践是一个很好的起点。

转载地址：http://plvdi.baihongyu.com/