Scrum 是一个框架，而不是方法论

Scrum 不是一种方法论

现存所有的IT和软件产品交付的方法论都具有这样的特征：内容详细、流程严格、顺序具有强制性的一些过程和程序，实现预先定义好的算法。所有的步骤、每一种可能的情况都被详细地记录下来。对于问题X，请见手册的第n页。方法论取代了创造性、自主性和对产品的主动思考，比如对各个阶段、各项任务、必须做的一些预研、技术和工具的思考。只要遵从这个方法论，即使结果还没有出来，也没有人会觉得有事，因为结果在文档中已经有了。方法论依赖的是对预先给定算法的结果的高度可预见性。传统的方法论建立在这样的信念之上，即：产品开发是一个简单的活动，这个活动可以被计划并且执行结果具有高度的可预见性。然而这个信念在实践中被一次又一次地证明无效。
 
Scrum基于这样的事实，即：产品开发是复杂的，具有极度不可预测性，过程也充满了许多不确定性。虽然Scrum是一种系统的方法，即：经验过程控制的一种规范性应用，但对于如何尽快地交付产品，Scrum中并没有给出详尽、规范的设计和规划方案，更别提如何记录、签署、移交或者归档这些方案。Scrum中没有具体规定需要预先交付的文档类型方案和可交付物方案的内容，也没有规定产品开发的时间。基于拖延、浪费时间和资源等原因的考虑，Scrum去掉了IT业的一些典型做法，比如产品各阶段之间的移交、关键阶段控制点、过程监控会议等。
 
Scrum 不是一个混杂在一起的指令性的食谱手册大集合。它也不是一个方法论。Scrum把经验主义演变成一种科学的方法。它用启发方式取代了编程算法的方式，在相互尊重和自组织的基础上，去应对产品开发过程中的各种不可预知性，并解决那些复杂的问题。Scrum是一个过程吗?
如果Scrum是一个过程，那么它肯定不是一个可重复的过程（可预见或者步骤可重复）。这对我们的认知是一种挑战，因为“过程”这个术语通常都是调用预知的算法步骤、重复的操作并控制过程自上而下执行；有点像是一种…方法论。
 
Scrum可不是这样的命令性过程，如果非要说它是一个过程，那么它也是一个服务性过程。对产品开发过程中的所有参与者和他们的工作来说，最有效方法就是应用Scrum和Scrum的各项规定。参与者发现要想应用好Scrum，就必须要缩小中间结果和预想输出结果的差距。Scrum是一个过程，它有助于揭示真实的过程、结构和工作方式，并不断地适应实际的环境和当前的状况。因此，我们更愿意称Scrum为一种框架。

Scrum是一个框架

作为一个框架，Scrum以一种弱规定的方式，按照特定原则对产品开发中各个角色和各项规则进行了描述，为开发者提供辅助和便利。相应内容在Scrume指南中均有明确描述。虽然方法很少，但每一个方法都能解决一个常见的产品交付挑战。
 
Scrum框架为产品开发提供了多种选择和策略，也提供了顺应环境和状况变化的方式，开发团队在其中可以找到自我。Scrum的核心价值在于对Scrum团队的活动和行为给予指导，并不断完善框架本身。
 
经过近20年的Scrum应用，Scrum指南中的Scrum规则不断演进，已经有多次小功能更新和发布。Scrum的解决方案需要放对地方才能充分发挥其优势，然而在开发复杂产品的时候，Scrum的解决方案却更多地被用在强调“要做什么”而不是指导“如何去做”。
 

作者：tracy_hope（可译网作者）