读书感想
如果是我自己选书来看的话我不会想到要看这本书，以往的书单都是类似于《XXX从入门到放弃》。在阅读了本书的第一部分之后，才觉得自己应该要好好读一下这本书，因为它提醒了一些我在工作中未曾注意到的细节。书的第一部分分了几个章节介绍了敏捷实践，极限编程概述，计划，测试，重构。
第一章 敏捷实践
这一章节介绍了敏捷开发的一些原则以及在构建敏捷开发团队时需要注意的问题。敏捷开发团队里面所有角色岗位都能有效沟通，能及时得到客户的反馈，拥抱不断变化的需求。
1.1 敏捷联盟
由于许多公司的团队陷入了不断增长的过程，导致软件开发的质量下降，开发的效率也越来越低。所以我们需要有一些能可以让软件开发团队快速工作，响应变化的声明，也就是敏捷联盟宣言。这份宣言从四个方面阐述了敏捷开发团队需要注意的问题。
1 个体和交互胜过过程和工具
一个优秀的团队并不意味着团队里的每一个都是顶尖的开发人员和用着最好的工具，而是团队里的每一个人都能与团队里的其他人紧密合作以及有效地沟通。
2 可以工作的软件胜过面面俱到的文件
在给新团员培训时候，最好的两份文档就是代码和团队。代码真实地展示了它所做的事情，而整个系统的架构图存在于团队成员的脑海中。所以不能因为准备详细的文档耽误软件开发进程。
3 客户合作胜过合同谈判
需要与客户进行真诚的合作，及时向客户展示成果并得到客户的反馈。
4 相应变化胜过遵循计划
太长远的计划不适合制定得太详细，只需要详细制定接下来两周详细的工作计划即可。
1.2 原则
1 我们最优先要做的就是通过尽早的，持续的有交付价值的软件来是客户满意。
2 即使到了开发后期，也欢迎需要的改变。
3 经常性地交付可以工作的软件，时间间隔越短越好。
4 项目开发期间，业务人员和开发人员必须天天在一起工作。
5 围绕被激励起来的个人构建项目。给他们提供所需要的环境和支持，并信任他们能够完成工作。
6 团队内部，效率最高的信息传递方法就是面对面交谈。
7 工作的软件是首要的进度度量标准。
8 敏捷过程提倡可持续的，稳定的开发速度。
9 不断关注优秀的技能和好的设计会增强敏捷能力。
10 简单，敏捷团队不会试图构建华而不实的系统。
11 最好的架构，需求和设计出自于自组织的团队。
12 每隔一段时间，团队成员会在如何才能进行更有效地工作方面进行反省。
第二章 极限编程
2.1 极限编程实践
2.1.1 客户作为团队成员
开发人员应该与客户进行紧密地合作，如果客户实在无法参与进来，那应该找到能够替代客户的人
2.1.2 用户素材
用户素材是需求的整理，是一个计划工具。
2.1.3 短交付周期
1迭代计划
每次迭代耗时两周，是一些小的交付，可能被放如产品也可能不会。
2 发布计划
2.1.4 验收测试
2.1.5 结对编程
2.1.6 测试驱动的开发方法
2.1.7 集体所有权
2.1.8 持续集成
2.1.9 可持续的开发速度
软件项目不是全速的短跑，它是马拉松长跑。团队需要保持稳定的开发速度，一开始就尽力狂奔则会是整个团队精疲力尽。
2.1.10 开放的空间环境
2.1.11 计划游戏
2.1.12 简单的设计
2.1.13 重构
代码往往会腐化，所以我们必须经常对代码进行重构。重构是持续进行的，而不是在项目结束时、发布版本时、迭代结束时、甚至每天快下班的时候。
2.1.14 隐喻
第三章 计划
3.1 初始探索
合理拆分用户素材，过大过小的素材都难以估算。开发人员根据以往的经验大概估算出一个时间。
3.2 发布计划
如果知道开发速度，客户能对每个素材的成本有所了解。根据素材的商业价值和有些级别，再结合开发成本来制定发布计划。
3.3 迭代计划
3.4 任务计划
3.5 迭代
第四章 测试
4.1 测试驱动的开发方法
提前编写好测试用例迫使我们从不同的角度去思考程序里面的每个函数该是怎么被调用的，以及会提醒开发人员是不是漏掉了某些功能模块。
4.2 验收测试
测试光有单元测试还不够，单元测试是用来验证个别机制的白盒测试，而验收测试则是用来验证系统满足客户需要的黑盒测试。
网友评论