《敏捷宣言》及其背后的12准则
《敏捷宣言》
我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观：
 个体与交互 重于 过程和工具
 可用的软件 重于 完备的文档
 客户协作   重于 合同谈判
 响应变化   重于 遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者。

《敏捷宣言》背后的12准则
我们遵循以下准则：
我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
项目过程中，业务人员与开发人员必须在一起工作。
要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
可用的软件是衡量进度的主要指标。
敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
对技术的精益求精以及对设计的不断完善将提升敏捷性。
要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
最佳的架构、需求和设计出自于自组织的团队。
团队要定期反省如何能够做到更有效，并相应地调整团队的行为.

谈敏捷不提《敏捷宣言》就像去东北没见过翠花的酸菜一样。咱先上翠花的酸菜：《敏捷宣言》及其原则。
“人”以及“人与人的互动”
Individuals and interactions
 胜于
over  “过程”和”工具”
processes and tools

可运行的软件
Working software
 胜于
over  面面俱到的文档
comprehensive documentation

客户合作
Customer collaboration
 胜于
over  合同谈判
over contract negotiation

响应变化
Responding to change
 胜于
over  遵循计划
over following a plan 

在此，我试图对《敏捷宣言》作些解读：
◆方法套路要灵活——方法和工具是死的，人是活的，人要是太“面”或者协作不好，再强大的方法和工具都是白扯；
◆文档的编制要创新——上百页的项目报告没人乐意写，更没几个人乐意读。好在大家现在用结绳记事的人不多，要不得用多少绳子打多少扣啊？干的就是软件的活，却还用很原始的文字描述，难道这又是中国万恶的教育制度惹的祸？咱不是为人师表的灵魂工程师，咱就是弄点“软的(soft)东西(ware)”，所以只有软件能跑起来，才能算有建设性。码文字？不是咱的长项！
◆重新看待“合同”——这一条可能是针对非自用软件的生产的。咱没接过对外的服务合同，所以也没太多切身的体会。但俺意会一下，就是做人要厚道，不要太斤斤计较，最终把软件做好了，你好我好大家好，到时候再论功行赏，皆大欢喜。
◆弄清项目管理中的“计划”——“计划赶不上变化”。要是计划一点都不会变的话，人在执行计划过程中的自主能动性、创造性就体现不出来，计划也就是没必要由人来完成了。我们应该拥抱变化，积极应对变化，而不应死板地遵循预先的计划。那计划还有什么意义呢？我觉得计划是理清工作思路的作用，也就是要“抬头看路”。响应变化就是“低头拉车”了。

敏捷宣言背后遵循的原则：
1.产品设计开发过程中最重要的是：通过及早并频繁地交付有价值的软件来赢得客户的满意。
2.要欢迎改变需求，即使是在开发的后期。敏捷过程中的“变”，是为了让客户保持竞争优势。
3.交付要频繁，交付的软件要可运行。交付周期从数周到数月不等，但间隔的时间要尽量短。
4.在整个项目过程中，开发人员必须每天都与业务人员一起工作。
5.项目组所选的人要积极。然后，给予他们工作所需要的环境、支持和信任。
6.面对面交谈是开发团队内部和开发团队间传递信息最有效率和效果的方法。
7.可运行的软件是衡量进度的首要指标。
8.敏捷过程提倡可持续的开发。出资人、开发者和用户应始终保持稳定的步调（迭代周期）。
9.对技术的精益求精以及对设计的不断完善，将会提高敏捷性。
10.尽量去掉不必要做的工作——这就是“简洁”的艺术。
11.最佳的架构、需求和设计产生于自组织的团队。
12.团队要定期反思“如何能变得更有效率”，然后对自己的行为进行相应的优化和调整。

http://developer.51cto.com/art/201009/225390.htm