如何做：估算任务的粒度在2~8小时.doc

如何做：估算任务的粒度在 2~8 小时 我们现在是用 IMD 的方式评估工作量，即每一个故事的大小，分解任务时将任务的粒度控制在 2～ 8 小时之内。 我们的想法： Sprint Planning 中分解任务部分要达到的目标，不仅仅是看到了一个计划，更重要的是如何完成计划。将任务分解为小时为单位，是为了使团队考虑如何实现功能时考虑的更加细致，更容易在团队内部讨论，及早发现问题，更加靠谱。 瀑布和 RUP 的开发方式和敏捷开发进行任务拆分，如果我们认为一个版本的功能要拆为 100 份工作会分析的比较透彻，那么打个比方， 1000 元分为 100份，每份 10 元 ;50 元分为 100 份，每 份 0.5 元 ;瀑布开发的周期较长，整体工作量大，任务拆分的评估单位为天就不错了，而敏捷开发周期短，每个周期的功能工作量小，如果仍然以天为单位，例如 3 天，团队成员无法了解 3 天的细节，本来敏捷开发就没有特别完善的文档，那么如果在 3 天里出现了意外，团队无法进行有效的帮助。 我们是这样做的： 每一个故事对任务的拆分，至少包含：编码、测试、文档 ;如果任务超过 8个小时，则再拆分。 在 Sprint 中往往有上一个 Sprint 的 Known issues，修改并不会花费很多的时间，很多小的 issue 只会花费 20 分钟，这样我们会汇总相似的，表明工作量为 2～ 3 个小时 当某一个 Story确实无法完成时，团队可以根据任务，和 PO讨论拆分 Story。我们有过这样一个例子：一个 Story 要求用户可以查询手机号码以获得通话记录，我们分解的任务是：查询界面、精确查询、带 *、 ?、关联姓名等查询、查询结果界面，其中带 *、 ?、关联姓名等查询耗时较多，最后将 Story 拆分为：用户可以精确查询手机号码以获得通话记录、用户可以模糊、关联查询手机号码以获得通话记录。其中前者在此次 Sprint 内完成 举例： 我们有一个 story：用户可以发送定时短信，以便在方便的时间编写短信，在不方便的时 间发送短信。 分解的任务为： 1. 从数据库中查询满足定时发送的短信 (2H) 2. 利用第三方的发送端口发送 (15H) 2.1 编写调用第三方发送 API 的接口 (5H) 2.2 编写 API 接口的测试用例 (3H) 2.3 准备 API 接口的测试数据 (2H)