在敏捷项目管理中，我们常会在对于用户故事进行评审的时候，提到一个词，那就是故事估点。
这篇文章我们就聊一聊，敏捷开发中的故事点是什么？以及如何进行故事估点。
先说概念
故事点，是敏捷项目管理和开发中的一种抽象的度量单位，用于估计实现一个或多个用户故事的复杂度，它是对度量的一种描述方式。一个故事点就是一个数字，透过这个数字告诉整个团队用户故事的复杂度。
复杂度包括功能的难易程度、风险和需要多长时间。
即故事点可以是一个理想的工作日：没有任何干扰，没有会议，没有电子邮件，有没有电话以及其他干扰等；团队可以把故事点作为用户故事复杂度的测量。
以团队估算
故事估算应该是由整个团队集体完成。 在敏捷研发管理中，我们会发现有些故事可能包含了多个任务，任务估算也就属于执行这个任务的团队成员。
之所以故事估算需要全体成员完成，有主要原因：
第一，在故事估算前，还不确定团队中是谁负责完成这个故事，所以应该把故事分配给整个团队，而不是某个人。 第二，团队决定的估算可能比个人估算更有用。 第三，通过估点过程的细节澄清，使团队成员对故事理解达成一致。
估算
我们先明确一下估算的单位。
对用户故事大小进行估算时并没有标准单位，比较常用的两个单位是故事点和理想天数，两者之间并不存在孰优孰劣的区别。
故事点是用来衡量用户故事大小、复杂度以及数量的单位，也就是说，它是一个基准，可以用来估算其他用户故事。
故事点
故事点用于衡量用户故事的大小和数量。故事点受很多因素的影响，比如复杂度和实际大小。故事不一定是看起来大就大。
故事点结合复杂性和有形大小等因素，产生一个相对比较值，其目标是比较各个故事。
比如：如果创建一个记录卡是2个故事点，那么搜索一个记录卡是8个故事点。这意味着搜索故事是创建故事的4倍大小，这样，以此类推就可以比较出其他用户故事的大小。
理想天
另一个估算用户故事的方法是使用理想天。
理想天是很常见的估算单位，它代表完成一个故事需要多少个工作日或人天。但理想天和自然天不一样。在理想情况下，我们可能会完成某项工作，可在实际工作中，可能被各种各样的事情打扰，并不能全身心投入到该工作中，导致完成它所需的时间可能会超出许多。
所以，影响理想时间的一个重要因素是可能会引发误解。
讲个通俗故事：你在周二下午的时候，向研发同事展示了一个故事，问他，这个故事有多大，他说，两天。你说，可以，那你在周三下午早些时候可以做完。他可能连连摆手说，no，no，bro，我要在今天下午和明天做完现在手里的工作，然后，我可能得周四才开始做，但因为我并没有整天都在做这个需求，所以我可能下周一的某个时间做完。你说，你跟我说这是个两天的故事，所以应该周四做完。他说，我说的是两个理想天，不是自然天，请不要把我的理想天直接对应到日历上，不能这么玩。
你看，产品负责人和程序员就是这么打起来的（开个玩笑）。
所以，如果在团队里，大家默认一致理想天作为故事点不会招致误解，理想天可能更好一点，否则最好采用故事点。
估算
在对用户故事进行估算时，所有参与估算的团队成员对该故事进行估算。
假如团队定义一个故事点为一个理想工作日，那么开发人员则想想完成该故事需要多少理想日（故事点）。假如团队定义一个故事点为故事的复杂度，则估算值为开发人员所觉得的故事复杂度。
比如团队成员有五个，其中三个成员对故事估值为3，另外两个，一个估值5，一个估值2。
这时估算值很有可能相差很大，就需要估算值高的和低的成员再解释一下估算依据，如此循环，直到团队对故事估点达成一致。
估点较高的成员可能会说，“要测试这个故事，我们需要创建一个模拟数据库对象，可能需要一天时间，还有，我们不确定我们的标准压缩算法是否能用，可能需要新写一个占用更少内存的算法”。估点较低的成员会说，“我考虑把信息存在一个XML文件中，这样比数据库简单，当然，我没有考虑到更多的数据，可能这是个问题”。
接着，大家对该故事讨论几分钟，重新进行估算，大多数情况，第二轮的估算值就差不多一样了，但是如果没有，就需要重复之前的过程。
这样做的目的是要为故事得到一个统一的估算值，让团队所有人对这个故事点有一个共识，这意味着，不管是谁完成这个用户故事，那么他是认可这个故事点的。
但是，使用这个方法非常耗时，在实践中，可直接由全员同步参与讨论得出一个相对正确的故事点。
使用故事点
一个团队对故事点是不断磨合和调整的。
在一轮迭代结束时，团队计算已完成的总故事点数。
举例来说，假如一个团队在一个2星期的迭代中完成了32个故事点，那么很有可能下轮迭代团队也会完成32个故事点。我们用“团队速率”来代表一个团队在一轮迭代中完成的故事点数。
团队速率如何使用呢？
如果团队将要开始一个新的项目，他们估算了项目所有故事，一共300故事点，于是，在开始第一轮迭代之前，他们计划一个星期完成30点，意味着他们需要10轮迭代完成项目。
第一轮迭代结束后，团队将实际完成的故事点数加起来，他们得到50点，而不是30点，如果他们每轮迭代都完成50点，那么他们一共需要6轮迭代来完成项目。
那他们应该按测量的50点作为速率计划么？
是的，不过需要满足三个条件。
首先，这轮迭代中没有发生异常时间，比如加班，多了程序员等等。
其次，必须采用前后一致的方式进行估算。这样以确保尽量减少迭代速率的起伏。
最后，第一轮迭代的故事必须是独立的。
以上就是全部内容~
如果有任何疑问，欢迎大家留言，一起探讨😊~
