敏捷项目估算：什么是故事？什么是点数？

引言

当你要雇一位漆工来装饰你的房子，或者一位修理工来修你的车时，你会要他们先给个估算，对吗？你需要知道大概会花多少钱，需要多长时间。这是常识。

然而经验告诉我们什么？初始的估算和最终的账单有多大差距？很有可能漆工会发现有松动的石膏需要铲除，墙面需要修补和重新粉刷；修理工一定会发现要让你车子重新上路还有些其它的问题要解决。在 1951 年的《纽约客》杂志中有这样一幅漫画，Syd Hoff 画了一个修理工对他的客户说：

“当然，那不过只是个估算，实际的花费一定会更多”

如果漆工或修理工告诉我们的这些问题还不是非常紧迫，我们可以选择暂时不处理…… 然而，通常的情况是，我们会觉得不得不修复那些额外的问题。谁会想住在一个可能墙面受潮的房子里，或者开着一辆有可能方向盘失灵的车呢？

那我们怎么解决这样的问题呢？常见的做法就是我们坚持要工人给一个全面的、确定最终价格的估算，也就是通常我们叫的“报价单”，这样工人就会花更多心思用更长的时间来进行更准确的估算。然而现实中，无论他们如何用心努力，终究还是无法预知到那些意想不到的问题。

在项目中，我们面临同样的问题

传统上，项目经理往往会致力于创建很详细的估算，这个估算从财务的角度要经得起推敲。当然这样的估算是基于能够预见的情况再加上针对“已知的未知因素”所设的应急预算…… 然而就像 Donald Rumsfeld 的名言所说“有一些我们未知的未知因素——有些事情我们根本不知道我们不知道”。就像上面那些商人，我们永远无法预知那些意想不到的情况。

我们花越长的时间来创建详细的估算，麻烦却越多。我们可以把详细的估算看作是一个绑定报价，一个不同于真正交付价值的目标，它使得我们的注意力都放到能在协议的日期和成本内交付一些东西——任何东西，无论它的价值高低。

在每次实施后的回顾评审中，初始估算和实际之间的差距总是让我们备受打击，然后告诉我们自己下次再努力些。爱因斯坦曾经说过，所谓神经错乱就是“一遍又一遍地做同样的事情，却期望得到不同的结果”。因此事情不应该这样，一定有其它更好的方法。

敏捷项目显然就不是这样？我们何不就从一个大概的需求范围开始，然后在做的过程中逐渐理清细节？嗯，对，但也不全对。在敏捷项目中我们不会去创建详细的估算来束缚自己，但是对将要进行的工作量的大小有一个认识还是很重要的，这就是为什么……

为什么我们需要估算

忘掉那些传统的估算，那些漂亮的精心制作的甘特图，那些图表迫使我们的注意力都放在要进行的任务上，而不是要交付的成果。在项目中有三种活动需要我们进行一些粗略的估算。

1. 当我们在考虑一个新提议项目的合理性时，我们需要提前知道大概的成本，这样才能决定是否值得投入。
2. 当我们正在将新的或改进的产品推向市场时，我们需要知道那些重要的特性大概什么时候可以发布，这样我们才能安排相关的活动。
3. 当我们在为工作排优先级时，产品负责人需要知道每个故事（或待办清单项）的成本，而团队需要知道每个故事的价值。

有件事很有意思，只要整个团队都一起参与进来共同协作，估算本身也可以变成一种很有意义的活动。它有助于团队增进理解，并保证团队每个人都对要交付的需求范围和价值达成共识。

然而对“估算”这个词的传统理解可能会让我们偏离这个方向。

使用“大小”而不是“估算”

为了避免让人误会我们讨论的是对成本和时间的估算，当我们评估一个故事的复杂程度时，有些人喜欢用“大小”而不是“估算”来描述。在90 年代当我第一次使用Scrum 和XP 时——那时它们都还没有被称为敏捷实践——我们是使用T-shirt 尺寸来评估故事的大小（S，M，L，和XL）。

现在我们使用故事点数——一种评估故事之间相对大小的方法——因此我们先找到可能最简单的故事，将它的点数设为1 点，接下来用其他的故事与它进行比较，如果另一个故事比这个更复杂，那个故事可能就是3 点。

让评估变得更有趣的是，我们不采用简单连续的数列，比如1，2，3，4，5 等——而是采用一种近似菲波拉契数列的形式，像1，2，3，5，8，13 等（就如《达芬奇密码》里面看到的）。这样当数字越大相邻数之间的间隔也越大，使得我们更容易区分哪个故事更小哪个更大。

尽管这不是一种精确的科学，但对上面提到的三种需要估算的情况这种方法已经足够好了。像John Maynard Keynes 所说，“粗略的正确好过精确的错误”。这也意味着，我们仍然需要将故事点数转换成粗略的时间和成本估算。

另一个主要用于敏捷项目的实践是建立“完成标准”，就是对一个故事要能够标注为完成并可发布所需要满足的所有条件进行全面的理解，包括各种项目，比如用户文档、翻译、广告等等。

假如我们有清晰的完成标准，就可以拿几个样例故事来计算所需要的工作量。基于这种计算我们就能为投资决策进行粗略的成本估算，为版本计划进行粗略的时间估算，让我们对故事有更充分的认识以便能协助产品负责人进行故事优先级的设置。

然而有些人仍然认为即使以故事的方式进行估算也会让我们从真正的价值交付上分心。针对这一点，有一个围绕着#NoEstimates 的讨论。

什么是#NoEstimates 讨论

如果你在Twitter 上关注了任何一位敏捷方面有影响力的人，你可能已经注意到他们有些人参与了#NoEstimates 标签的讨论。看起来这是要我们完全停止进行估算，其实它是要我们不再进行故事点数的评估，而是立即开始开发。

这个讨论自从出现后已经有了一个迅速发展的势头，因为那些在大项目中工作的人他们感觉无论是用故事点数进行评估还是仅仅统计故事的个数，团队产量的跟踪结果基本是相同的。

一定程度上这可能是因为那些有经验的交付团队每个迭代会将故事实时地（Just-in-time）以一致的标准拆分成更小的故事——这样的拆分使得团队每个迭代能产出更多潜在可交付的增量——无论项目在迭代里是采用的非常小的故事，还是适度大一些的故事，最终每个迭代的产能报告看上去都差不多。

#NoEstimates 这种方式使得故事的优先级设置更简单了，使得交付团队能够更快地开始工作。然而可怜的产品负责人和项目投资方他们仍然需要知道项目大概要花费多少成本，需要多长时间。好消息是我们还可以基于故事个数的统计来进行粗略的估算，只要项目能够建立起足够有效的度量指标来让这样的估算可行。

对于任何刚开始敏捷之旅的新团队来说，无论如何我都强烈建议你们采用故事点数进行估算，直到你具有了和那些团队一样的丰富经验和成熟度。

结论

作为总结，引用General Dwight D. Eisenhower 的一句名言：“在准备开始一个项目时，我总是发现估算的数字是没有用的，但估算的过程却必不可少”。我们仍然需要进行估算，不管这样的活动叫什么名字，不管在这样的活动中我们如何进行计算。

我要感谢Esther Derby（估算成为目标），Mike Cohn（为发布计划和优先级设置进行估算），Ahmed Sidky（全员估算），Martin Fowler（故事点数），Ian Mitchell（完成标准），Vasco Duarte（故事个数vs. 故事点数），Stephen Forte（度量与估算），Neil Killick（有经验的团队定义更小的故事），和其他很多人，感谢他们在这个话题上给我的分享——以及我上面对他们各自论文的链接引用。

关于作者

David Morris 是一位独立业务敏捷性实践者、教练和讲师；通过他的公司 Sophorum 为新西兰各地的客户提供业务分析、团队领导，教练和培训服务。他有近 30 年的项目交付经验，在这 30 年中他以团队成员，团队领导，以及自己企业的负责人身份参与了各种类型的项目，比如战略、经营和技术类的项目，并在这些项目中运用了结构化的、迭代的和敏捷的方法。

David 通过了 CBAP、ICAgile Certified Practitioner、Certified ScrumMaster 和 IT Certified Professional 的认证。他主持研究小组、专业开发讲座和训练营；帮助 Agile Auckland 和 IIBA NZ 组织活动；在欧洲和澳大利亚的的各种大会和活动上进行演讲；并参与了多本书的创作（包括“Agile Extension to the BA Body of Knowledge”）；他也是一位活跃的博主，tweeter 和维基百科编辑。

查看英文原文： Estimating on agile projects: what’s the story, what’s the point?

译者信息：姚安峰，微博：霜木

感谢侯伯薇对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。