当前位置：首页 > 敏捷开发 > 正文

故事点的秘密

2018-11-26 来源：杰克船长与精益敏捷徐东伟

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

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

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

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

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

故事点是相对估算哈！

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

相对估算有啥好处？

如果用理想人天估算，一个故事，有经验的人说需要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是啥？问度娘啊！

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

大家还有补充的吗？欢迎留言交流哈！

关于作者：

徐东伟，敏捷咨询顾问，很享受读万卷书，行万里路，阅人无数的生活！

2008年开始践行敏捷，对敏捷、精益、SAFe、DevOps着迷！希望能够为中国企业的发展贡献自己的微薄之力，同时交到好多好多志同道合的小伙伴！

分享到:

免责声明：
　　1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
　　2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！

上一篇：
杀不死你的让你更坚强，反脆弱型研发组织构建
下一篇：
第12届敏捷行业年度报告

延伸阅读：

more 会议活动

more 公开课

more PMO

微信扫一扫关注

故事点的秘密

延伸阅读：

会议活动

公开课

PMO

IT项目管理界官方微信

PMO大会官方微信