高质量的估算能够帮产品负责人优化效率和冲突。因此，精准估算的重要性毋庸置疑。估算并非易事。对软件开发人员来说，估算堪称是最难的工作之一。估算必须考虑所有能帮助产品负责人做出影响整个团队和业务决策的因素。因此，从开发到高管都为它焦头烂额也不足为奇，但这种做法是错误的。敏捷估算并不是什么性命攸关的大事，就只是估算而已，事实就这么简单。
我们不用要求团队周末加班加点来弥补一项被低估的工作。换句话说，与其事后补救，不如事前看一看有什么方法可以让敏捷估算尽可能变得更精准。
与产品负责人（PO）合作
敏捷开发中，产品负责人 要负责确定 backlog 的优先级次序——即一个按优先级排好序的工作列表，其中包含关于产品所有所需完成的功能和修复的缺陷的简短描述。产品负责人能够从业务中提取需求，但他们不一定了解具体如何实现。因此，精准的估算能让产品负责人对每个工作项目的工作量有新的了解，这对他们评估每个项目的相对优先级能起到一定作用。
开发团队开始估算后，关于需求和用户故事的问题会经常出现。这是一件好事：这些问题可以帮整个团队更加充分的理解工作。对产品负责人来说尤为特别，将工作项拆解为粒度较小的任务，然后通过估算故事点帮助他们确定所有（和可能隐藏的）工作的优先级。而一旦他们得到开发团队的估算后，可能会再重新排列 backlog 中的工作项。
敏捷估算是一项团队工作
敏捷估算的关键在于全员（包括开发人员、设计人员、测试人员、部署人员……等等）参与。团队每个成员都能就产品和需要交付的工作贡献一个用户故事。例如，如果产品管理者想要实现支持新浏览器这一看似简单的功能，开发和 QA 就需要谨慎权衡，因为他们的经验告诉他们这个看似简单的需求背后可能隐藏巨大的困难。
同样的，设计的变更不仅要设计团队的投入，还需要开发和 QA 人员的参与。缺乏全员参与的估算会降低估算质量，也会导致团队士气低迷，因为关键的贡献者会认为自己被排除在外。所有这些因素都会影响最终交付的软件质量。
因此，不要让你的团队成为封闭估算的受害者。封闭状态下的估算只会加速失败。
故事点和小时数
传统的软件开发团队以时间为单位来估算工作量，例如：天、周、月等等。而敏捷团队大多采用故事点为计量单位。故事点的相对规模（工作量）用斐波那契数列如 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100 表示。这听起来似乎有点有违常理，但这种抽象的表述实际上能够促使团队针对工作的难点做出更果断的决策。下面是使用故事点的几点原因：
- 以日期为单位，无法计量那些无法避免的非项目相关的工作，如需要团队成员参与的电子邮件、会议和访谈等。
- 日期可会存在一定的感情因素，而相对估算则可以剔除感情因素。
- 每个团队估算工作的范围略有不同，这意味着团队的速度（以故事点为计量单位）自然也会有所不同。反过来，这样就可以避免出现以速度为争端的团队间的勾心斗角。
- 一旦团队就每个故事点价值的相对工作量达成一致，团队就可以在无争议的情况下实现点数的快速分配。
- 故事点能够激励团队成员以工作难度而非耗费的时间为基础来解决问题。这确保团队成员能专注于价值交付，而不是强调花费了多少时间。
故事点和计划扑克
使用故事点进行估算的团队会用计划扑克的形式来统一团队的估算值。团队从 backlog 中抽取一个工作项，简单地讨论之后，请每个成员在脑海里构思一个估算。然后每个人拿一张卡片，写下自己的估算值，由 scrum master 收齐卡片后展示每位的估算值。如果估算一致，那么讨论结束，如果存在不同的估算值，就花点时间（无需太久——几分钟即可）了解为什么成员给出了不同的估算。记住，估算讨论应该抓大放小、提纲挈领，如果团队过于纠缠细节，则暂停讨论，提升讨论的水平和高度之后再继续。
精准估算讲究效率，无需浪费时间
任何单个任务都不应花费超过 16 小时。（如使用故事点，则可以设置 20 个故事点为上限）。如果单个工作项超过这一工作量，对其进行精准估算会更难。而精准估算对于位于 backlog 顶部的工作项来说尤为重要。如果单个工作项的估算超过了 16 小时（或 20 个故事点）的上限，意味着我们需要将其拆分为更小的工作项并重新进行估算。
对于那些位于 backlog 下方的工作项，可以只进行粗略估算。因为等到团队真正开始要做该工作项时，需求可能已经发生了变化，相应的应用程序肯定会有所变化。因此，先前的估算可能就会不那么准确。所以不要浪费太多时间去估算那些可能会发生变更的工作项。只需要提供粗略的估算，为产品负责人提供一个可以用来确定产品路线图优先级次序的大概数据即可。
借鉴以往估算的经验
回顾会议是团队从已完成的迭代中总结经验教训的机会，当然也包括估算准确性总结。很多敏捷工具可以跟踪故事点，这让团队可以更轻松地反思和调整估算。例如，我们可以尝试提取过去故事点估算值为 8 的 5 个用户故事，讨论每个工作项的工作量是否大致相同。如果存在差异，讨论其背后的原因。然后将讨论得到的经验用于未来的估算。像敏捷的其他实践那样，估算也是一项熟能生巧的实践。因此团队肯定会越做越好。
翻译 / 校对：Worktile
文章来源：Worktile 敏捷博客
欢迎访问交流更多关于技术及协作的问题。
文章转载请注明出处。