第一章 敏捷实践

1.敏捷软件开发宣言

1）个体和交互 胜过 过程和工具

这里体现了敏捷开发中以人为本的理念，软件是人编出来的，如果这个活动离开了人，是行不通的。团队的作用是十分地重要的。

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

这里持续不断地频繁地交付可以工作的软件比耗费巨大的精力和时间浪费在文档的写作上要高明得多。没有文档的代码是一场灾难，单过多的文档比过少的文档要更糟糕。文档过多会导致其难以维护，所以一个优秀的文档时致力于系统的总体框架的说明，其总的页数不应超过二十页。具体的细节的东西应当使用代码来说话，代码是没有其他二义性的语言；在培养团队中的新成员的方法上，要采用面对面的交流方式，最好的两份文档时代码和团队。

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

学会让客户参与到项目之中来，那些希望与一个软件编写团队签订一份合同而到达期限后收取代码的方式是不对的，这将使得项目遭受巨大的挫折。要积极与客户进行相关的交流。

4）相应变化生活遵循计划

我们在构建计划时应当确保计划时灵活的并且易于适应商务和技术方面的变化。计划不能考虑地太远，因为商务环境和用户的需求是变化的，要不断地根据这些变化来调整自己的计划。

一个理想的计划时：为下两周做详细的计划，为下三个月做粗略的计划，再以后就做极为粗糙的计划。我们应当清楚地指导下两周要完成的任务，粗略地了解一下三个月内实现的需求，对于未来有一个模糊的想法就好了。这种意味着我们只有对于迫切的任务才花费时间进行详细的计划，对于未来只有模糊的框架。这样在保证了计划灵活性的基础上，增加了现行的效率。

2敏捷软件的规则

1)我们最优先要做的是通过尽早的持续的交付有价值的软件使得客户满意；

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

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

4）在整个项目开发期间，业务人员和开发人员必须天天在一起工作；

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

6）在团队中，面对面交谈时最有效率和最富有效果的传递信息的方法；

7）工作的软件是好药的进度衡量标准，而不是以代码数来决定；

8）敏捷过程提倡可持续的开发速度，不能采用冲刺式的开发，而导致后期没有持续力；

9）不断地关注优秀的技能和好的设计；

10）简单

11）自组织的团队

其中敏捷开发的规则与敏捷开发宣言是部分对应的，它更像是对于宣言的一种解释。

第二章 极限编程概述

首先，是讲的客户。客户要作为开发团队成员。何谓客户？大家都常常在说客户这个词，XP团队中的客户是指定义产品的特性并排列这些特性优先级的人或者团体。有时客户是跟开发人员同属一家公司的业务分析师或市场专家。有时客户是用户团体委派的用户代表。有时客户是支付开发费用的人。

其次，user stories. 我不知道为什么user story被翻译成用户素材，这让我极为不习惯，总觉得别扭。user story是正在进行的关于需求谈话的助记符。它是个计划工具，可以使用它并根据它的优先级和估算代价来安排实现该需求的时间。

第三，短交付周期。

1、迭代计划。 每次迭代通常耗时两周。user story会被分解为任务，开发人员完成对这些任务的开发。

2、发布计划。大概计划随后大概6次迭代的内容。发布通常需要3个月的工作。

第四，验收测试。是在实现user stories之前或者实现user stories的同时进行编写。

第五，结对编程。也就是说两个程序员共用一台电脑完成。其中一个负责控制键盘敲入代码，另一个观察代码寻找错误进行改进。（这个还是很诡异的，国外实现了已经）。两人频繁互换角色。结对的关系每天至少要改变一次。以便于每个程序员在意天真可以在两个不同的结对中工作。一次迭代期间，每个团队成员应该和所有其它团队成员在一起工作过，并且应该参与了本次迭代的每项工作。

第六，测试驱动的开发方法。

第七，集体所有权。

第八，持续集成。使用nonblocking源代码控制工具。

第九，可持续的开发速度。这是一场马拉松。规则是不允许加班。

第十，开放的工作空间。

第十一，计划游戏planning game.本质是划分业务人员和开发人员的职责。业务人员决定feature的重要性，开发人员决定实现一个特性所花费的代价，即提供预算。

第十二，简单的设计

第十三，重构。持续进行，每个一个小时或半个小时就去做的事情。

第十四，隐喻metahpore。它是将整个系统联系在一起的全局视图。

第三章 计划

3.1 初始探索

深究、分解和速度

3.2发布计划

3.3迭代计划

3.4任务计划

迭代的中点

3.5迭代

3.6结论

第四章 测试

编写单元测试是一种验证行为，更是一种设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功能验证方面的反馈循环。

为了成为易于调用和可调式的，程序必须和它的周边环境解耦。这样，首先编写测试迫使我们接触软件中的耦合。

第五章 重构

随着时间的推移，现有的代码会 有 新特性、新功能的添加，需要处理一个又一个的错误，代码的结构逐渐退化。如果对此置之不理的话， 这种退化最终会导致纠结不清，难于维护的混乱代码。 xp（极限编程 eXtreme Programming）团队通过经常性的代码重构来扭转这种退化。重构就是在不改变代码行为的前提下，进行一系列小的修改，旨在改进系统结构。每个改造都是微不足道的，几乎不值得去做，但是所有的这鞋改造叠加在一起，就形成了对系统设计和构架的显著的改进。

    每一个软件模块都有三项职责：

        1、它运行起来所完成的功能。这也是该模块得以存在的原因。

        2、它要对应变化。几乎所有的模块在它们的生命周期中都要变化，开发者的职责保证这种改变应该尽可能的简单。一个难以改变的模块是拙劣的，即使能够工作，也需要对它inx修正。

        3、要和阅读它的人进行沟通。对模块不熟悉的开发人员应该能够比较容易地阅读并理解它。哟个无法进行沟通的模块也是拙劣的，童谣需要对它进行修正。

    在每次细微的改造之后，我们运行单元测试确保改造后没有造成任何破坏，然后去做下一次改造，如此往复，周而复始，每次改造之后都要运行测试。通过这种方式，我们可以在改造系统的同时，保持系统可以工作。重构是持续进行的， 而不是在项目结束时、发布版本时、迭代结束时、甚至每天快下班时进行的。重构是我们没隔一小时或者半小时就要去做的事情。通过重构，我们可以持续地保持尽可能干净、简单并且具有表现力的代码。

    总结：

    重构的目的是为了每天 清洁 你的代码，代码的清洁怎么强调都不过分！

    重构不仅 要使程序结构的各个部分之间相互隔离，也就是节耦合，甚至包括一个变量名、函数名的修改。

    重构应该是伴随着开发一起进行的。