故事点就是开发者的占星术：敏捷估算的集体幻觉

一场 35 分钟的估算闹剧

一位工程师回忆起这样一个场景：在冲刺规划会上，四名工程师花了整整 35 分钟争论一张工单到底该打 5 分还是 8 分。而这张工单的内容是——给一个表单字段加一个提示框。一行 JSX，一个 CSS 类，实际工作量大概 20 分钟。

但团队还是要郑重其事地请出"神圣的斐波那契数列"。有人说"这不是时间问题，是复杂度问题"，又有人补充"但也包含工作量"，产品经理在一旁频频点头，仿佛大家正在讨论天体物理学。最终他们定在了 5 分，感觉自己很有生产力，实际上一事无成。

作者把这种现象称为"估算剧场"（Estimation Theatre）——一场人人投入、却毫无产出的集体表演。

故事点如何从工具变成信仰

故事点（Story Points）最初的使命，是把团队从糟糕的时间估算中解救出来。它的逻辑听起来很美好：不预测具体耗时，而是用相对数值衡量"复杂度"与"工作量"。然而作者尖锐地指出，故事点最终没有解决问题，反而制造了一种新的宗教。

整个流程是这样的：我们给尚未真正理解的工作分配数字，把团队成员的数字取平均，画成图表，然后假装这张图表能预测未来。但它预测不了。

作者把它比作占星术。星座用任意的符号让你觉得混乱的人生是可控的；故事点用任意的数字让你觉得混乱的软件开发是可控的。两者都需要信仰，都忽略具体情境，也都会在真实世界发生意外的那一刻瞬间崩塌——一个线上 bug、一个生病的孩子，或是一个自上古版本就没更新过的依赖。

故事点的概念源于极限编程（XP）和早期Scrum实践，由Ron Jeffries等人在1990年代末推广。其核心思想是利用人类大脑在相对比较上比绝对估算更准确的认知特性——我们很难说出"这件事需要多少小时"，但相对容易判断"这件事比那件事难两倍"。斐波那契数列（1、2、3、5、8、13…）被引入估算，是因为数字间距越来越大，恰好反映了高复杂度任务的不确定性也越来越高这一现实。

然而，这套设计前提在实践中悄然失效。故事点本应是相对的、团队内部的参照系，但跨团队比较、跨季度趋势分析，乃至绩效管理，把它硬生生拽向了"客观数字"的角色。当一个本质上主观的相对量被当作绝对量使用，所有基于它的推断都会系统性地失真。

当数字本身成了目的

文章中最具批判性的一点，是指出故事点如何从"规划工具"异化为"绩效指标"。

一旦速度（Velocity）不再服务于规划，而是被用来衡量团队表现，整个系统就开始腐化：管理者质问为什么速度下降了，团队为了自保开始虚报估算。于是 2 分变成 5 分，5 分变成 8 分，最后谁也不知道任何数字到底意味着什么。

作者给出一句很犀利的总结：故事点唯一能可靠衡量的，就是一个团队能围绕故事点争论多久。

他还列举了几种常见的扭曲行为：

• 团队在估算一张工单上花的时间，比完成它还多；
• 工程师故意"压沙袋"（sandbagging），刻意低报产能，好在之后看起来像英雄；
• 速度图表被拿进绩效评估。

"这不是估算，"作者写道，"这是带着 Jira 许可证的恐惧。"

不确定性不是 bug，而是工作本身

这篇文章的核心观点在于重新定义估算的本质：不确定性不是需要被消灭的缺陷，它就是软件开发工作的常态。我们在黑暗中构建软件，边做边学，再多的"规划扑克"（Planning Poker）也改变不了这个事实。

这个判断对任何经历过敏捷流程的团队都值得深思。估算之所以永远不准，并非方法不够精细，而是因为预测的对象本身就充满了未知。试图用更复杂的仪式去对抗不确定性，往往只是增加了表演成分，而没有增加确定性。

真正有效的替代方案

抛开批判，作者给出了具体的替代路径，核心是用"已经发生的事实"代替"对未来的猜测"：

把工作切小，先交付

与其纠结一张大工单值多少分，不如把工作拆得足够小，然后真正交付一些东西出来。

测量周期时间（Cycle Time）

记录每项工作从"开始"到"完成"所花的实际时间，用这个真实数据建立对团队节奏的认知。

使用吞吐量（Throughput）与蒙特卡洛模拟

统计单位时间内实际完成的工作量；如果想做更精细的预测，可以运行蒙特卡洛模拟。关键在于：这些方法基于历史实绩，而非一屋子疲惫的开发者凭感觉报数字。

作者的建议直截了当：想做预测？看你上个月实际完成了什么——不是估算了多少，而是真正完成了多少。那才是你的数据，其余的都是表演。

**周期时间（Cycle Time）**是精益软件开发（Lean Software Development）中的核心度量指标，指一项工作从正式开始到最终交付所经历的实际时长，不含等待开始的排队时间。与故事点不同，周期时间是事后测量的客观数据，不依赖任何人的主观判断。

蒙特卡洛模拟则是一种基于概率的预测技术：将团队历史上的周期时间分布和吞吐量数据作为输入，通过大量随机抽样（通常数千次）模拟未来的可能结果，输出一个概率区间，例如"在10周内完成20项工作的概率为85%"。这种方式不承诺一个精确的截止日期，而是诚实地呈现不确定性的范围，反而比一个看似精确的故事点速度预测更具参考价值。两者结合，是看板（Kanban）体系中常见的数据驱动交付预测方法。

把故事点还原成它本来的样子

文章结尾并没有彻底否定故事点，而是提出了一种更务实的态度。如果你喜欢故事点，可以继续用，但要诚实地称呼它：它是一种谈论不确定性的共同语言，而不是承诺、合同或预言。

危险的转折点在于——当你把一个"5 分"当成一项承诺时，你就不再是在估算工作，而是在协商焦虑。

正如作者那句收尾所言：没有人靠读星座来交付软件。这篇文章的价值，不在于提供一套全新的工具，而在于戳破了许多敏捷团队心照不宣的集体幻觉，提醒我们回到最朴素的工程常识：用真实的交付数据说话。