本文是敏捷宣言签署人，极限编程的创造者之一 Ron Jeffries发表的对于故事点乱用的一些看法，部分观点有些理想化，但是值得借鉴的观点也是不少的，大家可以参考。
我想说的是，可能是我发明了故事点，如果真是这样，我现在很抱歉，我想谈一下现在我对故事点的一些看法，肯定会有人对我的看法感兴趣吧。
"故事"当然是极限编程（XP）的主意，不是Scrum。不知为什么，Scrum的实践者采纳了这个想法，Scrum官方文档提出了“Backlog Item”，但是将Backlog Item看作用户故事还是成为了Scrum实践中的通用做法。
在一定程度上说他们的选择是对的。我在其它地方写过关于如何使用“故事”的文章。今天我们将主要聊聊“故事点”。
在XP中，故事最初估算的都是时间：完成故事所需花费的时间。我们快速的进行我们称为“理想天”的估算：如果让你一个人独自完成需要多长时间（假设和你结对的 人不知道跑哪儿去了）。，然后将估算得到的理想天乘以一个因子得到实际需要的天数，这个因子我们一般取3，也就是3个实际天完成1个理想天的工作。
但是我们在谈论过程中经常会省略掉“理想”两个字，经常直接说“天”，结果就是我们的利益相关者经常困惑为什么一天的工作需要三天才能完成，甚至说我们为什么不能用三周完成五十“天”的工作。
我记得是因为这样，我们开始将“理想天”改称为“点”。因此如果我们估算一个故事为3点，则意味着需要9天来完成该故事。并且我们只是用故事点来判断需要将多少工作纳入到迭代内，因此如果我们说这个迭代完成20点也不会有人真的出来反对了。
我好像也建议过改一个名字，下面是一些我在回答我的同事Simon问题时引起的一些想法，Simon的问题是：
你真的为提出这个概念而后悔，还是仅仅因为他们在使用过程中未被正确理解和使用而感到遗憾?
我的回复是
- 我当然对他们的滥用感到遗憾
- 我认为使用它来预测“我们什么时候能完成”只是个下下策。
- 我认为使用它来跟踪估算情况与实际情况的差异只是无意义的浪费。
- 我认为对比不同团队的估算准确性和速率是有害的。
让我们再深入的讨论一下这个问题
一些敏捷方法以简化计划过程的名义设置一个跨团队的“统一的故事点”作为基准，表面上看起来很合理，实际却很容易陷入对团队比较的陷阱中去了，而且大多数情况下，企业经常这么做。
比较
首先就算是看起来一样的两个团队也会有自己的技术特点及环境特点，如果面对两个看起来一样的故事，一个团队给出2个点的估算，另一个团队给出6个点的估算，那不是很有趣吗，能代表他们哪个团队错了吗？这肯定不是用来比较团队的有效方法。
遇到这种情况时我们需要去关注它，首先判断他们的情况是否真的如看上去那样相似的，然后探讨一下估算较高的团队是否存在困难，是否需要我们可以提供的某种帮助。这样就会很好。如果我们简单的基于这个信息就得到显式或隐式的结论：“速度较慢”的团队较差或者已经陷入某种困境，那将是非常糟糕的。不幸的是现在这种情况十分普遍。
我发现当两个团队在同时进行开发时，对于很多管理者来说，将他们放到一起进行对比有一种让人难以抗拒的诱惑。在情况允许的条件下，这种诱惑会让我想放弃故事点的概念甚至干脆不再估算故事。
跟踪
对很多管理者而言，估算的结果往往直接对应到实际情况去，他们认为应该将估算值与实际值进行比较，确保估算值与实际值相符，如果不是这样，那就意味着人们应该去学习进行更准确的估算。
而对我来说，“真敏捷”最重要的是选择接下来要做的事儿，并迅速将它们做好。问题的关键是找到最有价值的事情并迅速完成，这意味着需要选择一部分高价值的事情，然后快速迭代 ，故事估算在这里没有任何帮助。
因此，如果估算的存在导致管理者将视线从价值上移开，转而关注如何改进估算结果，这时需要让他们的关注点回到我们的中心目的上：快速交付真正的价值。
如果遇到这些情况会让我想避免用故事点或者时间来进行估算。
压力
之所以管理者如此关注“估算”与“实际”情况是因为他们想得到“更多”的压力。即使很多团队已经完成了工作，对管理者来说仍然会觉得不够，他们还想要更多。
传递价值的方法不是越多越好，而是要频繁交付一些有价值的小成果，如果我们不评估故事，而是将它们分割的“足够小”，那么我们就可以稳定持续的交付价值。
关注于通过交付更多功能作为交付价值的手段的时候，会带来越来越多的压力，从而不可避免的导致各种不良的效果：团队会努力提高速度，并且会牺牲质量和忽略测试。很快就会产生越来越多的缺陷，团队由于糟糕的代码质量和缺陷而迅速降低交付速度，事情变得越来越糟，压力越来越大，最终变成一种灾难竞赛。
由于估算牵连出了很多不当的压力，因此我希望避免使用它。
更激进一些：我会宁愿避免迭代和召开Sprint计划会，我们不会只为了填满接下来几周的时间而选择工作，我们会列出一些接下来要做的最重要的事儿并努力完成。
预测完成
通常做法是列出要做的基本功能列表，考虑一会儿，然后决定产品下一个版本的功能范围，当然接下来一个问题肯定是“什么时候完成？”。
答案是没人知道。我们可以做更多工作来提高我们对这个问题的认知，某些领域在某些时候这是值得做的，例如当有大合同等待竞标时。但是当我们为内部或外部客户开发解决方案时，我们最好能频繁的交付可用的价值，不要等到不知道什么时候发布的那个大的“惊喜”版本。
最好的办法是选择一个版本发布的截止日期，并在该版本内选择尽可能多的“好东西”。而估算故事点甚至是估算时间都会妨碍这个过程，如果有可能，我的选择是尽量避免做这些无意义的事情。
分割故事
所以问题来了，如果我们不想估算故事，我们要怎么做呢？我的答案是分割故事，将较大的故事分成较小的故事，每个故事尽可能地具有较高的价值，但是完成工作所需的时间很少，理想的是少于一天，可能只有几个小时。
现在，我不在乎与您争论分割故事时是否必须要进行某种估算，因为如果团队只是在自己的大脑里完成了估算，不论是估算的故事点还是时间，那都将不会带来上面提到的各种问题。当然我们需要能够区分“可能足够小”与“可能不够小”，这与区分“一天”和“三天”并不太一样。
对此，我有一个窍门，是我从尼尔·基里克那里学到的：将故事分割直到只需要进行一次验收测试的时候就可以了，这个只需要稍加练习，就可以掌握 。
预测未来
但是，是不是肯定会有很多合理的情况下需要知道一个产品需要多久才能发布？好吧，这时候其实根本无需您把需求拆分到故事的级别来估算，这样反而会造成大量的浪费。
当然，如果必须这样做，请继续您的做法就好了。无论我做什么或关于应该做什么的理论，都只是我个人的想法。最后，您必须尽一切努力来使自己在所处状况中取得成功。但是我认为应该有一些更好的办法。
- 首先，考虑下一个版本的一个或几个重要功能。讨论他们解决的问题是什么，以及哪些软件可以帮助解决这些问题。讨论可能会有所帮助的最简单的功能。我们不必解决所有问题：通常只要我们能提供一部分功能，就足以使事情顺利进行。
- 其次，考虑一个截止日期，这样您便可以在那时获得一组最好的功能集合，设定截止日期并开始工作。
- 第三，将重要功能分割，然后去完成他们，您应该能够轻松地将它们缩短到一天或更短的时间。仅在接下来的最重要的部分工作，不要试图一次照顾到所有细节。您应该进入这样一种思维模式：假设如果我们只开发这一个小功能，客户（Jack）就可以使用它。 然后，完成这个功能的开发，让客户Jack尝试一下。我们希望尽可能快地迈向持续交付价值。
我们希望使所做工作的价值可见，以使我们的产品负责人和其他利益相关者迫不及待地想要实现目标。然后……无论是否做故事估算，我们都在做对的事情。
总结
好吧，如果我确实创造了故事要点，那么现在的我可能会有些遗憾，但不是很抱歉。我确实认为它经常被滥用，如果我们完全不使用故事估算就可以避免很多陷阱。如果它不能真的为您的团队或公司提供巨大的价值，我建议您以浪费为理由放弃它们。另一方面，如果您只是爱他们，那就继续吧！
更多文章请关注 @敏捷新视界
