故事点的秘密

全文923字，阅读大约需要3分钟！

亲，故事点，你知道几点啊？

故事点和功能数目没啥对应关系哈！

不要以为一个功能就是一个故事点！

故事点是用来评估工作量/规模的！

你应该不会以为光年是时间单位吧！一个道理呦！

故事点是相对估算哈！

我们不会故意把故事点对应到小时或者人天哈，虽然最后它必然会和小时或人天成正比。

相对估算有啥好处？

如果用理想人天估算，一个故事，有经验的人说需要1天，没有经验的人说需要3天，那就纠结了。

但是不管有没有经验，一个故事是另一个故事的几倍，两个人的答案应该是大体接近的吧。

不同迭代故事点的基准要相同哈！

我们要看团队每个迭代能够完成多少故事点，也叫作团队的“速率”（Velocity），即团队的能力。如果在不同的迭代中，使用不同的故事点基准，那就没有意义了！

不用过于纠结一个故事的故事点！

我说的不是不纠结，而是不要过于纠结哈！

为啥要使用改良的斐波那契序列啊？1,2,3,5,8,13,20,40....... 怎么没有4和6呢？就是不让你纠结于5和6的区别，3和4的区别，跨度大一些！

本来估算就是估算嘛，你觉得4准确，你真的觉得4就那么准确吗？

一个故事在本迭代差一点儿就完成了，那么这个故事在本迭代所得的故事点为0！

故事只有没完成和完成两种状态，没有部分完成的状态，千万别把这个故事的故事点乘以一个百分比来计算。

如果这个故事在下个迭代能够完成，那么这个故事的全部故事点都要算作下个迭代完成的。（虽然有点儿虐心）

为了防止以后虐心，在迭代回顾会中好好总结一下：如果因为并行的故事太多导致好几个故事都没有完成，那么下个迭代就逐个击破；如果因为计划的工作太多实在完不成，那就下个迭代计划的合理一些。我相信你总是有办法的！

当然，如果你能够把没有完成的这个故事拆分成2个相对独立的子故事，一个完成了，一个没有完成，这个时候完成的子故事对应的故事点数可以留在本迭代。

故事点主要用处就是团队速率！团队速率何用？

#1 通过观察每个迭代的团队速率，能够看到团队效率是否有提升，能够从宏观上看到一些问题，引发我们去做更进一步的分析。

#2 使用团队速率可以帮助进行发布计划，即预测做完一堆特性需要多长时间，从而得出大概的发布日期以及成本估算。

故事点的估算可以用计划扑克哈！

计划扑克是宽带Delphi的一种应用，宽带Delphi是啥？问度娘啊！

这是一种防止大家在评估故事点的时候受人干扰的一种背对背的方法，并且通过多轮投票和解释达成一致的方法。