Scrum敏捷开发原则，包括12项：

1．尽早、持续地交付有价值的软件或产品来使用户满意

前使用产品需求说明书或者测试用例来编写详细的需求，敏捷开发使用用户故事来罗列需求，规划迭代用户故事时必须按照优先级安排。

通过频繁迭代与用户形成良好的合作关系，及时反馈，不断完善和提高产品质量。敏捷开发小组关注的是完成和交付具有用户价值的功能，对于不能给用户带来价值的功能，坚决不做。

2.  即使到了开发后期，也欢迎改变需求

传统的瀑布式开发最大的缺点之一是对变化及变更的响应比较慢，难度大且成本高。

敏捷开发过程利用变化来为用户创造竞争优势，参与者不怕变化，他们认为改变需求是好事情，因为这些改变意味着他们更了解市场需求，更加以用户和市场需求为导向，与市场需求保持同步。

3．经常交付可以工作的软件，交付时间间隔越短越好

传统的瀑布式开发最大的缺点之一就是产品投放市场的时间太慢，一款产品的研发周期太长，很有可能会错失市场良机，而敏捷开发过程强调小步快跑，不断试错。

4．在整个项目开发期间，业务人员和开发人员必须天天在一起工作

有过异地沟通经验的人都知道，异地沟通成本很高，而且沟通的效率有时也很低，如果业务人员和开发人员天天在一起工作，有什么问题好面对面地沟通解决，这样效率高，成本低，也有利于团队内部信息的同步，减少不必要的麻烦。

5．围绕被激励起来的个人构建项目

业务和技术是引起不确定的两个主要方面，人是第三个方面，而业务和技术又必须由人来执行，所以能够激励人解决这些问题是解决不确定性的关键。要使个人的目标和团队的目标一致，就需要调动每个人的积极性，以个人为中心构建项目，提供所需的环境、支持与信任。

6．在团队内部，最具有效果且富有效率的传递信息的方法是面对面的交谈

在十几或者二十几个人组成的团队中，书面文档是一种比较合适的传递信息和沟通交流的途径，而敏捷团队一般不会有很多人，因为大团队实施敏捷方法时也会分成多个小的敏捷团队，所以大量的文档交流和沟通其实并不合适，面对面的交谈反而更快速、有效，沟通成本低，效率高。

7．工作的软件或产品是首要的进度度量标准

敏捷过程最终关注的交付物必须是用户可用的。一般的工作都比较容易衡量任务进展，比如，完成多少百分比了，还剩下多少百分比，在产品功能没有编码和测试完成之前，都不能以编写了多少行代码，运行了多少个测试用例来度量这个产品功能是否完成了。衡量这个功能是否完成的首要标准就是这个功能可以工作了，对用户来说已经可以使用了。

8．敏捷过程提倡平稳的开发节奏，发起人、开发者和用户应能保持一个长期、恒定的开发速度

在国内有很多互联网和移动互联网公司，在没有实施Scrum敏捷开发之前，开发人员加班加点、熬通宵是司空见惯的，在实施了Scrum敏捷开发之后，开发人员一到下班时间就消失得无影无踪了。敏捷开发过程希望能够可持续地进行开发，开发速度不会随着迭代的任务不同而不同，这与人在跑步的时候一样，突然加速快跑冲刺肯定消耗大量体力，也就是说，不平稳的开发节奏消耗的能力会比较多。

9．不断地关注优秀的技能和好的设计会增强敏捷能力

对于在敏捷过程经过验证的工具、技术解决方案、开发模式等都可以加以总结，在后续的迭代过程中都可以灵活应用，提高开发的效率，增强敏捷开发的能力。

10．简单化是根本（不做过度设计和预测）

需求千变万化，我们不可能预期后面的需求会如何变化，所以不可能一开始就构建一个完美的架构来适应以后的所有变化，想做到一劳永逸，也是非常不现实的。敏捷开发团队不会去构建明天的软件或产品，而是把注意力集中在通过最简单的方法完成现在需要解决的问题。

11．最好的构架、需求和设计出自于自组织的团队

在自组织团队中，管理者不再发号施令，而是让团队自身寻找最佳的工作方式来完成工作。

在经历了初期的磨合后，成员才会开始对团队共同的工作理念与文化形成一个基本的认识和理解，团队内会逐渐形成规矩，而且这些规矩是不言而喻的。

自组织团队是一个自动自发、有着共同目标和工作文化的团队，这样的团队总是在向它的组织做出承诺。

12．团队会定期对前一个迭代进行反省总结，以便调整自己的行为，提高开发效率

由于很多不确定性因素会导致计划失败，比如，项目成员增减、用户需求的改变、竞争者对我们的影响等都会让我们做出不同的反应。敏捷开发不是基于预定义的工作方式，而是基于经验性的方式，对以上这些变化，小组通过不断总结、反省和调整，来保持团队的敏捷性。