也读《敏捷软件开发》--- 敏捷原则

《敏捷软件开发--原则、模式与实践》一书，非常不错，特别适合作为小团队（3~6人）的软件开发指导，读这本书的时候，书中提到的一些原则与模式也是我们开发中经常会有意无意会用到的，比如涉及到迭代开发等软件开发方法论相关、常用设计模式等代码设计相关，收益匪浅。下面对要点做一下记录：

1.敏捷宣言
1）个体交互胜过过程和工具
要点：团队合作、沟通以及交互能力要比单纯的编程能力更为重要。

记住，团队的构建要比环境的构建重要的多。许多团队和管理者就是犯了先构建环境，然后期望团队自动凝聚到一起的错误。相反，首先致力于构建团队，然后再让团队基于需要来配置环境。

2）可以工作的软件胜过面面俱到的文档

文档是不可少的：系统架构、设计原理这一类的文档时必不可少的。但是，过多的文档是不可取的，过度编制文档本来就会很费时费工，而且由于软件一直在变化，维护文档也需要代价。

在给新成员传授知识时，最好的文档就是代码和团队交互。代码能够真实的反映软件的功能；团队成员中保持者系统的设计和原理图，通过人与人交互的方式，能够高效的使得新人融入到团队开发中来。

3）客户合作胜过合同谈判

成功的项目需要有序的、频繁的客户反馈。而不是依赖于合同或者关于工作的陈述，而是让软件的客户和开发团队密切的一起工作，并尽量地提供反馈。（这一点，在开发中深有体会）

4）响应变化胜过遵循计划

响应变化的能力常常决定着一个软件项目的成败。当我们构建计划时，应该确保计划的灵活并且易于适应商务和技术方面的变化。（学会拥抱变化--软件需求变更）

2.敏捷原则
1）我们最优先要做的是通过尽早的、持续的有价值的软件来使客户满意

2）即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

3）经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。

4）在整个项目开发期间，业务人员和开发人员必须实时的交互。

5）围绕被激励起来的个人来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

6）在团队内部，最具有效果并且富有效率的专递信息的方式，就是面对面的交流。

7）能够工作的软件，迭代的版本或实现的功能是首要的进度度量标准。

8）敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。（不是短跑，是马拉松。保持充沛体力是关键）

9）不断关注优秀的技能和好的设计会增强敏捷能力。（不断学习新的开发技能，提供效率）

10）简单（以最简单的、能够满足当前需求的方式完成工作，不过度预测）

11）最好的架构、需求和设计出自于自组织的团队。（由团队共同决定选出最优的任务分配和问题解决方案）

12）每隔一段时间，团队在如何才能更有效的工作方面进行反省，然后相应地对自己的行为进行调整。（环境在变，团队也要顺时而动，保存敏捷性）