一、 敏捷实践
1. 敏捷宣言
个体与交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
1.1 个体与交互胜过过程和工具
合作、沟通以及交互能力要比单纯的编程能力更为重要。
工具要选用合适的，不要一开始就盲目选择所谓强大的。要从小工具开始尝试，直到无法适用再去更换。
1.2 可以工作的软件胜过面面俱到的文档
面面俱到的文档需要花费大量的时间成本来编写和维护。过时的文档比没有文档更具危害性。
Martin文档第一定律：直到迫切需要并且意义重大时，才来编制文档。
1.3 客户合作胜过合同谈判
一个指明了需求、进度以及项目成本的合同存在根本上的缺陷。大多数情况下，合同中指明的条款远在项目完成之前就会变得没有意义。
那些为开发团队和客户的协同工作方式提供指导的合同才是最好的合同。
1.4 响应变化胜过遵循计划
需求永远不会绝对稳定，响应变化的能力常常决定着一个软件项目的成败。
较好的做计划的策略是：为下两周做详细的计划，为下三个月做粗略的计划，再以后就做极为粗糙的计划。
2. 原则
从上述价值观中引出的12条原则，它们是敏捷实践区别于重型过程的特征所在。
2.1 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2.2 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
2.3 经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
2.4 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
2.5 围绕被激励起来的个人开构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。
2.6 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
2.7 工作的软件是首要的进度度量标准。
2.8 敏捷过程提供可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
2.9 不断的关注优秀的技能和好的设计会增强敏捷能力。
2.10 简单--使未完成的工作最大化的技术--是根本的。
2.11 最好的架构、需求和设计出自于自组织的团队。
2.12 每隔一段时间，团队会在如何才能更有效的工作方面进行反省，然后相应的对自己的行为进行调整。
二、 极限编程
1. 极限编程实践
1.1 客户作为团队成员
1.2 用户素材(user stories)
用户素材(user stories)，也可叫做 用户故事，就是正在进行的关于需求谈话的助记符。
它是一个计划工具，客户可以使用它并根据它的优先级和估算代价来安排实现该需求的时间。
1.3 短交付周期
1.3.1 迭代计划
每次迭代通常耗时两周。这是一次较小的交付。
开发人员通过度量在以前的迭代中所完成的工作量来为本次迭代设定预算。
1.3.2 发布计划
XP团队通常会创建一个计划来规划随后大约6次迭代的内容，这就是所谓的发布计划。它表示了一次较大的交付。
1.4 验收测试
用户素材的验收测试需要在实现素材钱或者实现素材的过程中完成。
验收测试使用能够让它们自动并且反复运行的某种脚本语言编写。
1.5 结对编程
1.6 测试驱动的开发方法
编写所有产品代码的目的都是为了使失败的单元测试能够通过。
测试用例循序渐进的对代码的编写进行指导。
编写测试用例的好处是 可以用来验证修改过的代码，有利于重构；促使你编写可测试的代码，可有效的对代码解耦。
1.7 集体所有权
1.8 持续集成
每次签入代码时，需要跟其他的签入合并。为了避免合并的时间过长，团队的成员会非常频繁的签入他们的模块。
1.9 可持续的开发速度
1.10 开放的工作空间
1.11 计划游戏
计划游戏的本质是划分业务人员和开发人员之间的职责。业务人员决定特性的重要性，开发人员决定实现一个特性所花费的代价。
在每次发布和每次迭代的开始，开发人员给予上一次中他们所完成的工作量来为客户提供一个预算。客户在这个预算内选择用户素材。
1.12 简单的设计
a 考虑能够工作的最简单的事情
b 你将不需要它：不要对未来考虑的过多。
c 一次，并且只有一次：不要容忍重复的代码，使用抽象来消除重复。
1.13 重构
代码往往会腐化。重构就是在不改变代码行为的前提下，对其进行一系列小的改造，旨在改进系统结构的实践活动。
每次改造之后，要运行单元测试以确保改造没有造成任何破坏。
1.14 隐喻
隐喻是将整个系统联系在一起的全局试图。
后记
本篇介绍了敏捷开发的一些基本原则，下一篇将针对原则中的 计划、测试、重构 做详细的介绍。