代码改变世界

敏捷估计中的点

2011-04-07 13:16  横刀天笑  阅读(1653)  评论(2编辑  收藏  举报

今天IPM纠正了一个我长期的误解,现把经过记录下。

在IPM中,我们会对这个迭代要做的User Story进行简单的讲解,然后开发人员会对该User Story进行估计。现在存在这么一个问题:假如我们现在要对Story #1: Provide RSS for Latest Articles进行估点。但是我发现我们之前曾经做过Provide RSS for Most Viewed Articles。基于对已有工作的经验,我认为现在这个Story将很容易完成。因为数据源已经有了,我们只需要借用一下以前那个Story里已经实现的RSSFormater就可以很容易实现了。那么按照我原先的想法,我将这个Story估计为1个点。

不过今天IPM的时候讨论了一个问题:对当前Story的评估,是否必须根据过往Story的开发经验或知识。按照我以前的误解是需要。

但是今天同事讲,对Story的估计是为了衡量这个Story的大小,是根据该Story的复杂度进行评估。比如我们拿以前一个Story #x作为基准点1,看看当前这个Story相对于这个作为基准点的Story是多大,然后做出评估,而不依赖你对该Story中的某些知识的熟悉程度。也就是说给Story估的点是一种相对复杂度,而不是工作量(这是我的误解)。

那么就可能存在这样的情况:我们先完成了一个点数为2的Story #1,现在要做一个点数为4的Story #2。可能因为Story #2中有部分工作在Story #1里已经准备好了基础设施,导致这个4点的Story比2点的花更少的时间。同事说,这是正常现象,这表示我们对系统的熟悉程度正在逐渐提高。所以一般就会出现这样的情况:在项目刚刚开始的时候我们完成点的速率会很低,随着项目的深入速率也就会不断的提高。比如在刚开始我们每个迭代完成了10个点,后来我们每个迭代可以完成15个点了,这就表示我们对项目越来越熟悉了。后来某个迭代,我们完成点数突然降低了,我们就可以立马发现这个信号,然后寻找原因:比如是不是步入了系统里一个不熟悉的领域?是不是士气有问题了?是不是请假的人太多了?等等,这样就更利于可视化,更利于我们发现问题所在。

还有一点是,如果我们对Story的估计基于以后的知识,那么问题就来了,可能团队里,你比较熟悉这个背景知识,但是别人并不了解。那如果依赖背景知识到底怎么估计呢?如果按照你的估计方式,那这个Story是不是一定要你做呢?这又是另外一个问题。

那如果不基于过往的经验我们到底估计这个点呢?

首先就是划分任务,我们可以让熟悉这个领域的团队成员对这个Story进行划分。比如上面这个RSS,一种可能的划分方式:

  • 获取RSS所需数据源
  • 提供针对的RSSFormater
  • 编写格式化生成RSS的Velocity模板

因为划分任务后,每个任务都相对很小,也更明确了,我们就可以更好的评估该Story的复杂度。

那么如果碰到一个大家都不熟悉的领域呢?比如拿到一个Story后,大家都不知道到底该怎么下手,不知道水儿有多深。那么一般的建议就是不要对这个Story进行估计,我们需要让一个人先对这个Story Spike一下,然后拿到Spike结果后再划分任务,然后再估计。

总结一下

敏捷估计中对Story的估计是对Story复杂程度的衡量,并不表示完成该Story需要的工作量(因为工作量这东西还需要看完成该Story的人)。