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