“水桶”原理

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

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个点故事所导致的估算差别，计划照样可以继续。