用户故事估算技巧

用2的幂进行估算

开始的时候，我会将故事的规模估算为1点、2点、3点、4点，或是小、中、大、特大。人们总是觉得：中等大小的故事，其工作量是小型故事的两倍；而 大型故事是中等大小故事的两倍（诸如此类）。但到后来，发现这样的想法总是很难跟实际规划吻合起来。后来有人推荐我使用2的幂来估算。这一下，业务人员就 能理解我们的表达方式了。他们会知道8点的故事要远超过1点的故事。我认为1点、2点、4点、8点这样的规模估算要更加合适。故事越大，其中包含的未知因 素和风险也就越多。用2的幂进行估算，可以让人们对于大型故事所关联的风险更加注意。

使用4个数值

我参与过一个项目，他们用1、2、4、8作为估算值。前两次估算会议结束后，不到5%的故事只有1点，大约30%的故事是2点。项目经理决定去掉 “1”这个估算值，因为他觉得这样做太容易了。此后的每次估算会议中，有趣的事情发生了：突然只有5%的故事变成了2点，相当多的故事变成了4点。开发人 员改变他们的估算规模，我认为这不是有意的，只是开发人员总是会想得多一些。没几个开发人员愿意确定表明：用户故事非常简单，估算允许的最小数值就是它的 工作量。在多次项目过程中见过类似行为后，我选择估算的最小数值为4点。不过我觉得用4点作为最大估算数值也不错。无论如何，这只不过就是估算而已。如果 放太多精力在估算的准确度上，到后来就得负责说明为什么没能按照估算完成任务。估算的目的是要对项目规模和工作量有一个大致的概念，而不是要得到一个需要 严格遵循的工作计划。

不能取平均数，不能使用不在估算取值范围中的数字

使用数字4，可以让你得到一个粗略的估算，而不必在精确程度上花费太多时间。有的故事感觉比2点大一点，但是又比4点小一点。这样的故事不能估算为 3点。也没有理由使用3点进行估算。类似的故事隐含的风险或是未知因素让人觉得它不是2点，因此，它很有可能是一个4点的故事。如果使用平均数、或是不在 估算取值范围中的数字，有可能给团队成员或是项目干系人造成暂时的（也是不必要的）困惑。同时，从项目整体的角度来看，偶尔不太确定的估算也不会影响大 局。要保持简单，坚持使用取值范围中的数字。

独立投票

受他人影响是人的本性。如果一个技术leader说一个故事大小是两点，很可能其他团队成员都会随声附和。因此，在我负责的估算过程中，我会让每个 团队成员独立做出自己的选择。要想达到这样的目的，可以为每个成员发一张纸，让他们在上面写上自己的估算，等到每个人都写好之后，大家可以一起展示各自的 估算。另外一种方式，也是我喜欢的方式，是用“石头-剪子-布”（译注：英文名rock-paper-scissors，简称RPS）进行估算。在估算会 议上，我们会一直讨论某个故事，直到大家都准备好估算为止，然后我们会一起“抛出”自己的估算，就像是同时伸手出石头、剪子、布一样。我所说的“抛出估算 ”就是：伸出一个手指头表示1点，两个手指头表示2点，四个手指头就是4点。要是表示8点，那就得双手并用了。

选取最大的估算值

即使反复提醒过了，开发人员们还是很难估算，因为他们仍会受到团队的影响。如果某个开发人员认为可以在一天内做完某个故事，他会伸出一个手指头。然 而，这个故事也许不由该开发人员负责，另外的团队成员会接手，可是他可能会认为这个故事应该是2点甚至是4点。我总是选择团队成员给出的最大估算数值。也 许有人认为这是小题大做，可实际上每个团队成员对于风险的认知不同，也许给出最大估算的成员想到的风险要比其他人更完备。选择最大的估算值还有其他好处。 如果必须要同意一个较低的估算，那么做出最大估算的团队成员就得说明原因。对于团队中不那么资深的成员来说，这样的讨论可能让他觉得窘迫。对开发语言和工 具相关经验的匮乏，他们可能不知道怎么样快速完成某项工作。他们的担心是由自己的技能水平决定的。如果因为不想讨论为什么估算值那么高而不愿意给出自己真 正的估算，这对团队可无甚裨益。

对于取值高低的讨论，有可能使得整个团队提升估算值，或是让开发人员不甚情愿地降低自己的估值。不管怎样，你都要花更多时间来讨论，而这些讨论可能 一无所获。到最后，最重要的还是保持一致。通过跟踪团队开发速度（注），团队在一个迭代中可以完成多少故事，这总是可以知道的。因此，即使估算有所“膨胀 ”，速度也会随之变化，对于规划来说没有影响。

最后，选取最大的估算值可以节省估算会议的时间。如果团队中有人认为一个故事应该是8点，在讨论这个故事时，他可以大声说出来，宣称自己将抛出8点这个估算值。除非有人认为在团队成员的估算之间有很大差距，既然这个故事必将成为8点，那就没有必要再针对它讨论下去了

讨论大估算差

对于估算，经常会有误解，以为整个团队都同意某个故事的大小。如前所述，我会选择更大的指来解决估算不一致的问题。然而，有时很大的估算差距意味着存在某 些误解。因此，如果有两个估算的值差距大于2，总是会引发讨论（比如，如果一个成员抛出1点，而另一个认为是4点，大家就得澄清一下了）。讨论这些大的差 距，还可以减少给出最大估算的人被轻视的机会。

提防信息不足

有时会发生估算会议结束时还有故事未被估算的状况。与其匆忙给出一个让人不舒服的估算，不如去征询更多信息。估算为8点，暗示着这是一个很大的故事，但也 意味着你觉得它会占用两倍于4点故事所用的时间。因此，不要随便将不清楚的故事估算成8点。估算会议的目标不是要得到所有故事的估算值，而是要为提供了足 够信息的故事给出估算。

必要的投入

没人喜欢参加估算会议（好吧，就我所知的都不喜欢）。在我经历过的项目中，语速快的人负责将故事大声念出来，开发人员会问领域专家各种问题，然后他 们会进行估算。当没人向领域专家发问时，他们会在自己的笔记本上做其他的事情。一开始，我觉得这是利用时间的好方法，但是他们却会因此而错过一些东西。后 来我参加了这样一个项目，经理要求每个人轮流念一个故事。这样领域专家就参与进来了，因为他们害怕轮到自己念时看起来很愚蠢。由于每个人的全情投入，整个 会议也变得更有价值了。

猪和鸡

在供应火腿和鸡蛋的餐馆里面，猪是全身心投入，而鸡只是参与而已。

我经常听到这样的话：业务人员不应该干扰开发人员的估算，因为开发人员属于“猪”的角色，而业务人员都是“鸡”。我真觉得这个类比很不好。一个坏的产品出来，更有可能被解雇的是业务团队，而不是技术团队。然而，让业务人员干扰估算是会引发利益冲突的。

这个问题也很容易解决。业务人员想知道他们在下个迭代后能得到哪些功能，他们需要估算。由于业务人员不写代码，他们的估算都不大准确。在实际的估算 过程中，业务人员参与得越多，由此而对开发人员产生影响，也就有可能使业务人员得到的估算越不准确。在会议上，最好的领域专家只回答问题，而不会去干扰故 事开发过程的一丝一毫。

估算小组人数

团队的大小各有不同。在小于等于6个人的小型团队中，我建议整个团队都参与估算会议。不同的观点有助于夯实项目远景，并对估算产生正面效果。不过， 我相信是存在收益递减效应的。如果是大团队，就不一定全都参与针对每个故事的估算了。再说，这就是一个估算，6个人跟15个人的准确性不会有太大差别。如 果你的团队多于6个人，我建议分成不同的估算小组。一般来说，我希望最少能有3个人参与故事估算，但是不要超过6个人。

新故事

新故事的出现有两种形式：新功能需求和既有故事的切分。一般我会根据新故事的优先级考虑何时进行估算。如果一个故事要在下个迭代中完成，那就得对它 马上估算。不过，要是新故事在接下来几个迭代中都不会出现，再等等也无妨，直到有了足够的故事来证明召开估算会议的必要性。我发现估算会议上得到的估算值 更为可靠，因为在那个环境中，大家都将精力放在估算之上。通过切分得到的故事有其复杂性：它们可能已经估算过了。我强烈建议在估算新故事时，不要考虑之前 的估算值。如果一个故事因为其风险或不确定性需要切分，很有可能之前的故事是不靠谱的——忽略原先的估算吧。

不要用笔记本电脑

至少不要给开发人员提供笔记本电脑。把故事列表打印出来分发给大家，或者用投影仪投放在屏幕上，但是不要让开发者从自己的笔记本上读故事列表。笔记本总是从某些方面吸引开发人员的注意力，因此使得他们偏离会议的目标：得到有价值的估算。

必要的参与

这个建议非常重要。理论上说，除团队之外的开发人员都不能参与估算会议。也就是说参与会议的每个程序员都有可能要去开发被估算的故事。如果一个开发人员不 喜欢估算某个故事，那我就不希望他们开发这个故事。当然，凡事有例外。对于新成员来说，我会给他们一周的时间来适应，之后再参与估算会议。不过，一般来 说，拒绝参加估算会议的开发人员应该说明：有什么样更严重的问题等着他解决。

过时的估算

团队会改变，项目会变化，天有不测风云。不管是什么原因，估算都有可能过时。过时的估算毫无用处。要跟上过时估算，开发团队会有压力，而业务人员根 据之前了解的进度，希望故事可以及时完成。估算过时与否并不重要，重要之处在于估算不再可行了，由之产生的计划也不再可靠。我参加过的项目中，所有的估算 在 12-24周内都会过时。承认估算过时，而不要用不准确的信息安排计划。因此，我建议重新过一遍已经过了12周的故事估算。虽然这些估算可能没有问题，但 是开发人员有机会提供新的信息，这对于整个业务来说肯定有所裨益。

小恩小惠

这个建议最容易做到了。为估算会议购买各种好吃的零食。科学证明：甜食会让人产生幸福感，而幸福感会带来协作。想让估算会议按照既有方向进行，这是 最简单、最便宜的方式。不过要注意：好吃是关键。如果拿出来的零食在团队房间中已经存在，那就索然无味了。在最近参与的项目中，一想起来要开会了，我就会 去面包店买刚出炉的什锦饼干。

感谢

我想特别感谢：Brent Cryder, Dennis Byrne, Fred George, Joe Zenevitch, Mike Ward, Sean Dora。他们帮我把这些想法固定下来而且不断改进，跟别人一样，我也肯定遗漏了一些做出贡献的人，请原谅我的疏漏。

关于作者

Jay Fields在ThoughtWorks工作，负责软件开发和相关的顾问工作。他热衷于发现和改进创新的解决方案。最近，他的主要精力放在领域特定语言 （DSL）之上，而且已经交付了很多应用，使得领域专家可以顺利地编写业务逻辑。对于开发人员通过软件测试提升软件设计的成熟度，他也很感兴趣。

阅读英文原文 ：User Story Estimation Techniques