SQ3R阅读法
Survey：浏览
1、书名：《Extreme Programming explained:Embrace Change》,中文译名《解析极限编程：拥抱变化》；
2、作者：Kent Beck（肯特·贝克），美国著名软件工程师与作家，在软件工程方面有很大的贡献。他是Smalltalk软件的开发者，设计模式的先驱，测试驱动开发的支持者，也是极限编程的创始者之一。现在Facebook工作。
维基百科摘录：
Beck全家似乎都弥漫着技术的味道。生长在硅谷, 有着一个对无线电痴迷的祖父，以及一个电器工程师父亲。从小就引导Kent Beck成为了业余无线电爱好者。在俄勒冈州大学读本科期间，Kent Beck就开始研究起模式。然而在他最终拿到计算机学位之前，他却是在计算机和音乐中交替学习。似乎Java大师都能够有这样的能耐，另一Java大牛Rod Johnson同样也拥有音乐学的博士学位。 Kent Beck一直倡导软件开发的模式定义。早在1993年，他就和Grady
Booch（UML之父）发起了一个团队进行这个方面的研究。虽然著有了《Smalltalk Best Practice Patterns》一书，但这可能并不是Kent Beck最大的贡献。他于1996年在DaimlerChrysler启动的关于软件开发的项目，才真正地影响后来的软件开发。这次的杰作就是XP（极限编程）的方法学。和软件开发大师Martin Fowler合著的《Planning Extreme Programming》可谓是关于XP的奠基之作。从此，一系列的作品如《Test
Driven Development: By Example》，《Extreme Programming Explained: Embrace Change》让更多的人领略到了极限编程的精髓，也逐步导致了极限编程的流行。Kent Beck的贡献远不仅如此。对于众多的Java程序员来说，他和Erich Gamma共同打造的JUnit，意义更加重大。也许正式这个简单而又强大的工具，让众多的程序员更加认可和信赖极限编程，从而引起了Java敏捷开发的狂潮吧。
Questions（提出问题）
1、什么是XP？
XP是一套软件开发规则，它没有新的概念，甚至好多都是存在很久的。它的创新之处在于把这些实践结合在一起，并彻底地执行它们，并确保这些实践在最大程度上相互支持！
2、XP适用于哪些情形？
XP适用于中小型团队在需求不明确或者需求迅速变化的情况下进行软件开发的轻量级方法学。
3、本书结构
本书分三个部分：
第一部分：问题——提出XP试图解决的问题，并提出用来评估解决方案的标准；
第二部分：解决方案——将第一部分的抽象概念转换为具体方法论的实践，但不会确切地说明如何实现这些实践，而是讨论大体结构；
第三部分：实现XP——如何采用XP来进行工作。
Read：
第一部分：问题
第一章 最基本的问题：风险
1、常见的风险以及XP如何化解？
（1）进度延迟——XP要求发行周期较短，最多为几个月；一个发行周期内，要求对客户提出的功能进行一到四周的迭代，最后要求优先实现优先级较高的功能。
（2）项目取消——XP让客户选择具有最大业务意义的最小版本，从而在投入生产前减少发生错误的机率；
（3）系统恶化——XP创建并维护一整套测试程序，每次发生变化后都要运行测试程序，以确保质量；
（4）缺陷率高——XP测试时，既遵从程序员按逐条功能编写测试程序的观点，又遵从客户按逐个程序特性编写测试程序的观点；
（5）业务误解——XP要求客户成为整个团队的一部分。
（6）业务变更——XP缩短了版本周期，因此每个版本的开发过程中的变化就少；
（7）错误过多——XP强调只专注于具有最高优先级的任务；
（8）人员调整——XP要求程序员承担估算和完成自己工作的责任，并将实际花费时间进行反馈，以改进他们的估算。
第二章 开发过程
1、XP开发的完整过程
（1）结对编程
（2）TDD驱动开发
（3）结对程序员不仅让测试用例运行，还要改进系统设计
（4）开发之后接着进行集成，以及集成测试；
第三章 软件开发的经济学
1、从经济上考虑，为了使软件开发更有价值，我们需要减少开销，加快收益并增加项目的可能的高效生产期，但最重要的是我们需要增加用于业务决策的选择。
第四章 四大变量
1、软件开发过程中的四大变量
（1）成本——钱多一点可以促进工作顺利进行，但是太短时间内投入太多金钱会产生更多无法解决的问题；
（2）时间——更长的交付时间有助于提高质量和扩大范围；
（3）质量——有意识的牺牲质量，可能在短时间内获利，但是未来耗费的成本是巨大的！
（4）范围——更小的范围有助于提高质量。
2、专注于范围
（1）范围是一个变化很大的量——因为客户根本不知道自己想要的是什么！
（2）XP对控制范围的解决办法
a、进行大量估算和反馈实际结果的工作；
b、优先完成客户最重要的功能！
第五章 变化的成本
1、软件工程中一个普遍的假定是修改程序的成本会随着时间的推移而以指数方式上升！——但是现在这个假设不再正确了！
2、XP能够实现的结果是：随着时间的推移，修改成本是一个平滑的曲线！
（1）简单的设计
（2）自动测试
（3）改进设计
第六章 学会开车——我们需要反馈来知道我们何时犯了错，而且需要能够以比较合理的成本来完成纠正！每次修改一小步！
1、软件中的一切东西都是变化的，需求变化、设计变化、业务变化、技术变化、团队变化、团队成员变化，只有变化才是永远不变的！
2、问题不在于变化，因为变化总是发生的，问题在于发生变化时没有能力应对！！
第七章 四大准则——衡量我们方向是否正确的标准！
1、XP的四个准则
（1）沟通——项目出现问题的一大原因是因为沟通出现问题！
（2）简单——简单和沟通是相互支持的关系，沟通越多，要做的越简单！
（3）反馈——乐观是编程的一大忌，而反馈则是良药！
（4）勇气——要有勇气更改体系结构的错误，要有勇气放弃原有的代码！
第八章 基本准则——知道我们进行具体的实践！
1、基本准则
（1）快速反馈——行动与反馈之间的间隔是学习的关键！
（2）假设简单性——把每个问题都看做可以用近乎荒谬的简单方法来解决！
（3）递增更改——每次修改一点点！
（4）提倡更改——最佳的策略就是在实践中运用最多的办法！
（5）优质工作——出色完成工作是每个人的希望！
第九章 回到基本问题——开发过程的基本工作！
1、开发过程中的基本工作
（1）编码——编码是最佳的实践！
（2）测试——不能测试的功能是不存在的！
（3）倾听——不懂业务的程序员不是合格程序员！
（4）设计——好的设计使系统能够扩展！
第二部分 解决方案
第十章 简短概述——依靠简单的实践之间的合作！
1、所有简单实践清单
（1）计划游戏——任何事情计划先行！
a、业务人员需要决定的内容：
- 范围——对系统而言，将问题解决到什么程度是有价值的！
- 优先级——确定哪个更重要!
- 版本的组成——软件完成多少才能使业务能够因为使用了该软件而改善状况！
- 发布的日期——软件发布会造成重大影响的日期！
b、技术人员需要决定的内容：
- 估算——实现一个功能需要花费多长时间！
- 后果——有些战略性的业务决策只有了解到技术后果后才能确定！
- 过程——如何组织工作和团队！
- 详细的日程设计——在一个版本里面，先完成哪些内容！
（2）小版本——每一个版本尽可能的小，包含最有价值的业务需求！
（3）隐喻——引入隐喻，易于沟通和阐述体系结构！
（4）简单设计——去掉任何可以拿掉而不违反规则的设计！
（5）测试——没有经过自动化测试的功能是不能够存在的！
（6）重构——重构是优化系统的捷径！
（7）结对编程——效率更高的编程！
（8）集体所有权——任何人发现改进任何代码的机会，都可以进行立即执行！（XP中每个人都对系统负责！）
（9）持续集成——减少出差机会！
（10）每周工作40小时——XP规则很简单，不能连续两周加班！
（11）现场客户——真实的客户必须与团队一起工作！
（12）编码标准——标准可以减少沟通成本！
第十一章 如何凑效——实践相互支持，一种实践的弱点可以由其他实践的优点来弥补！
1、任何实践都难以独挡重任，它们需要其他实践来帮助保持平衡！
第十二章 管理策略——使用商业基本要素全面管理项目
1、度量——制作大的可视表，对任务总量进行度量！
2、指导——好的教练是一个好的沟通者！
a、衡量教练的标准是她做出了多少个技术性决策！
3、跟踪——搜集某个时刻所有正在跟踪的测试数据，确保团队的实际进度！
4、干预——管理人员进行干预，可能是人员变动，可能是终止项目！
第十三章 设备策略——为团队创建开放的工作空间，外围是小的私人空间，中间是公共编程区！
第十四章 拆分业务责任和技术责任——技术人员把精力集中在技术问题上，业务人员把精力集中在业务问题上！
1、项目必须由业务决策来驱动，而技术决策则要给业务决策提供有关成本和风险的信息！
2、业务方和开发方任何一方得到权力过大，都会对项目造成损害！
第十五章 计划策略——迅速制定一个总体计划，然后在越来越短的时间内逐步将其完善！
1、制定计划是猜测为客户开发一套软件 的情况是什么样的过程！
2、制定计划的目的
（1）团结和组织团队开发
（2）决定范围和优先级
（3）估算成本和日程
（4）让大家对系统的成功信心百倍
（5）为反馈提供一个基准
第十六章 开发策略——背离传统的开发观念，我们认真制定今天问题的解决方案，并相信我们能够在明天解决明天的问题！
1、开发策略从迭代计划开始，持续集成减少了开发冲突并为开发过程创造了一个自然而然的结尾，集体所有权鼓励整个团队改善整个系统，最后结对编程将整个过程联系在一起！
2、持续集成——几个小时就集成一次！
3、集体所有权——复杂代码不会生存很长时间！
4、结对编程——值得用整个后半生来研习并得益！
第十七章 设计策略——永远使用能运行当前测试套件的最简单设计！
第十八章 测试策略——在编码前编写测试，并一直保留这些测试，并频繁地运行全部测试！
1、单元测试和功能测试是测试策略的核心！
2、其他测试
（1）并行测试——显示出新系统与旧系统之间差异的测试；
（2）压力测试——模拟可能的最高负载测试；
（3）灵活测试——确保遇到无意义的输入时能做出有意义的反应的测试。
第三部分 实现XP——实现上一部分的策略！
第十九章 采用XP——一次一种实践地采用XP。始终处理团队最紧急的问题！
1、实现XP的步骤
（1）找出最紧急的问题；
（2）以XP方式解决它；
（3）重复上述步骤！
第二十章 改进XP
第二十一章 理想的XP项目的生命周期——任意两个XP项目都不可能是完全相同的！
1、XP项目的声明周期
（1）探索
（2）计划
（3）第一本迭代
（4）生产
（5）维护
（6）死亡
第二十二章 人员的角色——程序员、客户、教练、跟踪者！
1、程序员——XP的核心
2、客户——极限编程中的重要组成部分！
3、测试员——负责编写功能测试
4、跟踪者——最好估算、收集反馈
5、教练——负责整个过程
6、顾问——帮助解决某个领域深入的技术知识问题
7、大老板——提供团队勇气、信心以及放权！
第二十三章 20-80原则——XP需要集合全部实践才能发挥最大功效！
1、程序员们喜欢使用20-80原则——80%的效益来自于20%的工作！
第二十四章 使XP难以执行的原因——人的恐惧心理！
1、XP在细节上很简单，但是执行起来很困难！
第二十五章 什么时候不应该使用XP——团队太大、客户多疑以及技术不能很好地支持更改！
第二十六章 工作中的XP——使用适用于XP的合同！
第二十七章 结论——XP让你克服心中的恐惧！
Recite:
Review: