Scrum 到底有多教条？

Scrum 被视作是一种适应性和灵活性俱佳、旨在改进开发过程的软件开发方法。多年以来，Scrum 的成功案例比比皆是。然而，一些团队依然察觉到许多刻板、教条之处。这究竟是Scrum 本身有问题，还是实践过程有瑕疵呢？

Terry Bunio 在他写给 Scrum 的信中提道，起初他对 Scrum 的过程、流程是何等着迷。可是渐渐地，他认识到框架的条条框框无益于项目成功所需的自由。

我的确需要这样一个流程，在 sprint 期间，让我能够追加合情合理的需求。我不希望讨论仅限在回顾时间，尤其当我觉得还有很多需要讨论……我痛恨被称为 Scrum Master。当前这一角色仿佛弱化了我作为项目经理的价值，使我仅仅变成个流程教练，而非一名有价值的团队成员。我感到事实上我不再是团队的一分子了。

Marek Blotny也觉得每日站立会议限制太多。Marek 不喜欢团队成员“保持沉默”直到轮到他们说话。他认为这无疑扼杀了天然的知识共享。他还提到，有时也没有必要坚持 15 分钟的硬性限制。如果整个团队正在热火朝天地讨论，就应该顺其自然。

因此如果你问我，强制执行如此刻板的日常 Scrum 架构是否合理。我会回答……肯定不合理！一方面，你要利用有效的 Scrum 实践来促进团队合作，另一方面，还要摒弃死板教条、事事照本宣科。

Rod Claar 提出，尽管 Scrum 很灵活，一些 Scrum 团队为了确保一开始就正确实施，则倾向于将它严格化。 Rachel Davies 在一些实施 Scrum 的团队也见过此类倾向。她谈到，

我一旦听到 Scrum Master 或团队试图“照着书本做 Scrum”，就会为自己敲响警钟。Scrum 是团队通向敏捷软件开发旅程中的一个起点。使用 Scrum 并非真正的终点。我们要运用 Scrum 来增量式发布产品。没有人要来跟着你的团队，检查你 Scrum 做得是否规范。

Geoffrey Wiseman 补充道，流程严格和敏捷并非必然形同水火。流程可以规定，一旦 sprint 开始就不得有任何干扰。Sprint 可以被看作是计划和实现的基础（atom），但它肯定也对实际操作中的灵活性敞开了怀抱。

这是强制条款吗？或许是。一些人也许会争论，如果你无法遵循那些约束，就不应该采用那个流程。不过实事求是地讲，Sprint 能在某一资源临时调整后继续进行吗？当然，我认为肯定能行。

因此，流程的严格程度一定要根据团队的想法来设定。虽然恪守约束，避免整个流程体系走向混乱是很好的，但过于教条以至于无视实际情况同样不利于项目和团队。

查看英文原文： How Rigid is Scrum