第一部分：1 - 来源

Scrum是一个能够用来开发复杂产品的管理框架。Scrum来源于知识管理，复杂适应系统和经验主义的流程控制理论。公认起源于一份Nonaka和Takeuchi于1986年发布的研究报告：The New，New Product Development Game。Scrum也从Lean借鉴许多知识。

Scrum是目前所有敏捷方法当中最流行的。在2013年，72%的宣称自己实施敏捷的团队或单独使用Scrum，或将Scrum与其它方法结合使用。更多有关敏捷和其它方法的信息参考“更多关于敏捷和Lean”。

 

现有方法存在的问题

l  发布时间过长

l  稳定需要很长时间

l  变更很难实施

l  质量下降

l  时间点要求让人很难受

长期以来，软件开发人员都在尝试使用定义化的方法开发和管理项目。定义化的方法适用于用户需求以及交付成果非常明确的场合。软件开发或其它复杂的工作不适合使用这样的定义化方法。而高比例的项目失败以及客户的不满意也正好证明了这一点。

 

Scrum如何解决问题

Alistair Cockburn将软件开发定义为“创新和沟通的合作游戏”。

传统的开发理论依赖于文档的记录以及将知识从一个专业人员传递到另一个专业人员。反馈时间太长甚至不存在反馈。大量未达到绩效的项目也显示这样的工作方法失败透顶。

2012年8月，Gartner发布一篇名为“我们熟知的瀑布模式的终结”的文章。它阐述了持续时间过长的瀑布模式是软件发布的最高的风险所在。

Scrum提供了一个有效协同工作和可视化的风险预测平台。

我发现许多首席级别的经理（C-Level）都明白下面这个传统项目管理模式和敏捷模式之间的对比。

在传统的预测型模式中，项目经理尝试通过约束项目范围来提供可信的项目预算及项目日程。在实践中，我们会碰到“三角约束”【即范围，成本和时间】，而质量往往被忽视。而在敏捷当中，时间和成本被认为是约束条件。产品经理与项目团队合作来迭代和持续交付最大价值的产品。计划与现实符合。

我发现高级别的利益相关者非常乐于见到项目能够达到时间和成本要求，至少时间和成本能被控制住。当然，项目范围作为变量确实非常让人感到担心。我的做法是寻求以及确认明确的项目约束。