2016 年 8 月 4 日

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

背景

自从我们使用scrum进行项目开发后,出现了这样那样的问题,有些是因为我们对scrum的理解不到位,有些则是客观因素导致的,针对这些问题,在每次迭代的总结会上,我们进行了反思,并根据具体环境对scrum进行了一一调整,想通过几篇文章和大家分享一下我的经验。

我说的不一定正确,只是描述问题,然后说说我对问题的看法,采取的解决方案,希望使用敏捷开发的大牛提供宝贵意见。

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

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

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

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

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

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

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

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

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

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

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

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

最新文章

  1. 网站怎么做才可以实现更好的盈利
  2. 如何提升网站的稳定性
  3. 如何找到一家好的北京网站设计公司
  4. 网站后期维护内容有哪些
  5. 网站导航设计的时候要注意哪些
  6. 公司网站制作怎样突出特色
  7. 高质量网站建设的要素有哪些
  8. 想要制作出优质网站需要如何进行策划
  9. 怎么才能让网站的运行速度更快
  10. 网站页面怎样才能设计的更出众

最新案例