我们现在是用IMD的方式评估工作量,即每一个故事的大小,分解任务时将任务的粒度控制在2~8小时之内。service.mypm.net
我们的想法:pmp.mypm.net
Sprint Planning中分解任务部分要达到的目标,不仅仅是看到了一个计划,更重要的是如何完成计划。将任务分解为小时为单位,是为了使团队考虑如何实现功能时考虑的更加细致,更容易在团队内部讨论,及早发现问题,更加靠谱。blog.mypm.net
瀑布和RUP的开发方式和敏捷开发进行任务拆分,如果我们认为一个版本的功能要拆为100份工作会分析的比较透彻,那么打个比方,1000元分为100份,每份10元;50元分为100份,每份0.5元;瀑布开发的周期较长,整体工作量大,任务拆分的评估单位为天就不错了,而敏捷开发周期短,每个周期的功能工作量小,如果仍然以天为单位,例如3天,团队成员无法了解3天的细节,本来敏捷开发就没有特别完善的文档,那么如果在3天里出现了意外,团队无法进行有效的帮助。talent.mypm.net
我们是这样做的:项目管理者联盟文章
每一个故事对任务的拆分,至少包含:编码、测试、文档;如果任务超过8个小时,则再拆分。bbs.mypm.net
在Sprint中往往有上一个Sprint的Known issues,修改并不会花费很多的时间,很多小的issue只会花费20分钟,这样我们会汇总相似的,表明工作量为2~3个小时service.mypm.net
当某一个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)talent.mypm.net
7. 更新部署手册(1H)转自项目管理者联盟
()内部分为评估的时间项目管理培训
一点体会:blog.mypm.net
实践中团队成员开始并不愿意以小时为单位进行拆分任务,一方面是不习惯如此细分,很琐碎,觉得是对自己的不信任,另一方面每个人都会或多或少评估工作量时给自己留一些Buffer,以天为单位留Buffer容易一些,以小时为单位则任务拆分的更细,buffer的空间就小了。项目管理者联盟
|