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"