英文原文：Drinking the Scrum Kool-Aid
Brian de Haaff 在博文“关于‘Scrum’的激烈论争”中指出，那些声称 Scrum 可以拯救企业的人是错误的。
Brian 说，虽然要尊重一些人对 Scrum 宗教般的狂热，但也应该明白为什么会存在“Scrum 狂热者”。他提供了两种关键的动机：
#1 工程师喜欢创建东西
如果没有发明家和工程师，世界会在哪里？很可能还在山洞里狩猎和采集。工程师创建了我们生活的世界，以及我所深知的由制造重要物品所驱动的一切。Scrum 是一种帮助工程师专注于创建的有效方法。它提供了一套准则，用于在一次接一次的冲刺中按照优先级交付真实可用且具备业务质量的软件。把事情做好并把相应的项从清单中划掉是有益的，而 Scrum 可以保证总是有一个长长的清单，总是有下一项工作可以完成。Scrum 可以保证有一个永不完结的待办事项清单。
#2 工程师不喜欢被吼
说真的，没有人喜欢被吼。Scrum 可以帮助工程经理和工程团队，使他们避免因为无法预测完工日期而被吼，因为 Scrum 不是日期驱动的。Scrum 削弱了“日期因素”的观念，并提供了一种方法，使工程师可以有条不紊地由一个功能转到下一个功能，而且没有在规定日期交付工作的压力。
虽然 Brian 承认，在定义和管理如何设计产品方面，Scrum 是一种行之有效的方法，但争论的关键是，Scrum 并没有为创建优秀的产品或者杰出的企业提供必要的输入。
我认为，人们普遍将 Scrum 描述为一种改革或交付优秀产品的方法，这是其真正挑战的开始。优秀的产品源于“为什么”包含“什么”以及“如何”交付。Scrum 用于“如何”交付是个好方法。这是一种可以为开发生产设施带来效率的方法，在有些环境中工作得很好。
然而，Scrum 没有解释“为什么”，而这正是产品如何讨人喜欢并赢得市场的潜在策略。
Scrum 的一项潜在原则是，它不会神奇地提供“为什么”。Ken Schwaber 在其著作《Scrum 敏捷项目管理》中写道，产品愿景必须已经明确。
开始一个 Scrum 项目所需的最小计划要包含产品愿景和产品 Backlog。愿景描述为什么开展该项目以及理想的结束状态是什么。
Brian 断言，在没有“为什么”的情况下，“如果工程师总是专注于已排序事项中的下一项，那么 Scrum 会对此造成妨碍。” Ilan Goldstein 在 Axis Agile 上的一篇博文中指出，如果没有产品愿景，那么团队最终只会专注于做他们知道的“什么”和“如何”那样的事：
带着快速投入和开始创建‘东西’的渴望，新的 Scrum 团队经常会把全部注意力都放在‘什么’（产品 Backlog）和‘如何’（冲刺 Backlog）上。这就像把运货马车放在了马的前面，因为正是在考虑‘什么’和‘如何’之前，我们需要认真地考虑‘为什么’。这个‘为什么’不会在产品 Backlog 或者冲刺 Backlog 中找到，而是包含在一个称为产品愿景的不言自明的独立工件中。
Brian 总结道，在纵饮“Scrum 急救液”之前，重要的是要保证没有盲目地将 Scrum 看作万灵药：
毫无疑问，Scrum 是一项重大举措，它对于工程团队生产力的积极影响无处不在。然而，它仍然只是一种简单的开发方法，而不是创建颇为可观的企业和交付优秀产品的灵丹妙药。在涉及产品交付时，Scrum 只占整个过程的 33%。
Scrum 无法拯救企业或者世界，因此要提防有人在你家门口敲门。狂热者来了。
相关文章
