实践敏捷 － 估算任务的粒度在2~8小时

在“敏捷中国”的邮件组中，有一个话题是“Scrum sprint plan中规模估算的做法调查”，大家的讨论很热烈。我们现在是用IMD的方式评估工作量，即每一个故事的大小，分解任务时将任务的粒度控制在2～8小时之内。

我们的想法：

1. Sprint Planning中分解任务部分要达到的目标，不仅仅是看到了一个计划，更重要的是如何完成计划。将任务分解为小时为单位，是为了使团队考虑如何实现功能时考虑的更加细致，更容易在团队内部讨论，及早发现问题，更加靠谱。

2. 瀑布和RUP的开发方式和敏捷开发进行任务拆分，如果我们认为一个版本的功能要拆为100份工作会分析的比较透彻，那么打个比方，1000元分为100份，每份10元；50元分为100份，每份0.5元；瀑布开发的周期较长，整体工作量大，任务拆分的评估单位为天就不错了，而敏捷开发周期短，每个周期的功能工作量小，如果仍然以天为单位，例如3天，团队成员无法了解3天的细节，本来敏捷开发就没有特别完善的文档，那么如果在3天里出现了意外，团队无法进行有效的帮助。

我们是这样做的：

1. 每一个故事对任务的拆分，至少包含：编码、测试、文档；如果任务超过8个小时，则再拆分。

2. 在Sprint中往往有上一个Sprint的Known issues，修改并不会花费很多的时间，很多小的issue只会花费20分钟，这样我们会汇总相似的，表明工作量为2～3个小时

3. 当某一个Story确实无法完成时，团队可以根据任务，和PO讨论拆分Story。我们有过这样一个例子：一个Story要求用户可以查询手机号码以获得通话记录，我们分解的任务是：查询界面、精确查询、带*、？、关联姓名等查询、查询结果界面，其中带*、？、关联姓名等查询耗时较多，最后将Story拆分为：用户可以精确查询手机号码以获得通话记录、用户可以模糊、关联查询手机号码以获得通话记录。

举例：

我们有一个story：用户可以发送定时短信，以便在方便的时间编写短信，在不方便的时间发送短信。

分解的任务为：

1. 从数据库中查询满足定时发送的短信 （2H）

2. 利用第三方的发送端口发送（15H）

2.1 编写调用第三方发送API的接口（5H）

2.2 编写API接口的测试用例（3H）

2.3 准备API接口的测试数据（2H）

2.4 测试API接口（5H）

3. 显示发送状态（2H）

4. 进行界面功能的单元测试（8H）

5. 更新需求文档（1H）

6. 更新设计文档（1H）

7. 更新部署手册（1H）

红色部分为评估的时间

一点体会：

实践中团队成员开始并不愿意以小时为单位进行拆分任务，一方面是不习惯如此细分，很琐碎，觉得是对自己的不信任，另一方面每个人都会或多或少评估工作量时给自己留一些Buffer，以天为单位留Buffer容易一些，以小时为单位则任务拆分的更细，buffer的空间就小了。

参考了《Agile Estimating and Planning》中对敏捷计划的看法：

1. 计划本身比最后的计划重要

2. 计划很容易调整

3. 如果需要，在项目过程中不断调整计划