Scrum 扩展“中止”

Scrum 扩展已经“中止”。这是从 Scrum.org 放出的最新消息，针对社区提出的、对 Scrum 方法论有争议性的补充。InfoQ 对于 Scrum 扩展的报道从 2011 下半年开始，当时 Scrum.org 宣布：对于 Ken Schwaber 和 Jeff Sutherland 最早制定的 Scrum 流程，他们会接受具备上下文的修改建议。从那时起，InfoQ 每个季度定期更新（ 2011 第四季度、 2012 第一季度）Scrum 扩展的进展状况。

“中止”这个新闻很突然，引出不少人问“为什么？”。Scrum.org 的官方说法是：

刚刚接触 Scrum 的组织，或是挣扎采纳敏捷实践的组织，他们能受益于更有经验的敏捷实践者的智慧和指导。Scrum 扩展的本意是希望形成一种机制，让社区去核查这些经过实践检验的、有效的实践以及相关文档，然后把这些指导性的东西交给大家。

我们这些在 Scrum.org 的人认识到了类似指导的需求，但我们也意识到：扩展的方式并不是大家期望的方式。我们很感激向社区提交扩展建议的人。有鉴于此，Scrum.org 将会很高兴地继续存放这些扩展，尽管这些扩展是以白皮书形式、而不是以支持 Scrum 框架的形式提交的。

但对于 Scrum 扩展的这个想法，从一开始就有争议，而且有些疑问仍然存在。在 Yahoo! 中关于建议扩展的讨论区上，有一次对于“规划卡片游戏”令人心痛不已的争论，此次讨论也许导致了 Scrum 扩展的最终失败。我们把讨论中的一些摘要放在下面，其中有很多知名的敏捷教练和实践者，包括 Ken Schwaber 等人。

Mark Levison 大声表明了自己对于 Scrum 扩展的看法：

这些对于 Scrum 的扩展让我深感不安。好像我们走上了 RUP 的老路。比如，这里有一个出色实践的列表，专门为你的需求打造。问题在于，RUP 初学者倾向于同时做很多实践。而真正的理念应该是只做一部分。当我在讲授 Scrum 时，我很早就会说：“Scrum 很简单，而且不完整。”接下来我会提到用户故事和估算（根据 Mike Cohn 的方式）。然而，我不认为这两个实践应该放到 Scrum 中去，即使作为扩展也没有必要。看起来我们是要开始修补这样一个成功而又简洁的系统了。恶龙降临。

Ron Jeffries 响应了 Mark 的情绪：

我强烈反对“Scrum 扩展”的做法，但是出于不同理由。我的理由包括：

• 扩展这样的提法，无疑让 Scrum.org 能够控制哪些东西在 Scrum 中可行，哪些不行。这对任何人都不好，即使是 Scrum.org。
• 到目前为止，这些扩展并没有把功劳归功于最初创造他们的人，也没有归功于已经实施了多年的那么多实践者。而且，这些扩展似乎是那些从未真正使用过它们的人撰写的。这真是没有尊重和效率低下的极品组合。
• 要想在 Scrum 中成功，团队需要做很多 Scrum 中没有提到的事情。Scrum 的基本前提——自组织，要求团队必须、能够、愿意去找出哪些对他们最好。扩展这种说法与自组织直接冲突，因此伤害了 Scrum 的理念和实践。
• 把某些活动提升为“扩展”，其他活动至少会在潜意识中被人认为没有被提升。然而有很多实践活动也非常重要，而且比起这个敲竹杠式的“卡片规划”提法有价值得多。扩展这个理念更有可能让团队感到掣肘，而不是帮到他们。

我喜欢使用卡片做规划和估算，如果有人必须要估算的话。（我的确认为估算在实践中通常不是好主意。）我认为没有人需要尝试 Scrum 扩展，或是必须用它才能成功。目前看来，所有提交的扩展都是这样的：更好的想法，只不过在别处描述得更好。

Ken Schwaber 的说法是：

当 Jeff 和我刚开始公布 Scrum 时，我们在其中放入了一部分实践，比如版本规划、Sprint Backlog 的格式，以及 Sprint 规划会议的最佳结构。随着人们不断使用 Scrum，衍生出很多同样有效的变通方案。随着这些实践不断涌现，它们的有效性也得到了证明，我们开始把一些“初学者”实践从 Scrum 中拿掉。实践者因此得到鼓励，用自己的最佳实践满足他们自己的要求。然而，结果就是：除了书籍、培训和教练课程外，没有其他的指导了。

我们认为：一种称为“扩展”的实践模型，可以帮助 Scrum 实践者。这些实践称为 Scrum 扩展，因为我们以 Scrum 为中心。如果 Scrum 团队不能熟练使用这些实践，Scrum 就可以发现导致这种情况的问题。如果使用得当，这些实践就能提升开发出高质量、高价值软件的可能性，同时还能管理风险和可预测性。

这些实践当然并不完美（又有什么是完美的？）。然而，它们有力、有效、有指导性。它们将会随着时间进化。未来，我们将会在最初版本发布的时候写明归属人，或者当正确的作者通知我们的时候，我们会再告诉大家。我们当然会把规划扑克的功劳放在 James Grenning 头上，并且会帮人们理解：菲波那契数列中的数字是前两个数字之和（1、2、3、5、8、13、21、34……【译注：Ken 此处明显带有情绪……】）。

这些扩展，就是我们和 Scrum 社区已经长期使用而且认为是有效的实践。我们会发布它们，并在编辑和评审流程后向社区推荐这些扩展实践。

我认为有必要重申：这些实践不是 Scrum 的一部分。它们是软件开发的最佳实践，Scrum 也揭示了对它们的需求。当我走进一间绘画用品店，会有一些小册子推荐如何画出清晰的边缘、如何去掉旧颜料、如何填充空洞等等。你画画时可以不用它们，但是结果可能不是很好。Scrum 和软件开发实践之间的关系也是如此。

所有人都看到我们这个职业需要帮助，而且能有一点儿是一点儿。我感谢所有认为这次行动出于好意的人们。

最后，看来反对 Scrum 扩展的人们信服了 Scrum.org 的领导力。Brett Wortman 的评论也许代表了很多人的心声：“Scrum 的魅力在于其简洁和不完整。这就是它为什么能够如此成功。”然而，笔者还是想留下这个问题：社区是不是丧失了讨论并让 Scrum 进化的机会？或者在这个实验正式启动前就把它干掉，这是最好的做法吗？更一步说：对于像 Scrum 模式语言这样的新想法，这次的决策会有什么影响？

查看英文原文： Scrum Extensions “Suspended”