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

在回应 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