《敏捷软件开发-原则、模式与实践》读书笔记-第一周
《敏捷软件开发：原则、模式与实践》第一周：第1~5章，38页：输出一篇读书笔记
第一部分 敏捷开发
“过程和方法对于项目的结果只有次要的影响。首要的影响是人。”
想要项目取得成功，就必须构建起具有合作精神的、自组织的团队。
一、敏捷实践
缺乏有效的实践会导致不可预测性、重复的错误以及努力的白白浪费。 延期的进度、增加的预算和低劣的质量致使客户对我们丧失信心。 更长时间的工作却生产出更加低劣的软件产品，也使得开发人员赶到沮丧。
敏捷联盟宣言
- 个体和交互 胜过 过程和工具
- 可以工作的软件 胜过 面面俱到的文档
- 客户合作 胜过 合同谈判
- 响应变化 胜过 遵循计划
-
人是获得成功的最为重要的因素。
一个优秀的团队成员未必就是一个一流的程序员。
合作、沟通以及交互能力要比单纯的编程能力更为重要。团队的构建要比环境的构建重要的多。
应该首先致力于构建团队，然后再让团队基于需要来配置环境。 -
直到迫切需要并且意义重大时，才来编制文档。
对于团队来说，编写并维护一份系统原理和结构方面的文档将总是一个好主意。
但是那份文档应该是短小的并且是主体突出的。“最多有一二十页，仅论述系统的高层结构和概括的设计原理”培训新成员，可以通过近距离的培训和交互。代码和团队是最好的两份文档。
人和人之间的交互是把这份脉络图传授给他人的最快、最有效的方式。 -
成功的项目需要有序、频繁的客户反馈
让软件的客户和开发团队密切地在一起工作，并尽量经常地提供反馈。
大多数情况下，合同中指明的条款远在项目完成之前就变得没有意义。 那些为开发团队和客户的协同工作方式提供指导的合同，才是最好的合同。
成功的关键在于和客户之间真诚的协作，并且合同指导了这种协作，而不是试图去规定项目范围的细节和固定成本下的进度。
-
确保计划是灵活的并且易于适应商务和技术方面的变化
计划不能考虑得过远。
为下两周做详细的计划，为下三月做粗略的计划，再以后就做极为粗糙的计划。
仅仅对于迫切的任务才花费时间进行详细的计划，一旦制订了这个详细的计划，就很难进行改变
原则
-
我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
-
即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
-
经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
-
在整个项目开发期间，业务人员和技术人员必须天天都在一起工作。
-
围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。
-
在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
-
工作的软件是首要的进度度量标准。
-
敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
-
不断地关注优秀的技能和好的设计会增强敏捷能力。
-
简单——使未完成的工作最大化的艺术——是根本的。
-
最好的架构、需求和设计出自于自组织的团队。
-
每隔一段时间，团队会在如何才能更有效的工作方面进行反省，然后相应地对自己的的行为进行调整。
每一位软件按开发人员、每一个开发团队的职业目标，都是给他们的雇主和客户交付最大可能的价值。
二、极限编程概述
作为开发人员，我们应该记住，XP并非唯一选择
客户作为团队成员
和客户一起工作
用户素材
是对正在进行的关于需求谈话的助记符。是一个计划工具，客户可以使用它并根据它的优先级和估算代价来安排实现该需求的时间。
短交付周期
XP 项目每两周交付一次可以工作的软件。
验收测试
验收测试使用能够让它们自动并且反复运行的某种脚本语言编写，这些测试共同来验证系统按照客户指定的行为运转。
结对编程
结对的关系每天至少要改变一次
可以极大地促进知识在团队中的传播。
测试驱动的开发方法
首先编写一个单元测试，由于要测试的功能不存在，所以它会运行失败。然后，编写代码使测试通过。
测试用例和代码共同演化，其中测试用例循序渐进地对代码的编写进行指导
结果是一个非常完整的测试用例集就和代码一起发展起来。非常有利于重构
编写可测试的代码，会强烈的激发你去解除各个模块之间的耦合。
集体所有权
结对编程中的每个人都具有拆出任何模块并对它进行改进的权力。没有程序员对任何一个特定的模块或技术单独负责
每个人都参与各个模块的工作，你可以是专业的，但是你不会被限制在自己的专业领域。
持续集成
使用非阻塞的源代码控制工具。
完成对模块的修改并把该模块拆入回去时，解决合并的问题。
为避免合并的时间过长，团队的成员会非常频繁的迁入他们的模块。
可持续的开发速度
为了尽快完成开发，团队必须要以一种可持续的速度前进。
团队必须保持旺盛的精力和敏锐的警觉。
团队必须要有意识地保持稳定、适中的速度
XP 的规则是不允许团队加班工作。如果发布目标就在眼前并且能够一蹴而就，则允许加班。
开放的工作空间
在“充满积极讨论的屋子”里工作，生产率非但不会降低，反而会成倍地提高
计划游戏
本质是划分业务人员和开发人员之间的职责。
业务人员即客户决定特性的重要性，开发人员决定实现一个特性所花费的代价
简单的设计
不会考虑未来的用户素材。
尽可能以最简单的方式实现第一批用户素材，只有当一个用户素材迫切需要基础结构时，他们才会引入该基础结构
- 考虑能够工作的最简单的事情
-
你将不需要它
只有在有证据，或者至少有十分明显的迹象表明现在引入这些基础结构比继续等待更加合算时，团队才会引入这些基础结构
-
一次，并且只有一次
极限编程者不能容忍重复的代码。消除重复最好的方法就是抽象。
重构
代码结构会随着一个有一个特性的添加而逐渐退化。XP 团队通过经常性的代码重构来扭转这种退化。
重构是我们每隔一个小时或者半个小时就要去做的事情。
隐喻
将整个系统联系在一起的全局视图；是系统的未来景象，是它使得所有单独模块的位置和外观变得明显直观。
三、计划
初始探索
随着项目的进展，客户会不断编写新的的用户素材。
探究、分解和速度
过大或者过小的素材都是难以估算的。
任何过得的素材都应该被分解成小一点的部分，任何过小素材都应该和其他小的素材合并
分割或者合并一个素材时，应该对其重新进行估算。
可以将用户素材的估算点数乘以速度得到实现该用户素材的实际时间。如“2 天实现一个素材点”，那么相对估算是4点的用户素材，应该需要8天的实现时间。
花费几天时间去原型化一到两个用户素材来了解团队的速度就够了。
发布计划
客户知道每个素材的商业价值和优先级别，可以选择那些想要最先完成的素材。
客户挑选在该发布中他们想要的素材，并大致确定这些素材的实现顺序。
迭代计划
一般的迭代规模需要两周。
一旦迭代开始，客户就不能再改变该迭代期内需要实现的素材。
技术没有完成所有的用户素材，迭代也要在先前指定的日期结束。估算本次迭代的开发速度。
任务计划
新的迭代开始时，开发人员和客户共同制定计划。
开发可以签订任意类型的任务。让开发人员对整个项目了解得越多，团队就会越健康、越有知识。
迭代的中点
团队召开一次会议。了解当前素材完成进度，调整任务、重新分派，或者无法实现的时候告知客户。客户可以决定从迭代中去掉一个任务或者素材。
迭代
每两周，迭代结束时，给客户演示当前可运行的程序，要求用户对项目程序的外观、感觉和性能进行评价。客户以新的用户素材的方式提供反馈。
通过一次次的迭代和发布，项目进入了一种可以预测的、舒适的开发节奏。
但是
涉众对过程产生的数据并不总是满意的，特别是刚刚开始时。
使用敏捷方法只不过意味着他们将能够控制着团队以最小的代价获得最大的商业价值
四、测试
编写单元测试是一种验证行为，更是一种设计行为。同样，也是一种编写文档的行为。
测试驱动的开发方法
- 一个测试优先设计的示例
- 测试促使模块之间的隔离
- 意外获得的解耦合
验收测试
- 验收测试示例
- 意外获得的架构
单元测试和验收测试都是一种文档形式，那样的文档是可以编译和执行的，是准确和可靠的。
五、重构
在不改变代码外在行为的前提下对代码做出修改，以改进代码的内部结构的过程
- 素数产生程序：一个简单的重构示例
应该经常对你所编写和维护的每一个模块进行这种重构实践。
想要通过最小的努力就能够对我们的系统进行扩展和修改。想要具有这种能力，最重要的就是要保持代码的清洁。
感想：
总结
这一部分的主要内容是介绍敏捷开发，然后借助敏捷开发方法，作者提出了很多在软件工程实践中遇到的问题，并一一给出了很好的解决方案。
这些解决方案都是基于敏捷方法开发过程的。不过这些方案对于我们在平时工作中遇到的问题也具有很好的参考价值。
在这几章里，作者着重提到了敏捷开发过程中的核心元素：人，当然这个元素在所有开发方法里都是非常重要的，不过敏捷开发中对人的依赖更重。
在开发过程中，人这个元素，以及人与人之间的信息交流被认为是至关重要的。不管是在开发人员之间，还是在开发人员和业务人员（客户）之间，保持信息的不断交流往往就决定了项目的整个完成进度情况。
在开发人员之间，可以使用结对编程并不断更换结对关系的方法，来让技术知识在团队内部快速地传播，同时也能让开发人员对项目的整体有着比较深入的了解，这样团队内部的任何一个开发人员，都能够胜任任何一个模块的升级改造工作。
在开发人员和业务人员（客户）之间，要保持一种紧密的联系。在整个开发的过程中，一定要保持项目持续的接收到客户的反馈。这样才能保证项目的开发过程处于正确的轨道上。
开发过程中，使用短交付周期，不断的去完成用户素材，完成客户的需求，并及时得到他们的反馈。
使用单元测试能够帮助开发人员更好地考虑各个代码模块之间的耦合关系，能够帮助编写出低耦合度的代码。
验收测试可以使用客户熟悉的脚本语言。
个人理解的敏捷方法的重点
-
加强人与人之间的沟通交流，不管是在开发人员之间，还是在开发人员和客户之间。
-
要持续不断的接收到客户的反馈。并通过迭代的方法，在一步一步的完成用户素材的同时，接收客户需求的变更。
-
分解用户素材，正确的去估算用户素材。对大的素材进行分解，对小的素材进行合并。
-
开发过程中一定要做好测试工作。在这个基础上做好重构的工作。这样能保证代码的低耦合性，获取到合理的软件架构。
-
持续集成，持续交付