故事点 到底是什么？
故事点，理想人天，故事个数 有何区别？
团队又要如何选择呢？
针对这些问题，很多实践了多年的敏捷教练也不一定能够回答的清楚。敏捷落地的过程中经常会有人对点数估算觉得困惑和难以理解，所以就更不容易执行到位了。
有人说故事点是规模，也有人说是工作量，还有人说是复杂度，还有人说其实就是理想人天（不是某一个人的人天，而是大家达成相对一致的抽象的人天）。
哪个才是最准确的？
甚至有些教练开始抛弃“晦涩难懂”的故事点，而直接采用理想人天（有些团队实际落地会采用），或者不进行估算而直接采用数故事个数的方式（DevOps中经常采用此方式）。
故事点的定义
来看看敏捷大师们是如何定义的？
Mike Cohn：故事点是一个度量单位，用于表示完成一个产品待办项或者其他任何某项工作所需的所有工作量的估算结果。
Robert C.Martin：故事点是工作量的单位，被估算的不是时间，而是工作量。
让我们来给故事点做个通俗的解释：
故事点就是 工作量或规模 +复杂度因素+风险因素+不确定性因素，采用相对估算法估算出来的一个抽象的综合估值（数字）。
是不是依然感觉晦涩难懂，头有点晕？
让我们换一种表达形式：
故事点数 = 完成故事所需的工作量 + 复杂度/风险/不确定性因素
（类似考试时候的：分数 = 基础分 + 附加分 ）
这就是说我们在做点数估算的时候，首先要对比基准点的故事，进行相对故事工作量/规模大小的估算，然后要额外考虑故事的复杂度因素，风险因素，不确定性因素，并且为这些因素额外加上对应的点数，这样估算出来的点数就更加具有参考价值，也具备了相对准确性（注意：不是绝对准确，也不应该追求绝对准确）。
注意：
1.一个点不代表任何时间长短，所以敏捷团队只有通过迭代实际交付衡量验证，才能知道团队实际产能，才能将速率（一个迭代Sprint交付的点数总和）和排期计划结合起来做规划。
2.团队每个迭代产出的故事点大小，只能团队和自己比较，速率的变化。
3.故事点数衡量的是团队，而非个人。并且不能用于绩效考核，以免产生负面效果，数据失真。
估算数字选取
通常采用 斐波那契数列，有时根据具体情况也可以采用自然数来替代（具体要看故事之间的差别，思考怎样的数字间隔差异更加适合团队具体的情况）。
使用斐波那契数列有着源自自然的优势，斐波那契数列又称为黄金分割数列，大自然的奥秘蕴含其中，随着数字间距的扩大，对于颗粒度较大的需求更加便于我们判断选择哪个数字，隐晦和模糊的数字有其美妙之处 -- “大数定律”，当数量变大时，模糊性就消失了！
估算方法
通常采用: 敏捷扑克估算法
基本过程：
1）选择一个基准故事，点数设为1（团队达成共识，并且之后所有迭代以此故事为基准故事）
2）PO依次介绍故事背景，内容，验收标准 等信息
3）团队成员对故事做各自的点数估算，同时出牌（常用 斐波那契数列：1，2，3，5，8，提供8倍的估算范围）
4）团队成员对牌面数字偏差较大的进行解释估算理由（较大，较小 都要简单阐述理由）
5）然后重新进行第二轮估算（一般情况下，考虑到估算成本和效率，每个故事2轮估算即可，必要时可以进行多轮）
6）直到团队成员达成基本一致（不是绝对一致，最终结果简单协商确定即可）
这样做的好处是估算过程，团队可以充分讨论和沟通，信息得到充分快速的交流，并且避免一言堂或信息披露不足。
这样的方式可以加快风险，障碍，依赖的提前发现，并促进了团队信息交流和达成一致，团队内部信息披露也更加充分。
另外一种更加便捷的方法：用手指，来替代扑克牌进行出牌（过程相同），省去了扑克牌的准备。
这里要注意的核心点是：敏捷估算是 相对估算，所有故事的点数大小，均参考基准故事来进行相对比较。
那么 故事点，理想人天，故事个数 有何区别？团队又要如何选择呢？
下面我们来聊聊这些方法到底有哪些区别，以及分别在什么场景下进行选择，才是最适合我们的方式。
［故事点数]
场景：
经典的敏捷团队，团队氛围友好，跨职能自组织团队。促进团队交流，发挥团队的力量。
优点：
1.通过估算游戏，团队成员对每一个故事进行了充分沟通和讨论，分享了彼此掌握的知识和信息点，提前发现了部分风险和障碍，加强了对故事的认知和理解，达成全方位的需求共识。
2.通过估算游戏，获得了一个团队共同认可的相对准确的数据衡量。
3.所有迭代的基准点对齐后，可以对迭代计划和团队迭代交付速率有了数字量化的依据和衡量。（一个点不代表任何时间长短，所以敏捷团队只有通过迭代实际交付衡量验证，才能知道团队实际产能，才能将速率和排期计划结合起来）
缺点：
1.估算过程需要花费一点时间，但实际执行过程可以有简化提效的空间，抓住核心点是沟通达成理解一致。
2.点数估算比较抽象，新的团队不容易掌握和理解概念。
[理想人天]
场景：
涉及人力成本统计或者人员安排和排期预算等情况下。
优点：
比较好理解和安排计划，理想人天是对人天估算进行了人员抽象，也可以采用敏捷扑克估算法。
缺点：
执行起来，估算者容易和自己的实际工作情况联系，干扰到估算结果。
估算结果很容易被拿来做绩效考核，或者和个人产出挂钩，导致对团队产生负面影响（敏捷团队考核团队而非个人）
[故事个数]
场景：
在DevOps的需求流交付模式下，通常会采用此方法，大量需求，需求颗粒度相对均匀，团队较为成熟，并且企业更加关注宏观需求数量（通常作为一段时期的吞吐量数据被采集使用）。
优点：
快速简单易用，直接数个数，便于统计，省去了估算的成本。
缺点：
1.需求颗粒度不均匀的情况下，导致偏差较大，数据的可信度较低。
2.需要配合严格的需求拆分标准执行，例如规定较为严格的需求颗粒度上限，并且需要立即执行到位，对于大颗粒度的需求缺少过度过程（敏捷需求是渐进明细，允许大颗粒度需求的存在，点数可以有更大的用处），对于较为成熟的团队比较合适，新团队需要适应。
3.增加了较大的前期需求拆分成本，团队缺少执行的过度时间。
了解了以上内容，我的团队又该如何选择呢？
如果你的团队想了解经典的敏捷实践，并且前期需求颗粒度大小不够均匀，需求经常需要讨论，请选择故事点数。
如果你们的需求拆分的很到位，颗粒度比较均匀，可以选择不进行估算，直接数个数。
如果你需要尽快做出计划和预算，或者外包项目需要提前上报人日成本，可以选择理想人日。
当理解了以上概念的深层次含义，你也可以根据实际需要将三种方式进行部分结合，灵活运用。
作为一名敏捷教练和工程效率专家，在经过了多年以上三种实际实践后，我个人最喜欢的方式还是 敏捷点数估算。
需要思考的是，在保持敏捷故事点数原滋原味的优点基础上，将点数估算的落地成本降低，并且基准点做必要的对齐和选择，这样你就可以灵活运用点数获得你想要的效果。
那么你会如何选择呢？
