1.我们最优先要做的是通过尽早的，持续的交付有价值的软件来使客户满意。
比较实在的道理，不用多说了。"初期交付的系统中所包含的功能越少，最终交付的系统的质量就越高"。功能慢慢的实现，比较不会容易出错。
2.即使到了开发的后期，也欢迎改变需求，敏捷过程利用变化来为客户创造竞争优势。
这一点很难得，很少有人在开发后期还能对需求的变化面带微笑的。
3.经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
让客户心里放心，客户至上。对远比一大堆漂亮的文档更有效。
4.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
力保开发的最终软件是客户所真正需要的。
5.围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
程序员是我们实现价值的最基本元素，他们应该得到最充分的尊重。
６.在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交流。
face to face 的交流，人都是社会动物，交流，还是简单一点的好
7.工作的软件是首要的进度度量标准。
为什么比能工作的软件更有实际意义！！
８.敏捷过程提倡可持续的开发速度。责任人，开发者和用户应该能够保持一个长期的，恒定的开发速度。
９.不断地关注优秀的技能和好的设计会增强敏捷能力
不断地学习，才会不断的提高。Learning is like rowing upstream,not advance is to drop back.
10.简单--使未完成的工作最大化的艺术---是根本的。
简单，这是我的处事的原则，也是解决问题的原则，能一句话说清楚的事情，就不要说两句。但对于coding,可能多写几条代码才会使问题简单代，太简的代码，反而会复杂，当然，这并不绝对。
11.最好的构架，需求和设计出自于自组织的团队。
一个好的团队的力量，是不可估量的。
12.每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
人要成长，团队也要成长。
比较实在的道理，不用多说了。"初期交付的系统中所包含的功能越少，最终交付的系统的质量就越高"。功能慢慢的实现，比较不会容易出错。
2.即使到了开发的后期，也欢迎改变需求，敏捷过程利用变化来为客户创造竞争优势。
这一点很难得，很少有人在开发后期还能对需求的变化面带微笑的。
3.经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
让客户心里放心，客户至上。对远比一大堆漂亮的文档更有效。
4.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
力保开发的最终软件是客户所真正需要的。
5.围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
程序员是我们实现价值的最基本元素，他们应该得到最充分的尊重。
６.在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交流。
face to face 的交流，人都是社会动物，交流，还是简单一点的好
7.工作的软件是首要的进度度量标准。
为什么比能工作的软件更有实际意义！！
８.敏捷过程提倡可持续的开发速度。责任人，开发者和用户应该能够保持一个长期的，恒定的开发速度。
９.不断地关注优秀的技能和好的设计会增强敏捷能力
不断地学习，才会不断的提高。Learning is like rowing upstream,not advance is to drop back.
10.简单--使未完成的工作最大化的艺术---是根本的。
简单，这是我的处事的原则，也是解决问题的原则，能一句话说清楚的事情，就不要说两句。但对于coding,可能多写几条代码才会使问题简单代，太简的代码，反而会复杂，当然，这并不绝对。
11.最好的构架，需求和设计出自于自组织的团队。
一个好的团队的力量，是不可估量的。
12.每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
人要成长，团队也要成长。
受关注文章