敏捷开发实践(1)-故事工作量估算导致的问题

时间:14-06-17 栏目:敏捷开发测试 作者:乐测网 评论:0 点击: 656 次

故事工作量估算导致的问题

我们在对backlog中的story进行估算的时候,我们采用了一些前人总结出的敏捷开发的最佳实践,其中一条直接导致了我们这次迭代提前结束:

1、共同估算:在估算前不应该指定谁将开发这个故事,而是以接收故事的小组为单 位集体估算,每个人提出自己的看法,大家综合。这样才能以集体智慧完成任务。

共同估算没有错,用集体智慧和知识对“做什么,怎么做,需要多少工作量”达成共识,共同估算也是为了提高团队成员主人翁的意识,大家会关心自己曾参与讨论的事情;共同估算意味着共同讨论,能提高团队成员对需求的理解程度,有助于开发出满足需求的功能,而且如果开发期间领了任务的人有事脱离岗位,另一个曾经参与讨论的人更容易接手些。

但,注意红色的部分,”在估算前不应该指定谁将开发这个故事“,这个最佳实践确使我们吃了亏。

我们项目组一个5个人,迭代周期为2周,一共6个story,在开发进行了1周后,三个人闲置了,因为他们已经完成了各自的story,而他们又没办法插手别人的story,因为别人进行了一半,而这个story的任务是有连续性的,闲置下来的人根本无法领这些未完成story下的任务,也就是出现了”任务对人的依赖性“。

不知道我描述清楚了没,我们的第一次迭代就这么提前结束了,因为我不可能让三个人闲着没事干,等着另外两个人。

经过总结会,我们决定在对story的工作量进行估算的时候,我们把谁做这个story规定好,这样每个人在本次迭代的任务量都是饱和的,除非划分不合理,不然不会出现上述情况,这时候问题又来了,在对每个人的story进行工作量估算的时候,各自都想争取到更多的时间,也就是都认为自己的story工作量巨大,如果不满足他的要求,很可能会引发抵触情绪。

在估算前,到底应不应该指定谁将开发这个故事? 我们不能一棒子打死,简单答案绝不止是"应该"或”不应该“。要根据story的性质来决定,一般情况下:

1、对于功能性的Story,如开发一个用户管理模块,这种story,不应该指定由谁开发。分解后的任务粒度,应该尽可能地小,最好是1人日能完成,尽可能做到任务之间不要有依赖关系(尽可能,虽然很难)。
2、对于非功能性的Story,如解决某个架构上的难题,应该指定由谁开发,应该指定高水平的开发人员解决,对于大型项目,如果能有单独的一小部分人专门解决架构上的问题,环境上的问题,或者其他疑难问题,采用传统命令式的方式进行管理,我倒觉得更合适些。

最后针对迭代计划,进行一个宏观地评估,主要是为了避免出现任务粒度过大,依赖性强导致的"任务对人的依赖性"。

这篇就谈的这里,下篇谈谈敏捷开发实践中,关于文档的话题。

声明: 本文由( 乐测网 )原创编译,转载请保留链接: 敏捷开发实践(1)-故事工作量估算导致的问题

敏捷开发实践(1)-故事工作量估算导致的问题:等您坐沙发呢!

发表评论(需填写下方的验证回答,无用户名的评论将视为匿名发表,您也可以登陆或注册后再发表评论)

您必须 [ 登录 ] 才能发表留言!

@关注乐测网

-----==== 本站公告 ====-----
1.本站是目前唯一能支持智能手机平板电脑访问的软件测试技术网站.
2.具体访问方法请参考本站的手机访问说明,或直接点击以下链接:

→点击这里打开手机平板访问说明←

    智能手机平板电脑访问方法

1.用手机浏览器输入本站网址http://www.test666.com就可直接访问
2.微信、QQ、微博或手机浏览器的二维码扫描功能扫描以下二维码图

标签云球