再议故事点︱用户故事专栏
2022-12-15
来源：徐东伟敏捷教练 作者：Ron Jeffries
去做。关键的问题是找到最有价值的事情去做，并迅速去做。快速完成这些工作可以归结为完成高价值的小片段，并快速迭代。对故事的成本进行估算对此其实没有多大帮助（如果有的话）。
因此，如果“估算”的存在导致管理层将注意力从价值上移开，转而专注于改进估算，那么他就需要从现在开始关注核心目标，即快速交付真正的价值。
从这个角度来说，估算（无论是以点还是时间为单位）是应该避免的。
03压力
与“估算”/“实际”问题相关的是“管理层想要更多”的自然压力。无论团队完成了多少工作，这都是不够的。还要更多，更多，更多......
交付价值的最佳方式不是要更多、更多、更多，而是要频繁做有价值的小事。如果我们不去估算故事，而是把它们拆分成“足够小”的部分，我们就可以实现价值的平稳流动，随时交付。
对“更多”的关注阻碍了价值的增长。“想要更多工作”的压力持续增加，几乎不可避免地会带来糟糕的结果：团队试图要加快速度，最终在代码质量和测试上偷工减料。他们很快开始交付更多的缺陷，由于修复缺陷的返工增加，速度减慢，而且由于代码质量迅速下降，速度甚至更慢。事情变得越来越糟，压力越来越大，这变成了一场走向灾难的赛跑。
因为估算至少与“施加不适当的压力”有关，所以我宁愿避免估算。
我会更进一步：我宁愿完全避免迭代或Sprint计划。我们不会为填补未来几周的预算而工作：我们会努力列出接下来要做的几件最重要的事情。
04预测完成时间
通常的做法是，列出一个基本功能的清单，思考一段时间，然后就决定把清单中的这些功能定义为产品下一个版本的内容。接着，下一个问题就是“这一切什么时候才能完成？”
答案是没人知道。但是，当我们从事为内部或外部客户开发解决方案的业务时，我们最好经常提供少量的价值，而不是等待一个大发布，因为大发布有可能会等到天荒地老！
最好为下一个版本选择一个发布给客户的截止日期，并在该版本中尽可能多地选择更有价值的东西。在这里，估算（无论是以故事点还是时间为单位）是会碍事的。在我看来，在可能的情况下，最好避免进行估算。
05切片
所以问题来了，如果你不喜欢故事估算，你喜欢什么？嗯，我喜欢故事切片，这是一种将较大的故事切片成较小的故事的做法，每一个故事都尽可能有高的价值，但只需要很少的时间就可以完成，理想情况下不到一天，也许只有几个小时。
现在，我不想和你们争论切片中是否一定要有某种估算。如果你或你的团队在头脑中进行估算，却从未告诉任何人，那么估算的问题（无论是故事点还是时间）都不太可能出现。当然，知道“可能足够小”和“可能不够小”之间的区别并不等于知道“3天”和“1天”之间的区别。
另外，还有一个窍门。我从Neil Killick那里学到了这一点：把故事切成小块，直到它们只需要一个单一的验收测试。只要稍加练习，就能把事情做得很好。
06预测未来
但是……是否有一些合理的需求需要知道产品发布需要多长时间，难道那不需要进行估算吗？嗯，也许吧，但也许不是故事估算。你甚至可能不会把你的需求搞到故事这样级别的颗粒度，如果你这样做了，它们可能太庞大，而且很大程度上这就是浪费。
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
