1.我们最优先要做的是通过尽早的，持续的交付有价值的软件来使客户满意。
有一篇文章分析了对于公司构建高质量产品方面有帮助的软件开发实践，其中一个实践表明尽早的交付具有部分功能的系统和系统质量之间具有很强的相关性。文中说，初期交付的系统中所包含的功能越少，最终交付的系统的质量就越高。从该文中还发现，以逐渐增加功能的方式经常性的交付系统和最终质量之间有非常强的相关性。交付得越平凡，最终产品的质量就越高。敏捷实践会尽早的，经常的进行交付，我们努力在项目刚开始的几周内就交付一个具有基本功能的系统，然后我们努力坚持每2周就交付一个功能渐增的系统，如果客户认为目前的功能已经足够了，客户可以选择把这些系统加入产品中，或者他们可以简单的选择在检查一偏已有的功能，并指出他们想要的改变。
2。即使到了开发后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势：
这是一个关于态度的申明。敏捷过程的参与者不惧怕变化，他们认为改变需求是好的事情，因为那些改变意味桌团队已经学习到了很多如何满足市场需要的知识。敏捷团队会非常努力的保持软件结构的灵活性，这样当需求变化时，对于系统造成的影响是最小的。
3。经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好：
我们交付可以工作的软件，并且尽早的，经常性的交付他，不赞成交付大量的文档或设计计划
4。在整个项目开发期间，业务人员和开发人员必须天天都在一起工作
为了能够一敏锐的方式进行项目开发，客户，开发人员以及涉众之间就必须要进行有意义的，频繁的交互
5。围绕被激励起来的个人构件项目，给他们提供所需要的环境和支持，并且信任他们能够完成工作。
在敏捷项目中，人被认为是取得项目最成功最重要的因数，所有其他因数--过程、环境、管理等等都被认为是次要的。
6。在团队内部，最有效果的信息传递方式是面对面的交流
7。工作的软件是首要的进度度量标准、
敏捷项目通过度量当前软件满足客户需求的数量来度量开发进度，他们不是根据所处的开发阶段、已经编写的文档的多少或这已经常见的基础结构代码的数量来度量开发进度的，只有当30%的必须功能可以工作时，才可以确定进度完成了30%
8。敏捷过程提倡可持续的开发速度。责任人、开发者和用户应能够保持一个长期的、恒定的开发速度
敏捷项目不是50米短跑，而是马拉松长跑，团队不是以全速启动并试图在项目开发期间维持那个速度；相反，他们以快速但是可持续的速度行进。
9。不断的关注优秀的技能和好的设计会增强敏捷能力
高的产品质量是获取高的开发速度的关键，保持软件尽可能的简洁、健壮是快速开发软件的途径。因而，所有的敏捷团队成员都致力于只编写他们能够编写的高质量代码。他们不会制造混乱然后告诉自己等自己有更多的时间在来清理。
10。简单
敏捷团队不会试图去构建那些华而不实的系统。
11。最好的架构、需求和设计出自于自组织的团队
敏捷团队是自组织的团队，任务不是从外部分配给单个团队成员，而是分配给整个团队，然后再由团队来确定完成任务的最好方法。
12。每隔一段时间，团队会在如何才能更有效地更有效的工作方面进行反省，然后相应地对自己的行为进行调整。
