为什么敏捷估算是戏剧（以及该怎么做）

Source: Dev.to

请提供您想要翻译的具体文本内容（文章正文），我将按照要求把它翻译成简体中文并保留原有的格式、Markdown 语法以及技术术语。谢谢！

引言

每周三下午2点，十二位开发者走进会议室。接下来的九十分钟，他们举着写有斐波那契数的卡片，争论一个功能是5还是8，并假装能够预测在每天都在变化的系统中工作需要多长时间。
这就是你们现代的敏捷估算仪式。这是一场戏剧。每个人都心知肚明。

估算的问题

肮脏的秘密：所有的 story points、所有的校准培训、所有在 planning poker 中花费的时间——这些都不能让你的估算更准确。

估算成本

一个八人团队的典型两周 sprint：

• 90 分钟的 backlog refinement
• 2 小时的 sprint planning（包括估算）
• 30 分钟的重新估算遗留工作
• 每个 story 15 分钟的澄清

这相当于 每位开发者每个 sprint 4–6 小时。一年下来，八人团队共计 1,664 – 2,496 小时——相当于一名全职工程师只做估算工作的时间。

为什么估算仍然不准确

即使团队严格追踪 velocity 并进行精细的校准练习，估算仍然极度不准确。这不是纪律问题；对复杂工作进行准确的软件估算在数学上是不可实现的。

你在一个存在以下不确定性的系统中进行估算：

• 对需求的信息不完整
• 技术依赖未知
• 代码库持续变化
• 集成点会以新颖的方式失效
• 只有在组件交互时才会出现的涌现复杂性

不同的方法

对估算失败的成熟回应不是“更好的估算”。而是要承认，对于复杂的知识工作，估算只会提供虚假的精确度。

将工作拆分为可小规模部署的单元

不要： “重建通知系统 – 40 点”

要：

• “当用户的帖子收到第一条评论时发送邮件 – 直接上线”
• “添加邮件偏好切换开关 – 直接上线”
• “支持摘要模式而非即时模式 – 直接上线”

每个单元都直接上线到生产环境，交付价值，并且只需几天时间，而不是数周。

衡量真正重要的指标

停止衡量已交付的故事点。开始衡量：

• 循环时间（Cycle time）： 从开始工作到上线生产需要多长时间？
• 吞吐量（Throughput）： 每周完成了多少项工作？
• 在制品（Work in progress, WIP）： 同时进行的工作项有多少？

这些度量是实际数据，而不是主观的点数。

管理更大的计划

转换问题。不要问“这个功能需要多长时间？”而是问 “我们在 4 weeks内能交付什么？”

• 为工作设定时间盒。
• 定义问题和成功指标。
• 迭代工作，在时间盒结束前持续交付逐步改进的解决方案。

与管理层的坦诚对话

管理层想要确定性。估算戏剧给他们一种没有实质的幻象。当你放弃估算时，你被迫进行更艰难、更诚实的对话：

“我们不能保证它在六月前发布。我们可以保证在它发布之前我们不会做其他事，并且我们会每周部署增量，让您看到进展。”

这些对话让人感到不适，因为它们揭示了软件开发中不可简化的不确定性，但它们比假装故事点能解决预测问题更诚实，也更尊重每个人的时间。

实验提案

你不需要获得许可就可以停止在估算仪式上浪费时间。

1. 提出一个实验：一个不进行估算的冲刺——仅使用优先级顺序和周期时间。
2. 跟踪会发生什么。
3. 衡量吞吐量、节省的时间以及利益相关者的满意度。

预测： 吞吐量保持不变或提升，利益相关者满意度保持不变或提升，开发者满意度肯定提升。你已经消除了形式主义，转而进行实际工作。

结论

停止指派故事。开始交付软件。

完整文章及实用的转型检查清单请访问 AgileLie.com.