Agile Software Development Principles, Patterns,and Practices 第1-5章读书笔记

“过程和方法对于项目的结果只有次要的影响，首要的影响是人”。

“如果想要取得项目的成功，就必须构建起具有合作精神的，自组织的团队”。

个人认为敏捷方法的目的是：最大释放团队及团队中每个人的潜力。团队中的每个人都向着同一目标前进，相互协作，共同进步，使整个团队整体工作效率达到1+1>2的效果。

第一章 敏捷实践

1. 敏捷出现的背景：许多公司的软件团队陷入了不断增长的过程（流程）的泥潭。
2. 敏捷要解决的问题：让软件开发团队具有快速工作，响应变化能力。
3. 敏捷价值观（敏捷宣言）
   1. 个体和交互         胜过  过程和工具。
   2. 可以工作的软件  胜过  面面俱到的文档。
   3. 客户合作             胜过  合同谈判。
   4. 响应变化             胜过   遵循计划。
4. 敏捷原则
   1. 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
   2. 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
   3. 要不断交付可用的软件，周期从几周到几个月不等，且越短越好
   4. 项目过程中，业务人员与开发人员必须在一起工作。
   5. 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
   6. 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
   7. 可用的软件是衡量进度的主要指标。
   8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
   9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。
   10. 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
   11. 最佳的架构、需求和设计出自于自组织的团队。
   12. 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

第二章 极限编程概述

极限编程（XP）是敏捷方法中最著名的一个。由一系列简单却相互依赖的方法组成，这些方法结合在一起形成了一个胜于部分结合的整体。

1. 客户作为团队成员。
2. 用户素材（user stories）note：可以理解为用户功能需求。
3. 短交付周期。
   1. 迭代计划。 note：每次迭代通常耗时两周，这是一次小的交付。
   2. 发布计划。 note：通常为6次迭代计划的内容，一次发布计划通常为三个月的工作，这是一个较大的交付。
4. 验收测试。
5. 结对编程。
6. 测试驱动的开发方法。
7. 集体所有权。 note：每个人都需要参与项目的所有部分
8. 继续集成。
9. 可持续的开发速度。
10. 开放的工作空间。
11. 计划游戏。note：可以理解为做计划。
12. 简单的设计。
    1. 考虑能工作的最简单的实现方式。
    2. 你将不需要它。note：可以理解为提前做好准备。
    3. 一次，并且一次。note：可以理解为需要把代码重构，抽取出公共部分，提炼抽象，减少重复代码，减少代码间的耦合。
13. 重构。note：重构是需要持续的，最好每隔半个小时去做一次重构。
14. 隐喻。note：可以理解为充分理解系统的角色，并能准确形象的表述，帮助我们更好更准确地实现系统功能。

第三章 计划

在项目开始时，开发人员和客户会尽量确定出所有真正重要的用户素材（对用户有价值的需求）。开发人员共同对这些素材进行估算。

1. 探究，分解和速度。
2. 发布计划。
3. 迭代计划。
4. 任务计划。
5. 迭代。note：客户可以经常看到项目的进展。

第四章 测试

编写单元测试是一种验证行为，更是一种设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功能验证方面的反馈循环。

1.  测试驱动的开发方法
   1. 单元测试可以给以后的开发提供支援，以后向程序中增加功能，或者更改程序结构，就不用担心在这个过程中会破坏重要的东西。测试可以告诉我们程序仍然具有正确都饿行为。这样，我们就可以更自由地对程序进行改进。
   2. 从调用者的视角去观察我们将要编写的程序，能帮助我们设计出便于调用的软件。
   3. 迫使我们解除软件中的耦合。
2. 验收测试
   1. 作为验证工具来说，单元测试是必须要的，但是不够充分。单元测试用来验证系统的小的组成单元应该按照所期望的方式工作，但是它们没有验证系统作为一个整体时工作的正确性。单元测试是用来验证系统中的个别机制的白盒测试。验收测试是用来验证系统满足客户需求的黑盒测试。
   2. 验收测试可以促使在打的方面做出优良的系统架构决策。

第五章 重构

1. 重构是需要持续的，最好每隔半个小时去做一次重构。
2. 别让随着时间积累的“干硬的”比特影响程序的扩展和可修改。