| （一）：敏捷实践
价值观：
1. 个体和交互胜过过程和工具
2. 可以工作的软件胜过面面俱到的文档
Martin文档第一定律：直到迫切需要且意义重大时，再来编制文档。
3. 客户合作胜过合同谈判
4. 响应变化胜过遵循计划
原则：
1.最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
2.即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势
3.经常性的交付可以工作的软件，交付的时间间隔可以从几周到几个月，交付的时间间隔越短越好（不赞成交付大量文档或计划）。
4.在整个项目开发期间，业务人员和开发人员必须天天在一起工作
5.围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。
6.在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈（而不是文档）
7.工作的软件是首要的进度度量标准
8.敏捷过程提倡可持续开发进度责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度
9.不断地关注优秀的技能和好的设计会增强敏捷能力
10.简单——使未完成的工作最大化的艺术——是根本的
11.最好的架构、需求和设计出自于自组织的团队（不存在单一团队成员对系统架构、需求或测试负责的情况）
12.每隔一段时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整
敏捷过程举例：
SCRUM, Crystal, FDD(Feature Driven Development), ADP(Adaptive
Software Development), XP(eXtreme Programming)
（二）：极限编程概述
极限编程是一组简单、具体的实践，这些实践结合在一起形成了一个敏捷开发过程。项目团队可以直接拿来使用，也可以增加一些实践，或者对其中一些实践进行修改后再采用。
1. 客户作为团队成员
2. 用户素材
对于做计划而言，了解需求需要做到能够估算它的程度就够了。用户素材（user stories）就是正在进行的关于需求谈话的助记符。他是一个计划工具，客户可以使用它并根据它的优先级和估算代价来安排实现该需求的时间。
3. 短交付周期
迭代计划：XP项目每两周交付一次可以工作的软件。每次迭代由客户根据开发人员确定的预算而选择的一些用户素材组成。
发布计划：通常创建一个计划来规划后大约6次迭代的内容。不是一成不变的。
4. 验收测试
5. 结对编程
一人书写代码，另一人观察代码并寻找代码中的错误和可以改进的地方。两人角色频繁互换。
6. 测试驱动的开发方法
测试用例和代码共同演化，其中测试用例循序渐进地对代码的编写进行指导。编写测试用例和代码之间的更迭频繁（通常几分钟）
7. 集体所有权
没有程序员对任何一个特定的模块或技术单独负责。
8. 持续集成
使用非阻塞的源码控制工具。
9. 可持续性的开发速度
10. 开放的工作空间
每个人都了解对方的工作状态。
11. 计划游戏
划分业务人员和开发人员之间的职责。业务人员（客户）决定feature的重要性，开发人员决定实现一个feature所花费的代价。
12. 简单的设计
XP指导三原则：
a. 考虑能够工作的最简单的事情
b. 你将不需要它（只有存在证据或十分明显的迹象表明引入新的基础结构比继续等待更加合算时，才引入它）
c. 一次，且仅有一次（避免代码重复）
13. 重构（持续进行，抵制退化）
14. 隐喻
他是将整个系统联系在一起的全局试图；是未来的景象，使所有单独模块的位置和外观变得直观。如果模块的外观与整个系统的隐喻不符，那你就会知道这个模块是错误的。
举例：将文字输出到屏幕的系统——用卡车运垃圾比喻，缓冲区是卡车，屏幕是垃圾场，程序是制造垃圾者。所有名字相互符合，有利于从整体考虑系统。
（三）：计划
这是对XP中计划游戏部分的描述。相比其他敏捷方法，更加详细、精确。开发人员看到的是基于他们自己的估算并且由他们自己度量的开发速度控制的合理计划。管理人员从每次迭代中获取数据，使用这些数据来控制和管理项目。客户可以经常看到项目的进展，度量开发速度，拥有他们需要的所有数据和控制权，按照他们的意愿管理项目。
1. 初始探索
项目开始，客户和开发人员尽量确定所有重要的user story（不是所有），这些story随项目进展可能由用户修改、扩充。
开发人员对这些story进行相对估算，用点数表示）因子。例如“2天实现一个story点”
通常需要花几天时间去原型化一个到两个story
这个story所需的相对时间。
为了知道story的绝对大小，需要速度（velocity
来了解团队速度，这个过程称作探究（spike）
2. 发布计划
客户了解每个story的商业价值和成本，据此，他们选择那些想要最先完成的素材。开发人员和客户对项目的首次发布时间达成一致（一般2到4个月）
3. 迭代计划
迭代期间开发人员采用最具技术意义的顺序来实现这些素材。迭代开始后客户就不再改变本次迭代的story。迭代期间进行速度反馈。
4. 任务计划
迭代开始，开发人员将story分解为开发任务，一个任务就是一个开发人员能够在4到16个小时内完成的一些功能。
迭代中点：在迭代进行一半时，本次迭代中所安排的半数story期待被完成。否则会设法重新分配没有完成的任务和职责。
5. 迭代
每次迭代结束，给客户演示当前可运行的程序。客户对外观、感觉和性能进行评价并以新的story方式提供反馈。
（四）：测试
总的来说，编写测试好处有三：
一、使系统健壮、验证正确性
二、测试是一种良好的文档
三、对架构和设计有积极的影响，易于解耦
常用MOCK OBJECTS模式解耦各模块
常用XML作为测试输入、输出，解耦各模块
测试主要包括单元测试和验收测试。单元测试用来验证系统的小的组成单元应该按照所期望的方式工作，但是他们没有验证系统作为一个整体时工作的正确性。单元测试是用来验证系统中个别机制的白盒测试，验收测试是用来检验系统满足客户需求的黑盒测试。
（五）：单一职责原则（SRP）
社么是敏捷设计？敏捷设计是一个过程，不是一个事件。他是一个持续应用原则、模式以及实践来改进软件的结构和可读性的过程。他致力于保持系统设计在任何时候都尽可能简单、干净以及富有表现力。
下面我们介绍一些软件设计的一些原则和模式。
单一职责原则（SRP）：
就一个类而言，应该仅有一个因其他变化的原因。
1.社么是职责？
在SRP中，我们把职责定义为“变化的原因”。如果你能够想到多于一个的动机去改变一个类，那这个类就具有多于一个的职责。
2.如何判断两个职责是否应该被分开？
这依赖于应用程序变化的方式。如果应用程序的变化会影响连续函数的签名，那么为了防止程序僵化，这两个职责应被分离；如果程序变化总是导致两个职责同时变化，那就不必分离他们（事实上分离他们可能引入不必要的复杂性）
3. 持久化
大多数情况下把持久化和业务规则绑在一起是不明智的。还好，正如“测试”一章所言，测试驱动的开发实践常常会迫使在出现code
smell之前分离这两个职责。如果不是这样，应该用FACADE或PROXY模式进行重构。
| 
