敏捷软件开发 - 原则、模式与实践 —— 敏捷开发（一）

本文为敏捷软件开发 - 原则、模式与实践系列的一部分。

本文对应原书第1章和第2章。

敏捷软件开发宣言

• 个体和交互 胜过 过程和工具

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

• 客户合作 胜过 合同谈判

• 响应变化 胜过 遵循规则

敏捷开发原则

1. 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
2. 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势
3. 经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
4. 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作
5. 围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作
6. 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交流
7. 工作的软件是首要的进度度量标准
8. 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度
9. 不断地关注优秀的技能和好的设计会增强敏捷能力
10. 简单 - 使未完成的工作最大化的艺术 - 是根本的
11. 最好的架构、需求和设计出自于自组织的团体
12. 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整

极限编程实践

1. 客户作为团队成员。客户是定义产品特性并排列特性优先级的人。
2. 用户用例。
3. 短交付周期。迭代计划，两周一个迭代。发布计划，6个迭代一个发布。
4. 验收测试。自动化验收测试。
5. 结对编程。
6. 测试驱动开发。先编写单元测试，再实现代码，结果代码和完整的单元测试集共同形成。有利于重构。
7. 集体所有权。
8. 持续集成。
9. 可持续的开发速度。
10. 开发的工作空间。
11. 计划游戏。开发提供功能特性工作量列表，客户按照优先级指定本次迭代或发布的功能特性。
12. 简单设计。
    a. 考虑能够工作的最简单的设计
    b. 你将不需要它
    c. 允许犯错，但只有一次。对于不好的代码，发现立刻消除它们。例如重复代码。
13. 重构。重构就是在不改变代码行为的前提下，对其进行一系列小的改动，旨在改进系统结构的实践活动。重构是持续进行的。
14. 隐喻。它是将整个系统联系在一起的全局视图。通常可以归结为一个名字系统，这些名字提供了一个系统组成元素的词汇表，并且有助于定义它们之间的关系。

完整内容请查看敏捷软件开发 - 原则、模式与实践系列