如何做:估算任务的粒度在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) 2.4 测试 API 接口 (5H) 3. 显示发送状态 (2H) 4. 进行界面功能的单元测试 (8H) 5. 更新需求文档 (1H) 6. 更新设计文档 (1H) 7. 更新部署手册 (1H) ()内部分为评估的时间 一点体会: 实践中团队成员开始并不愿意以小时为单位进行拆分任务,一方面是不习惯如此细分,很琐碎,觉得是对自己的不信任,另一方面每个人都会或多或少评估工作量时给自己留一些 Buffer,以天为单位留 Buffer 容易一些,以小时为单位则任务拆分的更细, buffer 的空间就小了。