Bob大叔关于Scrum和敏捷的7条缺陷

作者 Mark Levison 译者 张晓庆 发布于 2010年2月13日

领域

过程 & 实践

主题

敏捷技术 ,

敏捷实施 ,

敏捷

标签

Failure ,

认证 ,

Scrum ,

自组织团队

在回应Scrum/Agile的固有缺陷这一问题时，Bob大叔写下这“7条”。他说Scrum天生有一些严重的缺陷（他强调说明：很多团队采用Scrum来避免这些问题）：

• 缺乏技术实践:Scrum是一个项目管理框架，在技术方面没给任何建议。Bob建议团队“需要从其他诸如XP的方法中借鉴技术实践。这套技术实践可能包括：TDD、持续集成、验收测试、结对编程、重构。”
• 30天的冲刺周期太长：多数讲师现在建议冲刺周期1-2周，大多数团队采用的是2周。
• Scrum教练有时变成了项目经理:有些Scrum教练把Scrum当作微管理和控制的一种形式。“这不是Scrum固有的问题，而是Scrum发展中遇到的问题。或者这要怪‘master’这个单词了。”
• 对产品Backlog的指导太少：“经过多年实践，我们知道了backlogs有很多分层次的实体，包括史诗、主题、故事等等。我们学会了怎么对它们估计；学会了怎么把高层次的实体拆解成低层次：史诗->主题->故事->任务。”
• Scrum暗中包含反管理：“Scrum过度强调了团队自管理的角色。自组织和自管理的团队本身是好的,但是具有局限性...Scrum的描述并没有给与很好的平衡。”
• 自动化测试：没有高质量的自动化测试，很难以短的迭代周期工作，很难知道故事是否真的做完了。
• 多团队：Scrum和通用的敏捷方法很少谈及怎样扩展，虽然很多实践者有一些想法，但是还没有达成广泛的一致。

MX Logic的软件开发主管Steve Ropa说：“我个人的经验是：在一定层次上，团队和成员需要领导。有时候领导来自于团队，但有时候不行。我感觉Bob大叔是说在团队和业务的交流上会产生局限，而这正是我的经历。”

Mark Woyna反击说“如果团队定期交付高质量的产品，客户比较满意，还要管理干什么？如果团队没有交付，尝试自我修正也不行，团队应该去寻求外部的帮助。”

《C#极限编程探险》一书的作者Ron Jeffries说：“多数Scrum团队所在的公司都有管理人员，并且在用他们。事实上这样对Scrum不但无益，而且经常由于管理人员的有意诋毁，使得Scrum被错误实施。”

Matt Heusser，软件工匠和测试专家，则建议:“更准确的说，应该把认证scrum教练描述成‘介绍一种新的产品开发方法’。这能把课程从软件开发中扩展开来，吸引整个团队，而不是团队中的一两个人。课程结束时可以发给一个证书，而不使用华丽虚饰的单词，比如‘认证’”。

《精益和敏捷开发应用指南》的作者之一Bas Vodde对讨论内容做了修订：“不应该把它叫做缺陷，相反应该指出Scrum本身需要其他实践的支持”。此外他不认为Scrum暗中包含了反管理，相反：

我认为许多人采用Scrum都会遇到这样的困难，即怎样处理管理角色的变化。自管理的团队确实把职责派发到团队中，因此管理的角色会发生变化。但太多的时候管理层认为“他们”不需要变化就可以使用Scrum这个框架（而不是命令...“你来做Scrum！”这已经意味着失败）。

我认为这不是Scrum特有的，如果深入研究自管理团队的历史和文献，会发现管理角色的变化是一个普遍的话题。然而，与任何其他角色类似，如果被告知当前的任务不需要再做，很容易把这理解成“反”的。

在你看来，Scrum和敏捷有什么缺点呢？

InfoQ之前的类似新闻： 失败的敏捷项目，12 Agile Adoption Failure Modes，为什么有些公司敏捷实施不成功

参见英文原文：Scrum/Agile Failings or the Theses of Uncle Bob Martin

译者 张晓庆 有多年的软件开发经验，主要是J2EE项目、Web应用和分布式系统等等，在电信网管开发方面经验丰富。

• 更早的 >