为什么每次 sprint 结束，总有一半任务完不成？

开发团队里有个没人说破的真相：用"小时"估算工时，人人都会低估。资深工程师想显得高效，新人不想暴露速度慢，产品经理在场时团队集体保守。然后 sprint 结束，任务 rollover，所有人假装惊讶。

打开网易新闻 查看精彩图片

我见过这种模式在不同团队、不同技术栈反复上演。问题不是我们不擅长估时间——而是"小时"本身就是错误的单位。

复杂度与时间完全是两个独立维度，却被大多数团队混为一谈。翻译一段英文到西班牙文很简单，几乎没复杂度；翻译整本《圣经》依然简单——单句认知负荷没变，只是量大。"简单"不等于"快"。反过来，复杂的分布式系统迁移听起来该花几周，但如果平台已有合适工具，可能一个下午就搞定。"复杂"也不等于"慢"。

把二维压缩成一维，结果自然荒谬。

我待过的团队最终采用类斐波那契数列：3、5、8、13。超过 13 不算估算，而是信号——任务该拆分了。

数字本身不重要，重要的是它们代表什么：不确定度、耦合度、影响范围、依赖关系、团队熟悉度……目标不是建立精确量表，而是让团队拥有讨论"难度"的共同语言，且与"耗时"脱钩。

故事点比小时更好的原因，说出来可能意外：它们绝对精度其实更低，但改变了对话性质。

问"这要花多久？"——对话是个人且防御性的。最懂的人抛数字，其他人点头。实际干活的新人默默恐慌，知道做不到却不敢反驳，怕显得慢。

问"这有多复杂？"——对话变成集体性的。为什么是 5 不是 3？有哪些模块？哪里可能出错？新人看资深工程师推演问题而学习，资深者偶尔发现自以为"trivial"的事其实并不简单。团队在动手前，真正理解了要构建的东西。