BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Scrum扩展“中止”

| 作者 Christopher Goldsbury 关注 0 他的粉丝 ,译者 郑柯 关注 3 他的粉丝 发布于 2012年7月20日. 估计阅读时间: 7 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

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" 

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT