菜单

一年多来我在多个团队讲解敏捷基本原则。在这过程中,我深深体会到人们对估算的恐惧。估算的过程看起来就像下面描述的这样:

  1. 选一个用户故事

  2. 查看代码库

  3. 讨论将如何实现故事

  4. 要求BA提供对应于解决方案的准确设计细节

  5. 要求QA提供他们将如何测试的准确细节

  6. 纠结,紧张

  7. 设这个故事是在组件A,Jeff负责组件A,他的速度相当快,可能几天就能做完?

  8. 伸出手指喊出“3天”, 然后一天8小时,结果出来了,“24小时!”

好了,并不是所有的团队都那样痛苦。但是,如果我告诉你,我至少有经历过一个项目,在实际上不是很了解故事的情况下,我们在几天之内估算了一年的用户故事,你感觉如何?这本身不值一提,毕竟我们本来就是随机地给他们分配点数,但是真正值得注意的是,我们几乎完全在预计时间划交付了!

那么,真正的敏捷估算应该怎样做呢?

重点是人?在你的团队,选出你认为最好的开发人员(A)和最差的开发人员(B)。现在选一个故事。A交付这个故事用多少小时,B交付用多少小时?我们是把它估算了两次吗?如果是,我们如何预计工作?如果不是,我们如何处理二者分别做而产生的不同结果?基于谁将真正去做某个故事进行估算,常常导致迭代计划的最后一刻才能出估算结果,这实际上已经价值不大了。

重点是时间?用户故事125如果估算是要费3天,可能就会去做;如果估算是6天就未必了。问题随即而来——以时间为指标进行估算。这相当有诱导性,所有的团队都试图这么做过。

或者重点是更好的方法?假如我是一个贪吃水果的人,假如我的同事比我吃得慢。如果我要花2分钟吃一个苹果,他花4分钟。假设交付你的项目类似于我们尽力吃完一个碗里的所有水果。水果代表故事,我有一些李子,苹果,香蕉,芒果和哈密瓜。

我知道李子大约是苹果一半的大小,吃个香蕉跟吃个李子的时间差不多。吃个芒果大约是吃苹果2倍的时间;哈密瓜,则大约是吃苹果的4倍。

这样我可以把它们放到水桶里来表示水果的相对大小和复杂度:

李子/香蕉 = 1 ,苹果 = 2,芒果 = 4,哈密瓜 = 8

是的,我听到你在说——“这不过是使用时间来确定相对打消,干嘛不直接试用时间呢?”这是因为,使用相对大小,不管谁吃水果,尺寸都保持不变。我那个同事,需要花4分钟吃一个苹果,吃个香蕉要2分钟,吃个哈密瓜需要32分钟,然而香蕉和哈密瓜相对大小保持不变。

这种方法通常更简单,因为团队能够看对比两个故事并很快看出,这一个是那一个一半的复杂度,还是两倍复杂度。全然没有文章一开头估算过程中的痛苦!我曾经见过团队为上百个故事估算只花费几个小时时间。这样,现在有我们达成一致的度量单位,我们将把它们称为故事点。

“但是那没有改变你和你的同事吃水果的速度,是吗?”那么,这是最好的部分。团队的成员以何种速度工作无关紧要。如果我将我们吃水果的任务拆分成10分钟的迭代,我的同事和我每个迭代吃15个点的水果价值(我每分钟吃1个点,他每2分钟吃1个点),我们说这个15是我们的“团队速率”。因为这是将团队看成一个整体,从而承受开发人员的不同速度。在敏捷方法里,看重的是团队!(如果你尝试计算个人速率,立即停止!这非常愚蠢,会造成低效能的团队。)

现在,我们再来看看“水果碗”:

12 李子 X 1 = 12

6香蕉 X 1 = 6点

6苹果 X 2 =12点

3芒果 X 4 = 12点

2哈密瓜 X 8 = 16 点

们的“水果碗”里,总共是58点, 不能被15(我们的团队速率)整除。 由于迭代有点像电影票(例如买0. 866666张电影票不合理),我们用4个迭代来完成。我们应该因此在40分钟内(我们估算的发布日期)吃完碗里所有的水果。

在允许我们的产品负责人根据范围调整发布日期。加6个苹果,交付推后一个迭代,或者拿掉两个哈密瓜提前一个迭代交付,或者拿出所有的香蕉和10个李子但加两个哈密瓜,这样我们应该在同一时间交付(尽管很可能要忍受令人不快的哈密瓜)。

水果故事讲完了。然后呢

们如何应用这些技术到我们的项目上?

  • 首先,永远对比着做故事估算,而不是单独来估。因此对故事的相对大小,我们需要有一个参考基准。选一个认为较小的故事(但不是最小的)定为2点,以此为参考。

  • 对比这基准故事进行评估,只讨论影响故事大小的实现细节。例如,相对于Oracle服务器,如果选择使用SQL服务器,不会改变故事的相对大小,也不必讨论,记录所有的假设。

  • 把每个故事放到1,2,4,8或16的“水桶”里。

  • 尽量保持小的故事。理想情况8个点的故事应该能在一个迭代内做完。任何更大的故事,最好把它视为“史诗故事”(Epic),需要再次拆分。

  • 对于每个故事“水桶”,快速检查里面的故事和估算点。每个故事“桶”里面,它们彼此看起来,相对大小都差不多吗?如果需要的话可以调换水桶。

  • 然后统计每个桶里面的故事点数,计算出目前掌握的项目范围。

常见问题:

为什么是这些水桶?如果我们有一个点数为100的故事会怎么样?

它将分配到水桶16。水桶16也用于放置所有太大或者太难估算的故事。

为什么在故事的大小上我们有如此严格的界限?

起初是为了准确度。我能够就准确合理地给出水果碗里的水果的相对大小,但一旦你开始问我“帝国大厦里有多少个苹果?”我很确定我不知道。所以没有大小的故事是无用的。他们无法在迭代里面被交付,必然变成小型的瀑布项目。

但是,无疑一些估算会是错的?

的确是这样,但是一旦有了估算,不要再重新估算故事。有一个很简单的理由。在大部分项目上,会发生几个支持2个点的人改为支持8个点,几个支持8个点的人改为支持2个点。

当我们允许重新估算时,会发生什么显而易见——支持2个点的人变成支持8个点,支持8个点的人......还是8个点。不允许重新估算,我们用小于预期8个点的故事来偿还大于预期2个点故事所导致的估算差别,计划照样可以继续。