(1)我们的最高目标是，通过尽早持续地交付有价值的软件来满足客户的需求。
(2)欢迎对需求提出变更，即使在项目开发的后期也不例外。敏捷过程要善于利用需求变更，帮助客户获得竞争优势。
迅速应对和适应变化，能给客户带来显著的竞争优势，从而应对新的机遇
(3)要经常交付可用的软件，周期从几周到几个月不等，且越短越好。
(4) 项目实施过程中，业务人员与开发人员要必须始终通力协作。
传统项目中负责商业价值的人员和软件开发人员是严格分开工作的
(5)要善于激励项目人员，给予他们所需的环境和支持，并相信他们能够完成任务。
(6)无论是对开发团队还是团队内部，信息传达最有效的沟通方法都是面对面的交谈。
非正式的口头沟通在敏捷项目管理中远比正式的书面沟通更普遍
敏捷项目中的沟通都是公开的，任何团队成员都可以自由参与对话
(7)可工作软件是衡量进度的首要指标。
传统项目往往极其纠结的是，项目的不断更新使得文件成为一种负担
真正的价值是通过结果来表达的，结果又是通过可用的软件来呈现的
(8)敏捷过程提倡可持续的开发。项目发起人、开发人员和用户应该都能够始终保持步调稳定。
敏捷项目比传统项目有更高的近作强度)（尤其是使用XP这样的方法时）
保持一个稳定的可持续的进展速度，从而使得团队成员不会在迭代周期的尾端匆忙赶工
(9)对技术的精益求精以及对设计的不断完善将提高敏捷性。
稳定和优质的项目比劣质的项目更加允许团队快速应对变化
(10) 简洁，即尽最大可能减少不必要的工作，这是一门艺术。
关键点是对客户价值保持专注和毫不犹豫地削减不增加价值的活动
(11)最佳的架构、需求和设计将出自于自组织团队。
自组织团队，即该团队自己去决定工作如何分配及谁去做某个特定的工作
不仅小团队是自我组织的，较大的跨职能团队也可以是自我组织的。
不存在某个人对架构、需求、测试负责的情况，整个团队共同承担这些责任
(12)团队要定期反省怎样做才能更有效，并相应地调整团队的行为。
传统项目里，当项目或阶段完成时开会总结是最常见的做法
在一个回顾活动中，查看上个迭代周期中已完成的工作或发布，
并评估下一次如何改进他们的做法
每日站立会议是另一项协调团队努力方向、团队自我评定和自我调整的重要方式
