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