第一部分 敏捷开发
第一章 敏捷实践
敏捷软件开发
个体和交互 -》 过程和工具
- 可以从一个小工具开始使用，直到不合适之后，再进行更换
- 不要认为，更大，更好的工具可以自动帮你做的更好。通常它们的阻碍大于帮助
- 记住：团队的构建大于环境的构建
可以工作的软件 -》面面俱到的文档
- 没有文档的的软件是一种灾难。代码不是传达系统原理和结构的理想媒介
- 团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行描述
- 过多的文档比过少的文档更可怕 时间、误导
给新成员传授知识方面，最好的两份文档是代码和团队
- 代码是惟一没有二义性的信息源
- 团队成员的头脑中，保存着时常变化的系统脉络图（road map）。人和人之间的交互是把这份脉络图传授给他人的最快，最有效的方式
直到迫切需要并且意义重大时，才来编写文档
客户合作 -》合同谈判
- 不能像订购日用品一样来订购软件。你不能够仅仅写一份关于你想要的软件的描述，然后就让人在固定的时间内以固定的价格去开发它。所有用这种方式来对待项目的尝试都以失败而告终。
- 成功的项目需要有序，频繁的客户反馈
- 哪些为开发团队和客户的协同工作方式提供指导的合同才是最好的合同
- 成功的关键在于和客户之间真诚的协作，并且合同指导了这种协作，而不是试图去规定项目范围的细节和固定成本下的进度
响应变化 -》 遵循计划
- 响应变化的能力常常决定这一个软件项目的成败。当我们构建计划是，应确保计划是灵活的并且易于适应商务和技术方面的变化
- 较好的做计划的方式是，每两周做一个详细的计划，为下三个月做粗略的计划，再以后就做即为粗糙的计划
原则
- 我们最优先要做的是通过尽早的，持续的交付有价值的软件来使客户满意
- 即使到了开发的后期，也欢迎改需求，敏捷过程利用变化来为客户创造竞争优势
- 经常性的交付可以工作的软件，交付的间隔可以是几周也可以是几个月，交付的时间越短越好
- 项目开发期间，业务人员和开发人员必须天天在一起工作
- 围绕被激励起来的个人来构建项目，给他们提供所需要的 环境和支持，并且信任他们能完成工作
- 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈
- 工作的软件是首要的进度度量标准
- 敏捷过程提倡可持续的开发速度。责任人，开发者和用户应该能够保持一个长期的，恒定的开发速度
- 不断的关注优秀的技能和好的设计会增强敏捷能力
- 简单–使未完成的工作最大化的艺术–是根本的
- 最好的架构，需求和设计出自于自组织的团队
- 每隔一定时间，团队会在如何才能更有效的工作方面进行反省，然后相应地对自己的行为进行调整
第二章 极限编程概述
极限编程实践
概述：极限编程（eXtreme Programming， 简称XP）
- 是敏捷方法中最著名的一个，它由一系列简单却互相依赖的实践组成。这些实践结合在一起形成了一个胜于部分结合的整体
客户作为团队成员
- 谁是客户？XP团队中的客户是指定义产品的特性并排列这些特性优秀级的人或者团队
用户素材
- 为了进行项目计划，必须要知道和项目需求有关的内容，但是却无需知道的太多。对于做计划而言，了解需求只需要做到能够估算它的程度就足够了
- 在XP中，我们和客户反复讨论，以获取对于需求细节的理解，但是不去捕获哪些细节。我们更愿意在索引卡片上写下一些我们认可的词语，这些可以提醒我们记起这次交谈。
- 开发人员在该卡片上写下对应于卡片上需求的估算。估算是基于和客户进行交谈期间所得到的对于细节的理解进行的
- 用户素材（user stories）就是正在进行的关于需求谈话的助记符。它是一个计划工具，客户可以使用它并根据它的优秀级和估算代价来安排实现该需求的时间。
短交付周期
- 迭代计划
- 发布计划
验收测试
- 结对编程
测试驱动的开发方法
- 编写所有产品代码的目的都是为了使失败的单元测试能够通过。首先编写一个单元测试，由于它要测试的功能还不存在，所以它会运行失败，然后编写使测试通过
- 编写测试用例和代码之间的更迭速度是很快的，基本上几分钟左右，测试用例和代码共同演化，其中测试用例循序渐进地对代码的编写进行指导
- 作为结果，一个非常完美的测试用列集就和代码一起发展起来，程序员可以使用这些测试来检查程序是否正确工作。-》非常有利于重构
- 当为了使测试用例通过而编写代码时，这样的代码就被定义为可测试的代码。这样做会强烈地激发你去解除各个模块的耦合，这样能够独立地对它们进行测试。
集体所有权
- 持续集成
- 可持续的开发速度
- 开发的工作空间
- 计划游戏
简单的设计
团队使他们的
-计划游戏的本质是划分业务人员和开发人员之间的职责，业务人员（客户）决定特性（feature）的重要性。开发人员决定实现一个特性所花费的代价
重构
第三章 计划 第四章 测试 第五章 重构