乐而歌之,悠哉悠哉!

 

敏捷还得要专业--记我的一次丢人事迹

   事情是这样开始的。。。

   这个sprint,我们挑选了4个story,并且每个story的point都是一样。PO看了很奇怪,因为在她看来有些story明显大于别的。我就给她把这些story不同的难点分析了一下,她大约理解了。不过在解释的时候,我特地提到一点就是有一个技术上的考虑,主要是考虑到比较后的一个story的需求,所以现在在架构上作了调整,确实比单纯完成这个story要复杂一些。这个话题我们并没有继续,但是我却自作聪明的解释了一下通常意义上3个point可以换算成2-3天,而5个point可以换算成3-5天。这下被抓住了...

  其实,想想看,还是自己不够专业,潜意识里还残留着传统项目管理的观念。正如公司负责流程优化的VP所言,敏捷里面不存在duration的概念,只有point,而point反应的只是story之间的相对复杂度,这个复杂度囊括了完成story需要的各项任务,是一个综合考量。

  我这两天一直在思考这个问题,因为自己对软件工程的度量属于长期思考加实践,包括复杂无比的功能点度量。我想VP误会我的意思,她可能觉得我在用duration作度量,其实不然,我只是分析了每个冲刺的结果,进行的换算,这两个是不同的概念,不过即使这样,对于一个在全公司负责推广敏捷的人来说也显得分外扎眼。

  敏捷强调的是对个人的尊重,它积极的排除了项目经理分配制,所有的任务都是各人自行挑选、安排。对于个一个story的大小,需要让每个人都心悦诚服,而非口服心不服。另外,敏捷一直强调自己是一个轻量级的过程,希望把很多管理上的事情简化。所以,故事点是一个比较好的选择,因为它反映的只是一个内心的感受,而非真实的结果。原因很简单,敏捷的人不需要精确的计划数据,因为反正会有需求变化,反正计划永远赶不上变化,与其浪费时间在细节的讨论上,还不如等到作的时候再说。对,所以我们在plan meeting的时候从来不决定task的时间,只有等到真正开始着手做了,等到需求再变要走变更流程了,我们才真正的拿出精力去思考到底需要多长时间来完成这个任务。即使这个任务和原先想的有出入,也未必就真的会影响到story的整体相对度量,因为一个story由多个task构成,说不定别的task变得复杂抵消了别的task难度降低的变动,这就是一种reconciliation。我相信故事点的提出,也是基于这样一种情境的假设。

  的确,传统的项目管理中对于duration的评估,是非常花时间的,耗费大量的成本。尤其是在做两个星期的计划时,想要提出duration,基本上已经想好代码量,测试case数量等等了。PMBOK里有一堆基本技术供参考,这里不予赘述。这些的基础都是基于需求稳定的情况。当然,变更是需要走综合管理的变更流程的。这些一套一套的都是敏捷所不齿的急于打破的。

  我想,正是由于这些地方水火不相容,才让故事点和duration的争论在业界也从未停歇把。因为,理论依据不同。

  综上所述,在plan meeting的时候,我们只需要考虑相对难度,尊重内心的直观感受,所以只要给出故事点就行;到了领取这个story下的task的时候,则需要给出一个时间,这个时间是一个承诺,每个人都应该非常慎重,即使如此,也不表示真正需要的时间是不能变的,因为敏捷的过程管理上不关心你的计划时间,因为那已经是过去,最关心的其实是完成这个任务还慎多少时间,因为这个时间点能决定后续的任务什么时候能接上,大家还有没有信心去完成这个story,毕竟不是一个人在战斗。

  

posted on 2010-11-12 23:08  秋实  阅读(320)  评论(0编辑  收藏

导航