敏捷软件开发（原则、模式与实践）第一部分 敏捷开发-读书笔记
本书一共被分为四个部分，其中第一部分 - 敏捷开发共用6个章节来阐述。
第一章 - 敏捷实践
讲到敏捷，我们就不得不提供敏捷软件开发宣言：
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合同 胜过 合同谈判
相应变化 胜过 遵循计划
虽然我们从接触敏捷的第一天开始就已经知道了敏捷的4句宣言。但是很多方面可能只是知道其中的字面意思。而在本章中，作者对每条宣言都做了详细的阐述。
1. 个体和交互胜过过程和工具
在此章中，强调个体和交互的核心是人。人才是获得成功的最为重要的因素。而人的合作、沟通以及交互能力要比单纯的编程能力更为重要。
2. 可以工作的软件胜过面面俱到的文档
敏捷开发强调可以工作的软件胜过面面俱到的文档。并不是说敏捷不需要文档。完全没有文档的项目将会是一种灾难。对敏捷团队来说，需要维护一份文档，但是这个文档必须短小且主题突出。短小：是根据项目的大小，最好在一二十页内；主题突出：文档中仅论述系统的高层架构和概括的设计原理。
由于敏捷不建议用面面俱到的文档，这样就不能像传统的项目一样，在有新成员加入时，发一堆文档让他熟悉项目。在敏捷团队，我们可以老成员带新成员的方法。让一个老成员紧挨着TA坐着，来帮助TA，把项目的知识传授给他们。通过近距离的培训和交互培养新成员。
所以对于敏捷项目的文档有一个条最重要的原则是：
直到迫切需要并且意义重大时，才来编制文档。
3. 客户合同胜过合同谈判
项目的需要基本处于一个持续变化的状态。特别对一个大型的项目来说，因此成功的项目需要有序、频繁的客户反馈。
4.相应变化胜过遵循计划
响应变化的能力常常决定着软件项目的成败。所以当我们在构建计划时，应该确保计划是灵活的，并且易于响应商业和技术方面的变化。
敏捷中，推荐较好的做计划的策略是：为下两周做详细的计划，为下三个月做粗略的计划，再以后就做极为粗糙的计划。
计划中的逐渐降低细致度，意味着我们仅对迫切的任务才花费时间进行详细的计划。一旦制定了详细计划，就更难进行更改。团队会根据这个计划启动工作并有相应的投入。
敏捷的12条原则：
1. 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2. 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3. 经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
4. 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5. 围绕被激励起来的个人构建项目。给他们提供所需要的环境和支持，并且相信他们能够完成工作。
6. 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
7. 工作的软件是首要的进度度量标准。
8. 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该都能够保持一个长期的、恒定的开发速度。
9. 不断地关注优秀的技能和好的设计会增强敏捷能力。
10. 简单 - 使未完成的工作最大化的艺术 - 是根本的。
11. 最好的架构、需求和设计出自于自组织的团队。
12. 每隔一定时间，团队会在如何才能更有效工作方面进行反省，然后相应地对自己的行为进行调整。
通过第一章的学习，对敏捷的四句宣言和12条原则，有了更进一步的理解。
第二章 - 极限编程概述
通过第一章，我们已经对敏捷的宣言和原则有了一定的了解。但是我们在实际项目中该做些什么昵？此章给出一个极限编程实践例子。
1. 客户作为团队成员
客户是指定义产品的特性并排列这些特性优先级的人或团体。客户必须是用户团体委派的。在整个开发周期中，客户和开发人员最好都在一起。
2. 用户故事
书上写的是用户素材，现在大家更习惯用用户故事来描述。在敏捷中，我们对需求的了解，只需要做到能够估算它的程度就足够了。用户故事只是正在进行的关于需求谈话的助记符。
3. 短交付周期
XP项目每两周交付一次可工作的软件。
- 迭代计划： 开发人员通过度量在之前的迭代中所完成的工作量来为本次迭代设定预算。一旦迭代开始，客户需同意不再修改此次迭代中的用户故事的定义和优先级。迭代期间，开发人员可自由分解用户故事，并依据最具技术和商业意义的顺序来开发任务。
- 发布计划：XP团队通常会创建一个计划来规划随后大约6次迭代的内容。发布计划由客户根据开发人员给出的预算所选择的、排好优先级别的用户故事组成。发布计划不是一成不变的，客户可以随时改变计划的内容。
4. 验收测试
一旦通过一项验收测试，该测试需加入到已经通过的验收测试集合中，并决不允许该测试再次失败。
5. 结对编程
结对人员：一个输入代码，另一个观察输入的代码并寻找代码中的错误和改进的地方。两人需积极的交互且频繁互换角色。
在一个迭代周期中，每个团队成员应该和所有其他的成员在一起工作过，并且他们应该参与了本次迭代所涉及的每项工作。
6. 测试驱动的开发方法
编写产品代码的目的是为了使失败的单元测试能够通过。
7. 集体所有权
项目中的团队成员可以项目的任何模块进行改进。
8. 持续集成
为了避免合并的时间过长，团队成员需频繁checkin他们的模块。每天的多次构建系统，重新创建整个系统。
9. 可持续的开发速度
团队必须要以一个可以持续的速度前进，必须保持旺盛的精力和敏锐的警觉，必须要有意识地保持稳定、适中的速度。
XP的规则是不允许团队加班工作。当然发布前（发布目标就在眼前并且可以一蹴而就）的一个星期例外。
10. 开放的工作空间
团队在一个开放的房间里一起工作。墙上挂满状态图表、任务明细表、UML图等。
11. 计划游戏
计划游戏：本质是划分业务人员和开发人员之间的职责。
业务人员：决定特性的重要性；
开发人员：决定实现一个特性所花费的代价。
12. 简单的设计
设计需尽可能地简单、具有表现力。XP的三条指导原则如下：
- 考虑能够工作的最简单的事情：尽可能寻找实现当前用户故事的最简单的设计。
- 你将不需要它：比较引入基本架构和继续等待那个更合算？
- 一次，并且只有一次： XP开发人员不能容忍重复的代码。消除重复最好的方法是抽象。
13. 重构
团队需经常性的代码重构来扭转代码结构的退化。
重构是在不改变代码行为的前提下，对其进行一系列小的改造，志在改进系统结构的实践活动。
14. 隐喻
说起来，关于隐喻这部分完成没看懂。
隐喻：它是将整个系统联系在一起的全局试图；它是系统的未来景象，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个系统的隐喻不符，那该模块是错误的。
第三章 - 计划
在第二章中，作者简单的提过计划游戏(Planing Game)。本章则是对计划游戏的进一步描述。
1. 初始探索
在项目开始时，客户和开发人员尽可能的确定所有重要的用户故事，但不会试图确定所有的用户故事。
开发人员对用户故事进行相对的估算。过大或过小的素材都难以估算。开发人员往往会低估大的用户故事而高估小的用户故事。将过大的用户故事分解成小一点的部分。将过小的用户故事和其它小的用户故事合并。当分割或合并一个用户故事时，应该对其重新进行估算。在估算时，需要一个速度(Velocity)的因子。
2. 发布计划
开发人员和客户需对项目的首次发布时间达成一致。客户不能选择与当前开发速度不符的用户故事。
3. 迭代计划
开发人员和客户决定迭代规模，一般建议两周。迭代期间用户故事的实现顺序属于技术决策范畴。
一旦迭代开始，客户就不能在改变该迭代周期中需要实现的用户故事。
即使没有完成所有的用户故事，迭代也要在先前指定的日期结束。
4. 任务计划
在新的迭代开始时，开发人员和客户共同制定计划，开发人员把用户故事分解成开发任务，一个任务就是一个开发人员在4～16小时内能实现的一些功能。
可以用活动挂图、白版和其它方便的媒介列出任务。
迭代进行到一半时，团队召开一次会议：确认用户故事完成情况，如果没有完成一半，团队重新设法分配没有完成的任务和职责，一保证在迭代结束时能够完成所有的用户故事。
如不能实现这样的重新分派，则需要通知客户。由客户决定从迭代中去掉一个任务或用户故事。让客户指出那些最低优先级别的任务和用户故事，这样开发人员可避免在其上花费时间。
5. 迭代
每两周迭代一次，每次迭代结束，给客户演示当前可运行的程序。要求客户对项目的外观、感觉和性能进行评价。
第四章 - 测试
编写单元测试是一种验证行为。
如果能在设计程序前先设计测试方案，可以迫使我们使用不用的观察点。从程序调用者的有机视角去观察要编写的程序。
通过先编写测试，迫使我们把程序设计为可测试的。把程序设计为易于调用和可测试的。
首先编写测试，迫使我们解除软件中的耦合。
有意图的编程：在实现之前，先在测试中陈述你的意图，使你的意图尽可能地简单、易读。
单元测试：促使在小的方面作出优良的设计。
验收测试：用来验证系统满足客户需求的黑盒测试。
验收测试：促使你在大的方面做出优良的系统架构决策。
第五章 - 重构
本次作者进行一次简单的重构过程。在这过程是，作者论述了，为什么要对这部分代码进行重构。对我在以后的工作中有一定的指导意义。
就像作者在本章一开始提到的，本章讲述的是关于人的注意力，阐述人们应该专注于手边的工作且确信自己正在尽全力，说明了使事物能够工作和使事物正确之间的区别。
每个软件模块都具有是那个职责：
- 运行起来所完成的功能。
- 它要应对变化。
- 要和阅读它的人进行沟通。
重构：在不改变代码外在行为的前提下对代码做出修改，以改进代码的内部结构。
第六章 - 一次编程实践
这是第一部分的最后一章，作者向我们演示了一个结对编程的方法和经验。可以指导我们在项目中实践结对编程。
