Scrum 扩展“中止”

  • Christopher R. Goldsbury
  • 郑柯

2012 年 7 月 18 日

话题:敏捷Scrum语言 & 开发架构文化 & 方法

Scrum 扩展已经“中止”。这是从Scrum.org放出的最新消息,针对社区提出的、对 Scrum 方法论有争议性的补充。InfoQ 对于 Scrum 扩展的报道从 2011 下半年开始,当时 Scrum.org 宣布:对于Ken SchwaberJeff 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" 

敏捷Scrum语言 & 开发架构文化 & 方法