敏捷软件开发 - 原则、模式与实践 —— 敏捷开发（二）

本文为敏捷软件开发 - 原则、模式与实践系列的一部分。

本文对应原书第3章 ~ 第6章。

计划

1. 初始探索
   在项目开始时，开发人员和客户会尽量确定出所有真正重要的用户用例。但，他们不会试图去确定所有的用户用例。注意用例的大小，过大或过小都不利于工作量的评估。

2. 发布计划
   根据开发速度，客户选择下面2-4个月需要完成的用户用例，并排列这些用例的优先级。发布计划可以调整。

3. 迭代计划
   根据开发速度，客户选择下面2周需要完成的用户用例，并排列这些用例的优先级。迭代计划一旦开始就不能改变。即使没有完成所有的用户用例，迭代也要在指定日期结束。并根据完成的用户用例计算出开发速度。

4. 任务计划
   开发人员把用户用例分解成开发任务，一般一个任务是一个开发人员能够在4-16小时内完成的一些功能。

5. 迭代的中点
   在迭代进行一半的时候，团队会召开一次会议，如果进度出现问题，团队会设法重新分配任务，以保证完成所有的用户用例。如果无法实现这样的重新分派，需要通知客户，客户可以决定去掉一些用例。

6. 迭代结束
   每2周，召开迭代结束会议，计算开发速度，给客户演示当前项目，客户可能提出新的用户用例。指定下一个迭代计划。

测试

1. 测试驱动开发的好处
   a. 程序中的每一项功能都有测试来验证它的操作的正确性。
   b. 编写测试可以迫使我们使用不同的观察点。我们必须从程序调用者的视角去观察我们要编写的程序。此外，会迫使自己把程序设计成可测试的，实现低耦合。
   c. 测试可以作为一种无价的文档形式。测试就像一套范例，它帮助其他程序员了解如何使用代码。这份文档是可编译、可执行的。

2. 一个测试优先设计的示例
   参看原书4.1.1 - 4.1.3

3. 验收测试
   单元测试是由开发人员编写的白盒测试。验收测试是由客户和QA编写的黑盒测试。正如单元测试作为可编译、可运行的有关系统内部结构的文档那样，验收测试是有关系统特性的可编译、可执行的文档。验收测试一定要可自动化运行。

4. 验收测试示例
   参看原书4.2.1 - 4.2.2

重构

软件模块的三项责任

1. 它运行起来所完成的功能。功能性。
2. 它要应对变化。可扩展性。
3. 它要和阅读它的人进行沟通。可维护性。

一个简单的重构示例
参看原书5.1

一次编程实践

参看原书第6章

完整内容请查看敏捷软件开发 - 原则、模式与实践系列